1. Unit 3 Functional Requirements

2. Syllabus Introduction Features and usecases Use case Scenarios Documenting use cases Levels of details SRS Document

3. CMSC 345, Version 9/07 S. Mitchell Use Cases Concepts, Specifications, and Diagrams

4. 4 CMSC 345, Version 9/07 S. Mitchell Introduction “Invented” by Ivar Jacobson in the late 1960’s (where have we seen his name before?) Introduced to the OO community in the late 1980’s Alistair Cockburn has extended Jacobson’s model Is a way to specify functional requirements Is notated using a use case specification Is not part of the Unified Modeling Language (UML), but is many times used in conjunction with it

5. 5 CMSC 345, Version 9/07 S. Mitchell What is a Use Case? (Cockburn) A use case captures a contract between the stakeholders of a system about its behavior. Describes the system’s behavior under various conditions as the system responds to a request from one of the stakeholders called the primary actor. 1.The primary actor initiates some interaction with the system to accomplish some goal. 2.The system responds, protecting the interests of all of the stakeholders. 3.Different sequences of behaviors, or scenarios, can unfold, depending on the requests and the conditions surrounding the request. The use case gathers these scenarios together.

6. 6 CMSC 345, Version 9/07 S. Mitchell Use Case Specification: Natural Language Example Use Case 1. Withdraw Money The system displays the account types available to be withdrawn from and the user indicates the desired type. The system asks for the amount to be withdrawn and the user specifies it. Next, the system debits the user’s account and dispenses the money. The user removes the money, the system prints a receipt, and the user removes the receipt. Then the system displays a closing message and dispenses the user’s ATM card. After the user removes his card, the system displays the welcome message.

7. 7 CMSC 345, Version 9/07 S. Mitchell Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main ScenarioStepAction ExtensionsStepBranching Action Open Issues Use Case Specification Template* *Adapted from A. Cockburn, “Basic Use Case Template”

8. 8 CMSC 345, Version 9/07 S. Mitchell NumberUnique use case number NameBrief verb-noun phrase SummaryBrief summary of use case major actions Priority1-5 (1 = lowest priority, 5 = highest priority) Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main ScenarioStepAction ExtensionsStepBranching Action Open Issues Use Case Specification Template* *Adapted from A. Cockburn, “Basic Use Case Template”

9. 9 CMSC 345, Version 9/07 S. Mitchell Number Name Summary Priority PreconditionsWhat needs to be true before the use case “executes” PostconditionsWhat will be true after the use case successfully “executes” Primary Actor(s) Secondary Actor(s) Trigger Main ScenarioStepAction ExtensionsStepBranching Action Open Issues Use Case Specification Template* *Adapted from A. Cockburn, “Basic Use Case Template” Precondition: y != 0 Postcondition: x / y double divide(double x, double y) { return (x / y); } Precondition: None Postcondition: if y==0 “Illegal”, else x / y double divide(double x, double y) { if (y == 0) cout << “Illegal\n”; else return (x / y); }

10. 10 CMSC 345, Version 9/07 S. Mitchell Number Name Summary Priority Preconditions Postconditions Primary Actor(s)Primary actor name(s) Secondary Actor(s)Secondary actor name(s) Trigger Main ScenarioStepAction ExtensionsStepBranching Action Open Issues Use Case Specification Template* *Adapted from A. Cockburn, “Basic Use Case Template” Actor Anyone or anything with behavior May be a person or system Primary: The stakeholder who or which initiates an interaction with the system to achieve a goal. Is generally a category of individuals (a role). Secondary: Provides a service to the system. Is almost never a person.

11. 11 CMSC 345, Version 9/07 S. Mitchell Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) TriggerThe action that caused the use case to be invoked Main ScenarioStepAction Step #This is the “main success scenario” or “happy path” Step #Description of steps in successful use case “execution” Step #This should be in a “system-user-system, etc.” format ExtensionsStepBranching Action Open Issues Use Case Specification Template* *Adapted from A. Cockburn, “Basic Use Case Template”

12. 12 CMSC 345, Version 9/07 S. Mitchell Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main ScenarioStepAction ExtensionsStepBranching Action Step #Alternative paths that the use case may take Open Issues Use Case Specification Template* *Adapted from A. Cockburn, “Basic Use Case Template” Extension Could be an optional path(s) Could be an error path(s) Denoted in use case diagrams (UML) by >

13. 13 CMSC 345, Version 9/07 S. Mitchell Number Name Summary Priority Preconditions Postconditions Primary Actor(s) Secondary Actor(s) Trigger Main ScenarioStepAction ExtensionsStepBranching Action Open IssuesIssue #Issues regarding the use case that need resolution Use Case Specification Template* *Adapted from A. Cockburn, “Basic Use Case Template”

14. 14 CMSC 345, Version 9/07 S. Mitchell NumberUnique use case number NameBrief noun-verb phrase SummaryBrief summary of use case major actions Priority1-5 (1 = lowest priority, 5 = highest priority) PreconditionsWhat needs to be true before use case “executes” PostconditionsWhat will be true after the use case successfully “executes” Primary Actor(s)Primary actor name(s) Secondary Actor(s)Secondary actor name(s) TriggerThe action that causes this use case to begin Main ScenarioStepAction Step #This is the “main success scenario” or “happy path.” …Description of steps in successful use case “execution” …This should be in a “system-user-system, etc.” format. ExtensionsStepBranching Action Step #Alternative paths that the use case may take Open IssuesIssue #Issues regarding the use case that need resolution Use Case Specification Template* *Adapted from A. Cockburn, “Basic Use Case Template”

