By Lynn Reynolds,2014-05-26 12:38
14 views 0



     Use-case Model: Writing Requirements In Context



     Identify and write use cases. Relate use cases to user goals and elementary business processes. Use the brief, casual, and fully dressed formats, in an essential style. Relate use case work to iterative development.


     Use case = ??Story??

     Writing use cases?ªstories of using a system?ªis an excellent technique to understand and describe requirements.


     What is use case?

     Use Cases are to discover and record functional requirements. A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system??s behavior under various conditions as it responds to a request from one of the stakeholders, called the primary actor. A Use Case is a collection of related success and failure scenarios that describe actors using a system to fulfill (or support) a goal. A scenario is a specific sequence of actions and interactions between actors and the system under discussion.


     Major Concepts in Use-Case Modeling

     An actor represents anything that interacts with the system.


     A use case is a sequence of actions a system performs that yields an observable result of value to a particular actor.

     Use Case


     Use Case

     The name of a Use Case should be the main goal of the Use Case. Use cases are fundamentally a text form, although they can be written using graphic form. In UML use-case diagrams, a use case is rendered as an ellipse.

     Process Loan


     Use Cases

     Use cases document system behavior from point of view of the user A user means anything that is external to the system under development

and which interacts with the system


     Use Cases and Functional Requirements

     Use cases are requirements (not all requirements). Primarily they are functional requirements that indicate what the system will do. Use cases define a promise or contract of how a system will behave. Use cases provide a structured way to help with requirements capture Identify the actors Find out what actors need from the system Find out any other interactions the actors expect to have with the system


     Use Cases Basics

     An actor is something with behavior, such as a person (identified by role), computer system, or organization; for example, a cashier The actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. A scenario is a specific sequence of actions and interactions between actors and the system under discussion. It is one particular story of using a system, or one path through the use case; A use case is a collection of related success and failure scenarios that describe actors using a system to support a goal


     Example of UC

     Example of POS Use Case ?C Handle Returns

     Handle Returns Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item ???? Alternate Scenarios: If the credit authorization is reject, inform the customer and ask for an alternate payment method. If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code (perhaps it is corrupted). If the system detects failure to communicate with the external tax calculator system, ????



     An actor is anything with behavior, including the system under discussion itself when it calls upon the services of other systems. Primary and supporting actors will appear in the action steps of the use case text. Actors are not only roles played by people, but organizations, software, and machines.


     Type of Actors

     Primary actor has user goals fulfilled through using services of the system.

     For example, the cashier.

     Supporting actor provides a service (for example, information) to

    the system. Often a computer system, but could be an organization or person.

     For example, the automated payment authorization service

     Offstage actor has an interest in the behavior of the use case, but is not primary or supporting

     For example, a government tax agency.


     UC Names

     Every use case must have a name that distinguishes it from other use cases. Rules of naming Use Case: Verb + Noun

     Place Order

     Validate User


     Goals and Brief Format Use Cases

     Customers and end users have goals (needs/requirements) and want computer systems to help meet them. The goals are primarily the starting point of finding out use case Brief format Use cases are a mechanism to help keep it simple and understandable for all stakeholders.

     Informally, they are stories of using a system to meet goals.

     Here is an example brief format use case: Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items.



     Use cases are text documents, not diagrams, and use-case modeling is primarily an act of writing text, not drawing. However, the UML defines a use case diagram to illustrate the names of use cases and actors, and their relationships.

     A Video Clerk who wants to rent a video to a custom er will communicate with the use case Rent A Video.

     Video Clerk

     Rent A Video


     Use Case Diagram (a Library System)

     Reserve book Browse Book Borrower Borrow copy of book Return copy of book Extend loan Update Catalog Borrow Journal Journal Borrower Librarian Return Journal Browser


     What Is a Use-Case Model?

     A model that describes a system??s functional requirements in terms

    of use cases A model of the system??s intended functionality (use cases) and its environment (actors)

     View Report Card

     Register for Courses

     Student Login


     Use Case Model

     The Use Case Model is described by the following constructs: Actors (name, description, status, subclass, superclass, and associations) Use cases (number, subject area, business event, name, overview, preconditions, description, associations, inputs, outputs, traceable to, usability index, and notes) Communication-associations between actors and uses cases Relationships between use cases (same as use case associations) Termination outcomes Conditions affecting termination outcomes Termination outcomes decision table Use case scenarios (number, termination outcome, description, and notes) Problem domain concept definitions System steps decision table Flow of events table System sequence diagram


     Use Case model(2)

     Number: Subject Area: Business Event: Name: Overview: Preconditions: Description: Associations: Traceable To: Usability Index: Inputs: Decision Table Outputs: xxxxxxxxxxxx T T F Notes: xxxxxxxxxxxx F F F

     xxxxxxxxxxxx F T xxxxxxxxxxxx

     Use Case

     Scenario Number Use Case Number Termination Outcome Scenario Notes Scenario Describption Termination Outcome:


     Name: Description: Status: Subclass: Superclass: Associations:

     T T

     Conditions Affecting:

     Problem Domain Concepts

     System Sequence Diagram

     Decision Table

     xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx xxxxxxxxxxxx T T F F F F F T T T

     Flow of Events

     STEP A/S ACTION xxxx xx xxxxxxxxxxxxxxx xxxx xx xxxxxxxxxxxxxxx xxxx xx xxxxxxxxxxxxxxx xxxx xx xxxxxxxxxxxxxxx xxxx xx xxxxxxxxxxxxxxx DATA xxxx xxxx xxxx xxxx xxxx VALIDATION NOTES xxxxxxxxxxx xxxxxxxxxx xxxxxxxxxxx xxxxxxxxxx xxxxxxxxxxx xxxxxxxxxx xxxxxxxxxxx xxxxxxxxxx xxxxxxxxxxx xxxxxxxxxx


     UC Formality Types

     Use cases are written in different formats, depending on need. Use cases are written in varying degrees of formality: Brief - terse one-paragraph summary, usually of the main success scenario. (The prior Process Sale example was brief.) Casual - informal paragraph format. Multiple paragraphs that cover various scenarios. (The prior Handle Returns example was casual.) Fully dressed - the most elaborate. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees.


     Use-Case Specifications

     Name Brief description Flow of Events Relationships Activity diagrams Use-Case diagrams Special requirements Pre-conditions Post-conditions Other diagrams


     Use-Case Model

     Actors Use Cases


     Use-Case Specifications

     Use-Case Flow of Events

     Has one normal, basic flow Several alternative flows

     Regular variants Odd cases Exceptional flows for handling error situations


     What Is a Scenario?

     A scenario is an instance of a use case.


     Case Study: Use Case - Process Sale

     See appendix for details


     My Recommendation: The Two-Column Format

     Main Success Scenario: Actor Action (or Intention) 1. Customer arrives at a POS checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier.. Cashier repeats steps 3-4 until indicates done. 6. Cashier tells Customer the total, and asks for payment. 7. Customer pays.

     System Responsibility

     4. Records each sale line item and presents item description and running total. 5. System presents total with taxes calculated.

     8. Handles payment 9. Logs the completed sale and sends information to the external accounting and inventory systems (to update inventory). System presents receipt.


     Extensions (or Alternate Flows)

     Extensions are very important. They indicate all the other scenarios

    or branches, both success and failure. Extension scenarios are branches from the main success scenario, and so can be notated with respect to it. For example,

     Extensions: 3a. Invalid identifier: 1. System signals error and rejects entry.

     7b. Paying by credit: 1. Customer enters their credit account information. 2. System requests payment validation from external Payment Authorization Service System. 2a. System detects failure to collaborate with external system: 1. System signals error to Cashier. 2. Cashier asks Customer for alternate payment. 3. ????


     Use Case Template

     Use Case Summary Actors Description Preconditions Normal Paths

     Postconditions Exceptions Alternate Paths Requirements Outstanding Issues

     { name } Identifier { id } { Brief text summary of the use case. } { Names of actors involved in the use case. } { Text description of the use case. } { Things that must be true for the use case to be executed, i.e. start state S0.} 1. First step of the use case. 2. Second step of the use case. . . { includes extension points, inclusions, etc. } . n. Last step of the use case. { Things that will be true after the use case has executed, i.e. final states Sf. } { Any known exceptions that may interrupt normal flow of events. } { Alternative paths through the case ?C should include responses to exceptions. } { Trace back to requirements realized by this use case. } { Text description of any issues concerning this use case needing resolution. Should include identity of responsible party.}


     Subject Area < Business events are triggers that stimulate activity within the business. They are the stimuli that Business Event prompt the business to act. Many business events occur at the interface point between the business and one of the external entities that it interacts with. Other business events are internal triggers based on conditions or predefined time intervals. Business events must be atomic (cannot be decomposed into two or more events) and detectable (observable). Furthermore, it is not possible for a business event to have partially happen.>

     system may have to be in a certain Preconditions state before the initiation of the use case is enabled. This may include required sequencing of use cases; for instance, one or more other use cases may have to have been executed successfully for this use case to begin.> Termination Outcome Condition Affecting Termination Outcome outcomes and the conditions under which they can occur.>

    #2> description of the series of events (conversation) of the most likely to occur termination Use Case outcome (a/k/a main course). Should be expressed in terms of what the actor does and how system Description responds. Should not be complicated by too many conditionals. In addition, should not include looping.> Use Case Associations related work products, models, or documents that this use case is traceable to. This may include Traceability business rules, data validation rules, a traditional functional requirements document, business objectives, To: GUI sketches/mockups/screens/prototypes, use case scenarios, etc??.> Inputs Summary Output Summary case ranked in terms of satisfaction, importance and frequency.> Usability Index Notes USE CASE #X


     How to Find Use Cases

     1. Choose the system boundary. Is it just a software application, the hardware and application as a unit, that plus a person using it, or an entire organization? 2. Identify the primary actors. Those that have user goals fulfilled through using services of the system. 3. For each, identify their user goals. Raise them to the highest user goal level that satisfies the EBP guideline. 4. Define use cases that satisfy user goals; name them according to their goal. Usually, user goal-level use cases will be one-to-one with user goals, but there is at least one exception, as will be examined.


     Identifying Actors

     When developing a use case model, identify the different roles played by the potential human users of the system

     People play different roles at different times E.g. A person can play the role of book borrower, librarian, browser or journal borrower at different times Any person who interacts with the system will be represented by at least one actor in use case model

     Typical Actors:

     Roles that people play Computer systems Electrical or mechanical devices


     Identifying Non?CHuman Actors

     Which external systems or devices that interact with the system should be shown on a use case diagram? These external systems or devices can either be shown:

     at all times, when the other system or device initiates contact, or when the other system or device gets value from the contact


     Identifying Use Cases

     Actor-Based Approach:

     Identify actors related to a system or organization Then, for each actor, identify the process they initiate or participate in

     Event-Based Approach:

     Identify external events that a system must respond to Relate events to actors and use cases

     Yet Another approach:

     Express business processes in terms of specific scenarios, then generalize


     A Common Mistake

     Representing individual steps, operations, or transactions as use cases Question: In POS system, is there a use case called ??printing receipt??? Tip:

     Use case is relatively large end-to-end process description that typically includes many steps or transactions


     Case Study: Writing Use Case - Step 1: Choosing the System Boundary

     For this case study, the POS system itself is the system under design; everything outside of it is outside the system boundary, including the cashier, payment authorization service, and so on. If it is not clear, defining the boundary of the system under design can be clarified by defining what is outside the external primary and supporting actors. Once the external actors are identified, the boundary becomes clearer.




     Steps 2 and 3: Finding Primary Actors and Goals

     Primary actors have user goals fulfilled through using services of the system. (Supporting actors provide services to the system under design) Brainstorm the primary actors! The primary actor is the framework for further investigation. Think of goals of the system Be suspicious if no primary actors are external computer systems. Reminder Questions to Find Actors and Goals:

     Who starts and stops the system? Who does system administration? Who does user and security management? Is "time" an actor because the system does something in response to a time event? Is there a monitoring process that restarts the system if it fails? Who evaluates system activity or performance? How are software updates handled? Push or pull update? Who evaluates logs? Are they remotely retrieved?


     (Continue) Work out The Actor-Goal List




     process sales process rentals handle returns cash in cash out start up shut down


     System Administrator


     add users modify users delete users manage security


     Sales Activity System

     analyze sales and performance data


     Step 4: Define Use Cases

     Name the use case similar to the user goal (name use cases starting with a verb).

     For example, Goal: process a sale; Use Case: Process Sale


     Steps to write a use case (Important)

     Step 1: Find the boundaries of the system (Context diagram, In/out list). Step 2: Brainstorm and list the primary actors. (Actor List) Step 3: Brainstorm and list the primary actors' goals against the system. (Actor-Goal List) Step 4: Write the outermost summary level use cases covering all the above. Step 5: Reconsider & revise the strategic use cases. Add, subtract, merge goals. Step 6: Pick a use case to expand or write a narrative to get acquainted with the material.


     Steps to write a use case (Continue)

     Step 7: Fill in the stakeholders, interests, preconditions and guarantees. Double check them. Step 8: Write the main success scenario. Check it against the interests and the guarantees. Step 9: Brainstorm and list possible failure conditions and alternate success conditions. Step 10: Write how the actors and system should behave in each extension. Step 11: Break out any sub use case that needs its own space. Step 12: Start from the top and readjust the use cases. Add, subtract, merge. Double check for completeness, readability, failure conditions.


     Use Case Diagrams

     The UML provides use case diagram notation to illustrate the names of use cases, actors, and the relationships between them


     Discussion of UCD

     A common sign of a novice (or academic) usecase modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text. Suggestion: Draw a simple use case diagram in conjunction with an actor-goal list. A use case diagram is an excellent

    picture of the system context; it makes a good context diagram, that is, showing the boundary of a system, what lies outside of it, and how it gets used.


     UC Diagram Suggestions

     The class box style can be used for any actor, computer or human. Using it for computer actors provides visual distinction.


     Splitting Use Cases

     Write major steps or branching activities of a use case as a separate one when:

     They are duplicated in other use cases They are complex and long and separating them helps factor the use cases into manageable pieces


     UML: Include Relationship

     A include relationship from use case A to use case B indicates that A will also include the behavior as specified by B ? similar behavior across use cases is identified after the use cases are specified POST

     Buy Items

     <> <> <>

     Pay By Credit


     Pay By Cash

     Pay By Check



     Another Example

     Use ATM Withdraw Case

     Deposit Case

     Transfer Account


     UML: Extend Relationship

     sometimes use cases are complex because they have many steps Used when a second use case story follows the story of a prior use case Extending a use case is, effectively, an alternate course of base use case Introduce an extending use case whenever logic for an alternate course of action is at a complexity level similar to that of your basic course of action



     An extends relationship from use case A to use case B indicates that an instance of B may include (subject to specific conditions) the behavior specified by A

     University Enrolment System Registrar

Report this document

For any questions or suggestions please email