Documenting Requirements using Use Case Diagrams

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
  developers 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 users 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

Book spa
Hotel self service subsystem
Check valid room number
Order food/ drink
ltltincludesgtgt
Request alarm call
Guest
10
Use Case Diagrams

Shows subsystem boundary
Use case
Use case 1
subsystem
relationship
Includes relationship shows Shared process
Use case 2
ltltincludesgtgt
Use case 3
Actor
11
Each Use Case

• Describes a system function from a users
  perspective
• Details business events and users interaction
  with the system during that event
• Represents a system activity, a well-defined part
  of the systems 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
ltltextendsgtgt
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

Examine account
Library subsystem
Login
Search online databases
ltltincludesgtgt
Search ebrary
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?