Software Engineering Chapter 04: Software Requirement Analysis

Chapter 04: Software Requirement Analysis

1. Introduction
• Many projects fail because they start implementing the system without determining
whether they are building what the customer really wants.
• It is important to learn requirements analysis and specification techniques thoroughly.
• The inputs to this process include the customer’s requirements and the project
constraints.
• Requirements relate directly to the performance characteristics of the system being
designed.
• They are the stated life-cycle customer needs and objectives for the system, and they
relate to how well the system will work in its intended environment.
• Constraints are conditions that exist because of limitations imposed by external
interfaces, project support, technology, or life cycle support systems. Constraints bound
the development teams’ design opportunities.
• Requirements Engineering is the process of establishing the services that the customer
requires from the system and the constraints under which it is to be developed and
operated. Requirements may serve a dual function:
o As the basis of a bid for a contract
o As the basis for the contract itself
• IEEE has defined the term requirements as:
(1) a condition of capability needed by a user to solve a problem or achieve.
(2) a condition or a capability that must be met or possessed by a system...,to
satisfy a contract ,standard, specification or other formally imposed
document....[IEE87].

2. Types of Requirements
• Requirements are categorized in several ways. The following are common
categorizations of requirements that relate to technical management:
1. Customer Requirements: Statements of fact and assumptions that define the
expectations of the system in terms of mission objectives, environment, constraints.
2. Functional Requirements: Functional requirements explain what has to be done by
identifying the necessary task, action or activity that must be accomplished.
Functional requirements analysis will be used as the top level functions for functional
analysis.
3. Non-functional Requirements: Non-functional requirements are requirements that
specify criteria that can be used to judge the operation of a system, rather than
specific behaviors.

Page 1 of 11
 Software Engineering Chapter 04: Software Requirement Analysis

4. Performance Requirements: The extent to which a mission or function must be

executed; generally measured in terms of quantity, quality, coverage, timeliness or
readiness.
5. Design Requirements: The “build to”, “code to”, and “buy to” requirements for
products and “how to execute” requirements for processes expressed in technical data
packages and technical manuals.
6. Derived Requirements: Requirements that are implied or transformed from higher-
level requirement. For example, a requirement for long range or high speed may
result in a design requirement for low weight.
7. Allocated Requirements: A requirement that is established by dividing or otherwise
allocating a high-level requirement into multiple lower-level requirements.

3. Characteristics of Requirements

Characteristic Explanation
Unitary
The requirement addresses one and only one thing.
(Cohesive)
Complete The requirement is fully stated in one place with no missing information.
The requirement does not contradict any other requirement and is fully
Consistent
consistent with all authoritative external documentation.
The requirement is atomic, i.e., it does not contain conjunctions. E.g., "The
postal code field must validate American and Canadian postal codes" should
Non-Conjugated
be written as two separate requirements: (1) "The postal code field must
(Atomic)
validate American postal codes" and (2) "The postal code field must validate
Canadian postal codes".
The requirement meets all or part of a business need as stated by stakeholders
Traceable
and authoritatively documented.
Current The requirement has not been made obsolete by the passage of time.
The requirement is concisely stated without recourse to technical jargon,
acronyms (unless defined elsewhere in the Requirements document), or other
esoteric verbiage. It expresses objective facts, not subjective opinions. It is
Unambiguous
subject to one and only one interpretation. Vague subjects, adjectives,
prepositions, verbs and subjective phrases are avoided. Negative statements
and compound statements are avoided.
Many requirements represent a stakeholder-defined characteristic the absence
Specify of which will result in a major or even fatal deficiency. Others represent
Importance features that may be implemented if time and budget permits. The requirement
must specify a level of importance.
The implementation of the requirement can be determined through basic
Verifiable possible methods: inspection, demonstration, test (instrumented) or analysis
(to include validated modeling & simulation).

Page 2 of 11
 Software Engineering Chapter 04: Software Requirement Analysis

4. Need of Requirements Analysis

