How are requirements and architecture related? What is in the requirements and what is in the architecture? And how do architecture and requirements interact? In this article, I describe this relationship and introduce the SYSMOD ZIGZAG pattern.
What and how?
When it comes to system requirements, the primary question is always "What does the system do?" I'd like to illustrate this using a simple example of a blood pressure monitor. A requirement could be, for example, the following: The system should be able to measure and display systolic and diastolic blood pressure on the upper arm. The requirement clearly states what the system does. How it does this is irrelevant to this requirement. Testing against the requirement verifies whether blood pressure is measured and displayed. It does not verify whether the correct components have been installed.
The first step is to clarify how requirements and architecture differ. The requirements describe what the system does, and the architecture describes how it does it. The architecture results in new requirements for the system. In our example, blood pressure measurement is implemented using a cuff, a pump, two valves, and a pressure sensor.
|
|
| Dipl.-Ing. Goran Madzar, Partner, Senior Systems Engineer E-mail: madzar@medtech-ingenieur.de Phone: +49 9131 691 240 |
|
Do you need support with the development of your medical device? We're happy to help! MEDtech Ingenieur GmbH offers hardware development, software development, systems engineering, mechanical development, and consulting services from a single source. Contact us. |
|
The ZIGZAG Pattern
This relationship is represented by the SYSMOD ZIGZAG pattern. Let's look at the example of the blood pressure monitor.
The requirement to measure blood pressure leads to an architecture with a pneumatic unit. This architecture with a pneumatic unit creates new requirements for the system. In this example, the overpressure shutdown, which is implemented by three architectural elements. The logical steps in the ZIGZAG pattern are "Zig" from the requirement to the architecture, "Zag" from the architecture to the new requirement, and "Zig" back to the architecture. This pattern can also be applied in the V-model.
In the figure above, the ZIGZAG pattern is shown on the left side of the V-model. This pattern is absolutely useful and independent of any tool or modeling language. In my opinion, understanding this pattern helps to better design requirements and architecture and manage their interactions.
Today I would like to end my article with a quote that also fits well with system architects :-)
"I am not a cynic or a skeptic, but an optimist. That is the most important prerequisite for becoming an architect." (Daniel Libeskind)
Best regards
Goran Madzar