1. Adding the Detail Filling in Use Case Templates

2. Use Case Template The use case diagram is important for visualizing a system and as a communication tool. Use case templates provide a detailed description of each use case including the flow of events. NB* written in terms of what the system should do, not how the system does it.

3. Use cases can be used in different situations e.g. to describe a business' work process, to focus discussion about upcoming software system to be the functional requirements for a system to document the design of the system. They might be written in a small, close-knit group, or in a formal setting, or in a large or distributed group. Each situation calls for a slightly different writing style and level of detail.

4. Tools we can use to help us fill in the template Storyboards(useful for games, subsequent prototyping) Written scenarios (stories) Activity diagrams (see IBM rational example of courseware management)

5. Source: IBM Rational

6. Characters in our story: Who are the stakeholders? Anyone who is affected by or who has an interest in the system.

7. Who are the Actors? Stakeholders Who provide inputs to system Who receive outputs from system Who trigger events in the system Who maintain the information in the system Actors are outside the system

8. About Actors and Goals Actors have goals Goals can be different levels: summary, user goals or subfunctions An actor triggers a use case when they want to achieve their goal. To achieve a goal there are many steps Goals can fail User goals : the cup of coffee test

9. Some steps 1. Actors & Goals. List the actors and which of their goals the system will support. Review this list, for accuracy and completeness. It is important to know the level of the goal.

10. 2. Main success scenario. For all use cases identified, write the trigger and outline the main success scenario. Review these in draft form to make sure that the system really is delivering the interests of the stakeholders you care about.

11. 3. Failure conditions Go through the steps of the main scenario and brainstorm all the failures that could occur. Note any open issues/ambiguities that you might need to ask questions about. Draft this list completely before working out how the system must handle them all.

12. 4. Failure handling Determine how the system is supposed to respond to each failure – again, this might involve noting these as open issues which might need resolution and thus having to ask more questions. These go down as extensions. Might reveal a new actor or a new goal that needs to be supported.

13. Scenarios A scenario is a sequence of actions that illustrates the behaviour of a system Tell a story or draw a storyboard or use an activity diagram to figure out the detail of how the actor gets or doesn’t get the goal descriptive stor Each scenario starts from a triggering condition e.g. User clicks on BOOK FLIGHT A scenario mostly has a main storyline that will be what happens in ideal conditions e.g. The steps I take leading to me I successfully booking a flight. e.g. The steps I take when I make a move in a chess game.

14. Alternative storylines might occur e.g. A flight is unavailable, is too expensive so I abandon the process and fail to achieve my goal e.g. my King is in check so I can’t make the move I want e.g. I walk into a brick wall or get shot by a gremlin... -a set of scenario fragments as extensions are specified to show what happens in different situations.

15. Example : get out of jail scenarios Use Case : Get Out of Jail Precondition: The player is in Jail. Trigger: Player clicks the “Get out of Jail” button. 1.Main Success Scenario: €50 is decremented from their money. The player can then roll the dice and continue with the game. 2. Alternative (failure) scenario The player clicks the “Get out of Jail” button. The player has less than €50. The player becomes bankrupt and all the tradable cells he or she owns becomes available in the game. The player is out of the game.

16. Subflows Some use case templates include subflows i.e. small scenarios which deal with subgoals. Extensions describe e.g. failure situations or situations where. SubVariations are where there can be different ways of doing things. Sometimes technical variations are specified. Use case templates can refer to other use cases

17. USE CASE # Goal in Context Scope & Level Preconditions Success End Condition Failed End Condition Primary, Secondary Actors Trigger DESCRIPTION EXTENSIONS SUB-VARIATIONS (use if there is more than one alternate option when specifying extensions above) None OPEN ISSUES

18. “With scenario-based requirements elicitation, we query the stakeholders for the kinds of things they want to be able to do. We ask them to describe how they envision the system in use. We then map these system problem statements into a system specification; the specification is represented as a set of actors and use cases, as we discuss below. “ Williams 2004

19. Who uses the system? Who installs the system? Who starts up the system? Who maintains the system? Who shuts down the system? What other systems use this system? Who gets information from this system? Who provides information to the system? Does anything happen automatically at a present time?

20. What functions will the actor want from the system? Does the system store information? What actors will create, read, update or delete this information? Does the system need to notify an actor about chances in the internal state? Are there any external events the system must know about? What actor informs the system of those events?