For the first time the software requirement Specification (SRS) is standard published by IEEE (institutes OF Electrical and electronics Engineers) under (ANSI/IEEE Std 830-1984) for the specification of software. IEEE revised the specification several times and is the momentarily newest version Std 830-1998.

Generally

The IEEE specified with this definition, how the document is to be developed. The chapters, which are to occur in this document, are certain thus. The document is in principle into 2 ranges divided:

• C-requirement (Customer requirement)
• D-requirement (development requirement)

Under C-requirements the requirements from view of the customer and/or the END user are to be seized. By D-requirements one understands the development requirements. This is the view from the eyes of the developer, that places technical aspects into the foreground, contrary to the customers.

With "requirements" (German: ") Both the qualitative and the quantitative definition of a necessary program from the view of the client are meant requirements". Ideally such a specification covers detailed description employment planned by purpose, in practice as well as the demanded function range of a software.

Here should technical - "which is "to know" the - like also technical aspects - "to which extent and under which conditions the software will be - Calculation to be carried.

A SRS contains at least three main chapters after IEEE standard. The suggested arrangement should be held to in the quintessential points. In practice this is modified however frequently in the detail. An exemplary arrangement could look as follows:

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

1. Introduction
   1. Purpose (the document)
   2. A goal (the program product)
   3. References to other resources or sources
   4. Explanations concerning terms and/or abbreviations
   5. Overview (as the document is
2. General description (the program product)
   1. Product perspective (to other program products)
   2. Product functions (a summary and an overview)
   3. User characteristics (information to expected users, e.g. education, experience, expertise)
   4. Restrictions (for the developer)
   5. Acceptance and dependence (not realizable and on later versions shifted characteristics)
3. Specified requirements (contrary to 2.)
   1. functional requirements (strongly dependent on the kind of the program product)
   2. non-functional requirements
   3. external interfaces
   4. Design Constraints
   5. Requirements at performance
   6. Quality requirements
   7. Other requirements

The difficulties, which result in practice in the case of such an requirement analysis, are

• possible interest conflicts, thus different goals on the part of the users
• unclear or even unknown technical basic conditions
• itself changing requirements or priorities already during the draft process

Literature

• Eric J. Braude: "Software engineering at Object Oriented Perspective", ISBN 0-471-32208-3
• Colin Hood, Rupert Wiebel/HOOD Group, optimizing with requirements management & engineering: Repeatable, Defined, Managed, Optimized, Springer publishing house, ISBN 3-540-211780
• Chris Rupp, SOPHIST GROUP, requirement engineering and - management professional one, iterative requirement analysis for practice, Hanser publishing house, ISBN 3-446-22877-2
• IEEE Guide ton of software requirement Specification, ANSI/IEEE Std 830-1984, IEEE press, Piscataway, New York, 1984.
• Karl E. Wiegers, software requirement, 2005, Microsoft press Germany, ISBN 3-86063-594-8; Note: The German translation of the second edition is from inferior quality: inconsistent translation of technical terms, in some place non-sense-donating layout. The original version is to be preferred therefore.

See also

• Requirement analysis
• Specification
• Work statement
• Product requirement specifications

Related links

• IEEE software engineering Collection
• Example of a software requirement Specification (EN.)
• SRS document collecting mains

Articles in category "Software requirement Specification"

We found here 5 articles.

Related Websites

We found here 3 related websites.

• How to write a software requirements specification
  How to write a software requirements specification.


• Software Requirements Specification Template
  Software Requirements Specification. for. <Project>. Version 1.0 approved. Prepared by <author>. <organization>. <date created>. Table of Contents ...


• Writing Software Requirements Specifications
  For technical writers who haven't had the experience of designing software requirements specifications (SRSs, also known as software functional ...