Software Requirements Specification

  • SQAP - Software Quality Assurance plan IEEE 730
  • SCMP - Software Configuration Management Plan IEEE 828
  • STD - Software Test Documentation IEEE 829
  • SRS - Software Requirements Specification IEEE 830
  • SVVP - Software Validation & Verification Plan IEEE 1012
  • SDD - Software Design Description IEEE 1016
  • SPMP - Software Project Management Plan IEEE 1058

The Software Requirements Specification (SRS ) is an IEEE ( Institute of Electrical and Electronic Engineers ), first published in ( ANSI / IEEE Std 830-1984 ) standard for specifying software. The IEEE has repeatedly revised the specification and the latest version is currently Std 830-1998.

The SRS includes the specifications as well as the specifications.

The IEEE Chap. 4.3 defines eight characteristics of good SRS:

  • Correctly
  • Unmehrdeutigkeit ( uniqueness)
  • Completely
  • Consistent
  • Reviewed by importance and / or stability
  • Verifiable
  • Modifiable
  • Trackable ( Traceable )

Correctly and Completely refers to the SRS regarding the actual requirements (external reference ). Consistency refers to the requirements in the form of SRS alone (internal reference ). Unmehrdeutigkeit can accurately interpretation, verifiability limits the complexity of a requirement description in addition to an efficiently testable measure. Modifiability implies, in particular freedom of redundancy. Traceability includes the front and rear direction.

Documentation

The IEEE has established with this definition, how the document should be set up. The chapters that should appear in this document, are thus established. In this case, the document is basically divided into 2 areas:

  • C Requirement ( Customer Requirement): range is comparable to the specifications
  • D Requirement ( Development Requirements): range is comparable to specification

Under C- Requirement the requirements from the customer's perspective and / or the end- user are recorded. Under D Requirement is meant the development requirements. This is the view from the eyes of the developer provides technical aspects to the fore, as opposed to the customer.

With Requirements ( German: , requirements ') is both the qualitative and the quantitative definition of a required program from the perspective of the client meant. Ideally, such a specification includes detailed description of the purpose of the planned use, in practice as well as the required functionality of a software.

It should professional - "What the software can? " - As well as technical aspects - " To what extent and under what conditions, the software will be used? " - Are taken into account.

An SRS includes IEEE Standard for at least three main chapters. Although the proposed structure should be maintained in the core points. In practice, this is frequently modified in detail. An exemplary structure might look like this:

  • Name of the software product
  • Name of manufacturer
  • Version date of the document and / or software

The difficulties that arise in practice for such a requirement analysis,

  • Potential conflicts of interest, ie, different targets by the users
  • Unclear or even unknown technical framework
  • Changing needs or priorities already during the design process
Institute of Electrical and Electronics Engineers Specification (technical standard) Functional specification Functional requirement
407819
de