Let's be honest—who hasn't heard of nonfunctional requirements? Somehow, these requirements seem to play an important role in all books and lectures on requirements engineering. But what about reality? In most of the specifications I read, this category of requirements is completely absent. In this article, I want to champion the rare species of "nonfunctional requirements" and explain why they are so important.
What are non-functional requirements?
To answer this question, I would first like to explain the functional requirements. All systems have specific functions that they fulfill. The functions of a system are essential, because what is the use of a system that does not fulfill a function? If you look at a blood pressure monitor, for example, its function is to measure and display the systolic and diastolic blood pressure. The functional requirements therefore describe what a system does. Since engineers usually know what a system has to do, it is not surprising that the functional requirements are usually easy to define. The situation is more difficult with non-functional requirements. These are all requirements that do not belong to the group of functional requirements and therefore do not specify a function. To get to the bottom of these, I would like to give you a nice abbreviation that I have heard myself and have expanded upon for myself. The abbreviation is originally RAMST and stands for Reliability, Availability, Maintainability, Safety, and Testability. This acronym is already great. However, I would adapt it slightly and add two more aspects. Therefore, my mnemonic is DRAMSSTThe additional "D" stands for design and thus encompasses all requirements regarding appearance and emotional factors. This can include shape, color, feel, and even acoustics. I understand this to encompass all the requirements that make a product appear beautiful. The second "S" stands for security and refers to the increasingly important IT security of products.
|
|
| 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. |
|
Why are these requirements important?
In the headline, I referred to the non-functional requirements as the secret stars. Isn't that a bit exaggerated? I don't think so, and I want to explain why. What separates great products from mediocre ones? For example, I have a great blender in my kitchen. Functionally, the blender can't do any more than many other blenders, of which there are plenty. But I have a good feeling about my blender. The design is very attractive, and the appliance is so high quality that I can't imagine it ever failing. It's not just plain plastic, but high-quality workmanship. The appliance has been in operation for 5 years and hasn't caused any problems. The difference between great and mediocre products is usually the non-functional requirements!
The Kano model, shown in the illustration below, is well known in this regard. Here you can see that there are basic factors, performance factors and excitement factors. With basic factors it is assumed that these are present. For example, a blender has to be able to mix, otherwise the device is no good and I will be massively dissatisfied. Then there are the performance factors. The higher the speed, the better my milkshake and the happier the customer. And then there are the excitement factors. Is the blender reliable, is it high quality, does it look great? These factors excite the customer. And these are all non-functional! Over time, the excitement factors increasingly become performance factors and finally basic factors. The first iPhone, with its touchscreen and design, had a unique selling point and made the competition look outdated. Today there are manufacturers whose names I don't know whose products contain the former excitement factors.
So ask yourself whether you want to develop mediocre products or products that generate enthusiasm. The more you lean toward the latter, the more you should focus on nonfunctional requirements. They are the underrated stars of requirements engineering.
Speaking of requirements engineering: We're happy to support you in improving your requirements engineering. We're happy to conduct reviews or training sessions and provide you with advice and support.
Best regards
Goran Madzar