Bug Types

Misunderstood Requirements in the Project Design Phase

Your client knows what's wrong. They *think* they know how to fix it. But treating symptoms is never as effective as treating the disease.

Mike Wolfe

Aug 7, 2021 • 3 min read

This is part 3 of a 7-part series comparing different kinds of software bugs.

What are Misunderstood Requirements (pre-code)?

While not a bug in the traditional sense, misunderstood requirements nonetheless fit the description of a software bug. Here's the Wikipedia definition:

A software bug is an error, flaw or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

If you base your application on a flawed understanding of what is required of the system, you can bet that it will "produce an incorrect or unexpected result" for your users.

Causes of Misunderstood Requirements (pre-code)

One of the main causes of misunderstood requirements is building your clients exactly what they ask for.

Um, come again?

No, that was not a typo. Building your clients exactly what they ask for is likely to lead to scope creep and an unmanageable software project. Why is that? Because your clients are not software developers.

They don't know how to design software. That's your area of expertise.

The Why Conversation

So if you're not supposed to build exactly what they ask for, what are you supposed to do instead? The key is to move beyond what they ask for and get to the heart of why they are asking for it.

Jonathan Stark refers to this as the "Why Conversation." The analogy he uses is that of a doctor and patient. Patients present with symptoms. It's the doctor's job to uncover the underlying cause of the symptoms. After all, it's more effective to treat the disease than the symptoms.

I love this excerpt from his book, Learn Your Lines:

And if you eventually take on the project without the answer to this question, you’d be like a doctor performing heart surgery simply because the patient asked for it. (e.g., Patient: “Hey doc, I heard you do triple bypasses! Can I get me one of those?” Doctor: “Sure! Hop up on the table and I’ll grab my scalpel!”)

Consequences of Misunderstood Requirements (pre-code)

In this series' introductory article, I list "misunderstood requirements" twice:

Syntax errors
Compile errors
Misunderstood requirements (before you start writing code)
Automated test errors
Runtime errors
Misunderstood requirements (after you've written the code)
Logic errors

I do that to underscore the importance of understanding the project requirements early in the process. It's faster to design an application than to implement it. If you realize you've misunderstood the requirements during the design phase, then all you've lost is the time you spent designing.

This pales in comparison to realizing your mistake at the end of the project after you've written all the code, created all the forms, and produced all the reports.

Redoing all that work... Well, let's be honest; it's probably not going to happen. Instead, you will have produced a 3-out-of-5-stars application. Not bad enough to throw it out or start over. But bad enough that everyone involved will be disappointed in the end result: you, the end users, and, of course, the client.