Gathering your project’s requirements by using a prototype can be effective because it is very attractive to the users. Requirements by prototype consists of planning and then developing a sample deliverable for the users to “play with,” review and modify. Prototyping takes some pressure off the users. They don’t need to specify all of the requirements up front, without having evidence that they work. After the team produces the initial project deliverables, the user/client evaluates the prototype and tells the project team about the prototype’s flaws. Then the team goes back to work to fix those issues. They produce another prototype for the user/client to evaluate, and the cycle goes on.
Project managers use prototyping with certain types of projects. It’s most often used in software development where the cost of making changes to the prototype is not too expensive. They also use prototyping in manufacturing, depending on the cost of each iteration. Prototyping can take a great deal of both the user/client’s and the project team’s time, depending on the number of iterations. The arguments in support of prototyping are that it encourages continuous contact between the user/client and the project team. Fans of prototyping say it produces a higher quality result and a shorter development cycle. On the other hand, prototyping can create a situation where the project team works on the effort forever. That’s because the user’s requirements change every time they look at a prototype. Requirements Gathering Main Page
Prototype vs Iterative
The requirements by prototype process is different from iterative development because we’re only asking for the requirements, not a final deliverable. We start by talking to the user and making a plan. Then we produce the prototype. Ideally, the user would review the prototype, make changes and then we would produce the final deliverable. In the real world we’d make another prototype for the user to review and modify. Producing one prototype after another allows us to develop the final deliverable prototype by prototype. Depending on the deliverable, prototyping can be very expensive and time consuming. But if a user or client wants to pay for this approach, a good project manager can accomodate them.
Prototype vs Waterfall
Using prototypes is very different from the classic waterfall approach where we finalize the whole plan in a lengthy planning effort, and then produce the deliverable. The waterfall approach is cheaper. But it requires the client or user to commit to exactly what they want during the planning process. It also limits the changes the client can make once we begin to execute. The prototyping approach allows for changes during each iteration, if the client will bear the cost.
Get more articles and videos each week