A Four-Stage Requirements Method (Khimonin)

Key ideas#

Stage 1. Product concept#

The business analyst or product manager leads this stage. The result is a Product Vision Document for a product built to order, or a Marketing Requirements Document (MRD) for an open-market product. The MRD adds detail on target segments and competitors.

The order of work differs by product type. For a product built to order: stimuli, then goals and success criteria, then customer needs, then a competitor review. For the open market: stimuli, competitors, target segment, needs, then goals.

• Stimuli are the triggers: market demand, operational necessity, a customer request, technical progress, legal constraints.
• Goals may be financial (market share, sales, return on investment, savings) or non-financial (satisfaction, productivity, reputation). Following Wiegers, Khimonin insists they be measurable.
• Target segment: home users, small and medium businesses, large companies, corporations. Needs differ sharply between them (administration, interface, security, scalability, licensing, support). Khimonin advises against aiming at large corporations before you have served smaller businesses.
• Scenarios describe all the processes and the environment in which the product will be used, for all users at once. For a built-to-order product they come from customer interviews; for the open market, from user profiles plus interviews with suitable people. Scenarios and the requirements inside them are prioritized with MoSCoW, and the two priorities are combined; for example, a Should requirement inside a Must scenario is treated as Should.
• Competitor review: identify the leaders, study price, delivery and demos, list the problems they solve and the features they offer, and summarize the strongest.
• Solution vision: a list of product capabilities, starting with the non-functional ones because they drive the cost and complexity of everything else, plus a short product image using Geoffrey Moore’s positioning template from Crossing the Chasm.
• Project content: Khimonin’s rough guide for waterfall projects is that estimates are only about 50% accurate after the concept, 60–70% after elicitation and analysis, and 80–90% after design. Hence his advice to add a twofold buffer to early expert estimates.

Stage 2. Eliciting requirements#

• Build user profiles. In corporate products a director, a secretary and an accountant use the same system very differently; design for real profiles, not an imaginary average user.
• Form an initiative group with at least one representative per profile.
• Collect user stories: a use of the product in a specific situation with a measurable result. Khimonin gives them use-case-like fields (ID, author, date, profile, priority, frequency, parent business requirement, precondition, goal, flow of actions), with the flow optional.
• Keep asking “Why?” before “what” or “how”, so you capture needs rather than ready-made solutions.

Stage 3. Analysing requirements#

The aim is to organize requirements and remove duplicates. Khimonin offers two routes.

A. Use-case-based (his preferred route, because every function stays linked to a user story that needs it):

1. Find the base use cases in the stories.
2. Draw a use case diagram colour-coded by priority: green for Must, yellow for Should, blue for Could, red for Won’t.
3. Remove repetition: extensions refer to the base use case instead of copying it.
4. Find mutually exclusive stories. Decide whether it is an author’s mistake or two genuine views; then choose one, or add conditions so both can hold.
5. Break use cases into indivisible elements.
6. Turn the diagram into a numbered list.

B. Specification-based (for small volumes, or teams that do not use use cases): extract unique requirements from the stories and split them into independent, indivisible statements.

Group stories into packages of about 20–30 to keep navigation and editing manageable. Then review the non-functional requirements again: at the concept stage they were assumptions, and now you have real stories to test them against. Changes to architecture-level requirements need sign-off from everyone responsible, because they move the budget.

Stage 4. Design#

The result is a functional specification: system-level requirements, a user interaction model, the product architecture and technical details.

• Model execution flows with activity diagrams when actions matter (wizards), state machines when states matter, and sequence diagrams when several objects work in parallel.
• Build GUI mock-ups in a separate prototyping tool, not in the development environment. Khimonin observes that each window changes several times, and later changes cost more.
• Specify each CLI or API function with syntax, description, parameters, result and an example, and give it to QA as early as possible.
• Describe architecture with a deployment diagram, components, interfaces, complex process flows and the database structure.