Hi Lena,

I've never worked on a 'pure' agile project, whatever that is, so there are probably others in the forum with better answers. What I have done is see agile done badly i.e. as an excuse to skip steps and get straight to building screens.

It seems to me that before you get to the stage of mockups you need to at least have a list of the functionality you want you system to support. I'd do that by listing what use cases I need perhaps with a description of what the funcitonality in the use case is without actually defining the use case. You then have your scope nailed down - this is the important piece to get understood by everyone. From there you can start mockups and work out your business rules, validations, data, etc with the business users as you go.

Agile talks about user stories which I think are just what I've described in broad terms. Going straight to mockups without taking the time to do this means you'll more than likely fail IMO. Buy a book or check on the web to get more information on user stories.

Kimbo

Lena,

In my experience, mockups can support the requirements gathering process when introduced at the right time, but they cannot be the entire requirements gathering process.  Here are a few key points that I've raised to management and executives before regarding the pitfalls of mockups to gather requirements.

1)  Mockups are nice because they help the business representatives or client visualize the functionality, but if introduced too soon in the process the natural tendency is for the business reps/clients to try and be screen designers.  Instead of stating that the system needs to support "x", they beginning saying that they need a dropdown to capture "y" and a button to do "z".  The client is not a UI designer, in fact few business analysts truly are.  So this tends to lead to a mess of an application.  Similarly it detracts from the true requirements which aren't what should the system have in terms of controls but what NEED does the business have that must be met via the system functionality.  It just places the emphasis on all the wrong things.

2)  When requirements are captured in UI mockups with no support requirements list, later in the design and development process analysts and developers encounter problems that cause them to question why the screen must be a certain way.  "Do we really need to have this control here versus there? Does it have to be on this screen, or can we capture the data later?"  At this point, there is no way of knowing if the control or feature was placed in its current location due to a specific requirement, or if it was an arbitrary design decision at the time.  We have no idea what the actual requirement is, do we.  We also don't know how design decisions map to true business requirements.

Ultimately, I believe that the introduction of UI mockups can be very helpful, but this should occur after an exhaustive list of features and usage scenarios (what business process flows need to be supported by the system) has been documented.  Only then can the UI mockups be generated without introducing major pitfalls.

Taking this one step further, when the time is appropriate to introduce UI mockups you may also consider using a tool to generate a clickable model.  These are basically mockups that have some ability to navigate from one to another and the ability to show new controls based on certain button clikcs or control selections.  A clickable model is a powerful tool for reveal problems with UI design that have not been considered. There are a number of tool on the market which are design to to this.

I hope these reasons can help you convey to your management the dangers of using mockups for the requirements gathering process.   I would try to communicate there benefit as a form of requirements verification.