Software Requirements Specification

Software Requirements Specification

1. good SRS should provide several specific benefits

   • Establish the basis for agreement between the customers and the suppliers on what the software product is to do
   • Reduce the development effort
   • Provide a basis for estimating costs and schedules
   • Provide a baseline for validation and verification
   • Facilitate transfer
   • Serve as a basis for enhancement

2. Definitions

   • contract
     • A legally binding document agreed upon by the customer and supplier. This includes the technical and organizational requirements, cost, and schedule for a product. (...)
   • customer
     • The person, or persons, who pay for the product and usually (but not necessarily) decide the requirements. In the context of this recommended practice the customer and the supplier may be members of the same organization
   • supplier
     • The person, or persons, who produce a product for a customer. In the context of this recommended practice, the customer and the supplier may be members of the same organization
   • user
     • The person, or persons, who operate or interact directly with the product. The user(s) and the customer(s) are often not the same person(s)

3. Nature of the SRS

   • The basic issues that the SRS writer(s) shall address are the following
   • Functionality
     • What is the software supposed to do?
   • External interfaces
     • How does the software interact with people, the system’s hardware, other hardware, and other software?
   • Performance
     • What is the speed, availability, response time, recovery time of various software functions, etc.?
   • Attributes
     • What are the portability, correctness, maintainability, security, etc. considerations?
   • Design constraints imposed on an implementation
     • Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?

4. Characteristics for a good SRS

   • Correct
     • An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet.
     • There is no tool or procedure that ensures correctness
     • The SRS should be compared with any applicable superior specification, such as a system requirements specification, with other project documentation, etc.
     • Alternatively the customer or user can determine if the SRS correctly reflects the actual needs
   • 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
     • In cases where a term used in a particular context could have multiple meanings, the term should be included in a glossary where its meaning is made more specific
   • 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
     • An SRS is internally consistent if, and only if, no subset of individual requirements described in it conflict. The three types of likely conflicts in an SRS are as follows
     • The specified characteristics of real-world objects may conflict
       • eg.: One requirement may state that all lights shall be green while another may state that all lights shall be blue
     • There may be logical or temporal conflict between two specified actions
       • eg.: One requirement may state that “A” must always follow “B,” while another may require that “A and B” occur simultaneously
     • Two or more requirements may describe the same real-world object but use different terms for that object
       • The use of standard terminology and definitions promotes consistency. eg.: a program’s request for a user input may be called a “prompt” in one requirement and a “cue” in another
   • 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
     • Degree of stability
     • Degree of necessity requirements are distinguished as:
       • essential
       • conditional
       • optional
   • 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. An example of a verifiable statement is: Output of the program shall be produced within 20 s of event x 60% of the time; and shall be produced within 30 s of event x 100% of the time. This statement can be verified because it uses concrete terms and measurable quantities
   • 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 cross referencing
       • 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. 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
   • Table of contents
     • 1.Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, acronyms, and abbreviations 1.4 References 1.5 Overview 2. Overall description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 Constraints 2.5 Assumptions and dependencies 3. Specific requirements () Appendixes Index