3.  The ASPICE-Processes (VDA Scope)

3.3 SWE.1 – Software Requirements Analysis

What is the purpose?

The software requirements are derived based upon the system requirements and the system architecture. They are analyzed, categorized, and documented in a software requirements specification.

What is the benefit?

The software requirements for the software related elements and their interfaces of the system architecture are fully analyzed and documented. These provide the basis for the actual software development.

What is the content?

  • Functional and non-functional requirements for the software are determined, taking into account the system requirements and the system architecture. (BP1)
  • All software requirements are examined for technical feasibility, testability, risks, effects on the operating environment and interdependencies. They are structured in a logical order according to the needs of the project. (BP2,BP3, BP4)
  • Verification criteria are developed for each requirement which give
    hints how requirement should be verified. (BP5)
  • The requirements are prioritized, structured, and assigned to releases.
    (BP2)
  • Consistent bidirectional traceability is established between software
    requirements and system requirements and architecture. (BP6, BP7)
  • Software requirements and their updates are agreed upon and communicated to all stakeholders. (BP8)
Sources for the determination of software requirements
Sources for the determination of software requirements

Experiences, problems and hints

  • In many cases, customer requirements are so detailed that they can be used as they are or with little modifications as software requirements. However, an analysis has to be performed to determine if there is any system impact. Also full coverage of and traceability to the customer requirements need to be demonstrated.
  • In the case of a software only product the customer requirements are linked directly to the software requirements, as there is no need for System Requirements in this case.
  • Regarding traceability between software requirements and system requirements and between software requirements and system architecture: redundancy is not required. The project can decide whether they implement it one way or the other.
  • If the project is based on a platform, the software requirements of the platform can be carried over. However, these platform requirements should be carefully analyzed to insure they are fully relevant and accurate for the new project requirements.
  • Traceability is not enough by itself, consistency has to be demonstrated. Consistency checks (through reviews) have to assure that software requirements are correct interpretations of system requirements and that traceability and links are correct and complete.
  • In some systems, functions may involve two or more disciplines, e.g. hardware and software. It must be clear which portion of the function is covered by the software requirements.
  • In software-heavy systems, the requirements on system and software
    level may be overlapping, but they should never be the same.

Automotive SPICE text of Software Requirements Analysis (SWE.1)

The purpose of the Software Requirements Analysis Process is to transform the software related parts of the system requirements into a set of software requirements.

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.

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.

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.

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

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.

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

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.

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

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.

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.

BP6: Establish bidirectional traceability. Establish bidirectional traceability between system requirements and software requirements. Establish bidirectional traceability between the system architecture and software requirements.

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.

BP7: Ensure consistency. Ensure consistency between system requirements and software requirements. Ensure consistency between the system architecture and software requirements.

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.

BP8: Communicate agreed software requirements. Communicate the agreed software requirements and updates to software requirements to all relevant parties.

Output Work Products

System architectural design, Communication record, Review record, traceability record, Interface requirements specification

If you wish to continue to the next chapter click here: