Finding Missing Requirements · Business Analysis Notes

Key ideas#

When to stop eliciting (for now)#

You will never reach total completeness, especially in agile work. Wiegers and Beatty list practical signals that it is time to move on:

Users cannot think of new use cases or stories.
New suggestions turn out to be variations of ones you already have.
Users repeat issues already discussed.
New ideas are out of scope or get low priority.
Users themselves propose leaving ideas for later.
Developers and testers ask fewer and fewer clarifying questions.

Assumed vs. implied requirements#

Assumed requirements are things people expect without saying them, because they seem obvious. What is obvious to the customer is not always obvious to the developer.
Implied requirements follow logically from a stated requirement but are never written down. If users can save a half-filled web form, they also need to reopen the draft. The book describes a portal where nobody specified navigation through the content hierarchy; the developers built a flat list paged 20 items at a time, and some content needed paging through more than 50 pages.

To surface both, ask “What are you assuming?”, use open, context-free questions (“What accuracy does the product need?”) instead of yes/no questions, re-interview, and bring in stakeholders who have not taken part yet. Fresh eyes find gaps that rereading does not.

Eight checks for missing requirements#

Decompose high-level requirements until they are simple. Vague high-level wording leaves room for the customer’s picture and the developer’s work to diverge.
Check user-class coverage. Each user requirement should benefit at least one user class, and every user class should have been heard.
Trace functional requirements to their origin: a user requirement, a system requirement or a business rule. This shows whether everything needed is actually described.
Check boundary values. One requirement for amounts under $100 and another for amounts over $100 leave exactly $100 undefined. Missing requirements often hide at the edges of ranges.
Represent the information another way. Text hides gaps; a diagram shows a missing arrow or transition at a glance.
Check complex logic. Combinations of AND, OR and NOT are almost always incomplete, and the “otherwise” branch is the one most often missing. Lay the logic out as a decision table or tree, which forces every combination to be listed.
Use a checklist of standard functional areas that are easy to forget: error logging, backup and restore, access security, reporting, printing, preview, user preferences.
Do a CRUD check against the data model. For each data entity, confirm there is a way to Create, Read, Update and Delete it where that makes sense. A missing operation on an important entity is a typical symptom of a missing requirement.

Walking through the quality attributes one by one works as another check; see Software Quality Attributes.

Two cautions#

Avoid analysis paralysis. The aim is an acceptable level of risk, not 100% completeness.
Balance the voices. Do not let the loudest customer dominate. Wiegers and Beatty suggest each product champion has a group of users from the same class behind them.

The authors also note that the line between “what” and “how” is blurry. Early design sketches and prototypes help elicitation, as long as you tell participants they illustrate an idea and are not the final design.

How to apply it#

After each elicitation round, review the stopping signals with the team.
Ask the assumption question at the end of every interview and workshop.
Build a CRUD matrix for your main data entities and look for empty cells.
Draw at least one model (process, data flow or state) for each major area and look for dangling flows.
Put every multi-condition rule in a decision table.
Walk the standard-areas checklist and the quality-attribute list once per release.
Invite one new stakeholder to a review specifically to look for what is missing.

Example#

The Workshop, a fictional bike-repair chain, builds a CRUD matrix for its booking and repair system:

Entity	Create	Read	Update	Delete
Booking	Customer, front desk	Customer, front desk, mechanic	—	Customer (cancel)
Repair job	Front desk	All staff, customer (status)	Mechanic	—
Parts order	System, workshop manager	Workshop manager	—	—
Customer	Customer, front desk	Front desk	Customer	—

The empty cells raise questions:

Booking / Update. Nobody can reschedule. Customers will call to move slots, which defeats the business objective. A new requirement: a customer can reschedule a booking.
Parts order / Update and Delete. What if the supplier sends the wrong part, or the job is cancelled? Requirements for amending and cancelling orders are added.
Customer / Delete. Can customers close their accounts, and what happens to their repair history? This goes to the owner as an open question.

A boundary check finds the $100 approval gap: repairs “under $100” are auto-approved and those “over $100” need customer approval. The standard-areas checklist adds printing a job ticket for the bike tag.

Checklist#

Stopping signals reviewed with the team.
“What are you assuming?” asked in every session.
Every user class has been heard and benefits from at least one requirement.
Every functional requirement traces to an origin.
Range boundaries checked for gaps and overlaps.
Multi-condition logic shown in decision tables, including “otherwise”.
CRUD matrix complete or gaps explained.
Standard functional areas checked.
At least one fresh reviewer looked for gaps.

Sources and further reading#

K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 7.