Diagnosing Requirements Problems
In short When a project shows trouble (unhappy customers, late surprises, constant change), work backward from the symptom to its likely cause in the requirements process, then choose a remedy that treats the cause. Wiegers organizes this reverse search into ten problem areas.
Based on: K. Wiegers, Software Requirements, 2nd ed. (Microsoft Press, 2003), appendix C (requirements troubleshooting guide).
On this page
Key ideas#
Symptoms are not causes#
A symptom is what you observe; a root cause is why it happens. Treating symptoms one at a time (an extra meeting here, a stricter template there) rarely sticks. Wiegers’ troubleshooting guide, an appendix in the second edition of his book that does not appear in the third, maps common symptoms to typical causes and possible remedies, grouped by area of requirements work.
Ten problem areas#
The table below condenses the idea into one line per area.
| Area | Typical symptoms | Common causes | Remedies to consider |
|---|---|---|---|
| Process | Each project uses different templates; tools barely used; analysts unsure of their role | No shared process, no management interest, no training | Document the current and target process; train; adopt a standard; appoint a tool champion |
| Product | Unhappy customers; product rejected at first sight; weak sales | Little user involvement; unrealistic expectations; guesswork | Focus groups; user classes and product champions; prototypes; align expectations with business objectives |
| Planning | Building starts on vague requirements; deadlines cut without cutting scope | Release date fixed before requirements are understood; scope uncontrolled | Document vision and scope before committing to dates |
| Communication | Duplicated work; decisions reopened; people use different terms | Unclear roles; no decision maker; no glossary | Define roles and who decides; keep a glossary |
| Elicitation | Wrong or absent customer representatives; solutions presented as needs | Customers lack time; user classes not identified | Identify user classes and champions; ask “why?” to find the need behind a requested solution |
| Analysis | Gold-plating (unrequested extras); untestable requirements; everything “top priority”; conflicts | No control over what gets approved; value and cost unknown; no one owns decisions | Record each requirement’s source and rationale; agree a prioritization process early; assign an owner to every open issue |
| Specification | Requirements passed on by word of mouth; documents out of date; conflicting versions | Belief that writing slows things down; poor version control | Define a requirements process; route changes through a change board that updates documents; use a requirements tool |
| Validation | Product misses business objectives; hidden requirements; no performance targets | Quality attributes never discussed | Teach analysts and customers about quality attributes; elicit them early with a template |
| Requirements management | Some planned requirements never get built | Specification not updated or not shared | Keep the specification current and accessible; trace requirements |
| Change management | Late, frequent changes; growing scope; requests lost or sent straight to developers; changes cost more than expected | Incomplete elicitation; vague scope; impractical or ignored change process; no impact analysis | A practical change process with a board and mandatory impact analysis; an owner for each requirement; schedule contingency |
How to apply it#
- Write the symptom in neutral, observable terms (“eight of last month’s 20 change requests went straight to developers”), not as blame.
- Find the matching area in the table. Several areas may apply.
- Ask “why?” repeatedly until you reach a cause you can act on. Use the table’s causes as hypotheses and confirm them with evidence from your project.
- Choose one or two remedies that address the cause, not the symptom.
- Decide how you will know the remedy worked, and when you will check.
- Feed recurring causes into a wider process improvement plan.
Example#
At The Workshop, a fictional bike-repair chain, workshop managers complain that the new booking app “keeps changing”, and the outside developers say requests arrive from three directions. The symptoms are late changes, requests bypassing any process, and screens reworked twice. They point to the change management and communication areas. Asking “why?” shows that managers message developers directly because nobody told them who decides on requirements, and there is no change log. The remedies: name the owner as the decision maker, set up a two-person change board (owner and business analyst, or BA) with a shared log, and ask developers to route every request there. One month later, the BA counts how many requests still bypass the log.
Pitfalls#
- Treating the table as a diagnosis → it lists likely causes; confirm them on your project.
- Fixing every area at once → start with the cause behind the most painful symptom.
- Blaming individuals → most causes are missing roles, processes or skills.
- Stopping at the first “why?” → the first answer is often another symptom.
Sources and further reading#
- K. Wiegers. Software Requirements, 2nd ed. Microsoft Press, 2003, appendix C (requirements troubleshooting guide).