Software Requirement Specifications
javatpoint.com/software-requirement-specifications
next → ← prev
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:
(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.
1/6
Note: It is essential to specify the responses to both valid and invalid values.
(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.
2/6
(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.
3/6
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.
Next TopicRequirements Analysis
← prev next →
For Videos Join Our Youtube Channel: Join
Now
Help Others, Please Share
Learn Latest Tutorials
4/6
SoapUI
RPA
Manual T.
Cucumber
Appium
PostgreSQL
Solr
MongoDB
Gimp
Verilog
Teradata
PhoneGap
5/6
Preparation
Aptitude
Reasoning
Verbal A.
Interview
Company
Trending Technologies
B.Tech / MCA
6/6
