Practical : 2

What is SRS (Software Requirement Specification)?

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 analysed. 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.

Characteristics of good SRS

Following are the features of a good SRS document:

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:

(1). All essential requirements, whether relating to functionality, performance, design,

constraints, attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data in all
available categories of situations.

(3). 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:

(1). The specified characteristics of real-world objects may conflict. For example,

(a) The format of an output report may be described in one requirement as tabular but in
another as textual.

(b) One condition may state that all lights shall be green while another states that all lights
shall be blue.

(2). There may be a reasonable or temporal conflict between the two specified actions. For
example,

(a) One requirement may determine that the program will add two inputs, and another may
determine that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires that "A
and B" co-occurs.

(3). Two or more requirements may define the same real-world object but use different terms
for that object. For example, a program's request for user input may be called a "prompt" in
one requirements and a "cue" in another. The use of standard terminology and descriptions
promotes consistency.

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.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing its

source in earlier documents.

2. Forward Traceability: This depends upon each element in the SRS having a unique name
or reference number.

The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is necessary
to be able to ascertain the complete set of requirements that may be concerned by those
modifications.

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.
Features of a good SRS document:

 Clear and Concise: The document should be written in a clear and concise manner,
avoiding unnecessary technical jargon or ambiguity. It should be easily
understandable by both technical and non-technical stakeholders.

 Complete: The SRS document should cover all the functional and non-functional
requirements of the software system. It should address all the needs and expectations
of the stakeholders.

 Well-Organized Structure: The document should have a well-organized structure

with appropriate sections and subsections. It should include an introduction,
functional requirements, non-functional requirements, system constraints,
assumptions, dependencies, and any other relevant sections.

 Consistent and Unambiguous: The requirements stated in the SRS document should
be consistent and unambiguous. Any potential conflicts or contradictions should be
resolved, and the requirements should be written in a way that leaves no room for
multiple interpretations.

 Measurable and Testable: The requirements should be specified in a way that allows
for objective verification and testing. They should be measurable, allowing the
development team to determine whether they have been successfully implemented.

 Traceability: The SRS document should provide traceability between the

requirements and their sources, such as user needs or business objectives. This helps
in understanding the rationale behind each requirement and facilitates change
management.

 Realistic and Feasible: The requirements should be realistic and feasible within the
given constraints, such as budget, time, and technology limitations. They should be
achievable without compromising the overall quality of the software system.
 Modifiable: The SRS document should be designed to accommodate future changes
and updates. It should be flexible enough to incorporate new requirements or modify
existing ones without requiring a complete overhaul.

 Non-Ambitious: The requirements should avoid specifying implementation details or

design choices. The focus should be on what the system needs to achieve, rather than
how it should be implemented.
  Reviewed and Approved: The SRS document should undergo thorough review and
approval by all relevant stakeholders, including business analysts, developers, testers,
and clients. This ensures that all perspectives are considered and any potential issues
or misunderstandings are addressed early on.

Properties of a good SRS document

The essential properties of a good SRS document are the following:

 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
behaviour 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 behaviour 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.

Make an SRS Document for any one topic.