The use of model-based tools for requirements management is intended to make our lives easier and work more efficient. However, these tools are often used merely as a replacement for Word. The requirements are entered into the tool, and then a document is generated. The potential for reuse is rarely utilized. In my professional practice, I see that many companies find it difficult to reuse requirements across projects or products. In this article, I would like to offer some approaches to rethinking requirements management and thus achieve significant efficiency gains with improved quality.
Why do we keep rewriting requirements?
A new project is on the horizon. It starts with a specification or requirements document. Perhaps you print out an old document as a template, and then you get started. We create a project in our tool and start typing: "The system should..." The tool dutifully generates a unique ID for this requirement (REQ-0001).
This is how you write down all the requirements for the product. I'm deliberately simplifying things here and ignoring the methodologies for determining requirements. At this point, it's only about documenting and managing them. Many companies already have a number of products and, therefore, requirements. Why are you recreating the requirements now instead of reusing them like Lego bricks? Here's a list of possible reasons:
- The old products are not well documented and things should now be done correctly.
- The new product is completely different from the old one.
- I don't know the other documents; I wasn't responsible for them. I may not have access rights at all.
- I have no idea how to reuse requirements with my tool.
- I don't know where to look since there are some products with good examples and many with bad ones.
- Actually, I don't have time to deal with this sort of thing. I have to get it done—I'm the man myself.
The number of reasons should not be underestimated. Nevertheless, the effort is worthwhile.
Why rewriting over and over again is bad?
Constantly coming up with new requirements is like reinventing the wheel every time. This process isn't particularly stable. Perhaps you recently took a requirements engineering training course and are careful to formulate requirements appropriately. But it could also be that you're a bit out of practice and the quality of the requirements suffers considerably. But who can remember all the various requirements necessary for a product? What did production and service need again, and what were the non-functional requirements? Guided by the headings, you cobble something together. I think it's clear to everyone that the quality of this specification can't be nearly as good as one that has already matured across various products. But it's not just the requirements that need to be considered; the test cases too. Creating the test cases takes more time than documenting the requirements. If you were to adopt requirements, you could also reuse the test cases one-to-one. This would make work much easier and save time.
How should requirements management be implemented?
My recommendation is to create a database or a shared project with all requirements and test cases. The projects then use this source and extract the requirements from it.
There are "common requirements" whose content does not need to be changed. These include requirements whose content does not require any changes, e.g., labeling of application parts and nameplates, standards, connectors to be used (power socket, USB, etc.), maintainability requirements, etc.
Customize requirements are requirements that have one or more parameters and must be adjusted. For example, we can define the maximum weight of a system as < 15 kg. This value can vary from product to product, but also between device variants. This value therefore represents only one parameter of the requirements, which depend on the product, variant, and version. Other customize requirements can also be performance requirements. For example, a requirement could be defined regarding which amplitude settings can be displayed for an ECG monitor.
|
|
| 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 procedure now involves selecting the relevant common requirements for the product and importing them. The same is done for the "Customize Requirements," selecting the parameters accordingly. This should already complete a large part of the work. The larger the database, the more Lego bricks there are that can be reused and don't need to be rewritten. All others that aren't yet in the database are actually created in the project. If these requirements are candidates for reuse, they can be imported back into the database.
Tips
If you don't already have a solution to the problem described above and are planning to take your requirements management to the next level, then I have the following tips for you:
- Make sure that the quality of the requirements and test cases in the database is good, as you will be dumping them into the products.
- Define a database manager who will take care of the requirements.
- Make sure IDs are unique across all projects. This is the only way to ensure requirements can be reused.
- On your next project, start not only collecting project requirements, but also building your database at the same time.
I've deliberately left out the tools in this article. All the tools I've used so far support this approach. If you have any questions or need help, feel free to contact me.
Best regards
Goran Madzar