1. Documenting Requirements using Use Case Diagrams

2. UML Unified Modelling Language Developed by Jacobson (1994)
Set of diagrams and techniques to model object oriented analysis and design.
Use Case diagrams
Activity diagrams
Communication diagrams
Sequence diagrams
Class diagrams
State diagrams

3. Use Case Modelling
Used to document the scope of the system and the developer’s understanding of what the users require.
good for modelling the functional requirements of a system.
A separate list of systems requirements both functional and non-functional should also be maintained.

4. Each use case represents one system activity or task- a well-defined part of the system functionality as seen from a specific user(actor)’s point of view.
They are backed up by behaviour specifications which specify the behaviour of each case using either UML diagrams or sequence diagrams, or in text form as use case descriptions.
Examples
Calculate stock requirements
Create film programme
Create new member
Update member details
Print season report

5. Requirements Gathering: Use Case Diagram shows SCOPE
Source: IBM Rational

6. .

7. .

8. What is the aim of Use Case modelling?
Elicit enough requirements information to prepare a model that communicates what is required from a user perspective.
If user’s requirements change through the life cycle, then the change is initiated in the use case model.
These changes then dictate what changes need to be made to other models.

9. Use Case Diagrams Business requirements – essential use cases Guest
Book
spa
Hotel self service subsystem
Check valid
room number
Order food/
drink
<<includes>>
Request
alarm call
Guest

10. Includes relationship
Use Case Diagrams
Shows subsystem boundary
Use case
Use case 1
subsystem
relationship
Includes relationship
shows
Shared process
Use case 2
<<includes>>
Use case 3
Actor

11. Each Use Case Describes a system function from a user’s perspective
Details business events and users interaction with the system during that event
Represents a system activity, a well-defined part of the system’s functionality
Has a goal
Is initiated by an actor, but can interact with other actors.
Has a more detailed description, possibly specifying a number of scenarios or alternate courses of action ( e.g. documented in a use case template)

12. Types of Use Case
Use cases are initially defined at a high level and successively refined and detailed as the analysis and software development process unfolds.
Essential use case – key business requirements – brief scenario descriptions
Real Use Case – more detail about what actually happens – use case template
What are the users trying to accomplish and why?

13. Business Requirements use case
Quickly document business events to define and validate requirements
Focus on strategic vision and stakeholder goals
System use case
Document use case narratives to more reflect implementation details and detailed system functionality

14. Relationships Association – communication with use case. Order Phone
Customer

15. Relationships: extends
Extends – extract more complex steps into their own use case. An extension use case is used when it extends the functionality of a single use case.
Used to model optional extras, additional functionality in a use case
to model an extension to or variation of a use case.

16. Example : Extends…
Used to specify optional extras, additional functionality
Student registration subsystem
register
Extension points
Late payment
If late payment authorised
<<extends>>
Process late
payment
student

17. Relationships : Include
Include – shows shared processes
Used if the intent is to factor common behaviour into its own use case.
– abstract use case – find 2 or more use cases that have identical functionality

18. Example : Includes… student Library subsystem Examine account
Login
Search online
databases
Search ebrary
<<includes>>
student

19. Note..... Conditions can be shown as UML comments
Arrows always point at the use case that is being included or extended.

20. Relationships : dependency, inheritance
Dependency – depends on – shows sequencing need.
Inheritance.

21. 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

22. Relationships between Actors
Generalisation and specialisation
Example
Campaign manager can do anything a staff contact can do and more – means that his role is a specialisation of a staff contact role.
Inheritance

23. Abstraction Abstracting functionality into super use case - e.g.
Assign staff team
Assign staff member
becomes : Assign staff.
This helps define the functionality and helps cut excessive repetition.

24. Primary business actor benefits from action
System actor – triggers system event
External server actor responds to a request
External receiver actor receives something.

25. Identifying use cases…
What are the main tasks of each actor?
What information does the actor need from the system or provide to the system?
Does the system/actor need to inform the system/actor of any changes?