Do’s and Avoids in Capturing Requirements¶
When customers talk, they rarely give you ready-made requirements. They tell you wishes, frustrations, or vague ideas. Your job is to turn intentions into clear, actionable requirements. Think of it like building a house: if all you hear is “make it nice and cozy”, the builder won’t know what materials, size, or budget to use.
Do’s¶
Do clarify needs, not just wants
Always ask “Why?” until you uncover the real problem. “We need a mobile app” might actually mean “Our staff need access while traveling”.
Do capture multiple sources
Users are important, but not enough. Managers, regulations, old systems, even competitors’ tools can reveal hidden requirements.
Do make it explicit
Turn fuzzy words into numbers or conditions:
- “Fast login” → “Login must take under 2 seconds for 95% of users.”
- “Secure” → “Passwords must be encrypted and follow company policy.”
Do mix techniques
Use interviews, observation, workshops, and prototypes. Each shows a different angle. Relying on only one method is like looking at a room through a keyhole.
Do keep levels separate
Write business goals (why), stakeholder needs (what), and system details (how) in different places. Otherwise, you’ll drown in contradictions.
Do validate early
Show your notes back to the customer: “Did I capture this correctly?” Small corrections now prevent big disasters later.
Do manage conflicts
If two stakeholders disagree, don’t decide alone. Document the conflict and guide them to resolution.
Do build shared language
Create a glossary of important terms. Make sure everyone uses the same words with the same meaning.
Avoids¶
Avoid jumping straight into solutions
Don’t design screens or databases before the problem is understood. First ask: “What problem are we solving?”
Avoid vague terms
Words like “user-friendly”, “fast”, “flexible” sound good but mean nothing unless defined.
Avoid assuming stakeholders know what they need
They often describe symptoms, not causes. A request for “more reports” may mean “we don’t trust the current data.”
Avoid focusing only on end-users
Customers and operators are obvious, but don’t forget maintainers, regulators, and even marketing. Missing them leads to nasty surprises.
Avoid mixing abstraction levels
Don’t put “grow sales by 10%” next to “button must be blue” in the same list. It confuses everyone.
Avoid one-shot elicitation
Requirements change. Expect to revisit and refine them — that’s normal, not a failure.
Avoid template-filling without thinking
A form is useful, but don’t just tick boxes. Always check whether the content makes sense.
Avoid ignoring traceability
Every requirement should have a source: a person, document, or law. If you can’t point to the origin, the requirement is suspicious.