SYS.3 – System Architectural Design

---

Hello there,
thank you for joining in for another round with me. This post will cover the A-SPICE SYS.3 – System Architectural Design process. In our last episode we took a closer look on the SYS.2 – System Requirements Analysis process. So if you missed this one, go check it out.

Lets get started

ID: SYS.3
Process name: System Architectural Design
Process purpose: Defining a System Architectural Design against your System Requirements and connecting them within the system elements. Also checking your design against a set of identified criteria shall be covered.
Process outcomes: You´re successful if:

• a System Architectural Design is identified that also tracks all elements of the system.
• the System Requirements are assigned to the elements of the system.
• the interfaces of each system element are determined.
• the dynamic behavior of the system elements is determined.
• consistency and bidirectional traceability are set between System Requirements and System Architectural Design.
• the System Architectural Design is accepted an communicated to all relevant parties.

Base practices:

SYS.3-BP.1 Develop System Architectural Design
In the first step we need to develop and document a System Architectural Design which specifies all elements of your system. This will be done by considering all relevant Functional and NonFunctional System Requirements.

As outcome we only have one Work Product

• 04-06 System Architectural Design

SYS.3-BP.2 Allocate System Requirements
Now we need to allocate our System Requirements to the Elements of our System Architectural Design.

As in BP.1 our only Outcome here is:

• 04-06 System Architectural Design

SYS.3-BP.3 Define Interfaces of System Elements

Now that we have identified the relevant requirements for our elements, we need to identify, develop and define interface in between of the elements.

Those results will be captured within:

• 04-06 System Architectural Design
• 17-08 Interface Requirements Specification

SYS.3-BP.4 Describe Dynamic Behavior

Within this BP our next task is to document and evaluate the dynamic behavior of the interaction between the system elements. Dynamic behavior can be ascertained by operation modes like:

• Start-up
• Shutdown
• Normal mode
• calibration
• diagnosis
• etc.

Those results are being stored and documented within:

• 04-06 System Architectural Design

SYS.3-BP.5 Evaluate Alternative System Architectures

First of we need to determine some evaluation criteria for our architecture. Those will be used to evaluate alternative system architectures according to the defined criteria. The explanation for the chosen system architecture shall be recorded. How are evaluation criteria defined? They may consist of quality characteristics like:

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

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

In the end the new information will be stored within

• 04-06 System Architectural Design

SYS.3-BP.6 Establish Bidirectional Traceability

As in different processes similar we need to establish traceability between the information entities we have created throughout this process.

As you see its pretty similar to the allocation of the system requirements to the system elements. So if your work environment supports you in terms of linking this could be done in one step.
In this case we will need:

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

SYS.3-BP.7 Ensure Consistency

As for the traceability the same applies to ensuring the consistency between our system requirements and system elements.

The consistency shall be checked for following WP´s:

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

SYS.3.BP.8 Communicate agreed System Architectural Design

In the end we need to make sure that every relevant stakeholder/party gets the updates about the agreed system architectural design and its updates.

In the end we need to store our communication evidence within:

• 13-04 Communication Result

One process more completed

Now lets try to get everything together:

That´s the scope for SYS.3 that we need to cover in order to fulfill this process A-SPICE compliant.

Thank You

for reading this post. I hope that it made the SYS.3 process a little bit clearer for you. If you have some questions, use the comment section. I´ll answer it ASAP. Because its close to Christmas, have yourself a Merry little Christmas.
Your NotDenis.

NEXT UP

• Deep Dive SWE.1 Software Requirements Analysis