1. Software Engineering Chapter 7 Fall 2000

2. Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts are forced to think in terms of who the users are and what business or mission needs can be fulfilled through them. By using use cases analysts are forced to think in terms of who the users are and what business or mission needs can be fulfilled through them. Use cases play a key role in driving the rest of the development work. Use cases play a key role in driving the rest of the development work.

3. Use-Case Model – Artifact Use-Case Model – Artifact serves as an agreement between the customer and the developers serves as an agreement between the customer and the developers consists of actors and use cases and their relationships consists of actors and use cases and their relationships If the use-case model is large, it can be organized into packages with different levels of abstraction. If the use-case model is large, it can be organized into packages with different levels of abstraction.

4. Actor – Artifact Actor – Artifact parties or systems outside the system that collaborate with the system parties or systems outside the system that collaborate with the system Each actor can have several roles Each actor can have several roles An actor plays one role for each use case with which it collaborates. An actor plays one role for each use case with which it collaborates.

5. Use Case – Artifact Use Case – Artifact Each way the actors use the system is a use case. Each way the actors use the system is a use case. A use case is a sequence of actions or a function. A use case is a sequence of actions or a function. A use case specifies the behavior of dynamic things. A use case specifies the behavior of dynamic things. A use case is a classifier (pre-class). A use case is a classifier (pre-class). A use case has operations and attributes A use case has operations and attributes

6. Use Case - Artifact A use case description can include statechart diagrams (fig 7.15&16), activity diagrams, collaborations, and sequence diagrams A use case description can include statechart diagrams (fig 7.15&16), activity diagrams, collaborations, and sequence diagrams A use case instance is an execution of the use case, or one path through the use case. A use case instance is an execution of the use case, or one path through the use case. A use case generally does not handle concurrency problems. Those may be identified in the analysis and solved in the design. A use case generally does not handle concurrency problems. Those may be identified in the analysis and solved in the design. The use cases are simply documenting what is required of the system from the user's point of view. The use cases are simply documenting what is required of the system from the user's point of view.

7. Examples of use case instances and the changing states: Examples of use case instances and the changing states: TransitionsStates Start the applicationIntroduction screen displays Click "Enter Data"Input screen displays Click "Exit"Application stopped TransitionsStates Start the applicationIntroduction screen displays Click "Enter Data"Input screen displays Enter the data, click "Submit" Schedule chart displays click "Back"Input screen displays click "Forward"Schedule chart displays click "Exit"Application stopped See "Modeling Large Systems" box on page 137-8.

8. Flow of events Flow of events The flow of events for each use case can be captured as a separate textual description of the use case's sequence of actions The flow of events for each use case can be captured as a separate textual description of the use case's sequence of actions

9. Special requirements Special requirements Textual description of requirements that don't fit anywhere else, but belong to the use case (such as nonfunctional requirements). Textual description of requirements that don't fit anywhere else, but belong to the use case (such as nonfunctional requirements).

10. Architecture Description – Artifact The architecture description starts with the use cases, and includes an architectural view of the use case model. Includes only the architecturally significant use cases. The architecture description starts with the use cases, and includes an architectural view of the use case model. Includes only the architecturally significant use cases.

11. Glossary – Artifact Any terms the users, developers or any other stakeholders might not be familiar with should appear in the glossary with a definition. Any terms the users, developers or any other stakeholders might not be familiar with should appear in the glossary with a definition. These definitions also help to form a concensus among developers where a term might have conflicting meanings. These definitions also help to form a concensus among developers where a term might have conflicting meanings.

12. User Interface Prototype – Artifact Prototypes can be developed to show the users and other developers what the user interface will look like and how it will work. Prototypes can be developed to show the users and other developers what the user interface will look like and how it will work. Screens, reports, etc. can also be drawn on paper to help with the description. Screens, reports, etc. can also be drawn on paper to help with the description.

13. Workers a position to which a real person can be assigned a position to which a real person can be assigned examples – President, tax accountant, sales rep examples – President, tax accountant, sales rep

