Documenting Requirements using Use Case Diagrams

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

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.

• 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

Requirements Gathering: Use Case Diagram shows SCOPE

Source: IBM Rational

.

.

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.

Use Case Diagrams

• Business requirements – essential use cases

Guest

Order food/drink

Bookspa

Request alarm call

Hotel self service subsystem

Check valid room number

<<includes>>

Use Case Diagrams

Actor

Use case 2

Use case 1

Use case 3

subsystem

Includes relationship shows

Shared process

<<includes>>

Shows subsystem boundary

Use case

relationship

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)

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?

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

Relationships

• Association – communication with use case.

OrderPhone

Customer

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.

Example : Extends…

Used to specify optional extras, additional functionality

student

register

Student registration subsystem

Process late payment

<<extends>>

Extension pointsLate payment

If late payment authorised

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

Example : Includes…

Search ebrarystudent

Search online databases

Examine accountLibrary subsystem

Login

<<includes>>

Note.....

• Conditions can be shown as UML comments

• Arrows always point at the use case that is being included or extended.

Relationships : dependency, inheritance

• Dependency – depends on – shows sequencing need.

• Inheritance.

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

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

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.

• Primary business actor benefits from action

• System actor – triggers system event

• External server actor responds to a request

• External receiver actor receives something.

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?