Software Requirement Specification(SRS)

Software Requirement Specification A software requirements specification (SRS) is a

detailed description of a software system to be developed with its functional and non-
functional requirements. The SRS is developed based the agreement between customer and
contractors. It may include the use cases of how user is going to interact with software
system. The software requirement specification document consistent of all necessary
requirements required for project development. To develop the software system we should
have clear understanding of Software system. To achieve this we need to continuous
communication with customers to gather all requirements. A good SRS defines the how
Software System will interact with all internal modules, hardware, communication with other
programs and human user interactions with wide range of real life scenarios. Using the
Software requirements specification (SRS) document on QA lead, managers creates test plan.
It is very important that testers must be cleared with every detail specified in this document in
order to avoid faults in test cases and its expected results. It is highly recommended to review
or test SRS documents before start writing test cases and making any plan for testing. Let’s
see how to test SRS and the important point to keep in mind while testing it.
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 conflicts. 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 requirement's 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.
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 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.

FURPS is an acronym representing a model for classifying requirements.

Usability - UX, Human Factors, Aesthetics, Consistency, Documentation Reliability -
Availability, Robustness/Durability, Recoverability, Stability, Accuracy Performance - Speed,
Efficiency, Resource Consumption

The IEEE standard for requirements documents The most widely known requirements
document standard is (IEEE, 1998).
This IEEE standard suggests the following structure for requirements documents:

1. Introduction
1.1 Purpose of the requirements document
1.2 Scope of the product 1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document

2. General description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies

3.Specific requirements, covering functional, non-functional and interface requirements. This

is obviously the most substantial part of the document but because of the wide variability in
organisational practice, it is not appropriate to define a standard structure for this section. The
requirements may document external interfaces, describe system functionality and
performance, and specify logical database requirements, design constraints, emergent system
properties and quality characteristics.

4.Appendices
5.Index

Although the IEEE standard is not ideal, it contains a great deal of good advice on how to
write requirements and how to avoid problems. It is too general to be an organisational
standard in its own right. It is a general framework that can be tailored and adapted to define a
standard geared to the needs of a particular organisation.
Useful link –
Data Dictionaries:
A data dictionary is a file or a set of files that includes a database's metadata. The data
dictionary hold records about other objects in the database, such as data ownership, data
relationships to other objects, and other data. The data dictionary is an essential component of
any relational database. Ironically, because of its importance, it is invisible to most database
users.
Typically, only database administrators interact with the data dictionary.