Elicitation and Gathering of Requirements - Requirements Engineering and Management for Software Development Projects - page 42

sign off on a requirements document as they are not well versed with the software
development methodologies and techniques such as DFDs (Data Flow Diagrams),
ERDs (Entity Relationship Diagrams), Use Cases, Class Diagrams etc. They are
afraid that they are approving something they do not understand and are unsure if
their stated requirements are included. Therefore, software development organi-
zations often build a prototype of the proposed system as they understood and
demonstrate it to the end-users. The end-users look at the prototype and provide
feedback on:
1. the missing features, if any, from the stated requirements
2. modification of the implementation of their requirements to suit their needs
3. wrong implementation of their requirements, if any
4. any additional requirements that were not included earlier
Prototypes used for this type of demonstrations are of two types,
1. Use and discard prototypes—these are built using a graphic tool like Visio or
a presentation tool like PowerPoint, or a spreadsheet like Excel. Once all the
requirements are obtained, the prototype would be discarded. That is, it would
serve no other purpose than to give an idea to users and obtain their feedback
and approval.
2. Use and improve prototypes—here, the prototype would be a mock up on the
actual development platform. The skeleton of the product would be built with
not much code behind the screens or reports but enough to demonstrate the
product to the end users. It would consist of screen layouts and report formats.
Screen layouts enable a user to visualize how the information input/enquiries
would look like and to determine if they meet their requirements. Report lay-
outs enable them to analyze the information outputs and to determine if their
requirements are understood by the developers in the right perspective.
When the initial requirements are very fluid and unreliable, use and throw
prototypes are used. But if, the initial requirements are more reliable, use and
improve prototypes are used. However, it is the project team's choice to use either
type of prototype. One additional advantage of prototyping is that the software
design also gets finalized by the time requirements are finalized. The concomitant
disadvantage is that effort must be expended on software design right at the time of
eliciting requirements.
Prototypes are used in project development scenarios largely. Prototypes are
also used when developing a new product the like of which does not exist in the
market.
3.2.6 Product Demonstrations
Now a day, quite a few COTS products are available with comprehensive func-
tionality with built in best practices for such areas as ERP (Enterprise Resources