you're reading...


A summary of IEEE Recommended Practice for Software Requirements Specifications

1. Overview
Five clauses as described below:

1.1 Scope

  • Describes the content and qualities of a good software requirements specification (SRS) and presents several sample SRS outlines.
  • To assist in the selection of in-house and commercial software products.
  • Does not identify any specific method, nomenclature, or tool for preparing an SRS.

2. References

  • ASTM 1340-90, Standard Guide for Rapid Prototyping of Computerized Systems.
  • IEEE std 610.12-1990, IEEE Standard Glossary of Softare Engineering Terminology (ANSI).
  • IEEE std 730-1989, IEEE Standard for Software Quality Assurance Plans (ANSI).
  • IEEE std 828-1990, IEEE Standard Software Configuration Management Plans (ANSI).
  • IEEE std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).
  • IEEE std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).
  • IEEE std 983-1986, IEEE Guide to Software Quality Assurance Planning.
  • IEEE std 1002-1987, IEEE Standard Taxonomy for Software Engineering Standards (ANSI).
  • IEEE std 1012-1986, IEEE Standard for Software Verification and Validation Plans (ANSI).
  • IEEE std 1016-1987, IEEE Recommended Practice for Software Design Descriptions (ANSI).
  • IEEE std 1028-1988, IEEE Standard for Software Reviews and Audits (ANSI).
  • IEEE std 1042-1987, IEEE Guide to Software Configuration Management (ANSI).
  • IEEE std 1058.1-1987, IEEE Standard for Project Management Plans (ANSI).
  • IEEE std 1074-1991, IEEE Standard for Developing Software LIfe Cycle Processes (ANSI).
  • IEEE P1233, October 1993, Draft Guide to Developing System Requirements Specifications.

3. Definitions
3.1 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. A contract may also contain informal but useful information such as the commitments or expectations of the parties involved.

3.2 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.

3.3 Supplier:
The person, or persons, who produces a product for a customer. In the context of this document, the customer and the supplier may be members of the same organization.

3.4 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).

4. Considerations for producing a good SRS
4.1 Nature of SRS:

  • SRS is a specification for a particular software product, program, or a set of programs that performs certain functions in a specific environment.
  • SRS may be written by one or more representatives of the supplier, one or more representatives of the customer, or by both.
  • The basic issues that the SRS writer(s) shall address are the following:

a) Functionality: What is the software supposed to do?
b) External Interfaces: How does the software interact with people, the system’s hardware, other hardware, and other software?
c) Performance: What is the speed, availability, response time, recovery time of various software functions, etc.?
d) Attributes: What are the portability, correctness, maintainability, security, etc. considerations?
e) Design constraints imposed on an implementation: Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environments(s) etc.?
Note: The SRS writer(s) should avoid placing either design or project requirements in the SRS.

4.2 Environment of the SRS

  • The software may contain essentially all the functionality of the project or it may be part of a larger system.
  • In latter case typically there will be an SRS that will state the interfaces between the system and its software portion, and will place external performance and functionality requirements upon the software portion.
  • The SRS:

a) Should correctly define all of the software requirements.
b) Should not describe any design or implementation details.
c) Should not impose additional constraints on the software.
Note: Therefore, a properly written SRS limits the range of valid designs, but does not specify any particular design.

4.3 Characteristics of a good SRS
4.3.1 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.

4.3.2 Unambiguous

  • An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation.
  • Requires that each characteristic of the final product be described using a single unique term.
  • In case of a term having multiple meanings, the term should be included in a glossary where its meaning is made more specific. Natural Language Pitfalls

  • Natural language is inherently ambiguous.
  • Should be reviewed by an independent party to identify ambiguous use of language so that it can be corrected.
  • Requirements Specification Languages  Write the SRS in a particular requirements specification language.
  • Its language processors automatically detect many lexical, syntactic, and semantic errors.
  • Disadvantage:

a) Length of time required to learn them.
b) Many non-technical users find them unintelligible.

  • May influence the requirements in subtle way. Representation Tools

  • Categories: object, process, and behavioural.
  • Real world objects, their attributes, and the services performed by those objects (Object Oriented). Hierarchies of functions that communicate via data flows (Process-Oriented).
  • Describes external behaviour of the system in terms of some abstract notion (such as predicate-calculus), mathematical functions, or state machines (Behaviour-Oriented).

