Understanding Use Cases for System Requirements

1. Specifying Requirements with Use Cases http://flic.kr/p/4kextB

2. What are you goingto learn about today? • How to specify what the system will do http://flic.kr/p/8JpkTg

3. Iterative Development Process We are here Analysis Requirements Design InitialPlanning Implementation Planning Testing Evaluation Deployment

4. FURPS Classification of Requirements • Functional: What does the system do? • features, capabilities, security • Non-functional: How well does it do it? • Usability: learnability, efficiency of use, memorability, user errors, satisfaction • Reliability: frequency of failure, recoverability, predictability, accuracy • Performance: speed, efficiency (time & space), responsiveness, throughput, resource usage • Supportability: testability, extensibility, adaptability, maintainability, localizability, portability Our focustoday

5. Larman Case Study: NextGen POS System • POS = Point of Sale • Used mainly to record sales and handle payments • Used in retail store Problem: How to identify functional requirements that will make the customer happy? http://flic.kr/p/4UtQzk http://flic.kr/p/4UtQzk

6. Use Case: Text stories of some actor using a system to meet goals UC Process Sale • Customer arrives at POS checkout with goods to purchase • Cashier starts a new sale • Cashier enters item identifier • System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done • System presents total, and asks for payment • Customer pays and System handles payment • System logs completed sale • System presents receipt

7. Refining the Definition of Use Case • Actors • 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 We focus only on success scenarios

8. Who are the actors? UC Process Sale • Customer arrives at POS checkout with goods to purchase • Cashier starts a new sale • Cashier enters item identifier • System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done • System presents total, and asks for payment • Customer pays and System handles payment • System logs completed sale • System presents receipt Since the cashier is the only one who interacts with the system, he/she is the primary actor

9. Main Success Scenario: A Deeper Look • Sequence of steps in a typical, successful use of the system • Three (+1) types of steps: • Interaction between actors (think message passing) • Validation (usually by system) • State change of system (e.g., recording or modifying something) • (Additionally, step 1 may indicate a trigger event) • Idiom: capitalize actors names

10. Where are the interactions betweenprimary actor and System? UC Process Sale • Customer arrives at POS checkout with goods to purchase • Cashier starts a new sale • Cashier enters item identifier • System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done • System presents total, and asks for payment • Customer pays and System handles payment • System logs completed sale • System presents receipt

11. Where does the system perform validation? Hmm. Larman left it out. Where might validation go? UC Process Sale • Customer arrives at POS checkout with goods to purchase • Cashier starts a new sale • Cashier enters item identifier • System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done • System presents total, and asks for payment • Customer pays and System handles payment • System logs completed sale • System presents receipt Probably should validate identifiers … and payment

12. Where are the state changes of system? UC Process Sale • Customer arrives at POS checkout with goods to purchase • Cashier starts a new sale • Cashier enters item identifier • System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done • System presents total, and asks for payment • Customer pays and System handles payment • System logs completed sale • System presents receipt

13. Step #1 trigger event? ;-) UC Process Sale • Customer arrives at POS checkout with goods to purchase • Cashier starts a new sale • Cashier enters item identifier • System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done • System presents total, and asks for payment • Customer pays and System handles payment • System logs completed sale • System presents receipt

14. What about this step? UC Process Sale • Customer arrives at POS checkout with goods to purchase • Cashier starts a new sale • Cashier enters item identifier • System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done • System presents total, and asks for payment • Customer pays and System handles payment • System logs completed sale • System presents receipt Not a great choice—too vague

15. UCs often include alternative scenarios • UC Handle Returns: • Main success scenario: 1. A customer arrives at a checkout with items to return. 2. 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… Pitfall: Scenario overload, many boring/obviousSee also Larman’s “fully dressed” UCs—yikes!

16. Why use cases? • Easy for customers to understand/contribute • Help communication • Emphasize user goals and perspectives • Keep the requirements focused on the customer • Good granularity for organizing work • Implement user-observable features • Don’t work for months on only user-invisible backend Oh So Agile!

17. 2 Guidelines for Writing UCs • Essential Style • Express narrative at level of user’s intentions and system’s responsibilities • Avoid UI details • Black-Box Style • Do not describe internal workings of system • Say what the system does, not how it does it • Think of system in terms of its responsibilities

18. 2 Guidelines for Writing UCs • Essential Style • Express narrative at level of user’s intentions and system’s responsibilities • Avoid UI details • Black-Box Style • Do not describe internal workings of system • Say what the system does, not how it does it • Think of system in terms of its responsibilities

19. What is wrong with this example? UC Authenticate Administrator • Administrator enters ID and password in dialog box. • System authenticates Administrator • System displays the “edit users” window • Limits possible designs by specifying UI • For example, precludes retina scanner http://flic.kr/p/9ksxQa

20. Here’s an essential-style example UC Authenticate Administrator • Administrator identifies self. • System authenticates identity. This version leaves open novel solutions such as biometric readers that the other version precluded

21. 2 Guidelines for Writing UCs • Essential Style • Express narrative at level of user’s intentions and system’s responsibilities • Avoid UI details • Black-Box Style • Do not describe internal workings of system • Say what the system does, not howit does it • Think of system in terms of its responsibilities

22. What’s wrong with this UC step? “The system generates a SQL INSERT statement for the sale…” Specifies how System stores the info—an implementation detail Better to say it like this:“The system records the sale.” http://flic.kr/p/9ksxQa

23. Iterative Development Question:Which UCs to write first? • High value • Represent system’s core functionality • High risk • Architecturally significant Note: You already have some idea about how the system will be built

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

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

26. Summary • Use cases • Actors and scenarios • Essential style • Black-box style http://flic.kr/p/YSY3X

27. UC Process Sale Customer arrives at POS checkout with goods to purchase Cashier starts a new sale Cashier enters item identifier System records sale line item and presents item description, price, and running total Cashier repeats steps 3-4 until indicates done System presents total, and asks for payment Customer pays and System handles payment System logs completed sale System presents receipt