A Software Requirements Specification (SRS) document describes the intended purpose, requirements and nature of software to be developed. It provides a detailed overview of software product, purpose, requirements and features. The SRS document fully describes what the software will do and how it will be expected to perform.
The customer requirements identified
during the requirements gathering and analysis activity are organized into SRS
document. The three most important contents of this document are the functional
requirements, non-functional requirements, and the goals of implementation.
It is written using end-user
terminology. This makes the SRS document understandable by the customer. SRS
document acts as a representation of software
that enables the customers to review whether it (SRS) is according to their
requirements. The SRS document normally serves as a contract
between the development team and the customer. Any future dispute between the
customer and the developers can be settled by examining the SRS document. The
SRS document is therefore an important document which must be thoroughly
understood by the developer team, and reviewed jointly with the customer. The
SRS document not only forms the basis for carrying out all the development
activities, but several documents such as users’ manuals, system test plan, are
prepared directly based on it.
Characteristics
of a Good SRS Document:
Software requirements
specification should be unambiguous, accurate, complete, efficient, and of high
quality, so that it does not affect the entire project plan. An SRS is said to
be of high quality when the developer and user easily understand the prepared
document. The characteristics of SRS are explained below:
Correctness: Every
requirement in the SRS must be true requirements of the system. User review is used to ensure the correctness of requirements stated in
the SRS. SRS is said to be correct if it covers all the requirements that are
actually expected from the system. Correctness
ensures that all specified requirements are performed correctly.
Completeness: SRS is complete when the requirements clearly define what the
software is required to do. This includes all the requirements related to
performance, design and functionality. SRS should contain all sorts of input
and it should provide features for handling all functions of the system.
Consistency: Requirements in SRS are said to be consistent if there are
no conflicts between any set of requirements. For
example, there can be a case when different requirements can use different
terms to refer to the same object. SRS should use consistent terminologies so
that there is no requirement that conflicts with another.
Unambiguousness: SRS is unambiguous when every requirement
specified in SRS document has only one interpretation. This implies that each
requirement is uniquely interpreted. In case there is a term used with multiple
meanings, the requirements document should specify the meanings in the SRS so
that it is clear and simple to understand.
Verifiability: SRS is verifiable if and only if there exists
some cost-effective process that can check whether the final product meets the
requirement.
Modifiability: SRS Document must be
modifiable. The requirements of the user
can change, hence requirements document should be created in such a manner that
those changes can be modified easily, consistently maintaining the structure
and style of the SRS.
Traceability: SRS is traceable when the source of each requirement is clear and facilitates the reference of each requirement in future. For this, forward tracing and backward tracing are used. Forward tracing implies that each requirement should be traceable to design and code elements. Backward tracing implies defining each requirement explicitly referencing its source.
0 Comments
if you have any doubts plz let me know...