Docstoc

Documenting Requirements using Use Case Diagrams

Document Sample
Documenting Requirements using Use Case Diagrams Powered By Docstoc
					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                         Hotel self
                    Book        service
                                subsystem
                     spa



                  Order food/                 Check valid
                     drink                   room number



                   Request
    Guest          alarm call
        Use Case Diagrams
                                 Shows
                                 subsystem
                                 boundary
        Use
        case                            subsystem
                 Use case 1
  relationship

                              Includes relationship
                 Use case 2          shows
                                 Shared process




                 Use case 3
Actor
                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.




                                    Order
                                    Phone




            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
                                           registration
                                           subsystem

                       register
                   Extension points
                   Late payment
                                      If late
                                      payment
                                      authorised



     student                              Process late
                                            payment
      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…

                            Library
          Examine account   subsystem



          Search online
                                   Login
            databases



student   Search ebrary
                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?

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:9/5/2012
language:Latin
pages:25