What Prototyping Entails
/I find prototypes extremely useful in guiding the thinking process during requirements elicitation and analysis. With prototypes, stakeholders can easily get a feel for what is required and what is superfluous. Prototypes also allow analysts to express in pictures their understanding of users' requirements, which they can in turn validate.
The concept of prototyping is often argued as being contrary to what business analysts are expected to do on projects. BA purists insist that analysts refrain from design. Prototyping at its core, is a form of design (however rudimentary) aimed at representing users' requirements. The challenge for analysts often lies in drawing the line between prototyping with the objective of system design and prototyping with the objective of fact-finding.
Prototypes have the innate power to bring requirements to life at minimal costs to the business. The amount of resources committed to building a prototype of course, depends on the level of detail required. It can be as simple as a drawing on a piece of paper or as interactive as clicking through windows of illustration.
Prototypes are effective in:
Eliciting business requirements
Confirming business requirements
Unveiling areas of conflict
Cons of Prototyping
1. You need to manage users' expectations – Prototypes are not always implemented as designed, either due to implementation constraints or identification of an improved design which may happen as the project progresses.
2. It is very easy to get bogged down by design details. If the objective is to trigger stakeholder discussion/confirmation, the prototype should contain only the minimum information necessary to achieve this and no more.
The Value of Prototyping
The main value of using a prototype is to convey to stakeholders how the solution should work and what it should do. A throwaway prototype is low-cost and is only used in triggering discussions around what should be built – it is eventually thrown away after use since there's no direct functionality behind it. In some cases, such prototypes are included in the requirements specification document for sign-off by stakeholders. With evolutionary prototypes however, the development team starts with a prototype and builds on it.
The value of prototyping is particularly obvious in complex domains where simply writing out textual requirements does not offer much value or clarity to stakeholders. Prototypes enable stakeholders to see the depth of the solution, clarify complex areas and make changes as early as possible.
Should You Use Prototypes Every Time?
My answer would be, "No". Your choice of whether or not to use prototypes should be guided by the complexity of the domain and the tendency of requirements to change. Imagine an architect trying to explain how a structure as complex as a building will look without a drawing. That would be pretty hard, right? If I were just trying to figure how to get to a store two blocks from me, however, a verbal or textual description would do. I would probably not need someone to draw me a map to get there.
Prototypes should be used for eliciting details of requirements, triggering discussions and identifying hidden requirements yet to be brought to light.
Tools For Prototyping
One common and easily-accessible tool for developing prototypes is Microsoft Excel. Because of its tabular form, it's easy to create tables and convert them to charts as a way of representing system output. These outputs are vehicles for presenting information to stakeholders. Prototypes may also be in the form of mockups with demo data or they may be developed with databases like Ms Access or Filemaker Pro and populated with test data. They are rarely complete and only focus on communicating key product functionalities to stakeholders before full system development begins.
Picture Attribution: Landscape Architect Designing Plan Stock Photo/Freedigitalphotos.net
