Date post: | 20-Dec-2015 |
Category: |
Documents |
View: | 253 times |
Download: | 0 times |
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?