4.3.3 Complete

  • All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular any external requirements placed by a system specification should be acknowledged and treated.
  • Definition of the responses of the software to 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. Use of TBDs

  • Any SRS that uses the phrase “to be determined (TBD)” is not a complete SRS. TBD is, however occassionally necessary and should be accompanied by

a) A description of the conditions causing the TBD.
b) A description of what must be done to eliminate the TBD.
4.3.4 Consistent

  • 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. Internal Consistency

  • If and only if, no subset of individual requirements described in it conflict.
  • Likely confilcts:

a) The specified characteristics of real-world objects may conflict.
b) There may be logical or temoral conflict between two specified actions.
c) Two or more requirements may describe the same real-world object but use different terms of that object.

  • The use of standard terminology and definitions promotes consistenc.

4.3.5 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.
  • All the requirements are not equally important. – Some requirement may be essential, while others may be desirable.
  • Identify requirements:

a) Have customers give more careful consideration to each requirement, which often clarifies any hidden assumptions they may have.
b) Have developers make correct design decisions and devote appropriate levels of effort to the different parts of the software product. Degree of Stability

  • Dimension of stability.
  • Expressed in terms of 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. Degree of Necessity

  • Rank as essential, conditional, and optional.
  • Essential: Implies that the software will not be acceptable unless these requirements are provided in an agreed manner.
  • Conditional: Implies that these requirements would enhance the software product, but would not make it unacceptable if they are absent.
  • Optional: Implies a class of functions that may or may not be worthwhile. This gives the supplier the opportunity to propose something that exceeds the SRS.

4.3.6 Verifiable

  • If and only if, every requirement stated therein 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 requirements.
  • In general any ambiguous requirement is not verifiable.
  • Should not include statements such as “works well”, “good human interfaces”, “shall usually happen”, “the program shall never enter an infinite loop”.
  • Use concrete terms and measurable quantities.
  • If a method cannot be devised to determine whether the software meets a particular requirement, then that requirements should be removed or revised.

4.3.7 Modifiable

  • If and only if, its structure and style are such that any changes to the requirements can be made easily, completely, and cosistently while retaining the structure and style.
  • Requires an SRS to:

a) Have a coherent and easy-to-use organization with a table of contents, an index, and explicit cross-referencing.
b) Not be redundant; that is, the same requirement should not appear in more than one place in the SRS.
c) Express each requirement separately, rather than intermixed with other requirements.

  • Redundancy itself is not an error, but it can easily lead to errors. occasionally help to make an SRS more readable.
  • Whenever redundancy is necessary, the SRS should include explicit cross-references to make it modifiable.

4.3.8 Traceable

  • If the origin of each of its requirements is clear.
  • If it facilitates the referencing of each requirement in future development or enhancement documentation.
  • Backward traceability (that is, to previous stages of development)
  • Forward traceability (that is, to all documents spawned by the SRS)
  • Forward traceability is especially important when the software product enters the operation and maintenance phase.

4.4 Joint Preparation of the SRS

  • Should begin with supplier and customer agreement on what the completed software must do.
  • Customers usually do not understand the software design and development process well enough to write a usable SRS.
  • Suppliers usually do not understand the customer’s problems and the field of endeavour well enough to specify the requirements for a satisfactory system.

4.5 SRS Evolution

  • May need to evolve as the the development of software product proceeds.
  • Additional changes can ensue as deficiencies, shortcomings, inaccuracies discovered in the SRS.
  • Requirements should be specified as completely and thoroughly as is known at the time, even if evolutionary revisions may seem inevitable. The fact that they are incomplete should be noted.
  • Identify, track, and report projection changes.

i) Provide an accurate and complete audit trail of changes.
ii) Permit the review of current and suspended portion of SRS.
4.6 Prototyping

  • Useful for three reasons:

a) Provides quick feedback.
b) Displays unanticipated apects of system behaviour; this helps to reach closure.
c) An SRS based on prototyping tends to undergo less change during development, thus shortening development time.

  • Should be use as a way to elicit software requirements.

