1. Use cases and requirement specification - 1 Use case diagrams 3 use cases System boundaries Remember: Use case diagramming is a tool, not the requirements. Requirements are text descriptions (scenario’s) Cbf, 2005-09-09from http://www-128.ibm.com/developerworks/wireless/library/wi-arch9/

2. Use cases and requirement specification - 2 Actors An actor is a person or system outside of your application that will interact with it. Actor inheritance Cbf, 2005-09-09from http://www-128.ibm.com/developerworks/wireless/library/wi-arch9/

3. Use cases and requirement specification - 3 Actors and Use cases You might choose to use one or several use case diagrams to model your system. For more complex systems it is a good idea to draw several rather than attempting to contain too much information in a single diagram. Putting everything into one diagram can make the diagram difficult to read. Cbf, 2005-09-09from http://www-128.ibm.com/developerworks/wireless/library/wi-arch9/

4. Use cases and requirement specification - 4 Documenting the use case - 1 Name: A brief, descriptive, and unique name for the use case. Description: A short description of what the use case does. Actors: A list of all the actors that interact with the use case. Priority: A short description of how important the use case is in the overall scope of the application. Knowing the priority of each use case lets you design the architecture accordingly. Status: Notes how complete (or incomplete) the development of the use case is. Preconditions: A list of conditions that must be true before the use case starts. Postconditions: A list of conditions that must be true after the use case is complete. Use case interactions: Identifies other use cases the use case interacts with or relies upon. Cbf, 2005-09-09from http://www-128.ibm.com/developerworks/wireless/library/wi-arch9/

5. Documenting the use case - 2 Flow of events: A list of events that happen during the execution of the use case. This could also contain alternative paths. Activity diagram: An activity diagram or diagrams of the flow of events or some part of the flow of events. Secondary scenarios: If the flow of events contains only a primary scenario, then here secondary scenarios might also be documented. User interface: A simplified picture of the user interface for the use case. A prototype of the user interface helps the development team see if the design is on the right track. Sequence diagrams: Sequence diagrams of the different scenarios. View of participating classes: A diagram of all the classes whose instances work together to implement the use case. Other requirements: Other requirements might include quality attributes if you do not have a specific document for them. Use cases and requirement specification - 5 Cbf, 2005-09-09from http://www-128.ibm.com/developerworks/wireless/library/wi-arch9/

6. Use cases and requirement specification - 6 More diagrams ! Activity diagram - Participating Sequence diagram classes Cbf, 2005-09-09from http://www-128.ibm.com/developerworks/wireless/library/wi-arch9/