LEARN. PRACTICE. GROW.Concept and mechanism
Elicitation needs a question and appropriate participants. An interview explores an experience; a workshop helps resolve interpretations; observation reveals tacit work; a survey can reach more people, but its sample and questions influence results. If only day-shift staff respond, do not automatically generalize to overnight on-call work. Capture each need’s source and rationale and confirm understanding. Decompose large capabilities into behaviors that can be discussed and evaluated while preserving the overall outcome. Splitting by technical layers may simplify internal organization, but does not guarantee each increment has business usefulness. Keep interfaces, data, and exceptions visible when distributing work.
Guided application
In a fictional case, an API returns success when it accepts a request into a queue. The consumer interprets that response as completed reconciliation. The contract needs to distinguish acceptance, completion, failure, and how to retrieve the result. Draw a sequence with producer, queue, processor, and consumer; use it to examine a retry after timeout. A requirement such as do not duplicate transactions needs an identity definition and resend behavior, not merely a promise. In another exercise, a rule covers values above 500 and below 500: the exact value remains untreated. Boundary examples make the gap discussable with its owner. Models are discovery and communication tools; they still need confirmation and connection to needs.
Accepting a request into a queue does not establish completed processing.
Common pitfalls
Convenient sample treated as population; technical split treated as value; timeout treated as proof of no execution.
Related topics: From need to solution scope · Value, stakeholders, and business case · Requirements plan and responsibilities
Specify contracts and exceptions teams can interpret consistently.
Reference: Collaborative and creative business analysis · Five-domain ECO / verified 2026-10-01