REQUIREMENT ANALYSIS AND SPECIFICATION

(Sec-B, Unit -3)

Dr. Jyoti Chaudhary

A.P , Department of Computer Engg.
TIT&S Bhiwani
 Requirement Engineering
• Provides a mechanism to understand what the
customer wants, analyzing the needs,
assessing feasibility, negotiating reasonable
solution, specifying solution unambiguously,
validating specifications, managing the
requirements as they are transformed into an
operational solution.
 R.E includes 7 steps
1. Feasibility Study /Inception
2. Rqmt. Elicitation/ Gathering
3. Rqmt. Analysis & Negotiation
4. Rqmt. Specification
5. System Modeling
6. Rqmt. Validation
7. Rqmt. Management
 1. Feasibility Study /Inception
• Involves answers to questions like:
• Why the s/w product/ project is started?
(Need of hour, one time event , business
need? Etc)
• Develop basic understanding of problem:
scope/feasibility/return/stability in market etc.
 2. Requirement Elicitation (gathering)
• Ask the customer/user/others – about the
objective for product/system.
• It’s a difficult task b’coz there exists lot of
problems like:
– Problem of Scope
– Problem of Understanding
– Problem of Volatility
To overcome these Sommerville & Sawyer
suggested guidelines for Rqmt Elicitation
• Assess Business & technical feasibility
• Identify People
• Define technical environment
• Indentify domain constraints
• Define one / more rqmt elicitation methods
• Solicit participation from many people
• Identify ambiguous rqmt. (For prototyping)
• Create usage scenarios
 3. Rqmt. Analysis & Negotiation
• Rqmt Analysis categorizes rqmts. into related
subsets, explores each rqmt in relationship to
others
• Examines rqmts. for consistency, omissions &
ambiguity.
• Ranks rqmts. based on the customer’s/ user’s
need
 As this phase commences following
questions are asked
• Is each rqmt consistent?
• Have all the rqmts been specified at proper level
of abstraction?
• Is rqmt unambiguous?
• If rqmt actually needed?
• Do any rqmt conflict with other rqmt?
• Is the rqmt testable? Once implemented
• Is the rqmt achievable in technical environment?
 4. Requirement Specification
• Rqmt Specification may be in different form , it can
be a written document, a graphical model, formal
mathematical model, prototype or combination of
these.
• We should use Standard Template for rqmt
specification b’coz it helps in presenting the rqmts
in a more consistent and understandable form.
• For large systems a written document (with graphics
& natural language ) may be the best approach.
• For small systems usage scenarios may be sufficient.
 System Specification (outcome of rqmt
specification)
• It is the final work product produced by the
system and rqmt engineer.
• It serves as foundation of H/w, S/w, Database,
Human engineering
• It specifies functionality & performance of the
system and the constraints on it.
• Also defines the information that is input to
and the output from the system.
 5. System Modeling
• A blue print or 3D rendering of the system is
developed, since written document is not
enough to visualize the system.
• It is done to more clearly understand the
workflow/ relationship to one another .
• Also to determine how rqmt fit into the
picture.
 6. Requirement Validation
• Work product produced after the rqmt Engg.
are assessed for quality in this phase.
• It examines the specification to ensure that all
the system rqmt have been stated un
ambiguously & inconsistencies / omissions /
errors have been detected and corrected.
• Also the work products are according to the
standards established for process, project and
product
 Validation Mechanism : Formal Technical
Review(FTR)
• Review team: System Engineers, Customers ,
Users etc.
• They examines the system specifications for :
error/ misinterpretations/ omissions /
ambiguity /conflict / unrealistic rqmts etc.
• Checklist of questions is framed and each
rqmt is checked against it.
 Checklist Questions Subset :

• If rqmt testable? If yes specify tests.

• Are rqmts clear?
• Is the source of rqmt identified?
• If rqmt related to other rqmts. ?
• If rqmt violate any domain constraint?
• If rqmt traceable to any system model that
have been created?
 7. Requirement Management
• It involves a set of activities that help the project
team to identify , control and track the rqmts and
changes to rqmts at any time as the project
proceeds.
• Each rqmt is assigned a unique number/ identifier.
• <rqmt type> <rqmt #>
• Rqmt type can be : D(data rqmt),F( Functional) ,
B(Behavioral ), I ( Interface ) P(Output)
• Example F09
 Traceability Table
