{"id":7421,"date":"2025-11-28T05:12:36","date_gmt":"2025-11-28T04:12:36","guid":{"rendered":"https:\/\/web-dev-weissblau.de\/microconsult\/?p=7421"},"modified":"2026-02-14T16:17:47","modified_gmt":"2026-02-14T15:17:47","slug":"requirements-management-i-want-i-need","status":"publish","type":"post","link":"https:\/\/www.microconsult.de\/en\/anforderungsmanagement-ich-moechte-ich-will-ich-brauche\/","title":{"rendered":"Requirements management \u2013 I want, I need!"},"content":{"rendered":"

If only it weren't for the customers. Or the project manager. Or my own boss. Everyone finds something to criticize about my beautiful embedded solution. One function is difficult to use, another is missing entirely, the input field should have a blue background, the response time is too long, the memory fills up too quickly, and so on and so forth.<\/strong><\/p>\n

The more complex the module, the more extensive and complex the requirements and the well-intentioned suggestions for extensions and improvements. Especially with embedded systems, complexity is constantly increasing, and with it, the number of requirements.<\/p>\n

The following image illustrates the situation:<\/p>\n

\"\"<\/p>\n

Figure 1: Requirements management \u2013 a challenge with requirements<\/em><\/p>\n

 <\/p>\n

Limited resources no longer allow us to implement most, let alone all, of the requirements. Filtering requirements inevitably leads to frustration. Who would accept having their own requirement rejected while another colleague's or client's is accepted? Add to that the constant time pressure. Ignoring the problem and waiting it out isn't an option either. The problem won't solve itself \u2013 the project manager is calling, and so is the competition.<\/p>\n

The good news is: there is a suitable solution for this, and it is called\u00a0Requirements management<\/strong>. The principle is quite simple and is outlined in the next image:<\/p>\n

\"\"<\/p>\n

Figure 2: Principle of requirements management<\/em><\/p>\n

The task is to process the requirements and ultimately determine whether a requirement must be implemented, can be implemented, or should be discarded. From the "Yes" and "Maybe" containers, the remaining requirements are transferred to the requirements backlog, in the exact order required for implementation. This completes the essential task for a requirements manager.<\/p>\n

The advantages of good requirements management are compelling:<\/p>\n