Chapter Four

Systems Analysis
(Requirement Analysis)

1
 Contents
1. Introduction
2. Analysis concept
 Entity, boundary, and control objects
 Association multiplicity revisited
 Qualified associations
 Generalization

3. Analysis activities
 Identifying entity objects
 Identifying boundary objects
 Identifying control objects
 Modeling interactions between objects: Sequence
diagrams
 Identifying associations
 Identifying attributes
 Modeling the nontrivial behavior of individual objects
 Modeling generalization relationships between
objects
 Reviewing the analysis model
2
 I. Introduction
 Analysis results in a model of the system that aims to be
correct, complete, consistent, and verifiable.

 Developers formalize the system specification produced

during requirements elicitation and examine in more detail
boundary conditions and exceptional cases.

 We focus on the identification of objects, their behavior, their

relationships, their classification, and their organization.

 Requirements elicitation and analysis are iterative and

incremental activities that occur concurrently.

 Analysis is different from requirements elicitation in that

developers focus on structuring and formalizing the
requirements elicited from users.
3
Cont…
The analysis model is composed of three
individual models:
1. Functional model , represented by use cases and scenarios
2. Analysis object model , represented by class and object
diagrams
3. Dynamic model , represented by statechart and sequence
diagrams.

4
 II. Analysis Concepts
 the main analysis concepts during system
analysis are:

1. Entity, boundary, and control objects

2. Association multiplicity
3. Qualified associations
4. Generalization

5
 1. Entity, Boundary, and Control Objects
The analysis object model consists of entity,
boundary, and control objects [Jacobson et
al., 1999].
 Entity objects: represent the persistent
information tracked by the system.
 Boundary objects: represent the interactions

between the actors and the system.

 Control objects: represent the tasks that are

performed by the user and supported by the system.

E.g. In the 2Bwatch example
 Year , Month , Day are entity objects
 ButtonBoundary and LCDDisplayBoundary are

boundary objects .
 ChangeDateControl is a control object.

6
 Cont…
 Modeling the system with entity, boundary, and control
objects has several advantages.
 First, it provides developers with simple heuristics to
distinguish different, but related concepts.
 Second, the three object type approach results in smaller and
more specialized objects.
 Third, the three object type approach leads to models that
are more resilient to change:
 UML provides the stereotype mechanism to enable the
developer to attach such meta information to modeling
elements.
 Suffix :boundary, control, appended after object name specifies the
type of the object where entity objects are left with out suffix.

7

 2. Association Multiplicity Revisited
Multiplicity indicates the number of links that can
legitimately originate from an instance of the class
connected to the association end.

Most associations belong to one of the following three

types of multiplicity:
one-to-one association
one-to-many association
many-to-many association
Specifying the multiplicity of an association becomes
critical when we determine which use cases are needed
to manipulate the application domain objects.
 E.g. consider a file system made of Directory (ies)
and Files. A
Directory can contain any number of
FileSystemElements. A FileSystemElement is an abstract
8
concept that denotes either a Directory or a File.
Cont…

 Fig. a hierarchical file system.

 A Directory can contain any number of FileSystemElements. A
given FileSystemElement, however, is part of exactly one
Directory.

 Fig. a nonhierarchical file system.

 A Directory can contain any number of FileSystemElements .A
9
given FileSystemElement can be part of many Directory
Cont…
If a system allows a given File to be part of
multiple Directory (ies), we need to define a use
case describing
 how a user adds an existing File to existing
Directory (ies).
 Moreover, use cases removing a File from a
Directory must specify whether the File is removed
from one Directory only or from all Directory (ies)
that reference them.
 Note that a many-to-many association can result
in a substantially more complex system.

10
 3. Qualified Associations
Qualification : is a technique for reducing multiplicity
by using keys.
 Associations with a 0..1 or 1 multiplicity are easier to

understand than associations with a 0..n or 1..n

multiplicity.
 Developers should examine each association that has a

one-to many or many-to-many multiplicity and check if

a qualifier can be added. -qualified association.

 Fig. how a qualified association reduces multiplicity (UML class

diagram). Adding a qualifier clarifies the class diagram and increases the
conveyed information. In this case, the model including the qualification
11
denotes that the name of a file is unique within a directory.
 4. Generalization vs Inheritance
Generalization: enables us to organize
concepts into hierarchies.

Inheritance: is a mechanism for reusing attributes and

behavior, even when the classes involved in the inheritance
do not have a generalization relationship.

During analysis: we only focus on the organization of

