Documenting Requirements using Use Case Diagrams - PowerPoint PPT Presentation

Loading...

PPT – Documenting Requirements using Use Case Diagrams PowerPoint presentation | free to download - id: 6ca043-MzQ0M



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Documenting Requirements using Use Case Diagrams

Description:

Documenting Requirements using Use Case Diagrams UML Unified Modelling Language Developed by Jacobson (1994) Set of diagrams and techniques to model object oriented ... – PowerPoint PPT presentation

Number of Views:18
Avg rating:3.0/5.0
Date added: 5 March 2020
Slides: 26
Provided by: ther103
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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?
About PowerShow.com