Software requirements specification

Last updated

A software requirements specification (SRS) is a description of a software system to be developed. It is modeled after the 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.

Contents

Software requirements specifications establish the basis for an agreement between customers and contractors or suppliers on how the software product should function (in a market-driven project, these roles may be played by the marketing and development divisions). Software requirements specification is a rigorous 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. [1] Used appropriately, software requirements specifications can help prevent software project failure. [2]

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

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

Typically a SRS is written by a technical writer, a systems architect, or a software programmer. [5]

Structure

An example organization of an SRS is as follows: [6]

  1. Purpose
    1. Definitions
    2. Background
    3. System overview
    4. References
  2. Overall description
    1. Product perspective
      1. System Interfaces
      2. User interfaces
      3. Hardware interfaces
      4. Software interfaces
      5. Communication Interfaces
      6. Memory constraints
    2. Design constraints
      1. Operations
      2. Site adaptation requirements
    3. Product functions
    4. User characteristics
    5. Constraints, assumptions and dependencies
  3. Specific requirements
    1. External interface requirements
    2. Performance requirements
    3. Logical database requirement
    4. Software system attributes
      1. Reliability
      2. Availability
      3. Security
      4. Maintainability
      5. Portability
    5. Functional requirements
      1. Functional partitioning
      2. Functional description
      3. Control description
    6. Environment characteristics
      1. Hardware
      2. Peripherals
      3. Users
    7. Other

Requirements smell

Following the idea of code smells, 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. [7]

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

See also

Related Research Articles

Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to:

<span class="mw-page-title-main">VHDL</span> Hardware description language

The VHSIC Hardware Description Language (VHDL) is a hardware description language (HDL) that can model the behavior and structure of digital systems at multiple levels of abstraction, ranging from the system level down to that of logic gates, for design entry, documentation, and verification purposes. Since 1987, VHDL has been standardized by the Institute of Electrical and Electronics Engineers (IEEE) as IEEE Std 1076; the latest version of which is IEEE Std 1076-2019. To model analog and mixed-signal systems, an IEEE-standardized HDL based on VHDL called VHDL-AMS has been developed.

<span class="mw-page-title-main">Software architecture</span> High level structures of a software system

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

Software maintenance in software engineering is the modification of a software product after delivery to correct faults, to improve performance or other attributes.

Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.

In software engineering, a test case is a specification of the inputs, execution conditions, testing procedure, and expected results that define a single test to be executed to achieve a particular software testing objective, such as to exercise a particular program path or to verify compliance with a specific requirement. Test cases underlie testing that is methodical rather than haphazard. A battery of test cases can be built to produce the desired coverage of the software being tested. Formally defined test cases allow the same tests to be run repeatedly against successive versions of the software, allowing for effective and consistent regression testing.

A test plan is a document detailing the objectives, resources, and processes for a specific test session for a software or hardware product. The plan typically contains a detailed understanding of the eventual workflow.

Architecture description languages (ADLs) are used in several disciplines: system engineering, software engineering, and enterprise modelling and engineering.

Software quality assurance (SQA) is a means and practice of monitoring all software engineering processes, methods, and work products to ensure compliance against defined standards. It may include ensuring conformance to standards or models, such as ISO/IEC 9126, SPICE or CMMI.

A software design description is a representation of a software design that is to be used for recording design information, addressing various design concerns, and communicating that information to the design’s stakeholders. An SDD usually accompanies an architecture diagram with pointers to detailed feature specifications of smaller pieces of the design. Practically, the description is required to coordinate a large team under a single vision, needs to be a stable reference, and outline all parts of the software and how they will work.

Software project management is the process of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored and controlled.

Instrument control consists of connecting a desktop instrument to a computer and taking measurements.

Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary as (1) the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or primary-subordinate relationship to one another; (2) the identification and documentation of derivation paths (upward) and allocation or flowdown paths (downward) of work products in the work product hierarchy; (3) the degree to which each element in a software development product establishes its reason for existing; and (4) discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks.

ISO/IEC/IEEE 42010Systems and software engineering — Architecture description is an international standard for architecture descriptions of systems and software.

IP-XACT, also known as IEEE 1685, is an XML format that defines and describes individual, re-usable electronic circuit designs to facilitate their use in creating integrated circuits. IP-XACT was created by the SPIRIT Consortium as a standard to enable automated configuration and integration through tools and evolving into an IEEE standard.

A concept of operations is a document describing the characteristics of a proposed system from the viewpoint of an individual who will use that system. Examples include business requirements specification or stakeholder requirements specification (StRS). CONOPS is used to communicate the quantitative and qualitative system characteristics to all stakeholders. CONOPS are widely used in the military, governmental services and other fields.

Software requirements for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as:

  1. A condition or capability needed by a user to solve a problem or achieve an objective
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
  3. A documented representation of a condition or capability as in 1 or 2

ISO 10007 "Quality management — Guidelines for configuration management" is the ISO standard that gives guidance on the use of configuration management within an organization. "It is applicable to the support of products from concept to disposal." The standard was originally published in 1995, and was updated in 2003 and 2017. Its guidance is specifically recommended for meeting "the product identification and traceability requirements" introduced in ISO 9001:2015 and AS9100 Rev D.

References

  1. Bourque, P.; Fairley, R.E. (2014). "Guide to the Software Engineering Body of Knowledge (SWEBOK)". IEEE Computer Society. Archived from the original on 28 December 2014. Retrieved 17 July 2014.
  2. "Software requirements specification helps to protect IT projects from failure" . Retrieved 19 December 2016.
  3. Pressman, Roger (2010). Software Engineering: A Practitioner's Approach. Boston: McGraw Hill. p. 123. ISBN   9780073375977.
  4. "DI-IPSC-81433A, DATA ITEM DESCRIPTION SOFTWARE REQUIREMENTS SPECIFICATION (SRS)". everyspec.com. 1999-12-15. Retrieved 2013-04-04.
  5. Donn Le Vie, Jr. "Writing Software Requirements Specifications (SRS)". 2010.
  6. Stellman, Andrew & Greene, Jennifer (2005). Applied software project management. O'Reilly Media, Inc. p. 308. ISBN   978-0596009489.
  7. 1 2 Femmer, Henning; Méndez Fernández, Daniel; Wagner, Stefan; Eder, Sebastian (2017). "Rapid quality assurance with Requirements Smells". Journal of Systems and Software. 123: 190–213. arXiv: 1611.08847 . doi:10.1016/j.jss.2016.02.047. S2CID   9602750.

[1]

  1. Taaffe, Ed. "Mr". thebridger. Retrieved 2019-02-02.