Requirements analysis involves defining customer needs and objectives in the context of planned
customer use, environments, and identified system characteristics to determine requirements for
system functions. Prior analyses are reviewed and updated, refining mission and environment
definitions to support system definition. Requirements analysis is conducted iteratively with
functional analysis to optimize performance requirements for identified functions, and to verify
that synthesized solutions can satisfy customer requirements. The purpose of Requirements
Analysis is to:
• Refine customer objectives and requirements
• Define initial performance objectives and refine them into requirements;
• Identify and define constraints that limit solutions; and
• Define functional and performance requirements based on customer provided measures
of effectiveness.
In general, Requirements Analysis should result in a clear understanding of:
• Functions: What the system has to do,
• Performance: How well the functions have to be performed,
• Interfaces: Environment in which the system will perform, and
• Other requirements and constraints.

5. Requirement Analysis Tasks

Software requirements engineering is a process of discovery, refinement, modeling, and
specification. Both the software engineer and customer take an active role in software
requirements engineering—a set of activities that is often referred to as analysis. The customer
attempts to reformulate a sometimes nebulous system-level description of data, function, and
behavior into concrete detail. The developer acts as interrogator, consultant, problem solver, and
negotiator.
Software requirements analysis may be divided into five areas of effort:
1. Problem Recognition- the goal of the analyst is recognition of the basic problem
elements as perceived by the user/customer;
2. Evaluation and Synthesis- the analyst must evaluate the flow and content of
information, define and elaborate all software functions, understand software behavior in
context of the events that affect the system, establish system interface characteristics and
design constraints;
3. Modeling- the analyst should create models of the system which serves as a foundation
for system design
4. Specification- the tasks associated with analysis and specification strive to provide a
representation of software that can be reviewed and approved by the customer;
5. Review- is conducted to check the progress of the project and to check whether all the
work is performed well according to the user requirements. A group of people read and
analyze the requirements, look for problems, meet and discuss the problems and agree on
actions to address these problems

Page 3 of 11
 Software Engineering Chapter 04: Software Requirement Analysis

6. Role and Tasks of System Analyst

The primary objective of any system analyst is to identify the need of the organization by
acquiring information by various means and methods. The system analyst has to coordinate with
the system users, computer programmers, manager and number of people who are related with
the use of system. Following are the tasks performed by the system analyst:

Defining Requirement: The basic step for any system analyst is to understand the requirements
of the users. This is achieved by various fact finding techniques like interviewing, observation,
questionnaire etc. The information should be collected in such a way that it will be useful to
develop such a system which can provide additional features to the users apart from the desired.

Prioritizing Requirements: Number of users use the system in the organization. Each one has a
different requirement and retrieves different information. Due to certain limitations in computing
capacity it may not be possible to satisfy the needs of all the users. Even if the computer capacity
is good enough is it necessary to take some tasks and update the tasks as per the changing
requirements. Hence it is important to create list of priorities according to users requirements.
The best way to overcome the above limitations is to have a common formal or informal
discussion with the users of the system. This helps the system analyst to arrive at a better
conclusion.

Gathering Facts, data and opinions of Users: After determining the necessary needs and
collecting useful information the analyst starts the development of the system with active
cooperation from the users of the system. Time to time, the users update the analyst with the
necessary information for developing the system. The analyst while developing the system
continuously consults the users and acquires their views and opinions.

Evaluation and Analysis: As the analyst maintains continuous he constantly changes and
modifies the system to make it better and more user friendly for the users.

Solving Problems: The analyst must provide alternate solutions to the management and should
an in-depth study of the system to avoid future problems. The analyst should provide with some
flexible alternatives to the management which will help the manager to pick the system which
provides the best solution.

Drawing Specifications: The analyst must draw certain specifications which will be useful for
the manager. The analyst should lay the specification which can be easily understood by the
manager and they should be purely non-technical. The specifications must be in detailed and in
well-presented form.

Page 4 of 11
 Software Engineering Chapter 04: Software Requirement Analysis

7. Requirement Analysis Principles

