In this article, I'll be discussing some other requirements gathering methods that complement use case modeling and should be used to ensure your requirements gathering goes swimmingly.
In particular, I'll be mentioning storyboards, wireframes and prototypes.
I'll also cover what level of quality and detail you should adopt when applying these techniques.
Finally, I'll describe how you can use these documents alongside use case modeling.
Use cases are perfect, aren't they?
You might ask why we would waste our time with other techniques for gathering functional requirements when we have the use case model. There is no approach that is foolproof and different people respond better to different techniques. Some people like very visual approaches and some are comfortable in the abstract. Others may prefer something very concrete and need something engaging and are easily distracted. The following techniques tend to be very visual, concrete and engaging. Use cases, on the other hand, are partly visual, not particularly engaging and somewhat abstract.
Why I am I wasting my time with use cases at all?
That will become apparent as we discuss the alternatives and the value they provide.
Storyboards
- Example of a storyboard
Storyboards were borrowed from the film and TV industry where a sequence of key events are drawn up that summarize the plot in a film. They are used to identify problems before significant investment is undertaken. They are used for the same reason in software development in that they can be produced quickly and at very low cost. They can be used to generate and explore alternatives or to test the feasibility of a specific approach. They appeal because they are very informal and the participants can agree what form it will take. For example, a number of 'scenes' may be sketched out exploring the customer experience for a specific project on a sequence of flipchart pages which would be tacked to the wall.
They will be produced in a workshop environment attended by the relevant stakeholders. They would appeal less to organizations that use only formal approaches but the benefits justify overcoming the initial period of discomfort.
Storyboards are not specific to user interfaces and could be equally used to describe a business process which includes the back office and other forms of interaction with the customer such as mail, email and telephone.
Wireframes
A wireframe is a bare user interface design that shows how the user interface will be constructed but without any focus on the aesthetics. It will be representative and won't be a working system, just a sequence of screens that should be shown in a particular sequence. It allows the user to 'see' the system at minimal cost and to try variations quickly.
These can be generated using dedicated tools or general diagramming tools (e.g. Visio, MS PowerPoint) or using basic web pages.
This approach can be more formal than the storyboard and can be used in a workshop environment or in a one to one, interview-based approach. Obviously, it works only for requirements where a great deal of user interaction with a system is required,
Prototypes
A prototype is a widely used term for a model that is not 'production-ready' (i.e. suitable for use in the target market) but can be used to run trials to test the product at reduced cost. In software development, there are a variety of different prototypes which serve different purposes and require differing degrees of investment in time and cost:
-
throwaway prototype Minimal effort is involved in its production but it should be enough to bring the system to life to elicit the best responses from the users/business stakeholders.
It can vary from a series of hand drawn sketches (more akin to a wireframe) to a series of PowerPoint slides to lightweight web pages using real, example data
-
evolutionary prototype This prototype is intended to elicit user feedback but it will also form the user interface for the final system so will not be discarded. This will, typically, take more effort to produce but the prototype will have greater value. It is only sensible to adopt this approach when the screen design has started to firm up, NOT when the project is in its first stages as there will be a lot of rework required.
-
technical proof of concept prototype This is a prototype which is used to explore, for example, some key part of the architecture where there is high risk. It does not necessarily include a user interface element so would not be used alongside use case modeling. It is included here for completeness only
Where do use cases fit in?
All of these techniques can be used independently or alongside the use case model. They can bring to life the use cases which will deliver better responses from users who are not comfortable with abstract approaches. At the point it is necessary to agree or baseline the requirements, none of these approaches is suitable - the use case model includes business rules and descriptions of system behavior which are concealed by any of these more visual approaches.
In addition, there are many other benefits offered by a use case model - for example, it can be a significant aid in planning and testing.
In summary, use case modeling is rarely a good method for gathering requirements in isolation.
There are several more visual, concrete and engaging approaches which add value to the requirements gathering approach and can be used alongside the use case model.
The approaches are - storyboards, wireframes and prototypes. They are all low cost and quick methods although the prototype can be more expensive if it is evolutionary.
Use cases can be used alongside but they will always be required when it comes to baselining the requirements.
Useful Links
Author: Alex Papworth, owner of businessanalystmentor where similar articles on many aspects of business analysis can be found.