Upgrade to remove ads
Systems Analysis and Design: Chapter 3 and 4 Notes
Terms in this set (56)
an activity that the system performs, usually in response to a request by a user
Use cases define functional requirements
Analysts decompose the system into a set of use cases (functional decomposition)
Two techniques for Identifying use cases:
1.) User goal technique
2.) Event decomposition technique
Name each use case using Verb-Noun
User Goal Technique
This technique is the most common in industry and is simple and effective.
Identify all of the potential categories of users of the system
Interview and ask them to describe the tasks the computer can help them with
Probe further to refine the tasks into specific user goals, "I need to Ship items, Track a shipment, Create a return"
User Goal Technique: Specific Steps 1-4
1.) Identify all the potential users for the new system
2.) Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales)
3.) Further classify potential users by organizational level (e.g., operational, management, executive)
4.) For each type of user, interview them to find a list of specific goals they will have when using the new system (current goals and innovative functions to add value)
User Goal Technique Specific stepts 5-8
5.) Create a list of preliminary use cases organized by type of user
6.) Look for duplicates with similar use case names and resolve inconsistencies
7.) Identify where different types of users need the same use cases
8.) Review the completed list with each type of user and then with interested stakeholders
Event Decomposition Technique
More Comprehensive and Complete Technique'
Identify the events that occur to which the system must respond.
For each event, name a use case (verb-noun) that describes what the system does when the event occurs
something that occurs at a specific time and place, can be described, and should be remembered by the system
an event that occurs outside the system, usually initiated by an external agent or actor
an event that occurs as a result of reaching a point in time
an event that occurs when something happens inside the system that triggers some process
reorder point is reached for inventory item
Perfect Technology Assumption
Don't worry about functions built into system because of limits in technology and people. Wait until design.
Event Decomposition Technique: Specific Steps 1-4
1.) Consider the external events in the system environment that require a response from the system by using the checklist shown in Figure 3-3
2.) For each external event, identify and name the use case that the system requires
3.) Consider the temporal events that require a response from the system by using the checklist shown in Figure 3-4
4.) For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case
Event Decomposition Technique: Specific Steps 5-7
5.) Consider the state events that the system might respond to, particularly if it is a real-time system in which devices or internal state changes trigger use cases.
6.) For each state event, identify and name the use case that the system requires and then define the state change.
7.) When events and use cases are defined, check to see if they are required by using the perfect technology assumption. Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in later.
Benefits of Event Decomposition
Events are broader than user goal: Capture temporal and state events
Help decompose at the right level of analysis: an elementary business process (EBP)
EBP is a fundamental business process performed by one person, in one place, in response to a business event
Uses perfect technology assumption to make sure functions that support the users work are identified and not additional functions for security and system controls
Use Cases and CRUD Technique
CRUD is Create, Read/Report, Update, and Delete (archive)
Often introduced in database context
Technique to validate, refine or cross-check use cases
NOT for primarily identifying use cases
CRUD Technique Steps
1.) Identify all the data entities or domain classes involved in the new system. (more in Chapter 4)
2.) For each type of data (data entity or domain class), verify that a use case has been identified that creates a new instance, updates existing instances, reads or reports values of instances, and deletes (archives) an instance.
3.) If a needed use case has been overlooked, add a new use case and then identify the stakeholders.
4.) With integrated applications, make sure it is clear which application is responsible for adding and maintaining the data and which system merely uses the data
Use Case Diagram
a UML model used to graphically show uses cases and their relationships to actors
Actor is the UML name for a end user
is Unified Modeling Language, the standard for diagrams and terminology for developing information systems
the boundary between the computerized portion of the application and the users who operate the application
Use Case Diagram Steps
1.) Identify all the stakeholders and users who would benefit by seeing a use case diagram
2.) Determine what each stakeholder or user needs to review in a use case diagram: each subsystem, for each type of user, for use cases that are of interest
3.) For each potential communication need, select the use cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams
4.) Carefully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeholders and users
the specific area (or domain) of the users' business need that is within the scope of the new system.
are those items users work with when accomplishing tasks that need to be remembered
Examples:are those items users work with when accomplishing tasks that need to be remembered
Also referred to as domain classes or data entities.
Use a checklist of all of the usual types of things typically found and brainstorm to identify domain classes of each type
Use a checklist of all of the usual types of things typically found and brainstorm to identify domain classes of each type
Brainstorming Technique Steps
1.) Identify a user and a set of use cases
2.) Brainstorm with the user to identify things involved when carrying out the use case—that is, things about which information should be captured by the system.
3.)Use the types of things (categories) to systematically ask questions about potential things, such as the following: Are there any tangible things you store information about? Are there any locations involved? Are there roles played by people that you need to remember?
4.) Continue to work with all types of users and stakeholders to expand the brainstorming list
5.)Merge the results, eliminate any duplicates, and compile an initial list
Noun Technique (details)
A technique to identify problem domain classes (things) by finding, classifying, and refining a list of nouns that come up in in discussions or documents
Popular technique. Systematic.
Does end up with long lists and many nouns that are not things that need to be stored by the system
Difficulty identifying synonyms and things that are really attributes
Good place to start when there are no users available to help brainstorm
Noun Technique Steps 1-2
1.) Using the use cases, actors, and other information about the system— including inputs and outputs—identify all nouns.
Examples For the RMO CSMS, the nouns might include customer, product item, sale, confirmation, transaction, shipping, bank, change request, summary report, management, transaction report, accounting, back order, back order notification, return, return confirmation...
2.) Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed.
Examples For the RMO CSMS, these might include price, size, color, style, season, inventory quantity, payment method, and shipping address.
Noun Technique Steps 3
3.) As this list of nouns builds, refine it. Ask these questions about each noun to help you decide whether you should include it:
Is it a unique thing the system needs to know about?
Is it inside the scope of the system I am working on?
Does the system need to remember more than one of these items?
Ask these questions to decide to exclude it:
Is it really a synonym for some other thing I have identified?
Is it really just an output of the system produced from other information I have identified?
Is it really just an input that results in recording some other information I have identified?
Ask these questions to research it:
Is it likely to be a specific piece of information (attribute) about some other thing I have identified?
Is it something I might need if assumptions change?
Noun Technique Steps 4-5
4.) Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further.
5.) Review the list with users, stakeholders, and team members and then define the list of things in the problem domain.
describes one piece of information about each instance of the class
Examples Customer has first name, last name, phone number
Identifier or key
One attribute uniquely identifies an instance of the class. Required for data entities, optional for domain classes. Customer ID identifies a customer
Two or more attributes combined into one structure to simplify the model. (E.g., address rather than including number, street, city, state, zip separately). Sometimes an identifier or key is a compound attribute.
Class and Object
Class is a type of thing. Object is a specific instance of the class. Each instance has its own values for an attribute
a naturally occurring relationship between classes (UML term)
Associations between exactly two different classes
Course Section includes Students
Members join Club
Unary Association (recursive)
Associations between two instances of the same class
Person married to person
Part is made using parts
Shows instances and how they are linked
Example shows instances of three classes
A category of classification used to describe a collection of objects
Classes that describe objects in the problem domain
A UML diagram that shows classes with attributes and associations (plus methods if it models software classes)
Domain Model Class Diagram
A class diagram that only includes classes from the problem domain, not software classes so no methods
Domain Class Notation
Domain class has no methods
Class name is always capitalized
Attribute names are not capitalized and use camelback notation (words run together and second word is capitalized)
an association that is treated as a class in a many to many association because it has attributes that need to be remembered, such as grade
A hierarchical relationship where subordinate classes are special types of the superior classes. Often called an Inheritance Hierarchy
the superior or more general class in a generalization/specialization hierarchy
the subordinate or more specialized class in a generalization/specialization hierarchy
the concept that subclasses classes inherit characteristics of the more general superclass
a class that allow subclasses to inherit characteristics but never gets instantiated. In Italics (Sale above)
a class that can have instances
a relationship between classes where one class is part of or a component portion of another class
a whole part relationship where the component part exists separately and can be removed and replaced (UML diamond symbol, next slide)
Computer has disk storage devices
Car has wheels
a whole part relationship where the parts can no longer be removed (filled in diamond symbol)
Hand has fingers
Chip has circuits
Entity-Relationship Diagrams (ERD)
An ERD shows basically the same information as a domain model class diagram
It is not a UML diagram, but it is widely used by data analysts in database management
There really is no standard notation, but most developers use the entity and crows feet notation shown in this text
An ERD is not good for showing generalization/specialization relationships and whole part relationships
THIS SET IS OFTEN IN FOLDERS WITH...
IT261 Systems Analysis and Design Chapter 4
Systems Analysis And Design: Chapter 1 &…
Systems Analysis and Design Chapter 5 an…
Systems Analysis and Design: Chapter 7 a…
YOU MIGHT ALSO LIKE...
Systems Analysis and Design - Chapter 3
System Analysis and Design in a Changing World, 6t…
OTHER SETS BY THIS CREATOR
Network Management Week #3 Notes
Network Management Week #2 Notes
Network Managemet Week #1 Notes
Systems Analysis and Design Final Review