Requirements Specification and Documentation

Information Items (types of documents)

From 29148-2018 Section 7

1. Business Requirements Specification (BRS) (29148-2018 Section 8.2) / System Definition Document (SWEBOK 5.1) / Concept of Operations (ConOps) (29148-2018 Annex B) / User Requirements Document

   1. Purpose: describes the organization’s motivation for why the system is being developed or changed, defines processes and policies/rules under which the system is used and documents the top-level requirements from the stakeholder perspective including expressing needs of users/operators/maintainers as derived from the context of use in a specific, precise and unambiguous manner

   2. Key Content: at the organization level, the organizational environment, goals and objectives, the business model, and the information environment, and, at the business operation level, the business operation model, business operation modes, business operational quality, organizational formation and concept of the proposed system. Typical types of requirements included in the BRS are organizational requirements and business requirements.

   3. Created By: the business itself, often with a business analyst

   4. Target Audience:

      1. a business analyst or representative user from the business to review and discuss the business model or operation

      2. business management to verify and revise

      3. a system analyst to review and discuss potential technical solutions

      4. software / systems engineers to create the SyRS and / or SRS

2. Stakeholder Requirements Specification (StRS) 29148-2018 Section 8.3 (sometimes combined with the SyRS (29148 8.3.1 Note 1) or BRS (Note 2))

   1. Purpose: describes the organization’s motivation for why the system is being developed or changed, defines processes and policies/rules under which the system is used and documents the top-level requirements from the stakeholders’ perspective including expressing needs of users/operators/maintainers as derived from the context of use in a specific, precise and unambiguous manner. In the context described in the BRS, the StRS describes how the organization will utilize the system as a means to contribute to the business.

   2. Key Content: Typical types of stakeholder requirements included in the StRS are organizational requirements, business requirements and user requirements. There is no one optimal organization for all projects.

   3. Created By: should be specified by the stakeholders. The stakeholders should be responsible for the content of the specification. Could be made by a business analyst or requirements engineer.

   4. Target Audience:

      1. Stakeholders to review and achieve consensus

      2. software / systems engineers to create the SyRS and / or SRS

3. System Requirements Specification (SyRS) (29148-2018 Section 8.4, SWEBOK 5.2) / System Operational Concept (OpsCon) (29148-2018 Annex A) (sometimes combined with SRS)

   1. Purpose: identifies the technical requirements for the selected system-of-interest and usability for the envisaged human-system interaction. It defines the high-level system requirements from the domain perspective, along with background information about the overall objectives for the system, its target environment and a statement of the constraints, assumptions and non-functional requirements. Provide a description of what the system should do, in terms of the system's interactions or interfaces with its external environment. A description of what the system's acquirers expect it to do for them, the system's expected environment, the system's usage profile, performance parameters, expected quality and effectiveness and verification activities

   2. Key Content: It may include conceptual models designed to illustrate the system context, usage scenarios, the principal domain entities, data, information and workflows. Completely describe all inputs, outputs and required relationships between inputs and outputs. Can be a paper document, models, prototypes, other non-paper document representations or any combination.

   3. Created By: a systems engineer or software engineer

   4. Target Audience:

      1. the technical community who will specify and build the system. Needs to be understandable by both the acquirer and the technical community.

4. Software Requirements Specification (SRS) (29148-2018 Section 8.5, SWEBOK 5.3)

   1. Purpose: a specification for a particular software product, program, or set of programs that performs certain functions in a specific environment.

   2. Key Content: all of the required capabilities of the specified software product to which it applies, as well as documenting the conditions and constraints under which the software has to perform, and the intended verification approaches for the requirements

   3. Created By: usually a software engineer but could be a technical writer, a systems architect, or a software programmer; one or more representatives of the supplier, one or more representatives of the acquirer, or by both.

   4. Target Audience:

      1. stakeholders to review and validate

      2. the development team and team managers as a basis for coding

      3. quality assurance / testers as a basis for designing tests

      4. operations

      5. maintenance

      6. project consultants

From SWEBOK

Software requirements specification establishes the basis for agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do as well as what it is not expected to do.

Software requirements specification permits a rigorous assessment of requirements before design can begin and reduces later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules.

Organizations can also use a software requirements specification document as the basis for developing effective verification and validation plans.

Software requirements specification provides an informed basis for transferring a software product to new users or software platforms. Finally, it can provide a basis for software enhancement.

From Software Requirements 3rd Edition, Wiegers & Beatty

• • Customers, the marketing department, and sales staff need to know what product they can expect to be delivered.

  • Project managers base their estimates of schedule, effort, and resources on the requirements.

  • Software development teams need to know what to build.

  • Testers use it to develop requirements-based tests, test plans, and test procedures.

  • Maintenance and support staff use it to understand what each part of the product is supposed to do.

  • Documentation writers base user manuals and help screens on the SRS and the user interface design.

  • Training personnel use the SRS and user documentation to develop educational materials.

  • Legal staff ensures that the requirements comply with applicable laws and regulations.

  • Subcontractors base their work on—and can be legally held to—the specified requirements.

What is the Difference Between SRS, FRS and BRS?