For analysis process following principle must be followed:
a) The information domain of a problem must be represented and understood.
b) The functions that the software is to perform must be defined.
c) The behavior of the software (as a consequence of external events) must be represented.
d) The models that depict information, function and behavior must be partitioned in a
manner that uncovers detail in a layered (or hierarchical) fashion.
e) The analysis process should move from essential information toward implementation
detail.

7.1 The Information Domain

All software applications can be collectively called data processing which transform data from
one form to another; that is, to accept input, manipulate it in some way, and produce output.
Software also processes events which represents some aspect of system control and is really
nothing more than Boolean data—it is either on or off, true or false, there or not there.

7.2 Modeling:
We create functional models to gain a better understanding of the actual entity to be built. It
must be capable of representing the information that software transforms, the functions (and
sub-functions) that enable the transformation to occur, and the behavior of the system as the
transformation is taking place.
a. Functional models: It focuses on the functions - transformations of data - that the
software must include. Software transforms information, and in order to accomplish this,
it must perform at least three generic functions: input, processing, and output. The
functional model begins with a single context level model (i.e., the name of the software
to be built). Over a series of iterations, more and more functional detail is provided, until
whole software with full system functionality is not represented.
b. Behavioral models: Most software responds to events from the outside world. This
stimulus/response characteristic forms the basis of the behavioral model. A computer
program always exists in some state—an externally observable mode of behavior (e.g.,
waiting, computing, printing) that is changed only when some event occurs. A behavioral
model creates a representation of the states of the software and the events that cause
software to change state.

7.3 Partitioning
Problems are often too large and complex to be understood as a whole. For this reason, we
tend to partition (divide) such problems into parts that can be easily understood and establish
interfaces between the parts so that overall function can be accomplished. Analysis principle
also suggests that the information, functional, and behavioral domains of software can be
partitioned.

Page 5 of 11
 Software Engineering Chapter 04: Software Requirement Analysis

In essence, partitioning decomposes a problem into its constituent parts. Conceptually, we

establish a hierarchical representation of function or information and then partition the
uppermost element by
a. Exposing increasing detail by moving vertically in the hierarchy
b. Functionally decomposing the problem by moving horizontally in the hierarchy.

7.4 Essential and Implementation Views (Logical and Physical Views)

An essential view of software requirements presents the functions to be accomplished and
information to be processed without regard to implementation details.
The implementation view of software requirements presents the real world manifestation of
processing functions and information structures.

8. Software Requirement Specification (SRS)

Need / Advantages of SRS

If an SRS is written well, it will serve the following purposes
• Feedback to the Customer: The software requirement specification assures the project
management stakeholders and client that the development team has really understood the
business requirements documentation properly. This also provides confidence that the team
will develop the functionality which has been detailed.
• Breaking the Requirements Down: The Software Requirement Specification is documented
in such a way that it breaks the deliverables into smaller components. The information is
organized in such a way that the developers will not only understand the boundaries within
which they need to work, but also what functionality needs to be developed and in what
order.
• These two points are particularly important in the process of software development. If your
development team do not understand that there are certain constraints on their work, as for
example the code must be tightly written so that it will compile and run quickly, then you
will run into problems later on when the code might deliver the functionality required, but no
one will ever see it because it takes so long to load!
• Understanding what order the functionality will be developed in means that the developers
have the "big picture" view of the development. This gives them an opportunity to plan ahead
which saves both project time and cost.
• Facilitating other Documentation: The SRS forms the basis for a load of other important
documents such as the Software Design Specification.
• Product Validation: It basically helps in validating with the client that the product which is
being delivered, meets what they asked for.

Page 6 of 11
 Software Engineering Chapter 04: Software Requirement Analysis

Users of SRS
• System customers: Specify the requirements and read them back to check that they meet their
needs; specify changes to the requirements
• Development Managers: Use the requirements document to plan a bid for the system and to
plan the system development process
• Implementation Programmers: Use the requirements to understand what system is to be
developed
• Test programmers: Use the requirements to develop validation tests for the system
• Maintenance programmers: Use the requirements to help understand the system and the
relationships between its parts.