• Once rqmts are identified traceability table are
maintained.
– Feature Traceability Table (how rqmt related to important
customer / product features)
– Source Traceability Table (Identifies source of each
requirement)
– Dependency Traceability Table (how rqmt related to one
another)
– Interface Traceability Table (how rqmt related to internal
and external interface)
– Subsystem Traceability Table (Categorize rqmt by
subsystem they govern)
 Traceability Table
Requirements Specific aspect of the system or Environment
A01 A02 A03 A04 ……. Aii
R01 √
R02 √ √
R03 √ √ √
R04 √
R05 √ √
:
Rnn
System Modeling
 Fig.
World View Business/Product System Engg. Hierarchy
Domain

H/W S/W DATA

Domain
View

Element DATA FUNCTION BEHAVIOR

View

Detail PROGRAM MODULE CLASS

View

WV= {D1,D2,D3…} DV i ={E1,E2,E3,….} EVj ={C1,C2,C3,…}

 System Engineering Hierarchy
• Stated in a slightly more formal manner,
• the world view (WV) is composed of a set of domains (Di), which can
each be a system or system of systems in its own right.
WV = {D1, D2, D3, . . . , Dn}
• Each domain is composed of specific elements (Ej) each of which
serves some role in accomplishing the objective and goals of the
domain or component:
Di = {E1, E2, E3, . . . , Em}
• Finally, each element is implemented by specifying the technical
components (Ck) that achieve the necessary function for an element:
Ej = {C1, C2, C3, . . . , Ck}
• In the software context, a component could be a computer program,
a reusable program component, a module, a class or object, or even
a programming language statement.
 System Modeling
• System Modeling is a modeling process where the
focus is on the World view / Domain view of the
Product Engineering.
• The engineer creates a model that :
– Defines the processes that serves the need of the view
under consideration.
– Represents the behavior of process & assumptions on
which behavior is based.
– Explicitly defines the Exogenous & Endogenous input to
the model
– Represents all linkages that will enable the engineer to
understand the view.
 Exogenous / Endogenous Input
• Exogenous inputs link one constituent of a
given view with other constituents at the same
level or other levels;
• Endogenous input links individual components
of a constituent at a particular view.
 Restraining Factors for Model Construction
• Assumptions- Reduce no. of possible permutations
& variations , thereby enabling the model to reflect
the problem in a reasonable way.
• Simplifications- Helps timely creation of the model.
• Limitations- Helps to bound the system.
• Constraints- guide the manner in which model is to
be created & approach to be used when model is
implemented.
• Performance- indicates the preferred architecture
for all the data, functions & methodology
System Model Template

User Interface
Processing

Process & control

Input functions
Output
Processing
Processing

Maintenance & self test

 System Simulation
• It is used to help to eliminate surprises, when
reactive computer based system are built.
• These tools are applied during system
engineering process, while the role of h/w , s/w ,
database & people is being specified.
• Modeling & Simulation tools enables a system
engineer to test drive specifications of the
system.
• Example :Case Tools-PRO/SIM tool
 Analysis Principles

• Investigators have identified analysis problems

and their causes .
• Further, they have also developed a variety of
modeling notations and corresponding set of
heuristics to overcome them.
• Each analysis method has a unique point of view.
• All analysis methods are related by a set of
operational principles.
Certain principles that guide the analysis work are :

1. Represent and understand the information

domain.
2. Define the functions that the software is to
perform.
3. Represent the behavior of the software.
4. Use models to depict information, functionality ,
and behavior and partition the model such that
it uncovers the details in a layered fashion.
5. Analysis process should move from essential
information towards implementation details.
By applying these principles, the analyst
approaches a problem systematically.

Come up with 3 major parts:

1.The information domain is examined so that
function may be understood more completely.
2. Models are used so that the characteristics of
function and behavior can be communicated in a
compact fashion.
3. Partitioning is applied to reduce complexity.
A set of guidelines for requirement engineering
given by DAVIS :
1. Understand the problem before beginning to
create the analysis model.
2. Develop prototypes to help user to understand
how human-machine interactions will occur .
3. Record the origin of and the reasons for every
requirement.
4. Use multiple views of requirements.
5. Prioritize requirements.
6. Work to eliminate ambiguity.
 The Information Domain

Information domain represents the data items or

objects that contain numbers, text, images ,
audio , video or any combination of these.
Information domain contains three different
views of the data and control as each is
processed by a computer program:
- Information content and relationship
- Information flow
- Information structure
 - Information content and relationship:
