Question: What is characteristics ?

 • Correct: SRS should specify the functionality correctly from all aspects. It

also be continually updated to reflect all the software updates and
enhancements.

• Unambiguous: As SRS is written iri natural language, it is possible for it to
be interpreted in multiple ways based on the context, cultural background
etc. So, SRS should consider these things and define and refine in most
unambiguous fashion as possible. This would include providing references,
elaborating any abstract requirement with example scenarios etc. It is a good
practice to get a proof read of SRS by another person to weed out an)’
ambiguous descriptions.

• Precise: The description should not contain fizzy words so as to make it
precise.

• Complete: SRS should provide all the details required by software
.designers for design and implementation of the intended software.

• Consistent: The terminologies, definitions and others used throughout the
SRS should be consistent. It is a good practice to pre-define all definitions,
abbreviations and refer them consistently throughout SRS.

• Verifiable: This supplements the unambiguous characteristic. All
requirements should be quantified with exact and verifiable numbers. For
instance “The home page should load quickly” is non-verifiable as “quickly”
is subjective; it is also not mentioned if the page should load quickly across
all geographies. Instead of these subjective terms the requirement should
quantify it with the exact response time: “The home page should load within
2 seconds in North America region”.

• Modifiable: The requirements should be detailed only once throughout the
document so that it is easy to modify and maintain the document in long run.
To ensure that SRS is modifiable it should:
1. Be coherent, well-organized and contain cross-referencing
2. Avoid redundancy
3. State each requirement separately

• Traceable: SRS should map the requirements to other business/user
requirement documents so that it is possible to trace the requirements. It
should also support backward-traceability and forward traceability.

• Ranked for importance/stability: The requirements should be ranked
based on its deemed business/user importance. Ranking is done based on:
1. Degree of stability: Stability is related to number of changes required
for implementing functionality.
2. Degree of importance: In this case, the requirements are classified
into categories such as essential, conditional and optional.

Few other characteristics of a good SRS are that it should be understandable by people
of varied backgrounds and it should be design independent. That is, without favoring
any particular design.