concepts into generalization relationships and should not
be interpreted in terms of reuse.

 N.B. The inheritance hierarchy, although initially derived

from the generalization hierarchy, will be restructured
during object design.

12
Cont…

Fig. An example of a generalization hierarchy (UML class

diagram). The root of the hierarchy represents the most
general concept, whereas the leaves nodes represent the
most specialized concepts.
13
 III. Analysis Activities
1. Identifying entity objects
2. Identifying boundary objects
3. Identifying control objects
4. Modeling interactions between objects:
Sequence diagrams
5. Identifying associations
6. Identifying attributes
7. Modeling the nontrivial behavior of individual
objects
8. Modeling generalization relationships between
objects
9. Reviewing the analysis model
14
 1. Identifying Entity Objects
 Participating objects are found by examining each use
case and identifying candidate objects.
 Natural language analysis [Abbott, 1983] is
an intuitive set of heuristics for identifying
objects, attributes, and associations from a
system specification.

Fig. Abbott’s heuristics for mapping parts of speech to model components15

Cont…
Dis adv. Natural language analysis:
 First, the quality of the object model depends highly
on the style of writing of the analyst (e.g.,
consistency of terms used, verbification of nouns).
 Second, there may be many more nouns than

relevant classes. i.e. correspond to attributes or

synonyms for other nouns.
 The following heuristics can be used in conjunction

with Abbott’s rules:

16
Fig. use case: ReportEmergency.
17
Cont…

Fig. Entity objects for the ReportEmergency

use case 18
 2. Identifying Boundary Objects
Boundary objects: represent the system
interface with the actors.
In each use case, each actor interacts with at least
one boundary object.
The boundary object collects the information from
the actor and translates it into an interface
neutral form that can be used by the entity objects
and also by the control objects.
Boundary objects model the user interface at a
coarse level. They do not describe in detail the
visual aspects of the user interface.

19
Cont…
Heuristics for identifying boundary objects

1. Identify forms and windows the users needs

to enter data into the system (e.g.,
EmergencyReportForm, ReportEmergencyButton).
2. Identify notices and messages the system
uses to respond to the user (e.g.,
AcknowledgmentNotice).
3. Do not model the visual aspects of the
interface with boundary objects (user mock-ups are
better suited for that).
4. Always use the user’s terms for describing
interfaces as opposed to terms from the
implementation technology.
20
Cont…

Fig. Boundary objects for the

21
 3. Identifying Control Objects
Control objects are responsible for
coordinating boundary and entity objects.
Control objects usually do not have a
concrete counterpart in the real world.
There is often a close relationship between a use
case and a control object; a control object is
usually created at the beginning of a use case
and ceases to exist at its end.
It is responsible for collecting information
from the boundary objects and dispatching
it to entity objects.
 E.g. control objects describe the behavior
22
Cont…

23
Cont…
 Initially, modeling the control flow of the
ReportEmergency use case with a
control object for each actor; ReportEmergencyControl for the FieldOfficer
and ManageEmergencyControl for the Dispatcher, respectively.

 Fig. Control objects for the ReportEmergency use case 24

 4. Modeling Interactions Between Objects:
Sequence Diagrams
 Sequence diagrams are used to help identify new
participating objects and missing behavior, to ensure
completeness of the system.
 It ties use cases with objects. It shows how the behavior
of a use case (or scenario) is distributed among its
participating objects.
 It allow the developers to find missing objects or grey
areas in the system specification.
 The columns of a sequence diagram represent the objects
that participate in the use case:
1. The leftmost column is the actor who initiates
the use case.(e.g., FieldOfficer)
2. In general, the second column of a sequence
diagram represents the boundary object with
which the actor interacts to initiate the use case25
(e.g., ReportEmergencyButton).
Cont…

26
 Cont…

Fig. Sequence diagram for the ReportEmergency use

case (initiation from the FieldOfficerStation
27
side).
Cont…

Fig. Sequence diagram for the ReportEmergency use case

(DispatcherStation). 28
Cont…

Fig. Sequence diagram for the ReportEmergency use case

(acknowledgment on the FieldOfficerStation).
29
Cont…

Fig. Refined ReportEmergency use case.

30
Cont…

Fig. Acknowledgment object for the ReportEmergency

use case

31
Cont…
N.B. Using sequence dig, we not only model the
order of the interaction among the objects, we also
distribute the behavior of the use case. In
other terms, we assign to each object
responsibilities in the form of a set of operations.
Note: that the definition of an object that is shared
across two or more use cases should be identical.
In other terms, if an operation appears in more
than one sequence diagram, its behavior
should be the same.
Sharing operations across use cases allows
developers to remove redundancies in the
system specification and to improve its
consistency. 32
 5. Identifying Associations
 An association shows a relationship between two or more