4.7 Embedding Design in the SRS

  • A requirement specified 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 should clearly distinguish between identifying required design constraints and projecting a specific design.
  • The SRS should specify what functions are to be performed on what data to produce what results as 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:

a) Partitioning the software into modules.
b) Allocating functions to the modules.
c) Describing the flow of information or control between modules.
d) Choosing data structures.
4.7.1 Necessary Design Requirements

  • Some requirements may severely restrict the design. For example, security or safety requirements may reflect directly into design such as the need to:

a) Keep certain functions in separate modules.
b) Permit only limited communication between some areas of the program.
c) Check data integrity for for critical variables.
4.8 Embedding Project Requirements in the SRS

  • The SRS should address the software product, not the process of producing the software product.
  • Project requirements represent an understanding between customer and supplier about contractual matters pertaining to production of software and thus should not be included in the SRS.
  • These normally include such items as:

a) Cost
b) Delivery schedules
c) Reporting procedures
d) Software development methods
e) Quality assurance
f) Validation and verification criteria
g) Acceptance procedures

  • Project requirements are specified in other documents, typically in software development plan, a software quality assurance plan, or a statement of work.

5. The Parts of an SRS
Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, an 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
Figure 1- Prototype SRS Outline

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.

5.1 Introduction (Section 1 of the SRS)
5.1.1 Purpose (1.1 of the SRS)

  • Delineate the purpose of the particular SRS.
  • Specify the intended audience for the SRS.

5.1.2 Scope (1.2 of SRS)

  • Identify the software product(s) to be produced by name (for example, Host DBMS, Report Generator etc.).
  • Explain what the software product(s) will, and, if necessary, will not do.
  • Describe the application of the software being specified, including relevant benefits, objectives, and goals.
  • Be consistent with similar statements in higher-level specifications (for example, the system requirement specification), if they exist.

5.1.3 Definitions, Acronyms, and Abbreviations (1.3 of the SRS)
This subsection should provide the definitions of all terms, acronyms, and abbreviations required to interpret properly the SRS. This information may be provided by reference to one or more appendixes in the SRS or by reference to other documents.

5.1.4 References (1.4 or SRS)

  • Provide a complete list of all documents referred elsewhere in the SRS.
  • Identify each document by title, report number (if applicable), date and publishing organization.
  • Specify the sources from which the references can be obtained.

5.1.5 Overview (1.5 of the SRS)

  • Describe what the rest of SRS contains.
  • Explain how the SRS is organized.

5.2 Overall Description (Section 2 of the SRS)

  • Should describe the general factors that affect the product and its requirements.
  • Does not state specific requirements. Instead, it provies a background for those requirements.

5.2.1 Product Perspective (2.1 of the SRS)

  • Should put the product into perspective with other related products.
  • Is independent and totally self-contained, it should be so stated here.
  • Defines a product that is a component a larger system, as frequently occurs, then this subsection should relate the requirements of that larger system to functionality of the software and should identify interfaces between systems and the software.
  • A block diagram showing the major components of the larger system, interconnections, and external interfaces can be helpful. System Interfaces

  • Should list each system interfaces.
  • Identify the functionality of the software to accomplish the system requirement and the interface description to match the system. User Interfaces

  • The logical characteristics of each interface the software product and its users.

a) Includes configuration characteristics

  • All the aspects of optimizing the interface with the person who must use the system.

a) This may simply comprise a list of do’s and don’ts on how the system will appear to the user.
b) should be verifiable. Hardware Interfaces

  • Specify the logical characteristics of each interface between the software product and the hardware components of the system.
  • Consider matters as what devices are to be supported, how they are to be supported, and protocols. Software Interfaces

  • Should specify the use of other required software products, and interfaces with other application systems.
  • For each required software product, the following should be provided:

a) Name
b) Mnemonic
c) Specification number
d) Version number
e) Source

  • For each interface, the following should be provided:

a) Discussion of the purpose of the interfacing software as related to this software product.
b) Definition of the interface in terms of message content and format. It is not necessary to detail any well-documented interface, but a reference to the document defining the interface is required. Communications Interfaces

  • Specify various interfaces to communications such as local network protocols etc. Operations

  • Specify the normal and special operations required by user such as:

