As a result of successful implementation of this process:

1. a software architectural design is defined that identifies the elements of the software;

2. the software requirements are allocated to the elements of the software;

3. the interfaces of each software element are defined;

4. the dynamic behavior and resource consumption objectives of the software elements are defined;

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

6. the software architectural design is agreed and communicated to all affected parties.

SWE.2.BP1: Develop software architectural design. Develop and document the software architectural design that specifies the elements of the software with respect to functional and non-functional software requirements. [Outcome 1]

NOTE 1: The software is decomposed into elements across appropriate hierarchical levels down to the software components (the lowest level elements of the software architectural design) that are described in the detailed design.

SWE.2.BP2: Allocate software requirements. Allocate the software requirements to the elements of the software architectural design. [Outcome 2]

SWE.2.BP3: Define interfaces of software elements. Identify, develop and document the interfaces of each software element. [Outcome 3]

SWE.2.BP4: Describe dynamic behavior. Evaluate and document the timing and dynamic interaction of software elements to meet the required dynamic behavior of the system. [Outcome 4]

NOTE 2: Dynamic behavior is determined by operating modes (e.g. start-up, shutdown, normal mode, calibration, diagnosis, etc.), processes and process intercommunication, tasks, threads, time slices, interrupts, etc.

NOTE 3: During evaluation of the dynamic behavior the target platform and potential loads on the target should be considered.

SWE.2.BP5: Define resource consumption objectives. Determine and document the resource consumption objectives for all relevant elements of the software architectural design on the appropriate hierarchical level. [Outcome 4]

NOTE 4: Resource consumption is typically determined for resources like Memory (ROM, RAM, external / internal EEPROM or Data Flash), CPU load, etc.

SWE.2.BP6: Evaluate alternative software architectures. Define evaluation criteria for the architecture. Evaluate alternative software architectures according to the defined criteria. Record the rationale for the chosen software architecture. [Outcome 1, 2, 3, 4, 5]

NOTE 5: Evaluation criteria may include quality characteristics (modularity, maintainability, expandability, scalability, reliability, security realization and usability) and results of make-buy-reuse analysis.

SWE.2.BP7: Establish bidirectional traceability. Establish bidirectional traceability between software requirements and elements of the software architectural design. [Outcome 5]

NOTE 6: Bidirectional traceability covers allocation of software requirements to the elements of the software architectural design.

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

SWE.2.BP8: Ensure consistency. Ensure consistency between software requirements and the software architectural design. [Outcome 1, 2, 5, 6]

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

04-04 Software architectural design [Outcome 1, 2, 3, 4, 5]

13-04 Communication record [Outcome 6]

13-19 Review record [Outcome 5]

13-22 Traceability record [Outcome 5]

17-08 Interface requirement specification [Outcome 3]