14. Worker – System Analyst Worker – System Analyst Responsible for the whole set of requirements, actors, use cases, etc. Responsible for agreement with user or customer. Responsible for the whole set of requirements, actors, use cases, etc. Responsible for agreement with user or customer. Responsible for terminology and glossary. Responsible for terminology and glossary. Not necessarily responsible for doing each individual use case. Not necessarily responsible for doing each individual use case.

15. Worker – Use-case Specifier Worker – Use-case Specifier Responsible for detailed description of one or more use cases. Responsible for detailed description of one or more use cases. Works with users of his/her use cases. Works with users of his/her use cases.

16. Worker – Interface Designer Responsible for describing what the user interface will look like for one or more use cases. Responsible for describing what the user interface will look like for one or more use cases. Might do prototypes to show users and to help developers agree on the interface. Might do prototypes to show users and to help developers agree on the interface.

17. Worker – Architect Worker – Architect Architect works in the requirements workflow to describe the architectural view of the use-case model. Architect works in the requirements workflow to describe the architectural view of the use-case model.

18. Figure 7.10 System Analyst System Analyst –Find Actors and Use Cases –Structure the Use-Case Model Architect Architect –Prioritize Use Cases Use-Case Specifier Use-Case Specifier –Detail a Use Case User-Interface Designer User-Interface Designer –Prototype User-Interface

19. Activity – Find Actors and Use Cases

20. Finding the Actors Finding the Actors Make a list of possible actors including people types and outside system types Make a list of possible actors including people types and outside system types For each possible actor, try to identify at least one user or system who will play the roles of the actor. For each possible actor, try to identify at least one user or system who will play the roles of the actor. There should be a minimum of overlap in roles of 2 actors. There should be a minimum of overlap in roles of 2 actors. The 2 actors could be combined into one, or a third actor could be used with the overlapping roles. The 2 actors could be combined into one, or a third actor could be used with the overlapping roles. Examples of actors, page 147. Examples of actors, page 147.

21. Finding the Use Cases Finding the Use Cases Sometimes they can be found from an existing business model. Sometimes they can be found from an existing business model. Workshops with the users. Workshops with the users. Actions that actors perform. Actions that actors perform. Results that actors need (actions from system to user). Results that actors need (actions from system to user). Other functions of the system. Other functions of the system.

22. Finding the Use Cases (cont.) Make list of candidate use cases Make list of candidate use cases Some on the list will not be use cases alone, but add to other use cases Some on the list will not be use cases alone, but add to other use cases For each use case, does it give a result of value to a particular actor? For each use case, does it give a result of value to a particular actor? Through iterations the use cases will change and evolve Through iterations the use cases will change and evolve Some may be modified through negotiations between users and developers to make the system more easily maintained or to add functionality for the user. Some may be modified through negotiations between users and developers to make the system more easily maintained or to add functionality for the user.

23. Briefly Describing Each Use Case For each use case, give it a short name and a longer description that will help in fitting it into the big picture. For each use case, give it a short name and a longer description that will help in fitting it into the big picture.

24. Describing the Use-Case Model as a Whole Diagrams and descriptions Diagrams and descriptions Individual use cases Individual use cases Interactions among use cases and actors Can use packages to put use cases/actors into groups. Interactions among use cases and actors Can use packages to put use cases/actors into groups. Description of the overall model and how it fits together Description of the overall model and how it fits together Informal review by persons not on the requirements/use case team Informal review by persons not on the requirements/use case team

25. Informal Review of Use Case Model All necessary functional requirements have been captured as use cases. All necessary functional requirements have been captured as use cases. The sequence of actions is correct, complete, and understandable for each use case. The sequence of actions is correct, complete, and understandable for each use case. Any use cases that provide little or no value have been identified. If found, these use cases should be reconsidered. Any use cases that provide little or no value have been identified. If found, these use cases should be reconsidered.

26. Activity – Prioritize Use Cases Which use cases need to be developed in early iterations? Which use cases need to be developed in early iterations? Architectural View of the use case model Which are architecturally significant use cases? Architectural View of the use case model Which are architecturally significant use cases? Prioritize all use cases, even those for future iterations. Prioritize all use cases, even those for future iterations.

27. Activity – Detail a Use Case Activity – Detail a Use Case describe the flow of events for each use case in detail. describe the flow of events for each use case in detail. How does the use case start, end and interact with users? How does the use case start, end and interact with users?