Software requirements specification

from Wikipedia, the free encyclopedia
Definitions of IEEE

The Software Requirements Specification (SRS) is a standard for the specification of software published by the IEEE ( Institute of Electrical and Electronic Engineers ) for the first time (under ANSI / IEEE Std 830-1984) . The IEEE has revised the specification several times. The current version is Std 29148-2018.

The SRS includes the specification sheet as well as the functional specification .

quality

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

  • correctly
  • unambiguously (unambiguously)
  • Completely
  • free of contradictions
  • rated according to importance and / or stability
  • verifiable
  • modifiable
  • traceable (traceable)

“Correct” and “complete” refer to the actual requirements specified in the SRS (external reference). Consistency refers to the requirements in the form of the SRS alone (internal reference). Unambiguity allows exactly one interpretation, verifiability also limits the complexity of a requirements description to an efficiently testable level. Modifiability particularly requires freedom from redundancy. Traceability encompasses the forward and backward direction.

documentation

With this definition, the IEEE determined how the document should be structured. The chapters that should appear in this document have thus been determined. The document basically consists of two parts:

  • C-Requirement ( customer requirement ): this part is comparable to a specification sheet ,
  • D-Requirement ( development requirement ): this part is comparable to a functional specification .

The requirements from the perspective of the customer and / or the end user are to be recorded under C-Requirement. D-Requirement is understood to mean the development requirements. This is the view from the developer's point of view, who puts technical aspects in the foreground, as opposed to the customer.

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

Specialist (“What should the software be able to do?”) And technical aspects (“To what extent and under what conditions will the software be used?”) Should be taken into account.

According to the IEEE standard, an SRS contains at least three main chapters. The proposed structure should be adhered to in the main points, but in practice this is often modified in detail. An exemplary structure could look like this:

  • Name of the software product
  • Name of the producer
  • Version date of the document and / or the software
  1. introduction
    1. Purpose of the document)
    2. Scope (of the software product)
    3. Explanations of terms and / or abbreviations
    4. References to other resources or sources
    5. Overview (how is the document structured?)
  2. General description (of the software product)
    1. Product perspective (to other software products)
    2. Product features (a summary and overview)
    3. User characteristics (information about expected users, e.g. education, experience, expertise)
    4. Limitations (for the developer)
    5. Assumptions and dependencies (factors that influence the development, but do not hinder, e.g. the choice of the operating system)
    6. Distribution of requirements (that cannot be implemented and properties that have been postponed to later versions)
  3. Specific requirements (as opposed to 2.)
    1. functional requirements (strongly dependent on the type of software product)
    2. Nonfunctional requirements
    3. external interfaces
    4. Design constraints
    5. Requirements for performance
    6. Quality requirements
    7. Other requirements

The difficulties that arise in practice with such a requirements analysis are

  • possible conflicts of interest, i.e. different goals on the part of the users
  • unclear or even unknown technical framework conditions
  • changing requirements or priorities during the design process.

literature

  • IEEE Guide to Software Requirements Specification . ANSI / IEEE Std 830-1984. IEEE Press, Piscataway / New Jersey 1984.
  • Colin Hood, Susanne Mühlbauer, Chris Rupp, Gerhard Versteegen (eds.): IX study requirements management . Methods and techniques, implementation scenarios and tools in comparison. 2nd Edition. Heise, Hanover April 2007, OCLC 255168117 .

Web links