Software Requirement

Specifications
 What is Software Requirement Specification – (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
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:
• All essential requirements, whether relating to functionality, performance, design,
constraints, attributes, or external interfaces.
• Definition of their responses of the software to all realizable classes of input data in all
available categories of situations.
• Full labels and references to all figures, tables, and diagrams in the SRS and definitions of
all terms and units of measure.
3. 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.
4. 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.
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. 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.
9. 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.

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.
The below diagram depicts the various types of requirements that
are captured during SRS.
 Structure of a SRS Document
An example organization of an SRS is as follows:
1. Purpose
• Definitions
• Background 3. Specific requirements
• System overview • External interface requirements
• References • Performance requirements

2. Overall description • Logical database requirement

• Product perspective • Software system attributes

• Reliability
• System interfaces
• Availability
• User interfaces
• Security
• Hardware interfaces • Maintainability
• Software interfaces • Portability
• Communication interfaces • Functional requirements
• Memory constraints • Functional partitioning
• Functional description
• Design constraints
• Control description
• Operations
• Environment characteristics
• Site adaptation requirements
• Hardware
• Product functions • Peripherals
• User characteristics • Users
• Constraints, assumptions and dependencies • Other