Projects often fail due to requirements engineering, so I'd like to address this important topic. This raises the question of what exactly is meant by requirements engineering? In this blog post, I'd like to address the topic of requirements engineering.
Requirements engineering is the structured process by which requirements are identified, documented, managed, analyzed, agreed upon, and tested. This results in the requirements for a project and a product arising from needs, visions, and constraints.
IEEE 1990 helps with the question of what a requirement is:
- A property or condition required by a user (person or system) to solve a problem or achieve a goal.
- A property or condition that a system or system component must satisfy in order to comply with a contract, standard, specification, or other formally prescribed document.
This rather formal description can be figuratively compared to the DNA of the system. Careless handling of requirements can lead to significant damage.
|
|
| 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 effort involved in writing requirements documents isn't in the writing itself; otherwise, if you can type halfway decently, you'd be finished in a week at the most. The largest part of the work is communication. This involves getting various stakeholders on board and collecting and reconciling their often conflicting requirements. In my experience, this accounts for about two-thirds of the work. The stakeholders can include the product manager, customer, client, project manager, management, QM/RA, service, production, lawyers, and many more.
There are a few things to consider when writing requirements. I also call these the requirements for the requirements. By this, I mean the properties that a requirement should have.
| Characteristic | Explanation |
| Testable | Every requirement is tested. If you can't think of a meaningful test case, then the requirement isn't good. |
| Complete | Make sure you don't forget anything. A lot of information is stored in your head. Put it down on paper. This will also improve the depth of the test. |
| Relevant | Only formulate requirements that are relevant to the component or system. It doesn't matter which components you use or how the implementation actually looks. |
| Consistent | Avoid contradictions in requirements. Make sure the requirements fit together. |
| Clearly | Formulate the requirements clearly so that there is no room for interpretation. |
| Context-free | Formulate the requirement in such a way that it can be understood without context. It's not good, for example, if the requirement can only be understood if you know which chapter it's in. The requirement should be understandable on its own. |
| Atomic | Keep the requirements short and concise. Avoid trying to combine multiple requirements into one. This will make the requirements more understandable, readable, and easier to test. |
There are many mistakes that can be made when formulating requirements. Ideally, you should use templates, which significantly improve the quality of the requirements. This means you always structure the requirements according to the same pattern. While this can be tedious to create, it is a great benefit for comprehensibility and clarity.
From my experience in projects, I have compiled a list of 10 tips that are often overlooked or ignored.
- Every requirement has a price tag and costs money.
- Every request costs time.
- Use a glossary with clear and defined terms.
- Conduct workshops with the customer or stakeholders and do not play a game of ping-pong.
- Less is more. Critically examine every feature.
- Keep the customer benefit in mind. Customer benefit is the reason the product is purchased.
- Don't put off making decisions. Unmade decisions can lead to a lot of unnecessary energy being invested.
- Define the priority of a requirement, what must be implemented and what is optional.
- Avoid implicit assumptions. The specifications should be understandable even if you have no prior knowledge.
- Use a tool to manage requirements.
I've often heard in projects: "Our customer/our product manager doesn't know what they want!" I've since discovered that this isn't the exception, but the rule. We develop innovative products where not everything is known. Moreover, the world is changing, and with it the product requirements. Approximately 1-5% of requirements change every month! The only way to counteract this is to keep projects short, reduce effort and complexity, and implement change management early on. If you work with requirements, you need a tool for it. Please don't use Word and Excel for this! That no longer works for larger projects.
One last important tip: Conduct reviews and check the requirements documents for both form and content. Involve your key stakeholders. It can also be useful to review small sections. This leads to quick results.
I'm very happy to receive feedback and engage with you. Feel free to comment on the article. If you know someone who might also be interested in the blog, I'd also be very happy if you would recommend it.
Best regards
Goran Madzar