[INF43] Lecture 4 How do we know what to build

软件工程 SoftwareEngineering


@ZYX 写于2020年04月08日

How do we know what to build part 2

1. What and why Use case

1. What is a Use Case

  1. A textual description of a set of actions defining interactions betweeen an actor and the system to achieve a goal
  2. includes
    1. Basic functionality/goal
    2. any precondition
    3. flow of events
    4. any postcondition
    5. any error conditon and/or alternative flow
  3. Use cases go hand-in-hand with requirements

2. Flow

  1. flow = a sequence of steps describing an interaction between a user and a system
    • A use case describes a set of flows that together accomplish a specific user “goal”
      1. ATM
      2. a flow pin right
      3. a flow pin wrong -> pin wrong 3times
  2. Types of flows:
    1. Basic flow -> "happy day" scenario 所有操作都合法
    2. alternative flow -> the goal is achieved, but in an alternative way
    3. exception flow -> the goal is not achieved

3. Why Use case

  1. Map well to design and implementation constructs
  2. Make it easy to verify/validate ad design and implementation against user goals
  3. Framed in terms of user goals and flows of events, user requests and system responses

4. Why not use case

  1. Not good for specifying
    1. User interfaces
    2. Data formats
    3. Business rules
    4. non-funstional requirements

5. Actor

  • Represent external entities that interact with the system
    1. Human
    2. Hardware
    3. Another software system
  • A use case is initiated by an actor (primary actor) to invoke a certain functionality in the system
  • A use case is a dialogue between actors and the system
    1. Example:
    2. run keeper
      1. actor -> posts on facebook
      2. actor -> text through SNS

6. Indentifying Actors

  • Actors are discovered
    1. by reading system documents
    2. by talking with customers and domain experts
  • Useful questions for identifying actors:
    Who uses the system?
    Who installs the system?
    Who starts up the system?
    Who shuts down the system?
    What other devices and external systems work directly with the system?
    Who gets information from this system?
    Who provides information to the system?
    Does anything happen automatically at a preset time?
    Who is interested in a certain requirement?
    Where in the organization is the system used?
    Who will benefit from the use of the system?
    Who will support and maintain the system?
    Does the system use an external resource?
    Does one person play several different roles?
    Do several people play the same role?
    Does the system interact with a legacy system

    1. Book flight
      • United Airline apps
    2. Payment
      • paypal

2. How to identify use cases

  • Useful Questions:
    What functions will the actor want from the system?
    What are the tasks of each actor?
    Does the system store information? What actors will create, read, update, or delete (CRUD) that information?
    What use cases will support and maintain the system?
    Can all functional requirements be performed by the use cases?

    1. Scope of a use case
    2. use audience-friendly terminology
    3. what not how
      How the use case starts and ends
      The interactions (in sequence) between use case and actors
      What data is needed by/exchanged during the use case
      Basic flow
      Alternative/exception flows (if applicable)

3. How to Build a Use Case

  1. Name use case
  2. Describe Basic Flow
  3. Add variations, if applicable
    1. Alternative Flows
    2. Exception Flows

Use Case Template

  1. Name/title
  2. Description
  3. Revision History
  4. Actors
  5. System Scope
  6. Goal
  7. Level
  8. Assumptions
  9. Relationships
    Extension Points
  10. Precondition
  11. Trigger Events

4. Use case diagram

  1. A graphical view of actors, use cases, and their interactions


  1. There is generally one use case model per system, consisting of:
    Use case diagrams (one or more)
    Textual descriptions of use cases
  2. Use cases are used as a unifying thread throughout development
  3. Use cases are used as a communication/understanding tool among diverse stakeholders
  4. A Variety of Readers:
    Marketing personnel, human factors engineers, specialty engineers
    System engineers
    Software developers
    System/software testers
    Project managers
    Technical writers