UNIT II

Requirement Analysis and

Specification
• The Requirement Analysis and Specification phase starts after the
feasibility study stage is complete and the project is financially viable and
technically feasible.
• This phase ends when the requirements specification document has
been developed and reviewed.
• It is usually called the Software Requirements Specification
(SRS) Document.
• Divide the requirements gathering and analysis activity into two separate
tasks:
• Requirements gathering
• Requirements analysis
• Requirements Gathering:
• It is also known as Requirements Elicitation. The primary objective of the
requirements gathering task is to collect the requirements from the stakeholders.
• A stakeholder is a source of the requirements and is usually a person or a group
of persons who either directly or indirectly are concerned with the software.
• 1. Studying existing documentation: The analyst usually studies all the available
documents regarding the system to be developed before visiting the customer
site. Customers usually provide a statement of purpose (SoP) document to the
developers. Typically these documents might discuss issues such as the context in
which the software is required.
• 2. Interview: Typically, there are many different categories of users of the
software. Each category of users typically requires a different set of features from
the software. Therefore, it is important for the analyst to first identify the
different categories of users and then determine the requirements of
each.
• 3. Task analysis: The users usually have a black-box view of software and consider the
software as something that provides a set of services. A service supported by the
software is also called a task. We can therefore say that the software performs various
tasks of the users. In this context, the analyst tries to identify and understand the
different tasks to be performed by the software. For each identified task, the analyst
tries to formulate the different steps necessary to realise the required functionality in
consultation with the users.
• 4. Scenario analysis: A task can have many scenarios of operation. The different
scenarios of a task may take place when the task is invoked under different situations.
For different types of scenarios of a task, the behaviour of the software can be
different.
• 5. Form analysis: Form analysis is an important and effective requirement gathering
activity that is undertaken by the analyst when the project involves automating an
existing manual system. During the operation of a manual system, normally several
forms are required to be filled up by the stakeholders, and in turn, they receive several
notifications. In form analysis, the exiting forms and the formats of the notifications
produced are analysed to determine the data input to the system and the data that are
output from the system.
• Requirement Analysis and Specification:
• After requirements gathering is complete, the analyst analyses the gathered
requirements to form a clear understanding of the exact customer
requirements and to weed out any problems in the gathered requirements. It
is natural to expect the data collected from various stakeholders to contain
several contradictions, ambiguities, and incompleteness.
• The main purpose of the requirements analysis activity is to analyse the
gathered requirements to remove all ambiguities, incompleteness, and
inconsistencies from the gathered customer requirements and to obtain a
clear understanding of the software to be developed.
• During requirements analysis, the analyst needs to identify and resolve three
main types of problems in the requirements:
• Anomaly
• Inconsistency
• Incompleteness
• Anomaly: It is an anomaly is an ambiguity in a requirement. When a
requirement is anomalous, several interpretations of that requirement are
possible. Any anomaly in any of the requirements can lead to the
development of an incorrect system, since an anomalous requirement can be
interpreted in several ways during development.
• Inconsistency: Two requirements are said to be inconsistent if one of the
requirements contradicts the other.
• Incompleteness: An incomplete set of requirements is one in which some
requirements have been overlooked. The lack of these features would be felt
by the customer much later, possibly while using the software. Often,
incompleteness is caused by the inability of the customer to visualise the
system that is to be developed and to anticipate all the features that would be
required.
Software Requirement
Specifications-SRS
• The production of the requirements stage of the software
development process is Software Requirements Specifications
(SRS) (also called a requirements document).
• This report lays a foundation for software engineering activities and is
constructing when entire requirements are elicited and analyzed.
• SRS is a formal report, which acts as a representation of software that
enables the customers to review whether it (SRS) is according to their
requirements.
• Also, it comprises user requirements for a system as well as detailed
specifications of the system requirements.
• The SRS is a specification for a specific software product, program, or set of
applications that perform particular functions in a specific environment. It
serves several goals depending on who is writing it.
• First, the SRS could be written by the client of a system.
• Second, the SRS could be written by a developer of the system.
• The two methods create entirely various situations and establish different
purposes for the document altogether.
• The first case, SRS, is used to define the needs and expectation of the users.
• The second case, SRS, is written for various purposes and serves as a contract
document between customer and developer.
Characteristics of good SRS
• 1. Correctness: User review is used to provide the accuracy of requirements
stated in the SRS. SRS is said to be perfect if it covers all the needs that are truly
expected from the system.
• 2. Completeness: The SRS is complete if, and only if, it includes the following
elements:
• (a). All essential requirements, whether relating to functionality, performance,
design, constraints, attributes, or external interfaces.
• (b). Definition of their responses of the software to all realizable classes of
input data in all available categories of situations.
• (c). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.
• 3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict
in the SRS:
• 4. Unambiguousness: SRS is unambiguous when every fixed requirement has
only one interpretation. This suggests that each element is uniquely
interpreted. In case there is a method used with multiple definitions, the
requirements report should determine the implications in the SRS so that it is
clear and simple to understand.
• 5. Ranking for importance and stability: The SRS is ranked for importance and
stability if each requirement in it has an identifier to indicate either the
significance or stability of that particular requirement.
• Typically, all requirements are not equally important. Some prerequisites may
be essential, especially for life-critical applications, while others may be
desirable. Each element should be identified to make these differences clear
and explicit. Another way to rank requirements is to distinguish classes of items
as essential, conditional, and optional.
• 6. Modifiability: SRS should be made as modifiable as likely and should be capable of
quickly obtain changes to the system to some extent. Modifications should be perfectly
indexed and cross-referenced.
• 7. Verifiability: SRS is correct when the specified requirements can be verified with a
cost-effective system to check whether the final software meets those requirements. The
requirements are verified with the help of reviews.
• 8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and
if it facilitates the referencing of each condition in future development or enhancement
documentation.
• 9. Design Independence: There should be an option to select from multiple design
alternatives for the final system. More specifically, the SRS should not contain any
implementation details.
• 10. Testability: An SRS should be written in such a method that it is simple to generate
test cases and test plans from the report.
• 11. Understandable by the customer: An end user may be an expert in his/her explicit
domain but might not be trained in computer science. Hence, the purpose of formal
notations and symbols should be avoided too as much extent as possible. The language
should be kept simple and clear.
• 12. The right level of abstraction: If the SRS is written for the requirements
stage, the details should be explained explicitly. Whereas,for a feasibility
study, fewer analysis can be used. Hence, the level of abstraction modifies
according to the objective of the SRS.
Properties of a good SRS document

• Concise: The SRS report should be concise and at the same time, unambiguous,
consistent, and complete. Verbose and irrelevant descriptions decrease readability and
also increase error possibilities.
• Structured: It should be well-structured. A well-structured document is simple to
understand and modify. In practice, the SRS document undergoes several revisions to
cope up with the user requirements. Often, user requirements evolve over a period of
time. Therefore, to make the modifications to the SRS document easy, it is vital to make
the report well-structured.
• Black-box view: It should only define what the system should do and refrain from stating
how to do these. This means that the SRS document should define the external behavior
of the system and not discuss the implementation issues. The SRS report should view the
system to be developed as a black box and should define the externally visible behavior
of the system. For this reason, the SRS report is also known as the black-box specification
of a system.
• Conceptual integrity: It should show conceptual integrity so that the reader
can merely understand it. Response to undesired events: It should
characterize acceptable responses to unwanted events. These are called
system response to exceptional conditions.
• Verifiable: All requirements of the system, as documented in the SRS
document, should be correct. This means that it should be possible to decide
whether or not requirements have been met in an implementation.