Hi Sonavi,

First prototyopes.

Here are the main factors to consider about prototypes:

1. scope - how much of the solution are you going to prototype? One complex screen or the entire solution (including the non-computerised parts? More likely somehwere inbetween these 2 extremes, so define the scope in terms of which processes and data will be in scope.

2. fidelity - how realistic will the prototype be? Bits of paper representing screens etc stuck on  wall or mocked up screens done in Access or some other screen generating tool with all the correct colours, fonts, etc. More likely somehwere inbetween these 2 extremes, so define the fidelity in terms of how realistic it will look.

3. functionality - how much will the prototype itself be able to do? All static data that is just shown for illustration only or a the ability to create, read, update and delete (CRUD) all of the data items in scope? Or more likely somehwere inbetween these 2 extremes, so define the functionality in terms of which data can be CRUDed.

4. Advantages of protypes - they make the solution seem more real (less abstract) and so will be excellent for confirming requirements at high (i.e. scope and functional) and (more ususally) low level (i.e. business rules). My prediction is you will uncover some detailed 'taken for granted' requirements that before this the user 'just assumed' you knew somehow. "I just thought you would know we cannot discount bulk orders without increasing shipping costs" and the like.

5. Disadvantages - a prototype that has the scope of the whole solution with maximum fidelity and full functionality differs from the solution how exactly? From a user perspective not much at all! Plus it will be expensive to develop and maintain as you uncover requirements. So not unatrually the users will just want to keep the prototype and forget the solution. Conversely a prototype that is a mock up of one screen on flipcharts may not uncover all the 'taken for granted' requirements (for that screen and the rest of the solution!) and is more abstract than the high scope, fidelity and functionality prototype. How do you choose what scope, fidelity and functionality for a prototype? There are no rules that I am aware of, just your professional judgement.

Second, eliciting equirements.

This is a big topic covering interviewing techniques, workshops, various collaborative work groups such as RAD, JAD, JRP, document investigation, surveys, questionaires, shadowing, ethnographic studies, reverse engineerng of code (when all else fails!!!) and so on. There are many, many, MANY books on the subject!

Are there any techniques that you are especially interested in?

Guy