SRS Document
It is a
reference document or contract between the customer and the development team.
Once the customer agrees to the SRS document the development team proceeds to
develop the product conforming to all the requirements mentioned in the SRS
document.
An SRS
document should clearly document the following:
1. Functional requirements of the system.
2. Non-functional requirements of the
system.
3. Constraints on the system.
1. Functional requirements of the system:
Each function of the system can be considered as performing a transformation of
a set of input data to the corresponding set of output data. The functional
requirements of the system should clearly describe each of the functions that
the system needs to perform along with the corresponding input and output data
set.
2. Non-functional requirements of the
system: Non-functional requirements deal with the characteristics of the system
that cannot be expressed functionally, e.g., maintainability, portability,
Usability, etc. The non-functional requirements also include reliability
issues, accuracy of results, human computer interface issues, operating and
Physical constraints, etc.
3. Constraints on the system: The
constraints on the system may describe certain things that the system should or
should not do.
Natures of SRS
The basic
issues the SRS writer(s) shall address are the following:
1. Functionality: What the software is
supposed to do?
2. External Interfaces: How does the
software interact with people, the system's hardware other hardware and other
software?
3. Performance: What is the speed,
availability, response time, recovery time, etc., of the various software
fundamentals?
4. Attributes: What are the considerations
for portability, correctness, maintainability, security, reliability, etc.
5. Design constraints imposed on an
implementation: Are there any required standards or effect, implementation
language, policies for database, integrity resource limits, operating
environment, etc.
Characteristics of a good SRS
An SRS should be
·
Correct
·
Unambiguous
·
Complete
·
Consistent
·
Ranked for Importance and for Stability
·
Verifiable
·
Modifiable
·
Traceable
Correct:
There is no tool or procedure that assures correctness. If the software must
respond to all button presses within 5 seconds and the SRS stated that "the
software shall respond to all button presses with in 10 seconds", then that
requirement is incorrect.
Unambiguous:
An SRS is unambiguous if and only if every requirement started therein has only
are interpretation. In cases, where a term used in a particular context could
have multiple meanings, the term should be included in a glossary where its
meaning is made more specific.
Complete: An
SRS is complete if and only if it includes of the following elements.
1. All significant requirements, whether
relating to functionality, performance, design constraints, attributes or
external interfaces.
2. Full labels and references to all
figures, tables and diagram in the SRS and definition of all terms and units of
measure.
Consistent:
An SRS is consistent if no subset of individual requirements desorbed in it
conflict.
There are 3 types of likely conflicts in an
SRS:
1. The specified characteristics of real
word objects may conflict, e.g. a. The format of an output report may be
described in are requirements as tabular but in another as textual.
b. One requirement may state that all
lights shall be green while another states that all lights should be blue.
2. There may be logical or temporal
conflict between two specified actions, e.g. a. Are requirement may specify
that the program will add 2 inputs and another may specify that the program
will multiply them.
b. Are requirement may state that 'A' must
always follows B, while another requires that A&B occur simultaneously.
3. Two or more requirements may describe the
same real word object but use different terms for that object. The use of
standard terminology and definitions promotes consistency.
Thank you !!