Business Analysis Notes

Techniques BABOK Guide v3, 10.36

Prototyping

5 min read · Updated

In short A prototype is an early, partial model of the solution that stakeholders can see and try. Reacting to something concrete surfaces missing requirements, wrong requirements, and untested assumptions far faster than reading a document, so you refine the model in short cycles until the open questions are answered.

Based on: IIBA, BABOK® Guide v3, technique 10.36 “Prototyping”; business analysis training materials (module on elicitation and collaboration); Yu. A. Maglinets, Analysis of Requirements for Information Systems, lecture 5 (presenting K. Wiegers’s classification); D. Leffingwell, D. Widrig, Managing Software Requirements; I. Kornipaev, Requirements Management (course slides).

On this page

What it is#

Prototyping elicits and validates stakeholder needs by building a model of the solution, or of part of it, and improving it iteratively with the people who will use it.

The BABOK Guide distinguishes two approaches:

  • Throw-away prototypes use simple tools such as paper, a whiteboard, or a mock-up tool, and never become production code. They suit functionality that is hard to understand or where stakeholders hold different views.
  • Evolutionary (functional) prototypes are working models built with specialized tools; they can grow into the final solution.

It also lists kinds of prototypes by purpose: a proof of concept tests whether a solution approach works, without modeling its look or processes; a form study checks size, appearance, and ergonomics without function; a usability prototype tests how users interact with it; a visual prototype shows the look without full function; a functional prototype tests functionality and business rules. Ways to build them include storyboarding, paper prototyping, workflow modelling, and simulation.

Wiegers’s two axes#

Maglinets presents K. Wiegers’s classification, which adds a second axis. A horizontal prototype models only the user interface; logic and data are simulated, though the screen text should use realistic domain content. A vertical prototype is a thin slice through all layers, built with the same technology as the target system, to test architecture, feasibility, or performance.

Throwaway Evolutionary
Horizontal Clarify use cases and functional requirements, find missing ones, explore UI options Build the interface step by step, for example on websites, when needs change fast
Vertical Show that something is technically feasible Build and grow core functionality, tune algorithms, test performance

Two related tools: before a horizontal prototype, sketch a dialog map of the main screens and the transitions between them (Maglinets notes it maps neatly onto a state diagram); and consider a storyboard, which Leffingwell and Widrig describe as passive, active, or interactive.

When to use it#

  • Requirements are vague, disputed, or depend on how something looks and feels.
  • Stakeholders say “I’ll know it when I see it”.
  • A technical approach is risky and needs a feasibility check.
  • You want to test a workflow with real users before building it.

The training materials list its strengths: it gives a visual picture of the future state, and stakeholders take part in shaping it and giving feedback.

When to be careful. The same materials warn that for complex systems, prototype sessions can drift into how to build instead of what is needed; a detailed prototype can create unrealistic expectations; and stakeholders or developers may lock onto it as an exact specification, losing flexibility. Kornipaev names three ways a prototype does harm: it distracts people with implementation details; it is used to sell a new technology rather than to check requirements; or it looks so finished that the customer believes most of the work is done and expects delivery within a week. For well-understood, stable requirements, or for back-end rules better captured in decision tables, a prototype may add little.

How to do it#

  1. State the question the prototype must answer: which requirements to clarify, or which risk to reduce.
  2. Choose the type: horizontal or vertical, throwaway or evolutionary. Start with the lowest fidelity that can answer the question.
  3. Plan the flow: pick the scenarios to cover and sketch a dialog map.
  4. Build it fast, with realistic content. Maglinets points out two benefits of paper: people focus on function rather than button colors, and nobody concludes the system is nearly finished.
  5. Annotate expected volumes and frequency. Maglinets, drawing on Leffingwell, suggests noting typical data volumes and how often each scenario occurs: a choice between two options suits a checkbox, a few dozen a drop-down, thousands a search with filters; the most frequent scenarios deserve the fewest steps.
  6. Review with users: let them work through scenarios, watch where they hesitate, and ask what is missing or wrong.
  7. Capture findings as new or changed requirements and log open questions.
  8. Iterate until the question is answered, then stop.
  9. Decide the prototype’s fate. Throwaway code must be thrown away; say so explicitly.

Example#

The Workshop, a fictional chain of 12 bike-repair workshops, tests online booking with a paper prototype of four screens: choose workshop, choose service, choose slot, confirm. The analyst runs short sessions with three customers and two front-desk staff.

Findings:

  • Customers did not know which service to pick (“is a squeaky brake a basic service?”). New requirement: a “Not sure? Describe the problem” option with free text and a photo.
  • Front-desk staff need to keep some slots free for walk-ins. New business rule: each workshop can reserve slots that are not offered online.
  • Mechanics need the bike type to estimate time. New field on the confirm screen.

Separately, the development team builds a vertical throwaway prototype to check whether the parts supplier’s catalog can be read automatically. It cannot, so the parts feature is postponed before any production code is written.

Common mistakes#

  • Polishing too early → keep fidelity low until the big questions are settled.
  • A prototype that looks finished → use sketchy styles and explain what is fake.
  • Debating implementation → steer back to what users need to do.
  • Throwaway code reaching production → agree up front that it will be discarded.
  • Selling technology → keep the prototype’s purpose on requirements.
  • Prototype as specification → write the requirements down separately.
  • Only the happy path → include errors and unusual cases.

Checklist#

  • The question the prototype must answer is written down
  • Type and fidelity chosen deliberately
  • Scenarios and dialog map prepared
  • Realistic content and data volumes used
  • Sessions held with real users, findings recorded
  • Findings turned into requirements and logged questions
  • Fate of the prototype agreed and communicated

Sources and further reading#

  • IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Technique 10.36 “Prototyping”.
  • Business analysis training materials (module on elicitation and collaboration).
  • Yu. A. Maglinets. Analysis of Requirements for Information Systems, lecture notes (in Russian). Siberian Federal University, 2007. Lecture 5 (prototype classification after K. Wiegers; paper prototypes; usability annotations after D. Leffingwell).
  • D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. (Storyboarding.)
  • I. Kornipaev. Requirements Management, course slides (in Russian). (Dangers of prototypes.)