characteristics of SRS

 CHARACTERISTICS OF AN SRS(Software requirements specification)

An SRS should have certain properties and should contain different types of requirements to
satisfy the basic goals:
They are as follows:

1. Correct :

 An SRS is correct if every requirement included in the SRS represents something
required in the final system.
 Correctness ensures that which is specified is done correctly.
 Correctness is an easier property to establish than completeness as it basically involves
examining each requirement to make sure it represents the user requirements.

2. Complete:

 SRS should be absolute.
Requirements must be complete such that all the required information to implement
the requirement is included.
 SRS must precisely define the entire real world situation that will be encountered and
the capability response to them.

3. Unambiguous:

 Every requirement stated has one and only one interpretation.
 No double meaning exist.
 Must use some formal requirement specification language to avoid ambiguities.
 The disadvantage of using other language is the large effort to write SRS, High costing
and difficulty in reading and understanding.
 example: All screen must load quickly.
Here quickly doesn’t specify how quick. Better one would be
“All screen must load within 5 second”

4. Verifiable:

 An SRS is verifiable (can be proved, demonstrate) if and only if every stated
requirement is verifiable.
 A verifiable/testable requirement can be defined as a requirement, which can be tested
and validated using any of the following methods:

 Inspection
 Walkthrough
 Demonstration
 Testing

 In this manner, it is possible to ensure that the requirement has been implemented
correctly.
 To be testable, requirements should be clear, precise, and unambiguous.
 Verification of requirements is done through reviews.
 Example: :”The system must be user-friendly. “
How will you test it once the software is developed and is ready to be delivered for the
UAT. It is not testable. So a better example would be:
“The user interface should be menu driven on the top of the website along with site
index. A tool tip for all the text boxes must be provided.”

5. Consistent:

 SRS should be dependable.
 SRS capability functions and performance levels are friendly, and the required quality
 No conflicts should be existed for consistency.
 Different requirements may use different terms to refer to the same object. This
should not be happened.
 E.g. Event E occur before event F in 1 module and event F occur before event E in
another module, this is inconsistency and it should not exist in SRS.

6. Ranked for importance and /or stability:

 Generally, all the requirements for software are not of equal importance.
 Some requirements are critical (serious, important), some are important, some are
desirable (wanted) and some are core (interior, center).
 Rank important and less important requirements as all are not same. It Indicates
stability of requirements.
 Stability of a requirement reflects the chances of it changing in future.

7. Modifiable:

 Every SRS Document must be modifiable and change easily.
 In modern software project, requirement are never static and don’t stop after SRS
Document is signoff.
 SRS must have a logical structure to be modifiable.
 In case of any change, specific requirement and dependent ones can be modified
accordingly without impact to others.

8. Traceable:

 Each requirement should be clearly specified and traceable.
 Traceability facilitates the referencing of each requirement in future development.
 There are two types of traceability: forward traceability & backward trace ability.
 Forward traceability: we can design and code with requirements of SRS.
 Backward traceability: we can identify or check requirements with design and code.