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 Book spa Hotel self service subsystem Check valid room number Order food/ drink <<includes>> Request alarm call Guest

Includes relationship Use Case Diagrams Shows subsystem boundary Use case Use case 1 subsystem relationship Includes relationship shows Shared process Use case 2 <<includes>> 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 <<extends>> Process late payment student

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… student Library subsystem Examine account Login Search online databases Search ebrary <<includes>> student

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?