Requirement in Software Requirement Specification (SRS) interpretation

Discussion

• Nirja Shah   -Posted on 05 Oct 15
  - An SRS should be as follows:
  
  Correct
  - This is one of the most important part.
  - The specification should always be correct.
  - No one writes a specification that they know is incorrect.
  - The discipline is keeping the specification up to date when you find things that are not correct.
  
  Unambiguous
  - An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation.
  - Spending time on this area prior to releasing the SRS can be a waste of time.
  - But as you find ambiguities - fix them.
  
  Complete
  - A simple judge of this is that is should be all that is needed by the software designers to create the software.
  
  Consistent
  - The SRS should be consistent within itself and consistent to its reference documents.
  - If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.
  
  Ranked for Importance
  - Very often a new system has requirements that are really marketing wish lists.
  - Some may not be achievable.
  - It is useful and important to provide this information in the SRS.
  
  Verifiable
  - Don't put in requirements like - "It should provide the user a fast response." or something like "The system should never crash."
  - Instead, provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds."
  
  Modifiable
  - Having the same requirement in more than one place may not be wrong - but tends to make the document not maintainable.
  
  Traceable
  - Often, this is not important in a non-politicized environment.
  - However, in most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document.

➨ Post your comment / Share knowledge