On the Requirements engineering Barcamp 2016 In Cologne, I held a session on precisely this topic. On the one hand, the requirements, on the other, the architecture. These two aspects are often covered by different tools. In many sessions and discussions at the Barcamp, there was consensus that both requirements and models have their place. But how can one deal with requirements being processed with one tool and models being processed with another? In this article, I briefly summarize the results and content of the session.
Why Connect?
First of all, the question arose: Why should requirements and architecture be connected at all? That is a perfectly legitimate question. The architecture describes the solution, while the requirement describes the problem. It is useful to establish a connection between the requirement and the solution in order to easily break down the requirements into subsystems and components. This results in the added value of knowing not only what the system does, but also which components contribute to it and how the system functions. This makes it possible to determine which requirements are implemented by which components (allocation). If there is a change in the requirements or the technical solution, it is possible to determine what the change affects. This traceability is a powerful and very practical tool. Another aspect is that there is a strong interaction between requirements and architecture. Requirements lead to an architecture, and conversely, new requirements arise from the architecture. If you want to know more about this, you can also read the article Requirements vs. Architecture – the zigzag pattern look at.
|
|
| 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. |
|
Solutions
In the session, we discussed five approaches to solving the problem, which I would like to briefly describe here. The order in which they are presented does not represent a ranking.
1) Architecture and requirements deliberately separated
It's perfectly legitimate to accept this separation. There's the world where we deal with requirements and tests, and there's architecture. These are expressed in separate documents and exist side by side. There's no real connection, and this is consciously accepted.
2) Integrate requirements into model
Requirements are part of SysML and can therefore be included in the models. This makes it possible to process requirements and architecture in one tool. Here I can find the article Requirements Engineering with Enterprise Architect recommend.
3) Manual procedure
It's not uncommon to use "images" from models for requirements documents. In this case, the model is used as a source for views that are then used in the requirements tool. This approach is also not objectionable. Anything that helps to better describe the system is acceptable :-).
4) External traceability
Traceability is achieved using external tools or mapping tables. I consider this solution problematic and not really suitable.
5) Synchronization tools
The tools have standardized interfaces ReqIF (Requirements Interchange Format), through which data can be imported and synchronized. This makes it possible to edit requirements and architectural elements in both tools. There are numerous tool manufacturers that offer adapters for synchronization. As examples, I would like to mention the ReqXChanger from Willert and the LieberLieber Connector. There are many others as well.
What else was important?
The session covered some fascinating topics, and the 45 minutes flew by. I'd like to highlight the following three aspects in particular:
- There are no tools that work out-of-the-box. Complex tools for requirements management or modeling must be configured and adapted (and validated) to your specific needs and processes. This involves effort, but it's worth it. After all, these are the tools you use every day, and efficient work is only possible if the tools work.
- Requirements and architecture are not set in stone and change. Experience shows that 2-5% of requirements change per month! That's a significant number, and it also makes it clear that tools are absolutely essential for these continuous changes.
- "Caregivers" are needed. A caregiver is someone who translates and facilitates communication within a project. It's pointless to have the best requirements or system models if they aren't communicated and explained. Many people don't have the time to read hundred-page specifications, and many don't understand models without explanation. Therefore, it's important that this information is prepared and presented. A systems engineer, a technical project manager, or simply a caregiver is needed here.
I really enjoyed the Barcamp and the session, and I can only encourage everyone to participate in such events. The amount of knowledge and experience you can gain from a Barcamp is incredible.
I would like to conclude today with a quote about Barcamps that I really like.
- When you come, Be willing to share with other BarCampers.
- If you go, be ready to share with the world.
Source: http://barcamp-siegen.de/die-barcamp-regelen/
Best regards
Goran Madzar