Requirements gathering alongside use cases


prototypeIn 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 (see Use Cases – an Introduction for more on use case modeling).

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.



Example of a storyboard

Example of a storyboard


Storyboards were borrowed from the film and TV industry where a sequence of key events are drawn up that summarise 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 organisations 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.


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, 


 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 behaviour 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

Wikipedia history of storyboards (not related to software)

Wikipedia definition of wireframes

Variety of useful wireframe articles and links

Wikipedia definition of protoype (in broadest terms)

More detailed analysis of prototypes and storyboards (from Craig Borysowich’s blog)

It's only fair to share...
Share on Facebook1Digg thisBuffer this pageShare on LinkedIn0Share on Google+0Share on VKTweet about this on TwitterShare on Tumblr0Pin on Pinterest0Share on Yummly0Flattr the authorShare on Reddit0Print this pageShare on StumbleUpon0Email this to someone

About Alex Papworth

18 Responses to “Requirements gathering alongside use cases”

Read below or add a comment...

  1. blog xuite says:

    Many persons who’re new to the web, or maybe are simply exploring
    the chance to start a web business question whether it is really important
    to their success to experience a blog. You sell t-shirts and bags which are branded using
    your blog’s logo to raise some income. No matter how big or small the business is, it is the most efficient
    tool for them.

  2. In this article, I will demonstrate making videos on the computer in three other ways:.
    The mouse’s motion is translated via a cursor that is displayed on the pc screen. The dll error arises as a result from the
    dll file failing to communicate a specific
    command that may enable a particular program to open.

  3. Amy says:

    Hi Alex –
    I just stumbled upon your post as I was researching articles and training on User Interface based requirements elicitation techniques. I have been working on a project that is very data focuses, however the business owners are struggling to understand their data needs without a screen in front of them. As a result we have started "sketching" (qualify similar to your storyboard example) screens for them to put the attributes on. So far, this has been working well, and our progress is rapidl improving. I am trying to find more articles and/or training to improve my skills in facilitating these sessions, capturing the applicable requirements and how to best document it all together (the use case, the sketch, the requirements, the LDM etc). Any suggestions?

  4. Good article, Alex.
    All these techniques are useful for exploring scenarios or possible designs, but I think none of is really about stating requirements. I still find it hard to improve on a good old numbered list of short textual statements to specify requirements in a way that is (a) understandable by the business owner (b) understandable by the designers and developers (c) testable and (d) traceable.

    • Alex P says:

      Hi Nick

      I agree with all of your points.
      I would always expect to produce a list of requirements statements as a deliverable. The question for me is – how do you produce a high quality set of requirements? My view is this can only be achieved with high quality interaction/requirements exploration with the stakeholders and any and all techniques which facilitate this should be applied.
      Different stakeholders respond in different ways to different approaches – some appreciate the more abstract, some engage better with more visual approaches. A few (not many) are quite happy labouring through a dry list of requirements. Although this may well be the end goal, the journey there is critical in delivering good results.

      Thanks for your comments

  5. Pradeep Narapuram says:


    Thanks for coming up with such informative blog. Adds lot of value for an experianced person too. Please keep up the effort.

    Thanks and Regards
    Pradeep Narapuram

    • Alex P says:

      Hi Pradeep

      thanks for the feedback. Be sure to let your colleagues know about this and make any suggestions for new articles or services you would like to see on the site.


  6. Hi Alex –

    I just came across your blog. Very nice. I like your articles.

    Like you, I have over 20 years in the software industry, the last 15 in IT. I have been writing on a similar blog for the past couple of years. We can reinforce each other’s efforts. When someone reads the same thing on multiple sites, it lends credibility to what is discussed.

    I think your readers will like my site, and my readers will like yours. Would you add a link to my site to your blogroll? I have added your site to my list. You will see it at



  1. […] Printouts of key ‘visuals’ to help bring to life and prompt the attendees (A1 or A0 size) (read about the value of a visual model here and visual models that specifically support use cases) […]

  2. […] lead stakeholders in all requirements gathering (see Requirements gathering alongside use cases) […]

  3. […] (see Requirements Gathering alongside use cases for more on this) Less formal approach using pictures, based on the idea from the film […]

  4. […] There are a huge range of visual models that can be used from a strategic level (Alexander Osterwalder’s Business Model Canvas) through to bringing to life the detailed interactions with a PC/laptop/mobile/smartwatch/fridge(!) (prototypes,wireframes and storyboards – I wrote about these in 2009!). […]

  5. […] A quick word of warning is that use case modelling is rarely a suitable technique to use in isolation. It should be used in conjunction with other techniques to improve the level of enagagement of your stakeholders and, hence, the quality of their requirements. For example, prototyping is a good approach to use in conjunction – this and other approaches are discussed further in Requirements gathering alongside use cases. […]

  6. […] a Dogsbody doing unpleasant work) actually did a nice post on his Business Analyst Mentor blog on useful techniques you can use alongside Use-Case modeling.He mentions storyboards, wireframes and prototypes.One of the reasons for using other techniques is […]

  7. […] (see Requirements Gathering alongside use cases for more on this) Less formal approach using pictures, based on the idea from the film world […]

  8. […] lead stakeholders in all requirements gathering (see Requirements gathering alongside use cases) […]

  9. […] More on requirements gathering techniques that can be used alongside use case modelling can be found in – Requirements gathering alongside use cases. […]

Leave A Comment...