Requirements analysis in software engineering encompasses those tasks that go into determining
the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting
requirements of the various stakeholders, such as beneficiaries or users.
Requirements analysis is critical to the success of a development project. Requirements must be
actionable, measurable, testable, related to identified business needs or opportunities, and defined to
a level of detail sufficient for system design.
Need for Software Requirement Specification (SRS)
The Software Requirement Specification describes what the proposed software should do without
describing how the software will do it.
1. It establishes the basis for agreement between the client and the supplier on what the
software product will do.
2. It provides a reference for validation of the final product
3. A high quality SRS is a pre-requisite for high quality product
4. A high quality SRS reduces the development cost as the cost of fixing a requirement error is
high as all the phases have to be repeated
Requirement engineering tasks
1. Inception: Casual interaction to get product request
2. Elicitation: Ask customer, user and others about their requirements
1. Requirement discovery
2. Requirement classification and organization
3. Requirement prioritizing and negotiation
4. Requirement documentation
3. Requirement elaboration: refinement of user scenarios
5. Specification in written document
These are discussed in detail in further sections.
Requirements discovery is the process of gathering information about the proposed and
existing systems and distilling the user and system requirements from this information.
Before the system analyst moves on to the task of information collection, he must plan his
strategy. The plan must include-
• Serialized steps of information collection
• List of information to be collected at each step
• List of sources for the information to be collected
• The enquiry about the purpose of each information
• The method of collection of each information
Techniques for requirement discovery are discussed as follows:
1. Viewpoints: The requirements sources (stakeholders, domain, systems) can all be
represented as system viewpoints, where each viewpoint presents a sub-set of the
requirements for the system. There are three generic types of viewpoints:
1. Interactor viewpoints represent people or other system that interact directly with
2. Indirect viewpoints represent stakeholders who do not use the system themselves
but who influence requirements.
3. Domain viewpoints represent domain characteristics and constraints that influence
the system requirements.
2. Interviewing: Formal or informal interviews with system stakeholders are part of most
requirements engineering processes. Interviews may be of two types:
1. Closed interviews where the stakeholder answers a predefined set of questions
2. Open interviews where there is no predefined agenda.
For getting the maximum out of an interview, the selection of the right candidate is
important. Before starting the interviews, the analyst must write down the hierarchy, or position
order of all. The interview must be conducted strictly in that order only, else the integration of
information into the system modeling will become impossible, and some information may be lost or
may remain unused.
It is hard to elicit domain knowledge during interviews for two reasons:
1. All application specialists use terminology and jargon that is specific to a domain.
2. Some domain knowledge may be so familiar to stakeholders that they might forget
to mention it.
Effective interviews have two characteristics:
1. They are open-minded, avoid preconceived ideas about the requirements and are
willing to listen to stakeholders.
2. They prompt the interviewee to start discussions with a question, a requirements
proposal or by suggesting working together on a prototype.
Personal rapport is the soul of successful interview. The interview of different people has to
be conducted depending upon the level and content of information.
Before conducting the interview, the analyst must ensure the status and role of the person
in the information system. Accordingly, an ordered list of unambiguous questions must be
framed for the interview. Each interview must start with simple and convenient questions to
encourage the interviewee. After the statement of the interviewee is over, the analyst must
summarize his statement to him and get his confirmation. Questions can be closed (requiring a
reply) or open (requiring interviewee to speak out his mind). Interviews with introvert type of
people must start with closed questions whereas those with extrovert persons must start with
open questions. Transition from one to the other type must be gradual and smooth.
They start with an outline of the interaction, and during elicitation, details added to create a
complete description of that interaction. A scenario includes:
1. A description of what the system and users expect when the system starts
2. A description of the normal flow of events in the scenario
3. A description of what can go wrong and how this is handled
4. Information about other activities that might be going on at the same time
5. A description of the system state when the scenario finishes
These are scenarios based techniques which identify the individual interactions with the
system. Actors in the process are represented as stick figures, and each class of interaction is
represented as a named ellipse. A use case encapsulates a set of scenarios, and each
scenario is a single thread through the use-case.
5. Ethnography is the observational technique that can be used to understand social and
organizational requirements. Following two types of requirements can be effectively
1. Requirements that are derived from the way people actually work
2. Requirements that are derived from cooperation and awareness of other people’s
Classification of Requirements
When we talk about the detail of requirements in relation to the system, we find two levels.
The first is user requirements which are governed by the external users of the system such as
client manager, system end-users, client engineers, system architects, etc. These briefly
outline the system and are part of high level abstraction specifying the external behavior of
The second is system requirement which specifies the characteristics of the system. These
define what the system should do. These are defined by the system end-users, client
engineers, system architects, software engineers, etc.
Each of the above requirements can be further divided as follows:
1. A functional requirement describes an interaction between the system and its environment.
2. Non-functional requirement describes a restriction on the system that limits our choices for
constructing a solution to the problem. They may relate to emergent system properties such
as reliability, response time etc. Failing to meet non-functional requirements can render a
system unusable.(Behavioral model)
Non-functional requirements can be related to the product, organization (cost, process,
quality) or general (such as legislation, ethical). These requirements are difficult to verify
because they are not easily quantifiable.
3. Domain requirements are defined by similar systems implemented. These may be functional
or non-functional and are important, as they reflect fundamentals of the application
The third is interface specification which defines the procedure interface (APIs), Data Structures and
representation of Data structures.
Types of requirements:
1. Physical environment under which the system should work.
2. Interfaces required for interaction with the external environment
3. User and human factors that affect the operation of system.
4. Functionality desired by the system.
5. Documentation needs can be specified by the management. The time for such
documentation can also be specified.
6. Data resource should be carefully defined for the system as data is a precious resource.
7. Resources apart from above should be mentioned, if they are involved with the system.
8. Security requirements are very important for systems dealing with critical resources.
9. Quality Assurance requirements as stated by the user or standards followed, should be
mentioned in the requirements report to allow verifications and inspections.
Evaluation: The requirements that have been gathered need to be evaluated to resolve
inconsistencies and also to understand why each requirement has been stated. In this task the
analyst needs to do the following:
o For every requirement X, get answers to question “Why do you need X?”
o Convert any requirements stated as “how to” into the corresponding “what” is required.
o Capture rationale to support future requirements
o Perform risk assessment, feasibility and cost/benefit analysis considering the technical,
cost and schedule concerns.
A risk assessment is also performed to address technical, cost and schedule concerns. The
rationale behind the information gathered in the previous stages is examined to determine
whether the true requirements are hidden in this rationale instead of being expressed explicitly.
Internally and commercially available software products and components are evaluated for
Prioritisation: The requirements are then prioritised based on cost and dependency and user
needs. Knowing the rationale behind each requirements helps in deciding the priority
Consolidation is required to put together all the requirements in a way that can be analysed
further. It comprises:
o Filling in as many ‘to be determined’ issues as possible
o Validating that requirements are in agreement with originally stated goals
o Removing inconsistencies
o Resolving conflicts
o Authorizing/ verifying to move to the next step of development, i.e. detailed
Often group development techniques are used for consolidation because they remove the
possibility of an individual’s interpretation of the requirements.
Following representational techniques are used:
1. Static descriptions: A static description lists the system entities or objects, their attributes,
and their relationships with each other. This view is static because it does not describe how
relationships change with time. Different ways to describe a system statically are:
1. Indirect reference is made to the problem and its solution
2. Recurrence relation like Fibonacci
3. Axiomatic definition with the help of axioms/ theorems to specify basic system
4. Expression as a language (PDL)
2. Dynamic descriptions
1. Decision tables represent a actions to be taken when the system is in one of the
2. Functional description and transition diagrams (automata)
3. Event tables represent system’ states and transitions in a tabular form.
4. Petri nets representing a graphical system by drawing a node for each state and an
arrow to mark the transitions with a given input.
3. System models are graphical representations that describe business processes and the
problem to be solved.
Context models: Architecture models describe the environment of the system. They are
supplemented by process models.
Behavioral models: They describe the overall behavior of the system. Examples are dataflow
diagrams and state machine models.
1. Data flow models are used to show how data flows through a sequence of processing
steps. It shows a functional perspective where each transformation represents a single
function or process. These are valuable because tracking and documenting how data
associated with a particular process moves through the system helps analysts
understand what is going on. The development of models such as data flow models
should be a top-down process.
2. State machine models describe how a system responds to internal or external events.
This type of model is often used for modeling real-time systems since these systems are
often driven by stimuli from system’s environment.
3. Data flow diagrams
Data models: Most widely used technique is Entity-relation-Attribute modeling. Defining the
logical form of the data processed by the system is called semantic data modeling. Like all
graphical models, data models lack detail. One may collect these descriptions in a repository
or data dictionary. Advantages of data dictionary are :
1. It is a mechanism for name management.
2. It serves as a store for organizational information.
Object models: Here system requirements are expressed using object model, designing
using objects and developing the system in an object-oriented programming language.
Developing object models during requirements analysis usually specifies the transition to
object-oriented design and programming.
1. Inheritance model
2. Object aggregation
3. Object behavior modeling
Critical system specification
High potential costs of system failure cause the specification for critical systems to accurately reflect
the real needs of users of the system. These are the requirements that should be a part of
1. Risk driven specification is an approach that has been widely used by safety and security
critical systems developers. It is applicable to any system where dependability is a critical
2. Safety specification process in its first stage defines the scope of the system, assesses the
potential system hazards and estimates the risk they pose. This is followed by safety
requirements specification and the allocation of these safety requirements to different sub-
systems. These requirements are broken into functional safety requirements and safety
integrity requirements. After delivery, the system must be installed as planned so that the
hazard analysis remains valid.
3. Security specifications are based around the assets to be protected and their value. The
steps involved are asset identification and evaluation of the degree of protection, threat
analysis and risk assessment, threat assignment to the assets, analysis of available
technology and finally specification of security requirements. Different types of security
specifications are authentication and authorization requirements, immunity requirements,
intrusion detection requirements, non-repudiation requirements, privacy requirements etc.
The information obtained from the customer during inception and elicitation is
expanded and refined. It focuses on developing a refined technical model of software
functions, features, and constraints. The end result is an analysis model that defines the
informational, functional, and behavioral domain of the problem.
It might be that different users have conflicting requirements. To reach a consensus
these requirements are prioritized by all parties and the most important requirements
become part of the document. Risk associated with each requirement is identified and
evaluated. The finalized requirements are used to assess approximate effort, time and cost
for the project. Finally the baseline is defined.
1. Requirement definition is a complete listing of everything the customers expects the system
to do. It is written jointly by the customer and developer. First we outline the general
purpose of the system; next we describe the background and objectives of system
development. We outline a description to the solution. Next we describe the detailed
characteristics of the proposed system. Finally we discuss the environment in which the
system will operate.
2. Requirement specification restates the requirements definition in technical terms
appropriate for the development of system design. It is written by requirements specialists.
The specification document may define the same requirements as in the definition
document as a series of equation.
Contents of an SRS
This chapter contains purpose of the document, scope of the document, an overview of
the requirements and the context in which the document was prepared
2. General Description
In this chapter, the proposed product is described in the context of existing systems, user
characteristics, problems faced, objectives of the proposed system and any known
3. Functional Requirements
This chapter lists all the functional requirements in the decreasing order of importance. For
each requirement, a description, criticality, risks and dependencies with other
requirements is documented.
4. Interface Requirements
This chapter is used to describe the user interfaces, hardware interfaces, communications
interfaces and interfaces to other software systems.
5. Performance Requirements
Speed and throughput requirements are described in this requirement
6. Design Constraints
This chapter specifies the design constraints imposed on the design team and could cover
standards to be complied with, hardware limitations, etc.
7. Other Non-Functional Attributes
Aspects such as security, reliability, maintainability, etc. that are important to the project
are described in this chapter.
8. Preliminary Domain Analysis
This chapter contains the modelling of the proposed system.
9. Operational Scenarios
This chapter contains the main scenarios (use cases) that will be experienced from the
10. Schedule and Budgets
This chapter can contain the estimates and a high-level project plan.
Characteristics of a good Software Requirement Specification
1. Completeness can be aimed by ensuring the following:
• Elicitation of the requirements from all the “stakeholders”
• Focus on user tasks, problems, bottlenecks and improvements required; rather than the
• Ranking or prioritising each requirement (functional as well as non-functional) for
• Marking areas where requirements are not known as “To Be Determined”
• Resolving all ‘to be determined’ requirements before the design phase.
2. Clarity (Unambiguous) is related by following issues
• Requirements should be reviewed by an independent entity to identify ambiguous use
of natural language.
• Specifications should be written in a requirement specification language.
• Requirements can also be expressed using requirements analysis and modelling
3. Correctness can be assumed if every requirement stated in the SRS is required in the proposed
system. All stakeholders need to review the SRS and confirm that the SRS correctly reflects their
4. Consistency can be maintained when any conflict between requirements within the SRS is
identified and resolved. Logical conflicts should be identified and removed.
5. Modifiability can be increased by proper documentation. Certain practices that can lead to high
• Minimal redundancy leads to lower inconsistencies when changes are incorporated.
• Labelling helps easily identify changed requirements.
6. Traceability cab is created by labelling all requirements and following them all through the
designing phase, test phase and so on. Fine grained, structured and precise statements are much
more preferable to large, narrative paragraphs. Traceability can be backward or Forward.
7. Feasibility should be checked before including any requirement
8. Testability (Verifiability) should be enhanced by stating the requirements correctly.
9. Ranked for importance and/or stability to ensure the most important ones are incorporated early
A number of requirements validation techniques can be used in conjunction or individually:
1. Requirements review where requirements are analyzed systematically by a team of
reviewers. The development team should explain all requirements and their implications to
the reviewing team in a formal review. In an informal review, the team interacts with
stakeholders to verify requirements. In both cases the team reviews the requirements for
consistency, verifiability, comprehensibility, traceability and adaptability.
Conflicts, contradictions, errors and omissions are pointed out by the review team.
2. Prototyping helps to ensure the correct requirements are found. Throwaway prototype,
where the prototype is discarded after correcting requirements is prepared, when the not
well understood requirements are significant for system. Otherwise exploratory prototype is
built which enhances the prototype once built.
3. Test case generation is a technique which prepares test cases for the requirements and
ensures that they are correctly stated.
4. Validation can be done by using checks on
1. Validity of requirements
2. Consistency to avoid contradiction
3. Completeness to include all constraints
4. Realism check to see if it can be really implemented
5. Verifiability ensures that test cases can be generated to check requirements
Common problems with Software Requirement Specification
1. Making Bad Assumptions due to lack of proper or no information.
2. Writing implementation (HOW) instead of requirements (WHAT)
3. Using incorrect terms such as ‘will not be limited to’, ‘such as’ etc.
4. Using Wrong Language which is ambiguous
5. Unverifiable Requirements that are written using terms such as maximize, fast,
6. Missing Requirements can be avoided using proper templates
7. Over-Specifying or stating unnecessary things
Requirements management consists of:
1. Requirements change management which involves systematic handling of changes to agreed
requirements (SRS) during the course of the project. Changes occur because there are
changes in the business and technical environment and preferences and priorities of users
change. Some requirements are enduring, i.e. relatively stable, and there are volatile
requirements that change over time. Change management process is as follows:
Further Impact analysis
Impact analysis Pending
Change Management process
1. Initiation: A change request form (CRF) is filled. It includes why such a change is
required, what benefits are expected with the change, or what difficulties will be
faced without the change.
2. Impact Analysis: The CRF is handed over to the Configuration Controller, who in
cooperation with others, evaluates the change from various perspectives e.g.
technical feasibility, additional resources, additional calendar time, impact on
current activities etc.
3. Evaluation: The change is presented in the periodic Change Control Board (CCB)
meeting which may accept, reject, partially approve, keep pending or perform
further impact analysis for the proposed change.
4. Planning: If CRF is partially or fully approved, the Configuration controller fill sup
the implementation plan for implementing the CRF.
5. Execution: changes are made according to the implementation plan.
6. Closing: The CRF is closed after verifying that all changes that were required
have been made.
2. Requirements traceability consists of maintaining traceability between the agreed (and
changed) SRS and the other work products (like design documents, test plans) created
downstream in the software life cycle.
Test case TC01 TC02 TC03 TC04 ...... TC49
R-01 X X X
R-02 X x
R-03 x X
There are three types of traceability information that may be maintained.
1. Source traceability information links the requirements to the stakeholders who
proposed the system.
2. Requirements traceability information links dependent requirements within the
requirements document. This helps in assessing how many requirements are likely
to be affected by a proposed change.
3. Design traceability information links the requirements to the design modules where
these requirements are implemented.
3. Tools for requirement documentation are also available. A few are
a. PSL/PSA: Problem statement language specifies the requirements which are
converted into models by the problem statement analyzer.
b. RSL/REVS: Requirement statement language specifies the requirement and
Requirement engineering validation system processes and analyzes RSL statements.
REVS consists of a translator for RSL, Centralized database and a set of automated
c. Structured analyses and design technique (SADT) creates a model that consists of a
set of ordered SA diagrams.
d. Structured System Analysis (SSA) includes data flow diagrams, data dictionaries, and
procedure logic representations and data store structuring techniques.
Key enablers that drive the maturity of the requirements engineering process are:
1. Senior management reviews requirements engineering for process compliance
2. Independent Software Quality Assurance group reviews requirements engineering for
3. Project manager monitors the progress of requirements engineering activities
4. Requirements engineering responsibility is explicitly assigned in each project.
5. Tools required for facilitating requirements engineering activities are explicitly identified,
made available and used.
6. Persons performing requirements engineering activities are trained/ skilled in the
application domain and requirements engineering process. Other project members are
provided the appropriate orientation on the application domain and requirements
7. Tools and resources are available to be able to maintain the requirements related
information and documents of past projects that may be re-used.
Commandments for Requirements
1. Don’t ignore the other side (LISTEN)
2. Understand the Domain (CONCEPTS)
3. Understand Why They Want it and How Badly (UNDERSTAND THEM BETTER)
4. Don’t be in a hurry (IT IS THE MOST IMPORTANT STAGE)
5. Do not Consider Anything as Obvious (DOCUMENT EVERYTHING)
6. Don’t Sweep it Under the Carpet (DON’T IGNORE ISSUES)
7. Don’t say “Yes” when you may need to say “No” (PROCEDURES FOR CHANGE
8. Work as a team
9. Don’t expect Analysts to Read your Mind
10. Don’t Just Sign-off without Rigorous SRS Review
Requirements can be measured on various parameters. A few commonly used measurable are:
• Function point metrics is a calculation dependent on the characteristic of requirement.
• Number of requirements can be used as a measure
• Number of changes to requirements is measured during the iterations
• Requirements size looks at the bigger picture of project size and complexity
• Kinds of requirements are important to be identified, because critical requiremenst are
more difficult to implement.
Function point calculation
Backup and recovery 4
Data Communications 2
Distributed processing 0
Performance critical 4
Existing operating environment 3
On-line data entry 4
Input transaction over multiple screens 5
ILFs updated online 3
Information domain values complex 5
Internal processing complex 5
Code designed for reuse 4
Conversion/installation design 3
Multiple installations 5
Application designed for change 5
Value adjustment factor 1.17
Information domain Opt Likely Pess Est. count Weight FP count
No. of external inputs 20 24 30 24 4 97
No. of external outputs 12 15 22 16 5 78
No. of external inquiries 16 22 28 22 5 88
No. of internal logical files 4 4 5 4 10 42
No. of external interface files 2 2 3 2 7 15
Count total 320