Characteristics of a Good Software Requirements Specification (SRS)

1. Correct: An SRS is correct if, and only if, every requirement stated therein is one that the
software shall meet. Traceability makes this procedure easier and less prone to error.
2. Unambiguous: An SRS is unambiguous if, and only if, every requirement stated therein has
only one interpretation. As a minimum, this requires that each characteristic of the final
product be described using a single unique term.
3. Complete: An SRS is complete if, and only if, it includes the following elements:
• All significant requirements, whether relating to functionality, performance, design
constraints, attributes, or external interfaces. In particular any external requirements
imposed by a system specification should be acknowledged and treated.
• Definition of the responses of the software to all realizable classes of input data in all
realizable classes of situations. Note that it is important to specify the responses to
both valid and invalid input values.
• Full labels and references to all figures, tables, and diagrams in the SRS and
definition of all terms and units of measure.
4. Consistent: Consistency refers to internal consistency. If an SRS does not agree with some
higher-level document, such as a system requirements specification, then it is not correct. An
SRS is internally consistent if, and only if, no subset of individual requirements described in
it conflict.
5. Ranked for importance and/or stability: An SRS is ranked for importance and/or stability
if each requirement in it has an identifier to indicate either the importance or stability of that
particular requirement. Typically, all of the requirements that relate to a software product are
not equally important. Some requirements may be essential, especially for life-critical
applications, while others may be desirable. Each requirement in the SRS should be
identified to make these differences clear and explicit.
6. Verifiable: An SRS is verifiable if, and only if, every requirement stated therein is verifiable.
A requirement is verifiable if, and only if, there exists some finite cost-effective process with
which a person or machine can check that the software product meets the requirement.
Nonverifiable requirements include statements such as "works well", "good human
interface", and "shall usually happen". These requirements cannot be verified because it is
impossible to define the terms "good", "well", or "usually".

Page 7 of 11
 Software Engineering Chapter 04: Software Requirement Analysis

7. Modifiable: An SRS is modifiable if, and only if, its structure and style are such that any
changes to the requirements can be made easily, completely, and consistently while retaining
the structure and style. Modifiability generally requires an SRS to
• Have a coherent and easy-to-use organization with a table of contents, an index, and
explicit cross referencing;
• Not be redundant (i.e., the same requirement should not appear in more than one
place in the SRS);
• Express each requirement separately, rather than intermixed with other requirements.
8. Traceable: An SRS is traceable if the origin of each of its requirements is clear and if it
facilitates the referencing of each requirement in future development or enhancement
documentation. The following two types of traceability are recommended:
• Backward traceability (i.e., to previous stages of development). This depends upon
each requirement explicitly referencing its source in earlier documents.
• Forward traceability (i.e., to all documents spawned by the SRS). This depends upon
each requirement in the SRS having a unique name or reference number.

9. Structured Analysis
Structured Analysis (SA) is a methodology for determining and documenting the requirements
for a system. It is a front-end methodology that allows users and/or systems analysts to convert a
real-world problem into a pictorial diagram.
There are three orthogonal views related to structured analysis:
• Functional View: This involves data flow diagrams, which define the work that has been
done and the flow of data between things done, thereby providing the primary structure of a
solution.
• Data View: This comprises the entity
relationship diagram and is concerned with what
exists outside the system that is being
monitored.
• Dynamic View: This includes state transition
diagrams and defines when things happen and
the conditions under which they may happen.

Elements of Analysis Model

The analysis model derived during structured
analysis takes the form as shown in below given
figure: The structure of Analysis Model

Page 8 of 11
 Software Engineering Chapter 04: Software Requirement Analysis