classes.
 Sequence diagrams allow developers to represent
interactions among objects over time, class diagrams allow
developers to describe the spatial connectivity of objects.
 Identifying associations has two advantages:
1. It clarifies the analysis model by making
relationships between objects explicit (e.g., an
Emergency Report can be created by a FieldOfficer or
a Dispatcher).
2. It enables the developer to discover boundary cases
associated with links. Boundary cases are exceptions
that need to be clarified in the model.
 Initially, the associations between entity objects are the most
important, as they reveal more information about the
application domain.
33
Cont…

34
Cont…
The object model will initially include too many
associations if developers include all associations
identified after examining verb phrases. Adding
unnecessary associations complicates the model.

 Fig. Eliminating redundant association. The receipt of an

EmergencyReport triggers the creation of an Incident by a
Dispatcher. Given that the EmergencyReport has an association
with the FieldOfficer that wrote it, it is not necessary to keep an 35
 6. Identifying Attributes
Attributes are the knows or properties of
individual objects.
 E.g. EmergencyReport, has an emergency type, a
location, and a description property.

Fig. Attributes of the EmergencyReport class.

When identifying properties of objects, only the

attributes relevant to the system should be
considered.
36
 E.g. FieldOfficer has an attribute social security
Cont…
N.B. Developers should identify as many
associations as possible before identifying
attributes to avoid confusing attributes and
objects.
Attributes have:
1. Name: identifying them within an object.
E.g. EmergencyReport object has attributes:
 emergencyType(e.g., fire, traffic, other)
 reportType(e.g. initial report, request for resource,
final report)
2. A brief description.
3. A type: describing the legal values it can
take.
E.g. The emergencyType attribute is an
enumeration that can take one of three 37
Cont…
 Abbott’s heuristics-noun phrases followed by a
possessive phrases (e.g., the description of an
emergency) or an adjective phrase (e.g., the emergency
description) should be examined.
 In the case of entity objects, any property that needs to be
stored by the system is a candidate attribute.
 Note that attributes represent the least stable part of
the object model. Often, attributes are discovered or added
late in the development when the system is evaluated by the
users. Attributes can be added later analysis model or
Design phases.

38
 7. Modeling the Nontrivial Behavior of
Individual Objects
Sequence diagrams are used to distribute
behavior across objects and to identify
operations.
Sequence diagrams represent the behavior of
the system from the perspective of a single
use case.
Statechart diagrams: represent behavior
from the perspective of a single object.
Adv. of state chart representation:
 To identify missing use cases
 Provide more-formal description of the behavior of

the object.
39

Cont…

Fig. displays a statechart for the Incident

class.
The examination of this statechart may help the
developer check if there are use cases for40
 8. Modeling Generalization Relationships
Between Objects
Generalization is used to eliminate redundancy
from the analysis model.
If two or more classes share attributes or
behavior, the similarities are consolidated into
a superclass.
E.g.Dispatchers and FieldOfficers both have a
badgeNumber attribute , both are PoliceOfficers who are
assigned different functions.Thus we introduce an abstract
PoliceOfficer class from which the FieldOfficer and Dispatcher
classes inherit.

41
 9. Reviewing the Analysis Model
The analysis model is built incrementally and
iteratively.
Once the analysis model becomes stable,
the analysis model is reviewed, first by the
developers, then jointly by the developers and
the client.

The goal of the review is to make sure that the

system specification is correct, complete,
consistent, and realistic.

42
Cont…
Q to check model Correctness:
 Is the glossary of entity objects understandable by
the user?
 Do abstract classes correspond to user-level
concepts?
 Are all descriptions in accordance with the users’
definitions?
 Do all entity and boundary objects have
meaningful noun phrases as names?
 Do all use cases and control objects have
meaningful verb phrases as names?
 Are all error cases described and handled?
 Are the start-up and the shut-down phases of the
system described?
43

Cont…
Q to check model Completeness:
 For each object: Is it needed by any use case?
In which use case is it created? modified?
destroyed? Can it be accessed from a boundary
object?
For each attribute: When is it set? What is its
type? Should it be a qualifier?

For each association: When is it traversed?

Why was the specific multiplicity chosen? Can
associations with one-to-many and many-to-many
multiplicities be qualified?
For each control object: Does it have the
44
Cont…
Q to check model Consistency:

Are there multiple classes or use cases with

