1. 1 Structuring Systems Requirements Use Case Description and Diagrams

2. Chapter 6 2

3. 3 What Is Requirements Structuring? The process of analyzing, organizing, and modeling the requirements obtained via interviews, questionnaires, observation, and document analysis The process of analyzing, organizing, and modeling the requirements obtained via interviews, questionnaires, observation, and document analysis Relevant UML models (i.e. ways to model the requirements) include use cases, class diagrams, interaction diagrams, and activity or statechart diagrams Relevant UML models (i.e. ways to model the requirements) include use cases, class diagrams, interaction diagrams, and activity or statechart diagrams

4. Chapter 6 4 What Is a Use Case? A depiction of a system’s behavior, under various conditions, as the system responds to requests from users A depiction of a system’s behavior, under various conditions, as the system responds to requests from users Interaction of an external entity (or actor) with the system Interaction of an external entity (or actor) with the system The user  uses the system The user  uses the system The actor  represents a role the user can play The actor  represents a role the user can play

5. Chapter 6 5 Use case modeling is utilized to demonstrate the functionality of a system Interactions between system and user

6. Chapter 6 6 UML Use Case Diagram Symbols > Actor Boundary Connection Include relationship Extend relationship Use Case

7. Chapter 6 7

8. 8 What Is an Actor? An external entity that interacts with the system An external entity that interacts with the system Most actors represent user roles, but actors can also be external systems. Most actors represent user roles, but actors can also be external systems. An actor is a role, not a specific user; one user may play many roles, and an actor may represent many users. An actor is a role, not a specific user; one user may play many roles, and an actor may represent many users.

9. Chapter 6 9 What Is a Boundary? The dividing line between the system and its environment The dividing line between the system and its environment –Use cases are within the boundary –Actors are outside of the boundary (i.e. external entities)

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

11. Chapter 6 11 What Is an > Relationship? A connection between two use cases A connection between two use cases Indicates a use case that is used (invoked) by another use case Indicates a use case that is used (invoked) by another use case Links to general purpose functions, used by many other use cases Links to general purpose functions, used by many other use cases Also called an abstract use case since it is never performed by itself Also called an abstract use case since it is never performed by itself

12. Chapter 6 12 Functionality is split out into a separate use case that can be > by other use cases

13. Chapter 6 13 What Is an > Relationship? A connection between two use cases A connection between two use cases Extends a use case by adding new behavior or actions Extends a use case by adding new behavior or actions Specialized use case extends the general use case Specialized use case extends the general use case

14. Chapter 6 14 Instructor is not needed for normal registration, only for special class registration

15. Chapter 6 15

16. Chapter 6 16 Include vs. Extend Use > if you want to model an extension to, or a variation of, a complete use case that exists in its own right Use > if you want to model an extension to, or a variation of, a complete use case that exists in its own right Use > if you want to factor the common behavior among two or more use cases into a single generalized use case Use > if you want to factor the common behavior among two or more use cases into a single generalized use case

17. Chapter 6 17 Actors can be grouped in generalization categories.

18. Chapter 6 18 Written Use Cases Document containing detailed specifications for a use case Document containing detailed specifications for a use case Contents can be written as simple text or in a specified format Contents can be written as simple text or in a specified format

19. Chapter 6 19 Sample Format for Written Use Case Title – descriptive name, matches name in use case diagram Title – descriptive name, matches name in use case diagram Primary actor – usually a user role Primary actor – usually a user role Stakeholders – any group or individual with an interest in the function of the use case Stakeholders – any group or individual with an interest in the function of the use case Precondition – conditions that must be satisfied in order to execute the use case Precondition – conditions that must be satisfied in order to execute the use case

20. Chapter 6 20 Sample Format for Written Use Case (Continued) Minimal guarantee – outputs that can be expected if the service attempt failed Minimal guarantee – outputs that can be expected if the service attempt failed Success guarantee – outputs that can be expected if the service succeeds Success guarantee – outputs that can be expected if the service succeeds Trigger – an event or action that initiates the use case Trigger – an event or action that initiates the use case Main success scenario – description of sequence of interactions between actor and use case during the use case execution Main success scenario – description of sequence of interactions between actor and use case during the use case execution Extensions – detailed description of how errors are dealt with (i.e. else statement that follows an if-then) Extensions – detailed description of how errors are dealt with (i.e. else statement that follows an if-then)

21. Chapter 6 21 A sample written use case

22. Chapter 6 22 Any Questions?