CSE400 SOFTWARE ENGINEERING FOR
REAL–TIME SYSTEMS
CHAPTER 3
(REQUIREMENTS
SPECIFICATION)
• 3.1 Use Cases
• 3.2 Use Case Diagram
• 3.3 System Context Diagram
Introduction
• This chapter describes how to represent the requirements in a
way that supports software development.
• The correspondent description is called the system requirement
specification.
• Fig. 3.1 shows the focus of this chapter. The system requirements
specification of the OCTOPUS method primarily includes a
structured organization of use cases and the system context
diagram.
Subsystem Analysis Phase
Figure 3.1 – The system requirement phase
3.1 Use Cases
• Use cases have been advocated by Jacobson (Jacobson ‘92).
• Use case are analogous to the script of a play.
• They describe the role of each actor in the play and how the
actors behave in a scenario.
• Unlike plays, use cases are alternative and repetitive.
• However, it is often useful to check their completeness by
combining them in a natural order and checking if they actually
cover way to use the system.
3.1 Use Cases
• Use cases treat the system to be built as a black box.
• Each use case describes a particular way of using the system.
• Use cases are goal-oriented.
• They describe how the system can be used to achieve the desired
results.
• Since any system has a finite set of goals to meet, the number of
use cases is always limited.
3.1 Use Cases
• A recommended practice for finding the use case of a system is to
consider all external agents that interact with it.
• These agents may be humans or other computers.
• While interacting with the system, each agent may play different
roles.
• An agent playing a role is called an actor.
• Since the role determines the context of usage, use cases are
associated with actors.
3.1 Use Cases
• Actors can be classified in several ways :
Active/Passive
Each use case is initiated by one actor. Some of the actors are passive.
They participate in use cases, but never initiate one.
Client /Nonclient
Actors either use the system for a certain purpose of just affect it.
Primary/Secondary
Secondary actors, like operators, only exist so that the primary actors can
use the system. Requirements should be written from the primary actors’
perspective in order to make the system user-centred.
3.1 Use Cases
• The information about the usage of the system is recorded on a use case
sheet such as in Fig.3.2.
• Use cases should show how the system works from the user perspective.
• Emphasize the effects of the operation
• Each use case is numbered to make referencing easier.
• Try to describe the intent of each use case clearly.
• Record any time requirements.
• Record the final effects of the operation in the postconditions.
• The preconditions should explain when the use case is applicable. If the
preconditions are satisfied, the system will eventually fulfil the postconditions,
unless some of the exception occur.
3.1 Use Cases
Figure 3.2 – Use case sheet
3.2 Use Case Diagram
• Use cases can be hierarchically composed from parts.
• Use cases not only have sub use cases, but they often share
exceptions or subactivities.
• If this hierarchy is utilized, specification is shorter and easier to
understand.
• Hierarchy can be visualized un a use case diagram using the
notation of the object diagram (Fig. 3.3).
• The diamonds in Fig 3.3 denote “parts of” relations and the names
indicate whether the parts are sub use cases, subactivities or
exceptions.
3.2 Use Case Diagram
Figure 3.3 – Services provided to the primary actor, the driver
3.2 Use Case Diagram
• The identification of use cases, the development of the structure
of use case diagrams and the specification of use cases are
interleaved activities.
• The use cases will later be restructured.
3.3 System Context Diagram
• Use cases help in specifying the functionality of the system.
• Also requires the analyst to think and define what actors are using
the system.
• The information is used to construct the system context diagram,
which gives a structural overview of the system’s environment.
• The context diagram shows the actors and how they are related to
the system.
• OCTOPUS enhances the expressiveness of the context diagram,
by allowing it to show important relationships between the actors.
3.3 System Context Diagram
• Fig 3.4 shows the Cruise Control System context diagram, which
demonstrates a number of interesting relationships between its actors.
Figure 3.4 –Cruise Control system context model
3.3 System Context Diagram
• The level of detail in the system context diagram can vary, but it
should always contain all the actors mentioned in the use cases of
the systems.
• If does not matter if an actor is primary or secondary, active or
passive, client or nonclient.
