User:Gerardnoordhuis/Software requirements specification

A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after a business requirements specification (CONOPS). The software requirements specification lays out functional and non-functional requirements, and it may include a set of use cases that describe user interactions that the software must provide to the user for perfect interaction.

Software requirements specification establishes the basis for an agreement between acquirers (customers) and suppliers (contractors) on how the software product should function.

The software requirements specification document lists sufficient and necessary requirements for the project development. To derive the requirements, the developer needs to have clear and thorough understanding of the products under development. This is achieved through detailed and continuous communications with the project team and acquirer throughout the software development process.

The SRS may be one of a contract's deliverable data item descriptions or have other forms of organizationally-mandated content.

Typically an SRS is written by a technical writer, a systems architect, or a software programmer.

Purpose
A software requirements specification is defined as a requirements specification pertaining to a software system. A software requirements specification contributes to the assessment of requirements before the more specific system design stages, and its goal is to reduce later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules. Used appropriately, software requirements specifications can help prevent software project failure.

Requirements engineering (RE) involves effectively communicating the requirements among various stakeholders. The manner in which requirements are documented is crucial for ensuring they can be "read, analysed, (re-)written, and validated".

Readers
The requirements document may be used for reference by a number of different stakeholders :

Writing an SRS
A requirements specification is typically written by the supplier, but the authors of the SRS can also include individuals representing the acquirer. It is recommended that the acquirer and the supplier work together to produce a well-written and completely understood SRS.

Several sources include an outline for structuring an SRS. SRS documentation usually includes at least those sections:


 * an introduction,
 * an overall description
 * specific requirements

Structure
One standardised outline that can be used is the following:

1. Introduction

 * Purpose
 * Scope
 * Product overview
 * Product perspective
 * Product functions
 * User characteristics
 * Limitations
 * Definitions

3. Specific requirements

 * External interfaces
 * Functions
 * Usability requirements
 * Performance requirements
 * Logical database requirements
 * Design constraints
 * Software system attributes
 * Supporting information

4. Verification
This section should elaborate on verification approaches and methods that can be applied to qualify the software.

5. Appendices


 * Assumptions and dependencies
 * Acronyms and abbreviations

Specific requirements
This section is usually the heart of the document and should generally be the largest section. This part of the SRS should be structured in a way that is most helpful for all stakeholders. There is no single optimal structure that is appropriate for all systems, but the SRS should always include Functional requirements and Non-functional requirements.

EEE standard 830 offers templates for organising the requirements based on eight approaches: by mode, user class, object, feature, stimulus, functional hierarchy, or a combination of these. There isn't a one-size-fits-all approach, so it might be advisable for organisations and project teams to adjust the templates to their specific needs.

IEEE standards
The importance of engineering requirements for software systems has been recognised since the early days of software engineering, and as a result several standards have been established. These standards provide guidelines on the content and format of an SRS document.

The Institute of Electrical and Electronics Engineers (IEEE) has published several software engineering standards, including IEEE Std 830-1998, "IEEE Recommended Practice for Software Requirements Specifications". Standard 830, last revised in 1998, has been replaced by ISO/IEC/IEEE 29148:2011, which received an update in 2018.

Characteristics of a good SRS
Research indicates that there is a positive correlation between high-quality SRSs and project success. According to IEEE 830 a proper SRS should be correct, unambiguous, complete, consistent, ranked, verifiable, modifiable and traceable. However, it is difficult for specifications to actually meet those criteria.

Detecting requirement defects
It is difficult to automatically detect defects in requirements artifacts, as industry requirements are primarily written in natural language which has no formal semantics. To face this challenge, the notion of requirements smell has been proposed to describe issues in requirements specification where the requirement is not necessarily wrong but could be problematic, following the idea of code smells. Requirement (bad) smells are "concrete symptoms for a requirement artifact’s quality defect for which we enable rapid feedback through automatic smell detection".

Examples of requirements smells are subjective language, ambiguous adverbs and adjectives, superlatives and negative statements.

Revising/updating the SRS
Requirements management is an important aspect of Requirements engineering. The SRS may need revision as the development of the software product progresses, as some details may be unknown at the start of the project and new issues may arise as the project progresses. According mentions two major considerations if additional changes are made :


 * 1) As could be read in the Characteristics of a good SRS the requirements should be as complete as possible at any time. If a requirement is incomplete and later revision is deemed inevitable, this should be mentioned in the SRS.
 * 2) Changes should be documented for traceability and previous, superseded parts of the SRS should stay available for review.

Prototype
A prototype can be used to demonstrate how the intended product will work, allowing stakeholders to visualize and interact with the features and functionality of the system. It can help improve communication between stakeholders by providing a common understanding.

Agile development
The development community still appears to be a bit unfamiliar with the role of requirements engineering practices in Agile software development methods and might need further research. Agile is incremental and iterative and practitioners could argue that a requirements document might have become obsolete as soon as it has been written, due to the ever-changing needs of the project. Therefore, the effort of creating specific requirements may not always seem of much use. Rather than a formal SRS document, methodologies like Scrum sometimes add requirements incrementally or write user stories instead. Rather than laying out requirements, Agile teams can us the user stories to illustrate the expected behaviour. These function as acceptance tests for developers, because they can check if they have implemented every user story.