1 / 16

Use

Use. Cases. Part 1. http://flic.kr/p/4kextB. Recall: Iterative development process. We are here. http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg. Recall: FURPS+ Classification of Requirements. F unctional : features, capabilities, security

paulharvey
Télécharger la présentation

Use

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 Part 1 http://flic.kr/p/4kextB

  2. Recall: Iterative development process We are here http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg

  3. Recall: FURPS+ Classification of Requirements • Functional: features, capabilities, security • Usability: human factors, help, documentation • Reliability: frequency of failure, recoverability, predictability • Performance: response times, throughput, accuracy, availability, resource usage • Supportability: adaptability, maintainability, internationalization, configurability

  4. Recall: UP Requirements Artifacts • Use-case model: (we’ll discuss in a minute, but primarily functional req.) • Supplementary specification: non-functional req. and functional req. that don’t fit in UCs • Glossary: Terms and definitions (surprisingly important!) • Vision: Overview of requirements focused on the business case for the system • Business rules: Rules and laws from the problem domain that must be followed http://flic.kr/p/6meLX

  5. Today, we’re going to learn about Use Cases (Ch. 6.0–6.10) But first, we must introduce a case study… http://flic.kr/p/anWc2v

  6. Larman Case Study: NextGen POS System • POS = Point of Sale • Computerized application used (in part) to record sales and handle payments • Typically used in retail store • Includes hardware • E.g.: barcode scanner • Interfaces with various service applications • E.g.: tax calculator • Must be fault tolerant • E.g.: handle cash as backup http://flic.kr/p/4UtQzk http://flic.kr/p/4UtQzk

  7. Use case: text stories of some actor using a system to meet goals 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.

  8. Let’s push the UC definition a bit further… Actor: something with behavior, such as a person, computer, organization Scenario (or use case instance): specific sequence of actions and interactions between actors and the system Use case: collection of related success and failure scenarios that describe an actor using a system to support a goal

  9. The first UC example I showed used a “brief” format; here’s one that uses a “casual” format • 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… • Alternative scenarios: • If the customer paid by credit, and the reimbursement transaction to their credit account is rejected, inform the customer and pay them with cash. • 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 accounting system…

  10. 3 kinds of actors • Primary actor: has user goals fulfilled through using the system • Identify to find user goals • Supporting actor: provides a service to the system • Identify to clarify external interfaces/protocols • Offstage actor: has an interest in the behavior of the UC, but is not directly involved (e.g., US Government) • Identify to ensure all necessary interests are identified

  11. Yet another definition… Use-Case Model: set of all written use cases; it is a model of system’s functionality and environment The UC Model is just one type of requirements artifact

  12. Why create use cases? Aha! • Easy for customers to understand/contribute • Help communication • Emphasize user goals and perspectives • Keep the requirements focused on the customer http://flic.kr/p/5dFxK2

  13. Which UCs to write/refine first? • High value • I.e.: Represent system’s core functionality • High risk • Architecturally significant http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg

  14. Activity: Creating use cases http://flic.kr/p/5dfuqL http://en.wikipedia.org/wiki/File:Barclayscyclehire.jpg

  15. Basic system architectureEmphasis on system boundary Bicyclestations The System Mobile/webcustomer Phonecustomer Phone system Servicetech Phonesupport

  16. Summary • Use cases • Actors and scenarios • Styles: • “Brief” • “Casual” • “Fully dressed” • The Use Case Model http://flic.kr/p/YSY3X

More Related