1. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 Functional Requirements through Use Cases Patrick Bailey Keith Vander Linden Calvin College

2. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 2 Imagine several dozen pages of this… 1. The system shall allow entry of a patron’s library card number. 2. The system shall flag patron records as non-useable if there is an overdue book associated with the account. 3. The system shall flag patron records as non-useable if there is an overdue book associated with the account. 4. The system shall allow entry of a book identification number for checkout. 5. The system shall maintain the status of a book. Statuses include available, checked-out, reserved and destroyed. 6. The system shall maintain the status of a video. Statuses include available, checked-out, reserved, being-viewed, on-order and destroyed. 7. The system shall mark a book as checked out for a patron provided the patron ID is entered, the patron record is not flagged and the book status is available. 8. The system shall mark a video as checked out for a patron provided the patron ID is entered, the patron record is not flagged and the video status is available. 9. The system shall apply a date two weeks from the current date as the due date for a book. 10. The system shall apply a date one week from the current date as the due date for a video.

3. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 3 Compared to … When a patron brings books or videos to the checkout desk, the clerk will do the following: Request the library card from the patron and enter the number into the system. The system will let the clerk know if the patron may check out materials. The clerk will enter the identification number of each book and video into the system. The system will create a receipt listing material checked out and each due date. Books are allowed to be checked out for two weeks and videos are allowed to be checked out for one week.

4. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 4 Basic Definition “The use case view captures the behavior of a system… as it appears to an outside user.“ It is done through partitioning the system into stories of usage by an actor. “The term actor includes humans, as well as other computer systems and processes.” The actor: “I think (or maybe I’m programmed to), therefore I am…human, machine, whatever…”

5. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 5 General Industry Observations ● Enhances customer ability to verify system description. Easier to comprehend. ● Story telling is a natural tool to create understanding “The job boils down to two things: paying attention … and then telling the truth about what you see.” Stephen King, “On Writing”

6. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 6 Use Case Relationships Association – Communication path between actor and use-case Extend – Insertion of additional behavior into a base use case not explicitly documented > Include – Additional behavior that is explicitly described. Often a shareable use case > Generalization – Relation to a specific use case that shares features

7. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 7 Diagram Sample video checkout book checkout item checkout verify user > check in item pay fine > Boundary Note: Video and book checkout have common steps identified in item checkout. Note: “pay fine” is not always a required process at check in where as “verify user” is always done at checkout, highlighting the use of > and >, respectively.

8. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 8 Example with text view…

9. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 9 The Text Elements (or the real work) Use Case Name Name of the use case Unique ID ID for requirements management Primary Actor Role/title/description of actor Supporting Actor Sometimes called stakeholders – define their goal or contribution Brief Description High level overview of purpose Pre conditions What must be true before hand. Main Scenario Typical or “basic” flow Post Conditions Success condition – “guarantee” Alternate Scenarios “Exceptions” to the basic flow Other Other considerations of importance

10. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 10 Other Considerations ● Non-behavioral requirements (ie constraints, “non-functional” requirement) ● Assumptions ● Issues ● Risk ● Priority ● Noted meeting information ● Other (there can always be more)

11. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 11 Considerations ● Larman recommends avoiding specifics about the user interface design layout. ● Styles of writing suggested for scenarios: – prose – Free flowing text style. – step - Events are described in ordered steps. – state – Specific description of state. Almost like steps but with description of how states change. (Note: States are typically underlined in the use cases because they may cross over)

12. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 12 Example – Library Check Out Use Case Name Material Check Out Use Case ID UC Lib 1.1 Primary Actor Library Desk Clerk – must be able to quickly check out books with no errors. Stakeholders Inventory Manager – Wants to ensure accuracy Library Manager – Responsible for quality and speed of service

13. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 13 Example Continued Pre- conditions Material is registered in system Patron is registered on system Main Scenario The patron arrives at the library checkout station and presents a library card and materials to check out. The clerk verifies the card ID is for a legitimate patron and that the patron is allowed to check out material. The clerk then records the ID number from each item being checked out and records their loan and their duration (books are two weeks and videos are one.) The patron is provided a receipt listing the materials and their due dates. Success Library has record of patron and checkout information.

14. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 14 Example with Steps Pre- conditions Material is registered in system Patron is registered on system Main Scenario 1. Patron library card and materials to check out. 2. Clerk verifies the card ID is for a legitimate patron and that the patron is allowed to check out material 3. Clerk records the ID number from each item being checked out 4. The due date for the material is determined 1. Each book is given two weeks 2. Each video is given one week 5. The patron is provided a receipt listing the materials and their due dates. Success Library has record of patron and checkout information.

15. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 15 Alternative Scenario Pre- conditions Material is registered in system Patron is registered on system Alternative Scenarios 1.1 Patron does not have library card. 1.2 Clerk requests some form of identification 1.3 Clerk verifies patron and issues temporary card (UC LIB 3) 2.1 Patron has overdue bill 2.2 Patron offers to pay bill 2.3 Clerk collects payment (UC LIB 4) 2.1a Patron does not pay bill 2.1b Clerk does not proceed

16. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 16 As A Process Use Case Modeling Prepare for use case modeling Perform initial use case modeling Expand on use case model Create test cases and documentation Organize the Use Cases Ongoing use case management Major Use Case Activity Groups Armour & Miller, Advanced Use Case Modeling, Addison-Wesley, 2000

17. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 17 Implications for SE Discipline ● Scope management based on stories and well defined system boundary. ● Natural inclination to strong cohesion with well developed stories. ● Better equipped to validate high level architectures with tools such as ATAM which focuses on scenario analysis ● AND…

18. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 18 Aligns Well With Iterative Development Alternate scenariosMain Scenario

19. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 19 Multiplicity Notation Multiplicity Lower Bounds Upper Bounds 1There is one and only one11 0..1There can be up to one01 0..*Optionally many0Infinite 1..*As few as one1Infinite http://community.borland.com/article/0,1410,30166,00.html

20. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 20 Multiplicity Example. Ref: http://bdn.borland.com/article/0,1410,30166,00.htmlhttp://bdn.borland.com/article/0,1410,30166,00.html

21. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 21 Detail on condition of extends > now highlights conditions http://community.borland.com/article/0,1410,30166,00.html

22. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 22 General Comment At one time, analysts produced process narratives. These were descriptions of system usage from an operational perspective. However, these were the documents that led up to “shall” scripting requirements.

23. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 23 Reverse Engineering – Existing Documents ● Reverse engineering is not appropriate since use cases discuss behavior and not implementation. ● It can be used, though, as a framework to understand existing systems that have changed ownership. ● Use cases can help set a context or a grouping for existing shall script documents.

24. Smith’s Aerospace © P. Bailey & K. Vander Linden, 2005 24 References Frank Armour and Granville Miller, Advanced Use Case Modeling, Addison Wesley 2000 Craig Larman, Applying UML and Patterns – Second Edition, Prentice Hall, 2002 Jong Kook Lee, Seung Jae Jung and Soo Dong Kim, Component Identification Method with Coupling and Cohesion, APSEC’01, IEEE Paper 1530-1362/01, 2001