the same name?
Do entities (e.g., use cases, classes, attributes)
with similar names denote similar
phenomena?

Are all entities described at the same level of

detail?
Are there objects with similar attributes and
associations that are not in the same
generalization hierarchy?
45
Cont…
Q to check if analysis model is Realistic:

Are there any novel features in the system?

Were there any studies or prototypes built to
ensure their feasibility?

Can the performance and reliability

requirements be met? Were these
requirements verified by any prototypes
running on the selected hardware?

46
Cont…

Fig. UML activity diagram, Analysis activities

47
 IV. Managing Analysis
1. Documenting Analysis
The requirements elicitation and analysis
activities are documented in the Requirements
Analysis Document (RAD).
 Object models, documents in detail all the objects
we identified, their attributes, and, in case we used
sequence diagrams, operations.
 Dynamic models, documents the behavior of the

object model, in terms of statechart diagrams and

sequence diagrams.
 The RAD, once completed and published, will be

baselined and put under configuration management.

48
Cont…
2. Assigning Responsibilities:
Analysis requires the participation of a wide
range of individuals.
There are three main types of roles:
generation of information, integration, and
review.
User: is the application domain expert, who
generates information about the current
system, the environment of the future system,
and the tasks it should support.
 Each user corresponds to one or more actors and
helps identify their associated use cases.

Client: an integration role, defines the scope of

the system based on user requirements. 49
Cont…
Analyst: is the development domain expert,
who models the current system and
generates information about the future
system.
 For a set of use cases, the analysis will identify a
number of objects, their associations, and their
attributes, using the techniques outlined.
Architect: an integration role, unifies the use
case and object models from a system point of
view.
 the role of the architect is necessary to provide a
system philosophy and to identify omissions in the
requirements.
Document editor: is responsible for the low-level
integration of the document. 50
 Cont…
Configuration manager: is responsible for
maintaining a revision history of the document as
well as traceability information relating the RAD.
Reviewer: validates the RAD for correctness,
completeness, consistency, realism, verifiability,
and traceability.
 Users, clients, developers, or other individuals may
become reviewers during requirements validation.

N.B. In the end, the requirements, however large the

system, should be understandable by a single
individual knowledgeable in the application domain.

51
Cont…
3. Communicating about Analysis
Contributing factors which makes the task of
communicating information most challenging are:
1. Different background of participants:- user,
client, developers.
2. Different expectations of stakeholders:-
Users, clients, and managements have different
objectives when defining the system.
3. New teams : refers to the ramp-up period
during which team members must learn to work
together.
4. Evolving system: When a new system is
developed from scratch, terms and concepts
52
 Cont…
Guidelines, which helps in managing the complexity
of conflicting views of the system:
1. Define clear territories: it includes definition of
private and public discussion forums.
2. Define clear objectives and success criteria:
codefinition of clear, measurable, and verifiable
objectives and success criteria by both the client
and the developers.
3. Brainstorm: Putting all the stakeholders in the
same room and having them quickly generate
solutions and definitions can remove many
barriers in the communication.
53
 Cont…
4. Iterating Over the Analysis Model
Analysis occurs iteratively and incrementally
even with the system design and implementation
phases.
The requirements activity can be viewed as
several steps (brainstorming, solidification,
maturity) converging toward a stable model.
Brainstorming: Before any other development
activity is initiated, requirements is a brainstorming
process.
Solidification: Once the client and the developers
converge on a common idea, define the boundaries
of the system, and agree on a set of standard terms,
solidification starts. 54
Cont…
5. Client Sign-off
It represents the acceptance of the analysis
model (as documented by the requirements
analysis document) by the client.
Client and developer agrees not only on the
functionality and features supported by the
system but also on:
 a list of priorities [High, Medium, Low
priorities]
 a revision process
 a list of criteria that will be used to accept or

reject the system

 a schedule and a budget
55
Cont…
Priorities:
High priority—A high-priority feature must
be demonstrated successfully during client
acceptance.
Medium priority—A medium-priority
feature must be taken into account in the
system design and the object design. It will
be implemented and demonstrated in the
second iteration of the system development.
Low priority —A low-priority feature
illustrates how the system could be extended
in the longer term.
56
Cont…

Fig. An example of a revision process (UML

57
activity diagram).
Cont…
Restating the acceptance criteria at sign-off,
the client ensures that the developers are
updated about any changes in client
expectations.

The budget and schedule are revisited after

the analysis model becomes stable.

The acceptance of the requirements analysis

document is more critical than any other
document, given that many activities depend
on the analysis model.
58
Thank You!

59