1. 1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and Information Technology Based on “Software Requirements Management, A use case approach”, by Leffingwell and Widrig

2. 2 Key Points  Use cases carry the majority of the requirements for the system.  The development team, with user involvement, writes the use cases.  Use cases are built on a common, standard format.  Use cases later drive test case development.

3. 3 The Benefits of Use Cases Why the intense focus on use cases? Because of the following benefits:  Compared to traditional requirement methods, use cases are relatively easy to write and easier to read.  Use cases force developers to think through the design of a system from the perspective of a user.  Use cases engage the users in the requirements process: help them understand the system that is being proposed and give them a way to communicate and document their needs.  Use cases give context for the requirements of the system: One can understand why a requirement is what it is as well as how the system meets its objectives.  Use cases provide an ordering mechanism for requirements: one can tell what has to happen before the next thing happens, and so on.

4. 4 The Benefits of Use Cases  Developers/Designers participate in use cases: They understood requirements  Use cases are a critical tool in the analysis process: help understand what the system needs to do  Use cases are a critical tool in the design and implementation process: reduce the risk of passing from an expression of requirements to a differing implementation  Use cases carry over directly into the testing process: help assure that the system actually does what it was intended to do  Use cases serve as inputs to the user documentation, conveniently organized in a step-by-step format. Use cases simply tell a better requirements story. Use them!

5. 5 Use Cases Basics  A use case describes sequences of actions a system performs that yield an observable result of value to a particular actor.  An actor is someone or something that interacts with the system.

6. 6 Use Cases Basics  Sequences of actions: a set of functions performed, an algorithmic procedure, or any other internal process that produces a result. The set is invoked when the actor initiates the use case by providing some input to the system. An action is atomic; that is, it is performed either entirely or not at all. The atomicity requirement is a strong determinant in selecting the level of granularity of the use case. if an action is not atomic in a use case, the level of granularity should be reduced to a finer level of detail.

7. 7 Use Cases Basics  An actor is someone or something that interacts with the system. Users: Users act on the system, Other systems or applications: Most software we write also interacts with other systems or other applications. This is another primary source of actors. A device: Many software applications interface to a variety of input and output devices. Time: Some use cases are triggered when a specific deadline occurs in the system.

8. 8 Use Cases Basics  A Use Case is a structure of logical elements that work together to define the use case. 4 mandatory elements: Name: Each use case has a unique name describing what is achieved by the interaction with the actor. EX: "Turn Light On/Off" and "Print Document" are good examples. Brief description: The purpose of the use case should be described in one or two sentences. EX: "This use case controls the selected light bank when instructed by the actor Homeowner.“ Actor(s) List each actor that participates in the use case. Flow of events: The heart of the use case is the event flow, usually a textual description of the interactions between the actor and the system.  The main (basic) flow of events  The alternate flows of events

9. 9 Use Cases Basics

10. 10 Use Cases Basics  Optional elements in a Use case: Pre-conditions: Must be present in order for a use case to start. Represent some system state that must be present before the use case can be used. EX: A pre-condition of the "Print Author's Manuscript Draft" use case is that a document must be open. Post-conditions: Describe the state of the system after a use case has run. Represent persistent data that is saved by the system as a result of executing the use case. EX: Post-condition of “Register" use case is that the new data is added in the profile of the student.

11. 11 Use Cases Basics Other stakeholders: Other key stakeholders who may be affected by the use case. EX: A manager may use a report built by the system, and yet the manager may not personally interact with the system in any way and therefore would not appear as an actor on the system. Special requirements: A use case may also refer to special requirements. EX: performance or throughput requirement ("support up to 100 simultaneous users") that applies to the specific use case

12. 12 Use-Case Specification Template

13. 13  Use-Case Specification Template: Use-Case Name Brief Description Name of System/SubSystem Flow of Events  Basic Flow  Alternative Flows First alternative flow Second alternative flow

14. 14 Use Cases Basics Special Requirements Pre-conditions Post-conditions

15. 15 Use Case Basics  Other templates (see word documents)

16. 16 Use Case Basics Use case consists of 2 parts: Use-case diagram – a diagram that depicts the interactions between the system and external systems and users.  graphically describes who will use the system and in what ways the user expects to interact with the system. Use-case narrative – a textual description of the events and how the user will interact with the system to accomplish the task.

17. 17 Use Case Basics

18. 18 Use Case Basics

19. 19

20. 20

21. 21

22. 22

23. 23

24. 24 A Step-by-Step Guide to Building the Use-Case Model  Step 1: Identify and Describe the Actors Who uses the system? Who gets information from this system? Who provides information to the system? Where in the company is the system used? Who supports and maintains the system? What other systems use this system?

25. 25 A Step-by-Step Guide to Building the Use-Case Model  Step 2: Identify the Use Cases and Write a Brief Description What will the actor use the system for? Will the actor create, store, change, remove, or read data in the system? Will the actor need to inform the system about external events or changes? Will the actor need to be informed about certain occurrences in the system?

26. 26 A Step-by-Step Guide to Building the Use-Case Model  Step 3: Identify the Actor and Use-Case Relationships Only actors can initiate a use case Many use cases may involve the participation of multiple actors. Each use case is analyzed to see what actors interact with it

27. 27 A Step-by-Step Guide to Building the Use-Case Model  Step 4: Outline the Individual Use Cases Basic flow:  What event starts the use case?  How does the use case end?  How does the use case repeat some behavior? Alternate flow:  Are there optional situations in the use case?  What odd cases might happen?  What variants might happen?  What may go wrong?  What may not happen?  What kind of resources can be blocked?

28. 28 A Step-by-Step Guide to Building the Use-Case Model  Step 5: Refine the Use Cases (Can be done later) All alternate flows, including exception conditions Pre- and post-conditions

29. 29 Use case diagram: refinement

30. 30 Use case diagram: refinement

31. 31 Use case diagram: refinement

32. 32 Use case diagram: refinement Extension use case –use case consisting of steps extracted from another use case to simplify the original. Extends the functionality of the original use case. Generally not identified in the requirements phase Extends relationship represented as arrow beginning at the extension use case and pointing to use case it is extending. Labeled >.

33. 33 Use case diagram: refinement Abstract use case – use case that reduces redundancy in two or more other use cases by combining common steps found in both. Available for any other use case that requires its functionality. Relationship between abstract use case and use case that uses it is called a uses (or includes) relationship. Depicted as arrow beginning at original use case and pointing to use case it is using. Labeled > or >.

34. 34 Depends On – use case relationship that specifies which other use cases must be performed before the current use case. Can help determine sequence in which use cases need to be developed. Depicted as arrow beginning at one use case and pointing to use case it depends on. Labeled >.

35. 35 Use case diagram: refinement

36. 36 Steps in Building A Use case diagram 1. Identify the actors 2. Draw the system boundary 3. Identify Use Cases 4. Place Use Cases on the diagram - G roup Use Cases into packages - Add Use Case relationships 5. Add associations