1 / 17

Use Cases

Use Cases. Within Requirements discipline/workflow Verbal descriptions of important functional (behavioral, transactional, block-box view) requirements Include information for other models such as exceptions, concepts, terminology, constraints, etc.

frankegreen
Download Presentation

Use Cases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Use Cases • Within Requirements discipline/workflow • Verbal descriptions of important functional (behavioral, transactional, block-box view) requirements • Include information for other models such as exceptions, concepts, terminology, constraints, etc. • Simple, easy to show to clients, emphasize client/user’s perspective • Example • Process Sale in POS system • Customer arrives at the cash register. Cashier starts new sale…

  2. Use Case Elements • Actor • Entity with behavior, usually external to our system (some are more obviously external others not) • Can be live, or other system, but must be physical • Primary – has goals fulfilled in the course of use case • Supporting – provides supports such as external systems • Offstage – has interest in the system’s behavior • Scenario (use-case instance) • A sequence or actions and interactions between actors and the system in the course of particular story, transaction, or use of the system • Use Case • A collection of related scenarios, some successful some exceptional or failures, describing actors interacting with the system to support a specific goal

  3. Use Case Example • Returns in POS • Main scenario: Customer returns an item within 30 days with the original package and cash receipt – pay back the cash • Extensions: • Alternatives: Customer paid by a credit card, or does not have the receipt • Exceptions: Item not purchased in the store

  4. Use Case Model • Use Cases • Text • System Sequence Diagrams • Actor-system interfaces and message sequencing • Contracts • Descriptions of change of state in the System • Use-case Diagrams • Relationships among uses cases and actors

  5. Use Case model Influence

  6. Use Case Formats • Brief • One paragraph summary • Useful during inception and early analysis in general to identify scope and risks • Casual • More detailed but still in early stages • Fully Dressed • All steps, scenarios, exceptions, special requirements, etc. • Needed in Inception for the important use cases to establish glossary, extract concepts, assess risk • Needed in Elaboration/construction when iterating on

  7. Use Case Example • Fully dressed Process Sale • See the textbook for a template and the actual use case

  8. Use Case Goals and Levels • It is important to identify all stakeholders and assess their goals • The purpose of Use Case is to address these interests • All relevant should be there • Not irrelevant should be there • User-goal level • Elementary Business Process EBP • Fulfillment of primary actor’s goals • Subsystem level • Not complete EBP, such as pay by credit (payment is only a part of sale)

  9. More on Use Cases. • Preconditions and Postconditions • Special requirements: related non-functional • Two-column format • More visual and comprehensible Actors does System does • Templates • www.usecases.org • Avoid UI details early on • Essential: item is recognized • Concrete: UPC bar code is scanned with optical scanner • Avoid early on

  10. How to Identify Use Cases • Choose system boundary • Is the cashier an actor or system? • Is Credit authorization our responsibility?

  11. How to Identify Use Cases • Find all primary actors and their goals • Who does what or needs what? • Rather than asking “what you do” ask “what is your role, goal, interest” • Analyze events • Remember stakeholders and their goals • Cashier wants easy processing while management wants efficient and secure processing • Keep track of these findings separately for reference

  12. How to Identify Good Use Cases • Boss test • Can you excuse your time doing THIS? • EBP test • Is it well defined process starting with some external need/event and leaving the state consistent? • Size test • Remember that use case(s) will be processed in your time boxes

  13. Use Case Diagrams

  14. Use Case Diagrams

  15. Use Case Diagrams

  16. Activity Diagrams • In requirements analysis it may be useful to have other views: • Dataflow • Process (control flow) • These are expressed with Activity Diagrams • Chapter 28

  17. Activity Diagrams

More Related