Information content --> represents the
individual data and control objects that
constitute some larger collection of information
transformed by the s/w. for e.g. Data object
PAYCHECK includes a pieces of data like payee’s
name, amount, deductions, gross pay etc

- Information flow:
Represents the manner in which data and
control change as each moves through a system.
Input information is transformed into
intermediate information and then to output .
- Information structure:
represents the internal organization of
various data and control items.
- if data organized in tree structure/ data
table (n-dimension) structure ?
- which info is related to other info
(within the structure)?
- all info represented in one
structure/different structures?
-how info in one structure is related to
info in other structure?
 Modeling
During software requirements analysis, we create models of
the system to be built in order to gain better understanding of
the actual system .

The models focus on:

- What the system must do, not how it does it.

The models usually have a graphic notation to represent:

- Information, processing, system behavior, and other
features.
The model must be able to represent:
- The information that s/w transforms.
- Function that enables the transform to occur.
- Behavior of system as transformation occurs.
The model is identical in form & shape but
smaller in scale than the actual one.

The second , third & fourth operational analysis

principles require:
- build models of functionality and behavior
We build two types of models
- Functional Models
Software transforms information and for this
it performs three generic functions:
- Input, Processing, Output

- Behavioral Models
Most software responds to events from the
outside world.
A behavior model creates a representation of
the states of the software and events that
causes software to change state.
Advantages of models:

- The model aids the analyst in understanding

the information, functionality, and behavior of
a system.

- The model becomes the focal point for review

in the aspects of completeness, consistency, and
accuracy of the specification.

- The model becomes the foundation for

design, providing the designer with an essential
representation of software.
 Partitioning
Problems are often too large & complex to
understand as a whole.
Partitioning decomposes a problem into its
constituent parts.

5th Analysis principle suggest that information ,

functional & behavioral domains of s/w can be
partitioned .
Establish a hierarchical representation of
information (or function) to partition it :

- exposing increasing detail by moving

vertically in the hierarchy .

- decomposing the problem by moving

horizontally in the hierarchy.
 Example : Functionality Partitioning Safe Home System

Horizontal partition

Safe Home Software

Configure system Monitor sensors Interact with user

Vertical partition Poll for sensor event Activate alarm functions

Activate audible alarm Dial phone number

 Software Prototyping
In some cases, it is possible to apply operational analysis
principles and derive a model of software from which a design
can be developed. While in other cases we can use prototype
model for customer and developer assessment.

Selecting the prototyping approach:

The closed-ended approach is called throwaway prototyping.

- a prototype serves only as a rough demonstration of
requirements.

The open-ended approach is called evolutionary prototyping.

- a prototype serves as the first evolution of the finished
system.
 Selecting the appropriate prototyping approach.
Questions Throwaway Evolutionary
Domain well understood Yes yes

If problem can be modeled Yes yes

Customer sure of basic Requirements Yes/no Yes/No
If Requirements stable & established No Yes
If Requirements ambiguous Yes No
Is there any contradiction in requirements. Yes No

Prototyping Methods and Tools:

- Fourth Generation Techniques

- Reusable Software Components

- Formal Specification and Prototyping Environments

 Software Specification
Specification : is a representation process, where
requirements are represented in a way that leads
to successful software implementation.

•There are certain principles for S/W specification

that if followed will lead to proper specification of
requirements, and will ultimately lead to
successful implementation of the S/W.
Specification Principles(Balzer & Goodman) :

1. Separate functionality from implementation.

2. Develop a model of the desired behavior of the
system.
3. Define the environment in which the system
operates.
4. Create a cognitive model rather than a design or
implementation model.
5. Specifications must be tolerant of incompleteness
.
6. Establish the content and structure of a
specification in a way, it is easy to be changed.
Guidelines for Requirement Specification/
Representation :

1. Representation format and content

should be relevant to the problem.
2. Information contained within the
specification should be nested.
3. Diagrams and other notational forms
should be restricted in number and
consistent in use.
4. Representations should be revisable.
The Software Requirements Specification

SRS is produced as the result of the analysis task.

The software requirements specifications includes:
Format of SRS Document:
1. The Introduction, which states the goals and
objectives of the software.
2. The Information Description provides a detailed
description of the problem that the software
must solve.
3. A description of each function, required to solve
the problem is presented in the Functional
Description.
4. Behavioral Description, section of the
specification examines the operation of the
software as a consequence of external events and
internally generated control characteristics.
5. Validation Criteria is probably the most
important , its all about testing.
6. Finally, the specification includes a
Bibliography and appendix
 SPECIFICATION REVIEW