a) The various modes of operations in the user organization; for example user-initiated operations.
b) Periods of interactive operations and periods of unattended operations.
c) Data processing support functions.
d) Backup and recovery operations.
Note: This is sometimes specified as part of the User Interfaces section. Site Adaptation Requirements

  • Define the requirements for any data or initialization sequences that are specific to a give site, mission, or operational mode, for example, grid values, safety limits, etc.
  • Specify the site or mission-related features that should be modified to adapt the software to a particular installation.

5.2.2 Product Functions (2.2 of the SRS)

  • Should provide a summary of the major functions that the software will perform.
  • Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher level specification (if one exists) that allocates particular functions to the software product.

a) The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time.
b) Textual or graphical methods can be used to show the different functions and their relationships. Such a diagram is not intended to show a design of a product but simply shows the logical relationships among variables.
5.2.3 User Characteristics (2.3 of the SRS)

  • Should describe those general characteristics of the intended users of the product including educational level, experience, and technical expertise.
  • Should not be used to state specific requirements but rather should provide the reasons why certain specific requirements are later specified.

5.2.4 Constraints (2.4 of the SRS)

  • Should provide a general description of any other items that will limit the developer’s options.
  • These include:

a) Regulatory policies
b) Hardware limitations (for example, signal timing requirements)
c) Interfaces to other applications
d) Parallel operation
e) Audit functions
f) Control functions
g) Higer-order language requirements
h) Signal handshake protocols (for example, XON-XOFF, ACK-NACK)
i) Reliability requirements
j) Criticality of the application
k) Safety and security considerations
5.2.5 Assumptions and Dependencies (2.5 of the SRS)

  • Should list each of the factors that affect the requirements stated in the SRS.
  • Are not design constraints on the software but are, rather, any changes to them that can affect the requirements of the SRS.

5.2.6 Apportioning of Requirements (2.6 of the SRS)

  • Should identify requirements that may be delayed until future versions of the system.

5.3 Specific Requirements (Section 3 of the SRS)

  • Should contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements.
  • Every stated requirement should be externally perceivable by users, operators, or other external systems.
  • Should include at a minimum a description of every input(stimulus) into the system, every output(response) from the system and all functions performed by the system in response to an input or in support of an output.
  • Often the largest and most important part of the SRS
  • Applicable principles:

a) Specific requirements should be stated in conformance with all the characteristics described in 4.3 of this recommended practice.
b) Specific requirements should be cross-referenced to earlier documents that relate.
c) All requirements should be uniquely identifiable.
d) Careful attention should be given to organizing the requirements to maximize readability.
Before examining specific ways of organizing the requirements it is helpful to understand the various items that comprise requirements as described in the following sub-clauses.
5.3.1 External Interfaces

  • Detailed description of all inputs into and outputs from the software system.
  • It should complement the interface descriptions in 5.2 and should not repeat information there.
  • Format:

a) Name of item
b) Description of purpose
c) Source of input or destination of output
d) Valid range, accuracy and/or tolerance
e) Units of measure
f) Timing
g) Relationships to other inputs/outputs
h) Screen formats/organization
i) Window formats/organization
j) Data formats
k) Command formats
l) End messages
5.3.2 Functions

  • Should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs.
  • These are generally listed as “shall” statements starting the The system shall…
  • These include:

a) Validity checks on the inputs.
b) Exact sequence of operations.
c) Responses to abnormal situations, including

i) Overflow
ii) Communication facilities
iii) Error handling and recovery
d) Effect of parameters.
e) Relationship of outputs to inputs, including

i) Input/Output sequences
ii) Formulae for input to output conversion

  • It may be appropriate to partition the functional requirements into sub-functions or sub processes. This does not however imply that the software design will also be partitioned that way.

5.3.3 Performance Requirements

  • Should specify both the static and dynamic numerical requirements placed on the software or human interaction with the software as a whole.
  • Static numerical requirements may include:

a) The number of terminals to be supported
b) The number of simultaneous users to be supported
c) Amount and type of information to be handled

  • Static numerical requirements are sometimes identified under a separate section entitled capacity.
  • Dynamic requirements may include, for example, the number of transactions and tasks and the amount of data to be processed within certain time periods for both the normal and peak workload conditions.
  • Should be stated in measurable terms.

Note: Numerical limits applied to one specific function are normally specified as part of the processing sub paragraph description of that function.

