Functional Modeling

Modelling System Context: UML Use Case Diagram

• A use case is an activity that the system performs, usually in response to a request by a user.
• Use cases define functional requirements.
• Name each use case using Verb-Noun.

Identifying Use Cases

• Two techniques:
  • User Goal
  • Event decomposition

User Goal Technique

• Most common in industry due to simplicity and effectiveness.
• Steps:
  1. Identify all potential categories of users of the system.
  2. Interview users to describe tasks the computer can help them with.
  3. Refine tasks into specific user goals.

Specific Steps for User Goal Technique

1. Identify all potential users for the new system.
2. Classify users by their functional role (e.g., shipping, marketing, sales).
3. Further classify users by organizational level (e.g., operational, management, executive).
4. For each type of user, interview them to find a list of specific goals when using the new system.
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 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.
• Event: something that occurs at a specific time and place, can be described, and should be remembered by the system.

Types of Events

• External Event:
  • Occurs outside the system, usually initiated by an external agent or actor.
• Temporal Event:
  • Occurs as a result of reaching a point in time.
• State Event:
  • Occurs when something happens inside the system that triggers some process (e.g., reorder point is reached for inventory item).

External Event Checklist

• External agent or actor wants something resulting in a transaction (e.g., customer buys a product).
• External agent or actor wants some information (e.g., customer wants to know product details).
• External data changed and needs to be updated (e.g., customer has new address and phone).
• Management wants some information (e.g., sales manager wants update on production plans).

Temporal Event Checklist

• Internal outputs needed at points in time (e.g., management reports, operational reports, internal statements and documents).
• External outputs needed at points of time (e.g., statements, status reports, bills, reminders).

Specific Steps for Event Decomposition Technique

1. Consider the external events in the system environment that require a response from the system by using a checklist.
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 a checklist.
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.
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.

Use Cases and Brief Use Case Descriptions

• Brief use case description is often a one-sentence description showing the main steps in a use case.

Use Case Diagrams

• Use case diagram: a UML model used to graphically show uses cases and their relationships to actors.
• UML is Unified Modeling Language, the standard for diagrams and terminology for developing information systems.
• Actor is the UML name for an end user.
• Automation boundary: the boundary between the computerized portion of the application and the users who operate the application.

Use Case Diagram Symbols

• Actor: A stick figure, usually meaning an actual person using the system.
• Connecting line: To show which actors participate in use cases.
• Automation boundary.

Steps for Use Case Diagrams

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.

Objectives

• Explain why identifying use cases is the key to defining functional requirements.
• Describe the two techniques for identifying use cases.
• Apply the user goal technique to identify use cases.
• Apply the event decomposition technique to identify use cases.
• Describe the notation and purpose for the use case diagram.
• Write fully developed use case descriptions.
• Develop activity diagrams to model flow of activities.
• Use the CRUD technique to validate use cases.
• Explain how use case descriptions and UML diagrams work together to define functional requirements.

Use Case Descriptions

• Write a fully developed use case description for more complex use cases.

Typical Use Case Description Templates Include

• Use case name
• Scenario (if needed)
• Triggering event
• Brief description
• Actors
• Related use cases (<>)
• Stakeholders
• Preconditions
• Postconditions
• Flow of activities
• Exception conditions

Use Case Description Details

• Use case name:
  • Verb-noun
• Scenario (if needed):
  • A use case can have more than one scenario (special case or more specific path)
• Triggering event:
  • Based on event decomposition technique
• Brief description:
  • Written previously when use case was identified
• Actors:
  • One or more users from use case diagrams
• Related use cases <>:
  • If one use case invokes or includes another
• Stakeholders:
  • Anyone with an interest in the use case
• Preconditions:
  • What must be true before the use case begins
• Post conditions:
  • What must be true when the use case is completed
  • Use for planning test case expected results
• Flow of activities:
  • The activities that go on between actor and the system
• Exception conditions:
  • Where and what can go wrong

UML Activity Diagram

• Used for Use Case

Use Cases and CRUD

• CRUD technique
  • Create
  • Read/Report
  • Update
  • Delete
• A good cross-check against the existing set of use cases. Used in database context
• Ensure that all classes have a complete “cover” of use cases
• Not for primary identification of use cases

CRUD Analysis: Steps

1. Identify all domain classes
2. For each class verify that use cases exist to:
   • Create a new instance
   • Update existing instances
   • Reads or reports on information in the class
   • Deletes or archives inactive instances
3. Add new use cases as required. Identify responsible stakeholders
4. Identify which application has responsibility for each action: which to create, which to update, which to use

Extending and Integrating Requirements Models

• Use cases
  • Use case diagram
  • Use case description
  • Activity diagram
  • System sequence diagram (SSD)
• Domain Classes
  • Domain model class diagram
  • State machine diagram