How do you identify the real user requirements (customer requirements)? Simple: you ask the users what their requirements are. Wrong! That won’t tell you what the user requirements are, just the user requests! This confusion can spell disaster for your project!
1. Consequences of mistaking user requests for user requirements
Like many others, I understood the importance of identifying and implementing user requirements. Therefore, I asked my users about their requirements repeatedly.
These requirements changed over time. New requirements were added, while others became less important. My team and I iterated after them. The result was a cost of EUR 100,000 (actually, it was more).
Please don’t make the same mistakes I did. Save yourself unnecessary iterations! Avoid delayed development projects that run over budget!
Don’t confuse user requests and user requirements!
2. User Requests
A user request is nothing more than a wish, which the client naturally claims to need. User requests are usually formulated as a solution sketch, i.e., a black box description of the system. For example, “Can you make the table so that I can sort it by clicking on the column headers” (e.g., by treatment date) or “Can you add/move button XY?” This means that user requests can be classified at the level of system requirements/specifications.
3. User Requirements
These user requests often conceal implicit user requirements. User requirements are stakeholder requirements and are defined as “activities necessary for an interactive system in a way that describes the activity, not in a technically implemented way.”
A user requirement could be (in line with the above user request): “The user must be able to identify the patients who were last treated on the system.” The only verbs available are “enter,” “select,” or cognitive actions such as “recognize,” as in this case.
4. From user request to user requirement
User requirements should be derived systematically. There are procedures for this. Directly asking users what they want is not effective, as Henry Ford already knew:
“If I had asked my customers what they wanted, they would have said ‘faster horses’
Or, as Steve Jobs put it: It’s not the user’s job to know what they want. That sounds arrogant, but it’s true. It is the task of product management to derive user requirements from a context. User wishes are usually the starting point for identifying the real requirements.
Anyone who doesn’t understand this will also fail to understand why 45% of implemented functionalities are not needed at all. In this case, requests were confused with requirements—an expensive mistake.
If you want to know how to determine usage and system requirements, come to the seminar on usability, requirements, and IEC 62366 in Konstanz.
5. Risks of confusing user requests and user requirements
Many people use the terms request and requirement interchangeably. I regularly hear people in companies say that a “user requirement” has to be met. But when I look at what it is, it’s not a user requirement at all, but simply a user request or a user wish. And not a requirement. This can have unpleasant consequences:
- Project delays and cost overruns: If you don’t identify the actual user requirements but implement the user requests directly, your users will constantly come to you with new “requirements.” You will be continually making improvements, which will drive up costs enormously. It may even come to the point where you have to cancel the project because new requests can no longer be implemented with the original architecture or technology.
- Problems with approval and audits: ISO 13485 and FDA make a clear distinction between system specifications and stakeholder requirements. You must be able to trace the connection between the two. However, if you believe that user requests are user requirements, this tracing becomes a circular reference, which is absurd and therefore a potential problem.
