Whenever I start a blog post about development, I start with the topic of the specifications. The specifications are the foundation of every development. The specifications impact the architecture, the technical implementation, the project costs, the schedule, the manufacturing costs, the scope of delivery, and, last but not least, customer satisfaction and market success. It is therefore one of the most important documents in a project. That's precisely why it's crucial that the foundation is solid. Otherwise, the project will be doomed from the start.
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? It refers to 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 a specification document 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 your 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 so that it can be understood without context. It's bad, 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 requirement short and concise. Don't try to cram 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.
- Never forget the intended purpose of the device in medical technology.
- Use a glossary with clear and defined terms.
- Conduct workshops with the customer or stakeholders, don't play a game of ping-pong.
- Less is more. Critically examine every feature.
- Keep the customer benefit in focus. Customer benefit is the reason the product is purchased.
- Don't put off making decisions. Unmade decisions can result in 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.
I've often heard in projects: "Our customer/our product manager doesn't know what they want!" I've since discovered that this is not 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 combat this is to keep projects short, reduce effort and complexity, and set up 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. I'll come back to this in a subsequent blog post.
One last important tip: Conduct reviews and examine the specifications in terms of form, content, and cost-effectiveness. Involve your key stakeholders. It can also be useful to review small sections. This leads to quick results.
Mistakes made in the specifications document will be a daily occurrence in the project. Therefore, pay attention to them when creating them so that the specifications document doesn't become your daily madness.
I welcome feedback and would love for you to contact me. Feel free to leave a comment on the article. If you know someone who might also be interested in the blog, I'd be very happy if you would recommend it.
Best regards
Goran Madzar