At the core of the model lies the data dictionary—a repository that contains descriptions of all
data objects consumed or produced by the software.
The entity relation diagram (ERD) depicts relationships between data objects. The ERD is the
notation that is used to conduct the data modeling activity. The attributes of each data object
noted in the ERD can be described using a data object description.
Data flow diagram describes both the data and functions that are used to transform input data
into output. The data flow diagram (DFD) serves two purposes:
(1) To provide an indication of how data are transformed as they move through the system
and
(2) To depict the functions (and sub-functions) that transforms the data flow.
The DFD provides additional information that is used during the analysis of the information
domain and serves as a basis for the modeling of function. A description of each function
presented in the DFD is contained in a process specification (PSPEC).
The state transition diagram (STD) indicates how the system behaves as a consequence of
external events. To accomplish this, the STD represents the various modes of behavior (called
slates) of the system and the manner in which transitions are made from state to state. The STD
serves as the basis for behavioral modeling. Additional information about the control a specs of
the software is contained in the control specification (CSPEC).

10. DATA FLOW DIAGRAM (DFD)

A data flow diagram (DFD) is a design tool to represent the flow of data through an
information system. Following reasons to design data flow diagram:
1. DFDs are easier to understand by technical and nontechnical people
2. DFDs can provide a high level system overview, complete with boundaries and connections to
other systems
3. DFDs can provide a detailed representation of system components
DFDs help system designers and others during initial analysis stages visualize a current system
or one that may be necessary to meet new requirements. DFDs represent the following:
1. External devices sending and receiving data
2. Processes that change that data
3. Data flows themselves
4. Data storage locations
The hierarchical DFD typically consists of a top-level diagram (Level 0) underlain by cascading
lower level diagrams (Level 1, Level 2...) that represent different parts of the system. A "context
level" DFD can be used to show the interaction between a system and outside entities; it can also
show the internal data flows within a system. This version is also called a context diagram. It
often shows the information system as a single circular shape with no details of its inner
workings: what it shows is its relationships with the external entities.

Page 9 of 11
 Software Engineering Chapter 04: Software Requirement Analysis

The different levels of a DFD indicate how detailed it is, e.g. a Level 0 DFD is a broad overview
of a system, showing hardly any detail within the system. A level 2 DFD explodes more
summarized processes and shows another level of complexity within them. A level 3 or 4 DFD
shows even more components opened up to show their inner details.
A data flow diagram graphically represents:
• Processes (Function) - jobs that are done with the data. A process transforms incoming
data flow into outgoing data flow.
• data stores - files, databases, archives. They can be manual, digital or temporary.
• external entities/terminators in a business or other system - other systems or people
beyond the control of the current system. These are the places which provide the
organisation with data, or have data sent to them by the organisation (e.g. customers,
partners, government bodies). External entities are sources and destinations of the
system's inputs and outputs.
• connecting data flows - arrows show how data flows from one place to another. Flows
that cross the system boundary are known as Input Output Descriptions. Label the arrows
with the name of the data that moves through it.

Page 10 of 11
 Software Engineering Chapter 04: Software Requirement Analysis

Here are the basic DFD shapes:

DFD Conventions (Thing to be remembered while designing DFDs)

• Do not allow a single page of a DFD to get too complex - it should have no more than 10
components. If it has more than this, combine some components into a single self-contained
unit and create a new DFD for that unit.
• Each component and subcomponent should be numbered. e.g. a top level DFD has
components 1 2 3 4 5. The subcomponent DFD of component 3 would have components 3.1,
3.2, 3.3, and 3.4; and the sub subcomponent DFD of component 3.2 would have components
3.2.1, 3.2.2, and 3.2.3. This enables a developer to plan in a top-down manner: starting with
representing large concepts, and then repeatedly breaking these objects into their
components.
• All processes must have at least one data flow in and one data flow out.
• All processes should modify the incoming data, producing new forms of outgoing data.
• Each data store must be involved with
at least one data flow.
• Each external entity must be involved
with at least one data flow.
• A data flow must be attached to at
least one process
• Data flows cannot go directly from
one external entity to another external
entity: such flows need to go through
at least one process.
• Data flows cannot go directly from an
external entity to a data store in the
system: such flows need to go through
at least one process.

Page 11 of 11