What is a SRS?

SRS – the combination of requirements and functional specification for the specification of systems and software

The definition of requirements is an essential aspect in the creation of software and systems. The IEEE (Institute of Electrical and Electronic Engineers) has published a standard for the specification of software and systems – the so-called Systems and Software Requirements Specification (SRS). The complete designation is: IEEE 29148-2018 – ISO/IEC/IEEE International Standard – Systems and software engineering — Life cycle processes — Requirements engineering.

Often the SRS is used as a synonym for customer specification. However, the SRS is not synonymous with a customer specification, because it defines customer requirements – also called C-Requirements – AND development requirements – according to D-Requirements. In other words, an SRS comprises both the customer specification and the functional specification.

Systems or software – what does the SRS specify?

There are publications that distinguish between a Software Requirements Specification (SRS) and a System Requirements Specification (SyRS). The reason for this distinction lies in the further development of the IEEE standard. Originally, IEEE 830-1998 defined a “Recommended Practice for Software Requirements Specification”. The standard was published in June 1998 and replaced by ISO/IEC/IEEE 29148:2011 in December 2011. This new ISO standard addressed processes and products in connection with the engineering of requirements for systems, software products and software services. The specification of software became the specification of systems and software.

A new, revised version was published in October 2018: ISO/IEC/IEEE 29148:2018 defines the construct of a good requirement (e.g. correct, unambiguous, consistent, evaluated according to importance and/or stability, verifiable, modifiable and comprehensible), provides >attributes and properties of requirements and discusses the iterative and recursive application of requirement processes over the entire lifecycle.

The structure of an a SRS

The Systems and Software Requirements Specification is the foundation for the development of a product. It defines the framework for all participants. Usually it contains the following elements:

• introduction with goal, purpose and scope
• general description of the solution to be developed
• user needs
• system and software requirements or system and software functions
• used definitions and acronyms
• supplementary information such as graphics, sketches, models, diagrams, etc.

The advantages of a SRS

Writing a Systems and Software Requirements Specification offers numerous advantages:

• It enables an estimation of expenses, costs, risks, etc.
• It enables the client to formulate his vision of the project / development.
• It forms the foundation for a common, documented understanding between the contractor and the client.
• It documents and structures the status of system and software requirements and is therefore a good tool for all participants.

In practice, it is often the case that a poor or insufficient specification leads to extensive follow-up costs and dissatisfaction on the part of those involved – the client, the contractor, the users. This is another reason why the creation of a good Systems and Software Requirements Specification (SRS) is becoming increasingly important.

Notes:

SRS not only stands for Systems and Software Requirements Specification, but also for a whole series of other terms such as

• Safety Restraint System (a safety system in motor vehicles),
• Safety Requirement Specification (a requirements document on functional safety) or
• Social Reporting Standard (accounting for non-profit organisations).

Here you will find a SRS overview.

Here you will find more information on IEEE 29148-2018.

If you are interested in more explanations, we recommend the free Requirements Engineering Whitepaper.

Here you will find additional information from our t2informatik Blog: