The software requirements specification (SRS) is an official statement of what the system developers should implement. It should include both the user requirements for a system and a detailed specification of the system requirements. In many cases, the user and system requirements are integrated into a single description. In other cases, the user requirements are defined in an introduction to the system requirements specification. As the number of requirements grow, it is more and more common to have the detailed system requirements presented in a separate document.
Requirements documents are essential when an outside contractor is developing the software system. However, some of the software development methodologies (i.e., agile methods) argue that requirements change so quickly that a requirements document is out of date as soon as it is written, therefore the effort spent with its preparation is largely wasted. Rather than a formal document, approaches such as Extreme Programming (XP) or Scrum collect user requirements incrementally and write these on cards as so-called user stories. The user then prioritizes requirements for implementation in the next increment of the system.
For business systems where requirements are unstable, this is a viable approach. However, in our opinion, it is still useful to write a short supporting document that defines the business and dependability requirements for the system; it is easy to forget the requirements that apply to the system as a whole when focusing on the functional requirements for the next system release.
The requirements document has a diverse set of users (stakeholders), ranging from the senior management of the organization that is paying for the system to the engineers responsible for developing the software. Figure Users of a requirements document [SOMMERVILLE2010] shows possible users of the document and how they use it.
![Users of a requirements document [SOMMERVILLE2010]](images/requirementsengineering/usersofsrs.png)
The IEEE Recommended Practice for Software Requirements Specifications ([IEEE830:1998]) discusses a number of issues that should be considered during the creation of an SRS. Here we only give a short overview of those considerations.
The SRS is a specification for a particular software product, program, or set of programs that performs certain functions in a specific environment. The SRS may be written by one or more representatives of the supplier, one or more representatives of the customer, or by both. The recommendation is that it should be prepared by both, together.
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.?
The SRS writer(s) should avoid placing either design or project requirements in the SRS.
An SRS has a specific role to play in the software development process, i.e., it plays a well-defined role in the whole project. It is a part of the total project plan and it should also conform to some higher-level documents like the System Requirements Specification which describes the requirements of a computer system (not only the software part). As a consequence, SRS writer(s) should be careful not to go beyond the bounds of that role. This means the SRS
Should correctly define all of the software requirements. A software requirement may exist because of the nature of the task to be solved or because of a special characteristic of the project.
Should not describe any design or implementation details. These should be described in the design stage of the project.
Should not impose additional constraints on the software. These are properly specified in other documents such as a software quality assurance plan.
Therefore, a properly written SRS limits the range of valid designs, but does not specify any particular design.
The Recommendation identifies 8 important characteristics which a good SRS should have. These are the following:
Correctness. An SRS is correct if, and only if, every requirement stated therein is one that the software shall meet. However, generally speaking there is no tool or procedure to ensure correctness. That’s why the SRS should be compared to superior documents (including the System Requirements Specification, if exists) during a review process in order to filter out possible contradictions and inconsistencies. Reviews should also be used to get a feedback from the customer side on whether the SRS correctly reflects the actual needs. This process can be made easier and less error-prone by traceability.
Unambiguity. 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.
Completeness. 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.
However, completeness is very hard to achieve, especially when talking about business systems where the requirements always change and new requirements raise. Completeness is something that agile methodologies (which think that there is a continuous change in the requirements) cannot interpret. On the other hand, when following a plan-driven methodology, completeness might make sense, but probably in a bit modified manner: all those requirements should be described in the SRS which are known by the actual time. It also requires updating of the document if some new requirements emerge.
Consistency. 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 a violation of correctness. 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. For example, the format of an output report may be described in one requirement as tabular but in another as textual or 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. For example, one requirement may specify that the program will add two inputs and another may specify that the program will multiply them or 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. For example, a program’s request for a user input may be called a “prompt" in one requirement and a “cue" in another. The use of standard terminology and definitions promotes consistency.
Ranking. 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. There are many possibilities of ranking requirements, however, most notably we use ranking based on the degree of stability and/or degree of necessity.
Stability can be expressed in terms of the number of expected changes to any requirement based on experience or knowledge of forthcoming events that affect the organization, functions, and people supported by the software system.
Based on necessity, one can identify classes of requirements as essential, conditional, and optional. Essential requirements are those that imply that the software will not be acceptable unless these requirements are provided in an agreed manner. Conditional requirements imply that these are requirements that would enhance the software product, but would not make it unacceptable if they are absent. Last but not least, optional requirements imply a class of functions that may or may not be worthwhile. This gives the supplier the opportunity to propose something that exceeds the SRS.
Verifiability. 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. In general any ambiguous requirement is not verifiable. 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". The statement that “the program shall never enter an infinite loop" is also nonverifiable because the testing of this quality is theoretically impossible. 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. If a method cannot be devised to determine whether the software meets a particular requirement, then that requirement should be removed or revised.
Modifiability. 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.
Redundancy itself is not an error, but it can easily lead to errors. Redundancy can occasionally help to make an SRS more readable, but a problem can arise when the redundant document is updated. For instance, a requirement may be altered in only one of the places where it appears. The SRS then becomes inconsistent. Whenever redundancy is necessary, the SRS should include explicit cross-references to make it modifiable.
Traceability. 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.
The forward traceability of the SRS is especially important when the software product enters the operation and maintenance phase. As code and design documents are modified, it is essential to be able to ascertain the complete set of requirements that may be affected by those modifications.
It is also important to note that the SRS may need to evolve as the development of the software product progresses. It may be impossible to specify some details at the time the project is initiated (e.g., it may be impossible to define all of the screen formats for an interactive program during the requirements phase). Additional changes may ensue as deficiencies, shortcomings, and inaccuracies are discovered in the SRS. Two major considerations in this process are the following:
Requirements should be specified as completely and thoroughly as is known at the time, even if evolutionary revisions can be foreseen as inevitable. The fact that they are incomplete should be noted.
A formal change process should be initiated to identify, control, track, and report projected changes.
Approved changes in requirements should be incorporated in the SRS in such a way as to
Provide an accurate and complete audit trail of changes;
Permit the review of current and superseded portions of the SRS.
A requirement specifies an externally visible function or attribute of a system. A design describes a particular subcomponent of a system and/or its interfaces with other subcomponents. The SRS writer(s) should clearly distinguish between identifying required design constraints and projecting a specific design. Note that every requirement in the SRS limits design alternatives. This does not mean, though, that every requirement is design. The SRS should specify what functions are to be performed on what data to produce what results at what location for whom. The SRS should focus on the services to be performed. The SRS should not normally specify design items such as the following:
Partitioning the software into modules;
Allocating functions to the modules;
Describing the flow of information or control between modules;
Choosing data structures.
However, in special cases, some requirements may severely restrict the design. For example, security or safety requirements may reflect directly into design such as the need to
Keep certain functions in separate modules;
Permit only limited communication between some areas of the program;
Check data integrity for critical variables.
Examples of valid design constraints are physical requirements, performance requirements, software development standards, and software quality assurance standards.
Therefore, the requirements should be stated from a purely external viewpoint. When using models to illustrate the requirements, remember that the model only indicates the external behavior, and does not specify a design.
The IEEE Recommended Practice for Software Requirements Specifications (IEEE 830) document proposes a structure for SRS documents (see Figure Recommended structure for SRS documents). As this is a recommendation, companies are welcome to adapt, tune and tailor this structure to their actual needs. This means that in the most of the cases, organizational standards are developed on the basis of this quasi-standard. While an SRS does not have to follow this outline or use the names given here for its parts, a good SRS should include all the information discussed here.
In fact, the 3rd section, entitled Specific requirements, may have different internal structures. Depending on the type of the application and the approach of requirements elicitation, IEEE 830 offers a range of possible structures in the Appendix. Here we selected the layout which suits to the case study and omitted the details of the others. For other types of software systems different organization might suit more, the reader should consult IEEE 830 for more information.