A review of the Software Requirements Specification

(and/or prototype) is conducted by both the software
developer and the customer.

The specification forms the foundation of the

development phase, extreme care should be taken in
conducting the review.

The review is first conducted at

A) Macroscopic level , that is, reviewers attempt to
ensure that the specification is complete, consistent, and
accurate when the overall information, functional, and
behavioral domains are considered.
B) The review becomes more detailed,
examining not only broad descriptions but the
way in which requirements are worded.
Each Domain (Information/ Functional/
Behavioral) is reviewed.
For example, when specifications contain
“vague terms” (e.g., some, sometimes, often,
usually, ordinarily, most, or mostly ), the
reviewer should flag the statements for
further clarification.
Once the review is complete, the Software
Requirements Specification is "signed-off" by
both the customer and the developer.

The specification becomes a "contract“ for

software development.

Requests for changes in requirements after the

specification is finalized will not be done
 Analysis Modeling
Analysis modeling uses a combination of text and diagrams to depict
requirements for data, functionality, and behavior, in a way that is
relatively easy to understand, and more important, straightforward
to review for correctness, completeness, and consistency.

Analysis Modeling is done by a software engineer also called an

analyst . He builds the model using requirements elicited from the
customer.

Analysis Modeling is done:

To validate software requirements.
To examine S/W from of different views (data/fun./behavior).
Reduces probability of errors.
Reduces probability of inconsistency.
Reduces probability of omissions & incompleteness.
Steps carried out in Analysis modeling:
Data Modeling
Functional Modeling
Behavioral Modeling
Requirements are modeled using a number of different
diagrammatic formats.
Data modeling defines data objects, attributes, and relation
ships.
Functional modeling indicates how data are transformed
within a system.
Behavioral modeling depicts the impact of events.

Once preliminary models are created, they are refined and

analyzed to assess their clarity, completeness, and
consistency.
Analysis Modeling Activity Outcome
-Data object Descriptions, (DM)
-Entity Relationship Diagrams, (DM)
-Data Flow Diagrams,(FM)
-State Transition Diagrams, (BM)
-Process specifications and Control specifications
are created as part of the analysis modeling activity.

The analysis model must achieve three primary

objectives:
(1) To describe customer requirements.
(2) To establish a basis for the creation of a software
design.
(3) To define a set of requirements that can be validated
once the software is built.
THE ELEMENTS OF THE ANALYSIS MODEL
DATA MODELING
Data modeling answers a set of specific questions .

1. What are the primary data objects to be processed by

the system?
2. What is the composition of each data object
3. What are the attributes that describe the data object?
4. What are the relationships between each object and
other objects?
5. What are the relationships between the objects and
the processes that transform them?

To answer these questions, data modeling methods make

use of the entity relationship diagram.
 Data Objects, Attributes, and Relationships

The data model consists of three interrelated pieces of

information: the data object, the attributes that describe
the data object, and the relationships that connect data
objects to one another
TABULAR REPRESENTATION OF DATA OBJECTS
 Cardinality and Modality
The elements of data modeling—data objects, attributes,
and relationships— provide the basis for understanding the
information domain of a problem.

We have defined a set of objects and represented the

object/relationship pairs that bind them.

But a simple pair that states: object X relates to object Y

does not provide enough information for software
engineering purposes. We must understand how many
occurrences of object X are related to how many
occurrences of object Y.
This leads to a data modeling concept called Cardinality
Tillmann defines the cardinality of an object/relationship
pair in the following manner:

Cardinality is the specification of the number of

occurrences of one object that can be related to the
number of occurrences of another object.

Cardinality is usually expressed as simply 'one' or 'many.'

For example, a husband can have only one wife (in most
cultures),

while a parent can have many children. Taking into

consideration all combinations of 'one' and 'many,' two
objects can be related as :
• One-to-one (l:l)—An occurrence of [object] 'A' can relate to one
and only one occurrence of [object] 'B,' and an occurrence of 'B'
can relate to only one occurrence of 'A.'

• One-to-many (l:N)—One occurrence of [object] 'A' can relate to

one or many occurrences of [object] 'B,' but an occurrence of 'B'
can relate to only one occurrence of 'A.'
For example, a mother can have many children, but a child can
have only one mother.

• Many-to-many (M:N)—An occurrence of [object] 'A' can relate

to one or more occurrences of 'B,' while an occurrence of 'B' can
relate to one or more occurrences of 'A.'
For example, an uncle can have many nephews, while a nephew
can have many uncles
 Modality
