1. Chapter 6: Structuring Requirements: Use Case Description and Diagrams Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer

2. Chapter Objectives Af ter studying this chapter you should be able to: – Understand how to structure requirements with use case diagrams. – Explain the basics of use case construction using UML standards. – Construct use case diagrams. – Write text-based use cases.

4. What Is Requirements Structuring? The process of analyzing, organizing, and modeling the requirements obtained via interviews, questionnaires, observation, and document analysis Relevant UML models include: – Use Cases – Class Diagrams – Interaction Diagrams, and – Activity or Statechart Diagrams

5. Use Case Deliverables Use case diagrams Use case descriptions (narratives)

6. What Is a Use Case? A depiction of a system’s functionality or behavior as a response to a user request It is a description of the actions that a system performs that yields an observable result to a particular user. A use case consists of a set of interactions between a user and a system relating to a single function (e.g. enter an order, determine price, withdraw cash) A use case may produce many outcomes. These are called scenarios (or sequences)

7. What Is a Scenario? A scenario (or a sequence) is a single outcome from the system as part of performing a larger use case. A scenario produces only one outcome. The customer browses the catalog and adds desired items to the shopping cart. When ready to check out, customer enters credit card information, and confirms the order. The system checks authorization, and confirms the sale. If instead, the customer decides to save the shopping cart for later use, or if the credit card information is invalid, those are two different scenarios Both of the above bullet points are the same use case, but the are 3 different scenarios

8. A Use Case Diagram

9. UML Use Case Diagram Symbols Use Case Actor Boundary Connection Include relationship Extend relationship Generalization >

10. What Is an Actor? An external entity that interacts with the system Most actors represent user roles, but actors can also be external systems. An actor is a role, not a specific user. As such, many users can play the same role. Alternatively, one user can play many roles.

11. What Is a Boundary? The dividing line between the system and its environment - Use cases are within the boundary. - Actors are outside of the boundary.

12. What Is a Connection? An association between an actor and a use case Depicts a usage relationship Connection does not indicate data flow

13. What Is an > Relationship? A connection between two use cases Indicates a use case that is used (invoked) by another use case Calls to general purpose functions UML uses a dashed arrow (pointing to the invoked use case) and the word >

14. An > Relationship

15. Another example of an > Relationship Both buying a house and selling a house require house valuation - You can make a single house valuation use case, and have both other use cases use (invoke) this use case using an > relationship

16. What Is an > Relationship? A connection between two use cases Extends a use case by adding new behavior or actions (a sub-class) A specialized use case extends a general use case UML uses a dashed arrow (pointing to the extended use case) and the word >

17. Examples of > Relationship Buying a product as a registered customer extends buying a product. - Buying a product as a registered customer adds functionality to buying a product Registering for a special class extends registering for a class use case. - Registering for special classes requires instructor permission plus all steps required for registering for a regular class

18. Example of > & Relationships A Use Case Diagram With both > relationships, and > relationship

19. Use Case Diagram in MS Visio

20. Include vs. Extend Use > if you want to factor a common behavior that two or more use cases can use Use > if you want to model an extension to a complete “more general” use case that exists in its own right, but you are looking to extend/improve the behavior

21. Generalization The act of grouping or categorizing objects into a more general or generic classes or types of objects UML uses a solid arrow pointing to the more general class

22. Actors may be grouped in generalized categories. Here as “Customer” Generalization

23. Generalized and Abstract Use Cases A generalized use case is a use case that is part of an > or > relationship. It is the use case that is on the arrow head side An abstract use case is a use case that does not have any actors. It is only used by other use cases. Example: track sales and inventory data. This use case is only used by other use cases.

24. Use Case Descriptions (Use Case Narratives) A written narrative and description of a use case Document containing detailed specifications for a use case Document can be written with no specific format, or using a use case template format

26. Sample Format for Use Case Narratives Title – name of use case, should match name in use case diagram Primary actor – the primary user role Other actors – other user roles Level – the level of the descriptive detail. summary, intermediate or detail level

27. Sample Format for Use Case narratives (Cont.) Stakeholders – any group or individual with an interest in the function of the use case Precondition – conditions that must be satisfied (must exist) before executing the use case Minimal guarantee – the least amount of processing that is promised by the use case Example: use case fails, roll back transaction. Success guarantee – outputs that is expected if the use case succeeds

28. Sample Format for Use Case narratives (Cont.) Trigger – an event that initiates the use case. Example: a deposited check, an executed sales order, a call from another use case Main success scenario – the step-by-step description of the sequence of interactions between the actor and the use case to bring the main scenario to success Extensions – detailed description of the else scenarios. Description of abnormal “what if” conditions. e.g. description of interaction if credit card is invalid

29. Use case description at summary level. High level bulleted items.

30. Use case description at intermediate level. More detail descriptive use case interactions

31. Use Case Advantages Every use case is a potential high level requirement A use case captures the detail of the interactions with the system that must be implemented A use case is a good starting point for the elaboration phase A use case represents the actor’s point of view A use case should only describe the external visible behavior of the interaction with the actor A use case should not focus on implementation

32. Recap Af ter studying this chapter we learned to: – Understand how to structure requirements with use case diagrams. – Explain the basics of use case construction using UML standards. – Construct use case diagrams. – Write use cases descriptions/narratives.