Chapter 7 - Requirements Engineering - Use cases

Gathering requirements

Many different perspectives:

  • Manager
  • Administrator
  • Operator
  • Director
  • Purchaser
  • etc...

Requirements engineering

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed

A requirement is a feature that a system must have or a constraint that is must satisfy to be accepted by the client. It may range from a high level abstract statement of a service or of a system constraint to a detailed mathematical functional specification.

Requirements engineering has two main activities.

  1. Requirements elicitation
  2. Requirements analysis

Difficulties with requirements elicitation

This requires collaboration between domain experts and technical experts (deelopers, clients, users). Hard to anticipate the effects that the new system will have on the organisation. Different users may have different requirements and priorities. System end users and organisations who pay for the system may have different requirements. There may also be natural language problems, where the customers may not be able to express what they want in words, even though they know what they want.

How requirements are elicited


Allow for details, first hand information gathering. This is expensive, however.

The structured interview can have different points of focus. There can be open discussion, but the structured discussion will get the main points that are required. A case study could be part of a focussed discussion, and looking at specific cases and scenarios that the system may be under.

The interviewer may give their idea of what they woud do, and then ask the customer to give a critique on the idea.


These are good if many people are involved, especially if dispersed across the organisation. They tend to have poor responses though.


This is accurate if done well: in that you get to see first hand what the clients are actually doing. This is also expensive, however. You get an impression of what they currently do, and the problems they are having that the software to be developed should solve.

Joint application design:

Workshops with clients facilitate consensus on requirements. Meetings may mean that clients are away from their workspace.

A customer may send some of their users to the place where the software is being developed to be part of the development team.

Typical requirements in the elicitation process

  • Identify actors
    • Types of user who interact with the system
  • Identify scenarios
    • Concrete examples of how the system will be used
    • Used to communicate with users about the requirements for the system
  • Identify use cases
    • Description of all possible behaviour in the system
    • These are abstractions unlike scenarios which are specific examples
  • Refine use cases
    • Ensure completeness including exceptions/error paths
  • Identify relationships among use cases
    • Factor out common functionality
    • Find dependencies
  • Identify non functional requirements


Requirements definition

A statement in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.

Requirements specification

A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor. For customers and developers.

Requirements documents

There are many different approaches to this. Typically grouped by feature. Requirements definition describes the requirements at a high level. The requirements specification gives the details for each function.

  • Name
  • Pre-conditions
  • Inputs
  • Source
  • Function description
  • Outputs
  • Post-conditions

Remember to look up the IEEE requirements engineering standard: ISO/IEC/IEEE 9148:2011

UML - Use case modelling

Use cases describe system behaviour that is visible to a user or to another system. Use ases are initiated by users or systems called actors. An actor represents anything that needs to interact with the system to exchange information - it may be a role a user plays or another system. In the diagram, actors are typically kept around the edges of the diagram.

Each use case is a significant set of sequences of interactions between the actor and system. It yields an observable result of value to the actor.

Use case diagrams represent an overview of the actors of the system and the behaviour that the system provides for them. The acto initiates system activity, a user case, for the purposes of completing some task.

If an external party initiates the input, it is considered an actor:

  • Potential human users of the system. Identify their roles
  • Interactions with external systems

Use cases do not describe the internal details of the software system. Even though they are likely to influence the form it eventually takes. They mipose constraints on designers who have to meet their functionality.

Describing use cases

Describe the course of events. Cover all possible events, especially where things can go wrong. The UML does not define a standard way to describe use cases in text form.


  • Name (short verb phrase)
  • Summary (description)
  • Actors
    • Primary actor (the one who initiates the use case)
    • All others involved
  • Triggers - events that start the user case
  • Pre-conditions - must be true before the use case can start
  • Post-conditions - will be true after the use case has finished
    • Minimumal guarantees (all cases)
    • Success guarantees (normally)
  • Flow of events (as a numbered list)
  • Alternative or exceptional flow of events - usually "At [point number] x... "
  • Extension points - where another use case can take over
  • Inclusions - summarises use cases that are included in this one.

Use case inclusion

Used where two use cases have shared behaiour. (Note that this is not inheritance, it is inclusion)


Example, new flow of events for record booking

  1. The receptionist performs the 'display bookings' use case - may be written as include(Display bookings) or include 'display bookings'
  2. The receptionist enters the customer name and phone number, the time of booking, the number of covers and table number
  3. The system records and displays the new booking

Watch out for copying and pasting use case points in multiple use cases. It is likely that it should include the original use case.

Actor generalisation

Eg from above.

The receptionist and the head waiter both can call the use case "Display Bookings". To simplify, introduce a generalised "Staff" actor. Thus, receptionist is a specialisation of staff, and head watier is a specialisation of staff. Receptionist is a subclass of staff, and staff is the super class of receptionist.


Use case extension

Record Arrival has an alternative flow where there is no booking for a customer and the customer must be booked as a 'walk-in'

Better to create a separate use case (with its own description) for the extension, and to indicate (in the description of the base use case, record arrival) where the 'extension point' occurs and when it is used.


Final restaurant use case diagram



Next steps

Build a domain model. Going from requirements design to system design. A class diagram is a good way to describe business concepts.


See Emergency response system example in slides

Example <<extend>>


The bahviour of ConnectionDown will extend the behaviour in OpenIncident if required. This use case extends the OpenIncident and AllocateResources use cases, automatically initiated if the network connection between FieldOfficer and Dispatcher is lost.

Use case guidelines

Use cases are often named with verb phrases. Actors are nounds. Steps are in active voice, where the subject is the agent of the action). It describes a complete transaction. Exceptions are separated out (as Alternative Flows or as 'extends')

Do not describe the interface in detail. Use extend for optional or exceptional behaviour. Use include for shared behavior that is always included in the normal flow.

Non-functional Requirements

Requirements that define what the system should do are called functional requirements. Non-functional requirements define system properties and constraints. Process requirements may also be specified mandating a particular computer assisted software engineering system, programming language or development method. Non functional requirements mat be more critical than the functional requirements. In some cases, if they are not met, the system is useless.


  • Reliability
  • Security
  • Availability
  • Maintainability
  • Portability
  • Performance