As a result of successful implementation of this process:

1. the software requirements to be allocated to the software elements of the system and their interfaces are defined;

2. software requirements are categorized and analyzed for correctness and verifiability;

3. the impact of software requirements on the operating environment is analyzed;

4. prioritization for implementing the software requirements is defined;

5. the software requirements are updated as needed;

6. consistency and bidirectional traceability are established between system requirements and software requirements; and consistency and bidirectional traceability are established between system architectural design and software requirements;

7. the software requirements are evaluated for cost, schedule and technical impact; and

8. the software requirements are agreed and communicated to all affected parties.

SWE.1.BP1: Specify software requirements. Use the system requirements and the system architecture and changes to system requirements and architecture to identify the required functions and capabilities of the software. Specify functional and non-functional software requirements in a software requirements specification. [Outcome 1, 5, 7]

NOTE 1: Application parameter influencing functions and capabilities are part of the system requirements.

NOTE 2: In case of software development only, the system requirements and the system architecture refer to a given operating environment (see also note 5). In that case, stakeholder requirements should be used as the basis for identifying the required functions and capabilities of the software as well as for identifying application parameters influencing software functions and capabilities.

SWE.1.BP2: Structure software requirements. Structure the software requirements in the software requirements specification by e.g.

• grouping to project relevant clusters,

• sorting in a logical order for the project,

• categorizing based on relevant criteria for the project,

• prioritizing according to stakeholder needs.

[Outcome 2, 4]

NOTE 3: Prioritizing typically includes the assignment of software content to planned releases. Refer to SPL.2.BP1.

SWE.1.BP3: Analyze software requirements. Analyze the specified software requirements including their interdependencies to ensure correctness, technical feasibility and verifiability, and to support risk identification. Analyze the impact on cost, schedule and the technical impact. [Outcome 2, 7]

NOTE 4: The analysis of impact on cost and schedule supports the adjustment of project estimates. Refer to MAN.3.BP5.

SWE.1.BP4: Analyze the impact on the operating environment. Analyze the impact that the software requirements will have on interfaces of system elements and the operating environment. [Outcome 3, 7]

NOTE 5: The operating environment is defined as the system in which the software executes (e.g. hardware, operating system, etc.).

SWE.1.BP5: Develop verification criteria. Develop the verification criteria for each software requirement that define the qualitative and quantitative measures for the verification of a requirement. [Outcome 2, 7]

NOTE 6: Verification criteria demonstrate that a requirement can be verified within agreed constraints and is typically used as the input for the development of the software test cases or other verification measures that should demonstrate compliance with the software requirements.

NOTE 7: Verification which cannot be covered by testing is covered by SUP.2.

SWE.1.BP6: Establish bidirectional traceability. Establish bidirectional traceability between system requirements and software requirements. Establish bidirectional traceability between the system architecture and software requirements. [Outcome 6]

NOTE 8: Redundancy should be avoided by establishing a combination of these approaches that covers the project and the organizational needs

NOTE 9: Bidirectional traceability supports coverage, consistency and impact analysis.

SWE.1.BP7: Ensure consistency. Ensure consistency between system requirements and software requirements. Ensure consistency between the system architecture and software requirements. [Outcome 6]

NOTE 10: Consistency is supported by bidirectional traceability and can be demonstrated by review records.

NOTE 11: In case of software development only, the system requirements and system architecture refer to a given operating environment (see also note 2). In that case, consistency and bidirectional traceability have to be ensured between stakeholder requirements and software requirements.

SWE.1.BP8: Communicate agreed software requirements. Communicate the agreed software requirements and updates to software requirements to all relevant parties. [Outcome 8]

13-04 Communication record [Outcome 8]

13-19 Review record [Outcome 6]

13-21 Change control [Outcome 5, 7]

13-22 Traceability record [Outcome 1, 6]

15-01 Analysis report [Outcome 2, 3, 4, 7]

17-08 Interface requirements specification [Outcome 1]