15. 15 CMSC 345, Version 9/07 S. Mitchell Number1 NameWithdraw Money SummaryUser withdraws money from one of his/her accounts Priority5 PreconditionsUser has logged into ATM PostconditionsUser has withdrawn money and received a receipt Primary Actor(s)Bank Customer Secondary Actor(s)Customer Accounts Database Use Case Specification Template Example Continued …

16. 16 TriggerUser has chosen to withdraw money Main ScenarioStepAction 1System displays account types 2User chooses account type 3System asks for amount to withdraw 4User enters amount 5System debits user’s account and dispenses money 6User removes money 7System prints and dispenses receipt 8User removes receipt 9System displays closing message and dispenses user’s ATM card 11User removes card 10System displays welcome message ExtensionsStepBranching Action 5aSystem notifies user that account funds are insufficient 5bSystem gives current account balance 5cSystem exits option Open Issues1Should the system ask if the user wants to see the balance?

17. 17 CMSC 345, Version 9/07 S. Mitchell Specification Writing Guidelines No trace of design Describes what the use case will do, not how it will do it (e.g., UI type is irrelevant) A dialogue between the user and the system Complete, clear, and consistent

18. 18 CMSC 345, Version 9/07 S. Mitchell Use Case Diagrams A way of visualizing the relationships – between actors and use cases – among use cases “A graphical table of contents for the use case set” (Fowler)

19. 19 CMSC 345, Version 9/07 S. Mitchell 1 Withdraw Money 2 Deposit Money 3 Transfer Money 4 Check Balance ATM System Bank Customer Customer Accounts Database primary actor role system name system boundary secondary actor use case <<Customer Accounts Database>> alternative actor notation stereotype association

20. 20 CMSC 345, Version 9/07 S. Mitchell Using Use Case Specifications in Conjunction with Use Case Diagrams UML is a graphical modeling tool only. Use case specifications are not part of the UML But, since each ellipse in a UML use case diagram represents a functional requirement, it may in turn have an associated use case specification.

21. 21 CMSC 345, Version 9/07 S. Mitchell 1 Withdraw Money 2 Deposit Money 3 Transfer Money 4 Check Balance ATM System Bank Customer Customer Accounts Database Teller 5 View Transaction History primary actor Why can’t a Teller do the things that a Bank Customer can do? Especially if he is a customer? He can. But he must “step into” the role of a Bank Customer.

22. 22 CMSC 345, Version 9/07 S. Mitchell 1 Withdraw Money Bank Customer Customer Accounts Database 1b Withdraw from Savings 1a Withdraw from Checking > Sub-use Case Diagram This is an extend dependency. It indicates that use case 1b is part of use case 1, but it may or may not be invoked. The same is true of use case 1a. All dependencies are extend unless stereotyped otherwise. note/comment

23. 23 Software Life Cycle Model Requirements Modeling  A requirement model is developed;  Functional requirements are expressed as: – Actors – Use case (with narrative description)  Essential: – User inputs – Active participation A throwaway prototype can be developed to clarify requirements

24. 24 Activities in Requirements Modeling The system is considered as a black box. Emphasis is on understanding the problem. Activities: use case modeling

25. Banking System Case Study25 The Problem Bank Server wan ATM

26. Banking System Case Study26 The Problem A customer can:  Withdraw funds Withdraw funds  Query an account  Transfer funds Transfer funds  Delete a transaction in any moment so The transaction is aborted The card is ejected Customer records, account records debit card records are all mantained on the server.

27. Banking System Case Study27 The Problem (Trx - withdraw funds) Before approving: – Do sufficient funds exist? – Is the max limit exceedeed? – There isn’t sufficient cash in the dispenser? If approved: – Cash is dispensed; – A receipt is printed; – The card is ejected

28. Banking System Case Study28 The Problem (Trx - transfer funds) Before approving: – Has the customer at least two accounts? – Aren’t there sufficient funds in the account to be debited? If approved: – A receipt is printed; – The card is ejected

29. Banking System Case Study29 The Problem A transaction starts when:  Card is inserted  Card is recognized (assumed true)  Card validated  PIN is entered & validated The customer is allowed three attempts to enter the correct PIN; if the 3 rd attempt fails the card is confiscated.

30. Banking System Case Study30 The Problem A card is composed by:  A magnetic strip in which encodes: Start date; Expiration date; Serial no.

31. Banking System Case Study31 The Problem An ATM operator can:  Start up and close down the ATM to replenish the cash dispenser for routine maintenance

32. Banking System Case Study32 The Problem (what is not in) It is assumed that functionality such as open/close accounts create/update/delete customer and cards is provided by an existing system and is not part of the problem. During modeling the Bank Server should be considered as part of the problem

33. Banking System Case Study33 Case study development Use case modelUse case model - Req model Static modelingStatic modeling - Analysis model Object structuringObject structuring – Analysis model Dynamic modeling – Analysis model

34. Banking System Case Study34 Use Case Model Validate PIN Withdraw funds Val.PIN Withdraw Funds Transfer Funds Query Account ATM Customer Operator Add CashShutdownRestart > Use case diagram

35. 25/may/2001Banking System Case Study35 Use case Model (Validate PIN Abstract use case) Use case name: Validate PIN Summary: system validates customer PIN Actor: ATM customer Pre: ATM is idle, displaying a welcome msg Description: 1. Customer inserts … 2. …… Alternatives: …… Post: Customer PIN has been validated

36. 25/may/2001Banking System Case Study36 Use Case Model (Withdraw funds Concrete Use Case) Use case name: Withdraw funds Summary: Customer withdraws a specific amount of funds from a valid bank account Actor: ATM customer Pre: ATM is idle, displaying a welcome msg Description: 1. Include Validate PIN abstract use case 2. Customer selects withdrawal, enter amounts,… 3. … … Alternatives: …… Post: Customer funds have been withdrawn and account debited