Prototyping and the Busienss Analyst

A prototype is "the original or model on which something is based or formed" according to the dictionary.  Prototyping is the act of creating such a prototype.

There is no part of the definition that suggests prototypes are done a certain way.

Therefore storyboards can certainly be considered prototypes as can wire frames.  Each should be done iteratively with increasing layers of understanding and refinement between the person creating the prototype and the person for whom the prototype is being developed. Use cases can also be considered a prototype. Anything that allows others to see the picture that is in your mind of the final solution is a prototype.

I have come to the understanding of the term 'prototyping' as the iterative actions and interchanges between developer or business analyst and the business person to create the model on which the software for a system is based. As early as the 1970s working on minicomputers with businesses that were new to automation, we found it easier to mock up the interfaces and operations rather than try to explain the concepts. Prior to that we used paper prototypes to show users what their reports would look like when the system was completed. In those days there was no user interface to prototype.  

There are issues and concerns with dynamic prototyping which describes animated, usually computerized prototypes.  I have found the viewers of a dynamic prototype using low tech tools such as white board or flip chart are much more likely to request changes and are more willing to experiment until they find the metaphor that works for them than they are with the dynamic prototypes (such as iRise).  I think it’s a cognitive thing. Viewing anything on the computer has the imprimatur of being permanent and having taken a lot of work to create. The viewer, usually a user of the system being modified, is hesitant to suggest changes. When the same screen is shown on a piece of paper, the viewer will make all sorts of changes without concern. 

Yes, in some ways a Requirements Document might be considered a prototype, but the review sessions tend to be more wordsmithing than productive. The prototype concept would have you create prototypes, either static or dynamic, and keep iterating them until they fairly accurately represent what the final solution will be, and then document the prototype in the Requirements Document.