Skip to content


Characteristics of a Good Software Requirements Specification (SRS)

Recently, I need to have a look at the IEEE SRS Standard. I think, all of you know very well about it. However, here, I want to reemphasize some basic points about good SRS characteristics briefly.

An SRS should be:

Correct

An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet. Traceability makes this procedure easier and less prone to error.

Unambiguous

An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. As a minimum, this requires that each characteristic of the final product be described using a single unique term.

Complete

An SRS is complete if, and only if, it includes the following elements:

  • All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements imposed by a system specification should be acknowledged and treated.
  • Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values.
  • Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.

Consistent

Consistency refers to internal consistency. If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is not correct. An SRS is internally consistent if, and only if, no subset of individual requirements described in it conflict.

Ranked for importance and/or stability

An SRS is ranked for importance and/or stability if each requirement in it has an identifier to indicate either the importance or stability of that particular requirement. Typically, all of the requirements that relate to a software product are not equally important. Some requirements may be essential, especially for life-critical applications, while others may be desirable. Each requirement in the SRS should be identified to make these differences clear and explicit.

Verifiable

An SRS is verifiable if, and only if, every requirement stated therein is verifiable. A requirement is verifiable if, and only if, there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement.

Nonverifiable requirements include statements such as "works well", "good human interface", and "shall usually happen". These requirements cannot be verified because it is impossible to define the terms "good", "well", or "usually".

Modifiable

An SRS is modifiable if, and only if, its structure and style are such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style. Modifiability generally requires an SRS to

  • Have a coherent and easy-to-use organization with a table of contents, an index, and explicit crossreferencing;
  • Not be redundant (i.e., the same requirement should not appear in more than one place in the SRS);
  • Express each requirement separately, rather than intermixed with other requirements.

Traceable

An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development or enhancement documentation. The following two types of traceability are recommended:

  • Backward traceability (i.e., to previous stages of development). This depends upon each requirement explicitly referencing its source in earlier documents.
  • Forward traceability (i.e., to all documents spawned by the SRS). This depends upon each requirement in the SRS having a unique name or reference number.
Buffer
Share

Posted in Software Engineering.

Tagged with , .


13 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. Emilia Blosfield says

    When in doubt, mumble; much more trouble, delegate; much more charge, ponder.
    Do a lot more than is necessary. What is the distance between someone who achieves cause real progress consistently and people who spend their lives and careers merely following? Further.

  2. dd says

    thank u

  3. firshan ali moon says

    [Green] thank yuu

  4. Pinar says

    why not also in Turkish :(

  5. Pinar says

    thanks anyway i appreciate it

  6. Dave says

    Abdullah, thank for your great work here. It is very helpful
    I have three questions I want to understand very well. 1). HOW IS THE LAYOUT OF A FORMAL REQUIREMENT SPECIFICATION? 2) EXPLAIN WHY A REQUIREMENT IS IMPORTANT FOR BOTH DEVELOPER AND CUSTOMER. 3)DRAW A DATA FLOW DIAGRAM (FROM LEVEL -0 TO LEVEL -2) FOR A SYSTEM WHICH COULD BE A BUSINESS SYSTEM OR AN EDUCATION SYSTEM, IN WHICH SHOULD HAVE AT LEAST 3 PROCESSES. PLEASE, AN APPROPRIATE DESCRIPTION IS REQUIRED FOR THE SYSTEM.

    I’m sorry for inconvenience.

    Thanks a lot!

    Dave.

  7. Leon says

    now i understand..thank you..

  8. Xavier says

    It’s very simple to find out any topic on net as compared to textbooks, as I found this post at this web page.

  9. cheap wow gold says

    it’s a very good weblog and that i like it greatly!

  10. nnonyelu henry says

    This is a very good work.Infact I have gone through it and gathered some information I will use for my exam on the 17th of Dec.Thank you so much for sharing.

  11. Prabhash Chandra says

    Hi Abdullah,

    I like the above explanation.. :-)

    could you please explain BRD, FRD separately. Also could you please let me know how BRD, FRD & SRS are linked in Traceability matrix??

    Thanks in advance!!



Some HTML is OK

or, reply to this post via trackback.