5.3.4 Logical Database Requirements

  • Should specify the logical requirements for any information that is to be placed into a database.This may include:

a) Types of information used by various functions
b) Frequency of use
c) Accessing capabilities
d) Data entities and their relationships
e) Integrity constraints
f) Data retention requirements
5.3.5 Design Constraints

  • Should specify the requirements derived from existing standards or regulations. Standard compliance

  • Should specify the requirements derived from existing standards or regulations.
  • They may include:

a) Report format
b) Data naming
c) Accounting procedures
d) Audit tracing
5.3.6 Software System Attributes

  • It is important that required attributes be specified so that their achievement can be objectively verified. Reliability

  • Specify the factors required to establish the required reliability of the software system at time of delivery. Availability

  • Specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart. Security

  • Specify the factors that would protect the software from accidental or malicious access, use, modification, destruction, or disclosure.

a) Utilize certain cryptographic techniques
b) Keep specific log or history data sets
c) Assign certain functions to different modules
d) Restrict communications between some areas of the program
e) Check data integrity for critical variables Maintainability

  • Should specify attributes of software that relate to the ease of maintenance of the software itself.
  • May be some requirement for certain modularity, interfaces, complexity, etc.
  • Requirements should not be placed here just because they are thought to be good design practices. Portability

  • Should specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems.
  • This may include:

a) Percentage of components with host-dependent code
b) Percentage of code that is host-dependent
c) Use of a proven portable language
d) Use of a particular compiler or language set
e) Use of a particular operating system
5.3.7 Organizing the Specific Requirements

  • Detailed requirements tend to tbe extensive.
  • Careful considerations should be given to organizing these requirements in a manner optimal for understanding.
  • No one proven optimal organization for all systems. – Different classes of systems lend themselves to different organizations of requirements. System Mode

  • For systems that behave quite differently depending upon the mode of operation (e.g. training mode, normal mode, emergency etc.)
  • The choice depends on whether interfaces and performance are dependent on mode. User Class

  • For systems that provide different sets of functions to different classes of users. Objects

  • Objects are real-world entities that have a counterpart within the system.
  • Associated with each object is a set of attributes (of that object) and functions (performed by that object).
  • Sets of objects may share attributes and services; such objects are grouped together as classes. Feature

  • An externally desired service by the system that may require a sequence of inputs to affect the desired result.
  • Each feature is generally described in a sequence of stimulus-response pairs. Stimulus

  • Some systems can be best organized by describing their functions in term of stimuli (e.g. aircraft landing system). Response

  • Some systems can be best organized by describing all the functions in support of the geneartion of response. Functional Hierarchy

  • The overall functionality can be organized into a hierarchy of functions organized by either common inputs, common outputs, or common internal data access.
  • Data flow diagrams and data dictionaries can be used to show the relationships between and among the functions and data.

5.3.8 Additional Comments

  • Organize the specific requirements for multiple hierarchies tailored to the specific needs of the system under specification.
  • There are many notations, methods, and automated support tools available to aid in the documentation of requirements.

5.4 Supporting Information
a) Table of Contents
b) Index
c) Appendixes

5.4.1 Table of Contents and Index

  • The table of contents and index are quite important and should follow general compositional practices.

5.4.2 Appendixes

  • The appendixes are not always considered part of the actual requirements specification and are not always necessary.
  • They may include:

a) Sample I/O formats, descriptions of cost analysis studies, or results of user surveys
b) Supporting or background information that can help the readers of the SRS
c) A description of the problems to be solved by the software
d) Special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements. When appendixes are included, the SRS should explicitly state whether or not the appendixes are to be considered part of the requirements.
Reference Document: IEEE Recommended Practice for Software Requirements Specifications, IEEE Std 830-1993 (Revision of IEEE Std 830-1984)

License of this document: Creative Commons Attributable-Share Alike 3.0 Unported License


3 Responses to “A summary of IEEE Recommended Practice for Software Requirements Specifications”

  1. sir wat will be the “supplementary requirements”content

    Posted by siri | February 19, 2012, 11:21 pm
  2. Where can I get the quality SRS template? If you have, can you please share ?

    Posted by Michael Gyan | March 19, 2012, 9:55 pm

Post a Comment