Reverse-Engineering Requirements From a Prototype
A prototype is the best tool there is for discovering what people need, and the worst possible way to record it. The step almost everyone skips is turning what the prototype revealed back into traceable requirements. Do it, and the prototype's learning survives; skip it, and you ship the mock-up's accidents as if they were the plan.
An earlier piece in this series argued that prototyping has become the primary way to gather requirements, because people reveal what they need when they react to...
The Prototype Is the Requirement: Why Interviews Alone Stopped Being Enough
The old model asked people what they wanted and wrote it down. The new one shows them something and watches what they do. The difference is the difference between stated needs and real ones.
For most of the history of enterprise software, gathering requirements meant the same sequence of moves. An analyst or product owner interviewed stakeholders, ran workshops, and asked people what they needed. The answers were captured in a document, a requirements specification, a set of user stories, a ...