The modality of a relationship is 0 if there is no explicit
need for the relationship to occur or the relationship is
optional.
The modality is 1 if an occurrence of the relationship is
mandatory.

To illustrate, consider software that is used by a local

telephone company to process requests for field service.
A customer indicates that there is a problem.
If the problem is diagnosed as relatively simple, a single
repair action occurs.
However, if the problem is complex, multiple repair
actions may be required.
The relationship, cardinality, and modality
between the data objects customer and repair
action.
 Entity/Relationship Diagrams

The primary purpose of the ERD is to represent

entities (data objects) and their relationships with
one another.

Object +Relationship (Pictorial representation) =

ER Diagram

A set of primary components identified for the

ERD:
Data objects, Attributes, Relationships, and
various type Indicators.
Data objects are represented by a labeled rectangle.

Relationships are indicated with a labeled line

connecting objects.

In some variations of the ERD, the connecting line

contains a diamond that is labeled with the
relationship.

Connections between data objects and relationships

are established using a variety of special symbols that
indicate cardinality and modality .
Expanded ER Diagram
 FUNCTIONAL MODELING AND INFORMATION FLOW
Information is transformed as it flows through a
computer-based system.
The system accepts input in a variety of forms; applies
hardware, software, and human elements to transform it;
and produces output in a variety of forms.
So, we can create a flow model for any computer-based
system, regardless of size and complexity.

A rectangle is used to represent an external entity.

A circle (bubble ) represents a process or transform.
An arrow represents one or more data items .
All arrows on a data flow diagram should be labeled.
The double line represents a data store—stored
information that is used by the software.
 Data Flow Diagrams
A data flow diagram is a graphical representation that
depicts information flow and the transforms that are
applied as data move from input to output.
The basic form of a data flow diagram, also known as a
data flow graph or a bubble chart, is illustrated in Figure.

DFDs may be partitioned into levels that represent

increasing information flow and functional detail.
A level 0 DFD, also called a fundamental system model or a
context model, represents the entire software element as a
single bubble with input and output data indicated by
incoming and outgoing arrows, respectively.
A level 1 DFD might contain five or six bubbles with
interconnecting arrows.
 B
A F Level 0 DFD

F2 Y
X

A F1 F4 B Level 1 DFD
Z W
F3
Information flow Refinement
 Ward and Mellor Extension
In conventional DFD control flow is not represented ,
Ward and Mellor extend basic structured analysis
notation.
They also represented control flow in diagram by using
dashed/shaded arrow & data flow by solid arrow .
Hatley and Pirbhai Extensions: They used separate
representations for both Information flow & Control flow
along with some special symbols.

Control Specifications are also there ,how s/w behaves when

an event / control signal is sensed and which process is
invoked as a result of this.

Process Specifications, are inner workings of a process.

 BEHAVIORAL MODELING

Behavioral modeling is used to model S/W’s reaction to the

external events.
STD- State Transition Diagram represents the behavior of a system
by depicting its states & the events that causes the system to change
state.
A system may be in number of states during its lifetime.
State is an observable mode of behavior.
In a state transition diagram we use:
1. Rectangles to represent the system states.
2. Labeled Arrow represents the transition b/w states. A
B
A – Events that cause the transition to occur.
B - Action that occurs as a result of the event.
 THE DATA DICTIONARY
The data dictionary is an organized listing of all data
elements that are pertinent to the system, with precise,
rigorous definitions so that both user and system analyst
will have a common understanding of inputs, outputs,
components of stores and [even] intermediate calculations.

The Data Dictionary contains the following information:

• Name—the primary name of the data or control item, the
data store or an external entity.
• Alias—other names used for the first entry.
• Where-used/how-used—a listing of the processes that
use the data or control item and how it is used (e.g., input
to the process, output from the process, as a store, as an
external entity.
• Content description—a notation for representing content.
• Supplementary information—other information about
data types, preset values (if known), restrictions or
limitations, and so forth.

Once a data object or control item name and its aliases are
entered into the data dictionary, consistency in naming can
be enforced.
If an analysis team member decides to name a newly
derived data item xyz, but xyz is already in the dictionary,
the CASE tool supporting the dictionary posts a warning to
indicate duplicate names.
This improves the consistency of the analysis model and
helps to reduce errors
 OTHER CLASSICAL ANALYSIS METHODS

Three important Analysis Methods are:

• Data Structured Systems Development.
• Jackson System Development .
• Structured Analysis and Design Technique
.