SWE.2 – Software Architectural Design

---

Hi there,
hope you´re doing well. I would like to continue today with our A-SPICE series. Todays scope will focus on the SWE.2 – Software Architectural Design process. Previously we had a closer look onto SWE.1 – Software Requirements Analysis, which provides us the relevant information for this process. Let´s go!!

Lets get started

ID: SWE.2
Process name: Software Architectural Design
Process purpose: Defining a Software Architectural Design to allocate relevant software requirements and its software elements. The design shall be also checked against defined criteria.
Process outcomes: You´ve managed to:

• define a software architectural design that determines the relevant software elements.
• allocate the software requirements to the elements of the software.
• define all interfaces for each software element.
• define the dynamic behavior and resource consumption objectives of the software elements.
• establish consistency and bidirectional traceability
• agree on the software architectural design an communicate it to all relevant parties.

Base practices:

SWE.2-BP.1 Develop software architectural design
First of all we need to develop and document the software architectural design, which define the software elements based on functional and non-functional software requirements.

The defined process outcome is:

• 04-04 Software Architectural Design

SWE.2-BP.2 Allocate software requirements
Next the software requirements are being allocated to the software elements within software architectural design.

Again we need to provide a updated:

• 04-04 Software Architectural Design

SWE.2-BP.3 Define interface of software elements
Now that the elements are defined but maybe not really connected, we need to identify, develop and define interfaces in between them.

Results of this process need to be stored in:

• 04-04 Software Architectural Design
• 17-08 Interface Requirements Specification

SWE.2-BP4 Describe dynamic behavior
Our Task now, is to document and evaluate the dynamic behavior of the interaction between the system elements. Dynamic behavior can be ascertained by operation modes like:

• listen()
• write()
• syncIT()
• log()
• start-up
• shutdown
• diag mode

Results need to be documented within:

• 04-04 Software Architectural Design

SWE.2-BP5 Define resource consumption objectives
In this step we want to identify and document the resource consumption objectives for all required elements of the software architectural design on the right hierarchical level. Examples could be:

• CPU load
• Memory (RAM, ROM, external/internal
• Architecture x86

The objectives can be found within:

• 04-04 Software Architectural Design

SWE.2-BP6 Evaluate alternative software architectures
Similar as in SYS.3-BP.5 we need to determine evaluation criteria for our architecture. Those will be used to evaluate alternative software architectures according to the defined criteria. The result of the chosen software architecture shall be recorded. How do I define such evaluation criteria? They can include quality characteristics like:

• Modularity
• Maintainability
• Expandability
• Scalability
• Reliability
• Security realization
• Usability

The results of make-buy-reuse analysis can influence such a decision.

The results of this process need to be provided within:

• 04-04 Software Architectural Design
• 17-08 Interface Requirements Specification
• 13-19 Review Record
• 13-22 Traceability Record

SWE.2-BP7 Establish bidirectional traceability
To fulfill this process it is very important to provide traceability between the software requirements and the elements of the software architectural design.

Results can be found in:

• 13-22 Traceability Record
• 13-19 Review Record

SWE.2-BP8 Ensure consistency
As for the traceability the same applies to ensuring the consistency between our system requirements and system elements.

To fulfill consistency we need to provide:

• 13-22 Traceability Record
• 13-19 Review Record
• 13-04 Communication Record
• 04-04 Software Architectural Design

SWE.2-BP9 Communicate agreed software architectural design
Finally we need to ensure that every relevant stakeholder gets the updates about the agreed software architectural design and its updates.

The results need to be stored within:

• 13-04 Communication Record

Finish 🙂

Let´s take a look into everything

Thank You

for your time today. I hope I was able to give you a small overview onto the SWE.2- Software Architectural Design process.

Next Up

• SWE.3 Software Detailed Design and Unit Construction