UNIT 3: SOFTWARE REQUIREMENT ANALYSIS

As systems grew more complex, it became evident that the goals of the entire system could not be easily
comprehended. Hence the need for more rigorous requirements analysis arose. Now, for large software
systems, requirements analysis is perhaps the most difficult and intractable activity; it is also very error-
prone. Many believe that the software engineering discipline is weakest in this critical area.
Software Requirements
IEEE defines a requirement as "(1) A condition of capability needed by a user to solve a problem or
achieve an objective; (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."
The goal of the requirements activity is to produce the Software Requirements Specification (SRS), that
describes what the proposed software should do without describing how the software will do it.
Need for SRS
The origin of most software systems is in the needs of some clients. The software system itself is created
by some developers. Finally, the completed system will be used by the end users. Thus, there are three
major parties interested in a new system: the client, the developer, and the users. Somehow the
requirements for the system that will satisfy the needs of the clients and the concerns of the users have to
be communicated to the developer.
SRS is the medium through which the client and user needs are accurately specified to the developer.
Hence one of the main advantages is:
An SRS establishes the basis for agreement between the client and the supplier on what the software
product will do.
This basis for agreement is frequently formalized into a legal contract between the client (or the
customer) and the developer (the supplier). So, through SRS, the client clearly describes what it expects
from the supplier, and the developer clearly understands what capabilities to build in the software.
Actually, the reality of the situation is that even with such an agreement, the client is frequently not
satisfied! A related, but important, advantage is:
An SRS provides a reference for validation of the final product.
That is, the SRS helps the client determine if the software meets the requirements. Without a proper SRS,
there is no way a client can determine if the software being delivered is what was ordered, and there is no
way the developer can convince the client that all the requirements have been fulfilled.
Clearly, if we want a high-quality end product that has few errors, we must begin with a high-quality
SRS. In other words, we can conclude that:
A high-quality SRS is a prerequisite to high-quality software.
Finally, we show that the quality of SRS has an impact on cost (and schedule) of the project. a
requirement error, if detected and removed after the system has been developed, can cost up to 100 times
more than removing it during the requirements phase itself.
A high quality SRS reduces the development cost.
Hence, the quality of the SRS impacts customer (and developer) satisfaction, system validation, quality of
the final software, and the software development cost. The critical role the SRS plays in a software
development project should be evident from these.
Requirement Process

The requirement process is the sequence of activities that need to be performed in the requirements phase
and that culminate in producing a high quality document containing the software requirements
specification (SRS).
The requirements process typically consists of three basic tasks: problem or requirement analysis,
requirement specification, and requirements validation.
Problem analysis often starts with a high-level "problem statement."
During analysis the problem domain and the environment are modeled in an effort to understand the
system behavior, constraints on the system, its inputs and outputs, etc. The basic purpose of this activity is
to obtain a thorough understanding of what the software needs to provide. The understanding obtained by
problem analysis forms the basis of requirements specification, in which the focus is on clearly specifying
the requirements in a document. Issues such as representation, specification languages, and tools, are
addressed during this activity.
Requirements validation focuses on ensuring that what has been specified in the SRS are indeed all the
requirements of the software and making sure that the SRS is of good quality. The requirements process
terminates with the production of the validated SRS.
As shown in the figure, from the specification activity we may go back to the analysis activity. This
happens as frequently some parts of the problem are analyzed and then specified before other parts are
analyzed and specified.
Furthermore, the process of specification frequently shows shortcomings in the knowledge of the
problem, thereby necessitating further analysis. Once the specification is "complete" it goes through the
validation activity. This activity may reveal problems in the specifications itself, which requires going
back to the specification step, or may reveal shortcomings in the understanding of the problem, which
requires going back to the analysis activity.
Problem Analysis
The basic aim of problem analysis is to obtain a clear understanding of the needs of the clients and the
users, what exactly is desired from the software, and what the constraints on the solution are. The analysts
have to ensure that the real needs of the clients and the users are uncovered, even if they don't know them
clearly.
The basic principle used in analysis is the same as in any complex task: divide and conquer. That is,
partition the problem into subproblems and then try to understand each subproblem and its relationship to
other subproblems in an effort to understand the total problem.
The concepts of state and projection can sometimes also be used effectively in the partitioning process. A
state of a system represents some conditions about the system. Frequently, when using state, a system is
first viewed as operating in one of the several possible states, and then a detailed analysis is performed for
each state.
In projection, a system is defined from multiple points of view. While using projection, different
viewpoints of the system are defined and the system is then analyzed from these different perspectives.
The different "projections" obtained are combined to form the analysis for the complete system.
Informal Approach
The informal approach to analysis is one where no defined methodology is used. Like in any approach,
the information about the system is obtained by interaction with the client, end users, questionnaires,
study of existing documents, brainstorming, etc. However, with this approach no formal model is built of
the system.
Data Flow Modeling
Data-flow based modeling, often referred to as the structured analysis technique, uses function-based
decomposition while modeling the problem. It focuses on the functions performed in the problem domain
and the data consumed and produced by these functions. It is a top-down refinement approach, which was
originally called structured analysis and specification, and was proposed for producing the specifications.
Data Flow Diagrams and Data Dictionary
Data flow diagrams (also called data flow graphs) are commonly used during problem analysis. Data
flow diagrams (DFDs) are quite general and are not limited to problem analysis for software requirements
specification. They were in use long before the software engineering discipline began. DFDs are very
useful in understanding a system and can be effectively used during analysis.
A DFD shows the flow of data through a system. It views a system as a function that transforms the
inputs into desired outputs. Any complex system will not perform this transformation in a "single step,"
and a data will typically undergo a series of transformations before it becomes the output. The DFD aims
to capture the transformations that take place within a system to the input data so that eventually the
output data is produced. The agent that performs the transformation of data from one state to another is
called a process (or a bubble). So, a DFD shows the movement of data through the different
transformations or processes in the system. The processes are shown by named circles and data flows are
represented by named arrows entering or leaving the bubbles. A rectangle represents a source or sinks and
is a net originator or consumer of data. A source or a sink is typically outside the main system of study.
All external files are shown as a labeled straight line. The need for multiple data flows by a process is
represented by a '*' between the data flows. This symbol represents the AND relationship. For example, if
there is a '*' between the two input data flows A and B for a process, it means that A AND B are needed
for the process. Similarly, the OR relationship is represented by a ' + ' between the data flows.
It should be pointed out that a DFD is not a flowchart. A DFD represents the flow of data, while a
flowchart shows the flow of control. A DFD does not represent procedural information. So, while
drawing a DFD, one must not get involved in procedural details, and procedural thinking must be
consciously avoided. For example, considerations of loops and decisions must be ignored.
Following are some suggestions for constructing a data flow diagram:
 Work your way consistently from the inputs to the outputs, or vice versa. If you get stuck, reverse
direction. Start with a high-level data flow graph with few major transforms describing the entire
transformation from the inputs to outputs and then refine each transform with more detailed
transformations.
 Never try to show control logic. If you find yourself thinking in terms of loops and decisions, it is
time to stop and start again.
 Label each arrow with proper data elements. Inputs and outputs of each transform should be
carefully identified.
 Make use of * and + operations and show sufficient detail in the data flow graph.
An example of a DFD for a system that pays workers is shown in following figure. In this DFD there is
one basic input data flow, the weekly timesheet, which originates from the source worker. The basic
output is the paycheck, the sink for which is also the worker. In this system, first the employee's record is
retrieved, using the employee ID, which is contained in the timesheet. From the employee record, the rate
of payment and overtime are obtained. These rates and the regular and overtime hours (from the
timesheet) are used to compute the pay. After the total pay is determined, taxes are deducted. To compute
the tax deduction, information from the tax-rate file is used. The amount of tax deducted is recorded in
the employee and company records. Finally, the paycheck is issued for the net pay. The amount paid is
also recorded in company records.

In addition to the walkthrough with the client, the analyst should look for common errors. Some common
errors are:
• Unlabeled data flows
• Missing data flows; information required by a process is not available
• Extraneous data flows; some information is not being used in the process
• Consistency not maintained during refinement
• Missing processes
• Contains some control information
Requirements Specification
Characteristics of an SRS
To properly satisfy the basic goals, an SRS should have certain properties and should contain different
types of requirements. In this section, we discuss some of the desirable characteristics of an SRS and
components of an SRS. A good SRS is:
1. Correct
2. Complete
3. Unambiguous
4. Verifiable
5. Consistent
6. Ranked for importance and/or stability
7. Modifiable
8. Traceable
An SRS is correct if every requirement included in the SRS represents something required in the final
system.
An SRS is complete if everything the software is supposed to do and the responses of the software to all
classes of input data are specified in the SRS.
Correctness and completeness go hand-in-hand; whereas correctness ensures that which is specified is
done correctly, completeness ensures that everything is indeed specified.
An SRS is unambiguous if and only if every requirement stated has one and only one interpretation. One
way to avoid ambiguities is to use some formal requirements specification language.
An SRS is verifiable if and only if every stated requirement is verifiable. A requirement is verifiable if
there exists some cost-effective process that can check whether the final software meets that requirement.
This implies that the requirements should have as little subjectivity as possible because subjective
requirements are difficult to verify.
An SRS is consistent if there is no requirement that conflicts with another. Terminology can cause
inconsistencies; for example, different requirements may use different terms to refer to the same object.
There may be logical or temporal conflict between requirements that causes inconsistencies. This occurs
if the SRS contains two or more requirements whose logical or temporal characteristics cannot be
satisfied together by any software system.
Generally, all the requirements for software are not of equal importance. Some are critical, others are
important but not critical, and there are some which are desirable but not very important. Similarly, some
requirements are "core" requirements which are not likely to change as time passes, while others are more
dependent on time. An SRS is ranked for importance and/or stability if for each requirement the
importance and the stability of the requirement are indicated. Stability of a requirement reflects the
chances of it changing in future. It can be reflected in terms of the expected change volume.
An SRS is modifiable if its structure and style are such that any necessary change can be made easily
while preserving completeness and consistency. Presence of redundancy is a major hindrance to
modifiability, as it can easily lead to errors.
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. Forward traceability means that each requirement should be
traceable to some design and code elements. Backward traceability requires that it be possible to trace
design and code elements to the requirements they support. Traceability aids verification and validation.
Components of an SRS
Completeness of specifications is difficult to achieve and even more difficult to verify. Having guidelines
about what different things an SRS should specify will help in completely specifying the requirements.
Here we describe some of the system properties that an SRS should specify. The basic issues an SRS
must address are:
• Functionality
• Performance
• Design constraints imposed on an implementation
• External interfaces
Conceptually, any SRS should have these components.
Functional Requirements
Functional requirements specify which outputs should be produced from the given inputs. They describe
the relationship between the input and output of the system. For each functional requirement, a detailed
description of all the data inputs and their source, the units of measure, and the range of valid inputs must
be specified.
All the operations to be performed on the input data to obtain the output should be specified. This
includes specifying the validity checks on the input and output data, parameters affected by the operation,
and equations or other logical operations that must be used to transform the inputs into corresponding
outputs.
An important part of the specification is the system behavior in abnormal situations, like invalid input
(which can occur in many ways) or error during computation. The functional requirement must clearly
state what the system should do if such situations occur. Specifically, it should specify the behavior of the
system for invalid inputs and invalid outputs. Furthermore, behavior for situations where the input is valid
but the normal operation cannot be performed should also be specified.
Performance Requirements
This part of an SRS specifies the performance constraints on the software system. All the requirements
relating to the performance characteristics of the system must be clearly specified. There are two types of
performance requirements: static and dynamic.
Static requirements are those that do not impose constraint on the execution characteristics of the system.
These include requirements like the number of terminals to be supported, the number of simultaneous
users to be supported, and the number of files that the system has to process and their sizes. These are
also called capacity requirements of the system.
Dynamic requirements specify constraints on the execution behavior of the system. These typically
include response time and throughput constraints on the system. Response time is the expected time for
the completion of an operation under specified circumstances. Throughput is the expected number of
operations that can be performed in a unit time.
All of these requirements should be stated in measurable terms. Requirements such as "response time
should be good" or the system must be able to "process all the transactions quickly" are not desirable
because they are imprecise and not verifiable. Instead, statements like "the response time of command x
should be less than one second 90% of the times" or "a transaction should be processed in less than one
second 98% of the times" should be used to declare performance specifications.
Design Constraints
There are a number of factors in the client's environment that may restrict the choices of a designer. Such
factors include standards that must be followed, resource limits, operating environment, reliability and
security requirements, and policies that may have an impact on the design of the system. An SRS should
identify and specify all such constraints.
 Standards Compliance: This specifies the requirements for the standards the system must
follow. The standards may include the report format and accounting procedures.
 Hardware Limitations: The software may have to operate on some existing or predetermined
hardware, thus imposing restrictions on the design. Hardware limitations can include the type of
machines to be used, operating system available on the system, languages supported, and limits
on primary and secondary storage.
 Reliability and Fault Tolerance: Fault tolerance requirements can place a major constraint on
how the system is to be designed. Fault tolerance requirements often make the system more
complex and expensive. Requirements about system behavior in the face of certain kinds of faults
are specified. Recovery requirements are often an integral part here, detailing what the system
should do if some failure occurs to ensure certain properties. Reliability requirements are very
important for critical applications.
  Security: Security requirements are particularly significant in defense systems and many
database systems. Security requirements place restrictions on the use of certain commands,
control access to data, provide different kinds of access requirements for different people, require
the use of passwords and cryptography techniques, and maintain a log of activities in the system.
External Interface Requirements
All the interactions of the software with people, hardware, and other software should be clearly specified.
For the user interface, the characteristics of each user interface of the software product should be
specified. User interface is becoming increasingly important and must be given proper attention. A
preliminary user manual should be created with all user commands, screen formats, an explanation of
how the system will appear to the user, and feedback and error messages.
Specification Language
Requirements specification necessitates the use of some specification language. The language should
support the desired qualities of the SRS— modifiability, understandability, unambiguous, and so forth. In
addition, the language should be easy to learn and use. As one might expect, many of these characteristics
conflict in the selection of a specification language. For example, to avoid ambiguity, it is best to use
some formal language. But for ease of understanding a natural language might be preferable.
In an SRS, as discussed, some parts can be specified better using some formal notation. For example, to
specify formats of inputs or outputs, regular expressions can be very useful. Similarly, when discussing
systems like communication protocols, finite state automata can be used. Decision tables are useful to
formally specify the behavior of a system on different combinations of inputs or settings. Similarly, some
aspects of the system may be specified or explained using the models that may have been built during
problem analysis. Sometimes models may be included as supporting documents that help clarify the
requirements and the motivation better.
Structure of a Requirements Document
All the requirements for the system have to be included in a document that is clear and concise. For this,
it is necessary to organize the requirements document as sections and subsections. There can be many
ways to structure a requirements document. Many methods and standards have been proposed for
organizing an SRS. One of the main ideas of standardizing the structure of the document is that with an
available standard, each SRS will fit a certain pattern, which will make it easier for others to understand
(that is one of the roles of any standard). Another role these standards play is that by requiring various
aspects to be specified, they help ensure that the analyst does not forget some major property.
The IEEE standards recognize the fact that different projects may require their requirements to be
organized differently, that is, there is no one method that is suitable for all projects. It provides different
ways of structuring the SRS. The first two sections of the SRS are the same in all of them. The general
structure of an SRS is given in following figure.

Validation
The development of software starts with a requirements document, which is also used to determine
eventually whether or not the delivered software system is acceptable. It is therefore important that the
requirements specification contains no errors and specifies the client's requirements correctly.
The basic objective of the requirements validation activity is to ensure that the SRS reflects the actual
requirements accurately and clearly. A related objective is to check that the SRS document is itself of
"good quality".
Before discussing validation, let us consider the type of errors that typically occur in an SRS. The most
common errors that occur can be classified in four types: omission, inconsistency, incorrect fact, and
ambiguity.
 1. Omission is a common error in requirements. In this type of error, some user requirement is
simply not included in the SRS; the omitted requirement may be related to the behavior of the
system, its performance, constraints, or any other factor. Omission directly affects the external
completeness of the SRS.
2. Another common form of error in requirements is inconsistency. Inconsistency can be due to
contradictions within the requirements themselves or to incompatibility of the stated requirements
with the actual requirements of the client or with the environment in which the system will
operate.
3. The third common requirement error is incorrect fact Errors of this type occur when some fact
recorded in the SRS is not correct.
4. The fourth common error type is ambiguity. Errors of this type occur when there are some
requirements that have multiple meanings, that is, their interpretation is not unique.
As requirements are generally textual documents that cannot be executed, inspections are eminently
suitable for requirements validation. Consequently, inspections of the SRS, frequently called
requirements review, are the most common method of validation.
Requirements review is a review by a group of people to find errors and point out other matters of
concern in the requirements specifications of a system. The review group should include the author of the
requirements document, someone who understands the needs of the client, a person of the design team,
and the person(s) responsible for maintaining the requirements document. It is also good practice to
include some people not directly involved with product development, like a software quality engineer.
Checklists are frequently used in reviews to focus the review effort and ensure that no major source of
errors is overlooked by the reviewers. A checklist for requirements review should include items like:
• Are all hardware resources defined?
• Have the response times of functions been specified?
• Have all the hardware, external software, and data interfaces been defined?
• Have all the functions required by the client been specified?
• Is each requirement testable?
• Is the initial state of the system defined?
• Are the responses to exceptional conditions specified?
• Does the requirement contain restrictions that can be controlled by the designer?
• Are possible future modifications specified?
Though requirements reviews remain the most commonly used and viable means for requirement
validation, other possibilities arise if some special purpose tools for modeling and analysis are used.
Metrics
The basic purpose of metrics at any point during a development project is to provide quantitative
information to the management process so that the information can be used to effectively control the
development process.
There are very few metrics that have been defined for requirements, and little work has been done to
study the relationship between the metric values and the project properties of interest.
Size—Function Points
A commonly used size metric for requirements is the size of the text of the SRS. The size could be in
number of pages, number of paragraphs, number of functional requirements, etc. As can be imagined,
these measures are highly dependent on the authors of the document.
Function points are one of the most widely used measures of software size. The basis of function points is
that the "functionality" of a system, that is, what the system performs, is the measure of the system size.
The original formulation for computing the function points uses the count of five different parameters,
namely, external input types, external output types, logical internal file types, external interface file types,
and external inquiry types. According to the function point approach, these five parameters capture the
entire functionality of a system. However, two elements of the same type may differ in their complexity
and hence should not contribute the same amount to the "functionality" of the system. To account for
complexity, each parameter in a type is classified as simple, average, or complex.
Quality Metrics
It is important to ensure that the SRS is of good quality. For this, some quality metrics are needed that can
be used to assess the quality of the SRS. Quality of an SRS can be assessed either directly by evaluating
the quality of the document by estimating the value of one or more of the quality attributes of the SRS, or
indirectly, by assessing the effectiveness of the quality control measures used in the development process
during the requirements phase. Quality attributes of the SRS are generally hard to quantify, and little
work has been done in quantifying these attributes and determining correlation with project parameters.
Hence, the use of these metrics is still limited. However, process-based metrics are better understood and
used more widely for monitoring and controlling the requirements phase of a project.
Number of errors found is a process metric that is useful for assessing the quality of requirement
specifications. Once the number of errors of different categories found during the requirement review of
the project is known, some assessment can be made about the SRS from the size of the project and
historical data.
Change request frequency can be used as a metric to assess the stability of the requirements and how
many changes in requirements to expect during the later stages.