1. The Next Stage in Analysis: Systems Use Case Diagrams

2. The process we have followed so far to discover the requirements of the system
Draw Business Use Case Diagram to capture the Business Processes
Write Business Use Case Descriptions
Fact Finding
Interviewing the Client for Technical, Functional Data Requirements

3. Identifying Actors and Systems Use Cases
Requirements Gathering
Need to find out what the user requires in the system (user’s needs)
Allows the Analyst to clearly understand the user’s requirements
Need to describe the interaction between users of the system and the system itself
Describes what the system is to do, not how it is going to do it (features)

4. The next part of the Process
Systems Use Case Diagrams
Systems Use Case Descriptions

5. Systems Use Case Diagrams, Dialog Charts & Systems Use Case Descriptions
Based on the dialog metaphor

6. Dialog Expresses that the User and Computer
Interact by Sending Messages

7. Documenting Dialogs Many methods exist for documenting Dialogs
Systems Use Case diagrams: the dialog between the actor and the system
Written descriptions such as systems use case descriptions or scenarios
Sketches of screens, i.e. storyboards
Dialog charts

8. Systems Use Case
“Visual representation of the dialog between the actor and the system
The ellipse is a graphical
representation of a use case
It is a placeholder for a description of how the system and its actors interact”*
*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 23

9. Actors “Can represent humans or other systems
Define the roles that users or other systems play when interacting with the system
Are outside the system, and usually outside the control of the system
Impose requirements on what the system being built must do”*
* Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 22

10. Actors
System Boundary

11. Actors User Applications Devices Time Events
Somebody who maintains the data, uses the data or generates reports
Applications
External processes or software systems ( interface)
Devices
External sensors (printers, scanners)
Time Events
System clock

12. UML Notation Actors are represented in UML by a ‘stick’ person
“I am an actor. I play a role that involves using the system. I
am outside of the system.”
“My name indicates my role.”
Order Clerk
“I can be a person, a department, a system, hardware, scheduler, and so on”.

13. Systems Use Case
“Each use case delivers something of value to at least one of the actors.
The concepts of actor goals and the delivery of value to the actors are fundamental to the successful discovery, definition, and application of use cases.”*
*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p.

14. Systems Use Case
“The use case should reflect the goals of the actors and enable, at least in part, their achievement”*
* Use Case Modeling, Kurt Bittner & Ian Spence, Addison Wesley, 2003, p. 23

15. Systems Use Case
A concrete value can be put on the successful performance of a use case. Every use case should have an easily understandable and clearly identifiable value*
* Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 23

16. Systems Use Case
“The actors use the system only if it enables them to do something that they want to do
The actors perform a use case only if doing so helps them achieve one of their goals. The physical manifestation of the goal is the value that the use case delivers to the actor.”*
Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 23

17. Systems Use Case Diagram
“Visual representation of the dialog between the actor and the system
The system and its actors interact by sending signals or messages to one another”*
*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 25

18. Systems Use Case Diagram
“To indicate such interactions, we use a communicate association
between the use case where the
interaction occurs and the actors
involved in the interaction”. *
* Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 25

19. System Use Case Diagram
“The communicate association represents a dialog between the actor and the system, a kind of communication channel over which data flows in both directions during the dialog.”*
*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 26

20. Systems Use Case Diagram
“A use case has at most one communicate association to a specific actor, and an actor has…one communicate association to a specific use case, no matter how many interactions there are”*
*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 25

21. System Use Case Diagram
System Boundary

22. Systems Use Case Diagram
“The complete network of such associations provides a static picture of the communication between the system and its environment.”* (the boundaries of the system)
*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, pp

23. Systems Use Case Diagram
“The use case starts when an actor does something, causing the system to do something in response. This dialog continues…until the system has done something useful for at least one actor.”*
*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 24

24. Actors communicate with the system
“To start the use case
To ask for some data stored in the system, which the use case then presents to the actor
To change data stored in the system by means of a dialog with the system
To report that something special has happened in the system’s surroundings that the system should be aware of”*
*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 26

25. Systems Use Case diagrams
One actor initiates a use case. However, after the use case has started, the use case can communicate with several actors.*
*Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 26

26. Use cases communicate with the Actor
“To report that something special has happened in the system that the actor should be aware of
To ask an actor for help in making a decision needed to achieve a goal
To delegate responsibility to an actor”*
Use Case Modeling, Kurt Bittner & Ian Spence, Addison-Wesley, 2003, p. 26