As discussed in the previous post, prototyping is one of the cost effective ways of presenting an approximation of a working system to the stakeholders to validate the concept and work out the kinks.

To get to the stage where a prototype can be built, you need to have at least some understanding of most of the high-level requirements.

Let’s look at the advantages of prototyping listed in BABOK:

  • Supports users who are more comfortable and effective at articulating their needs by using pictures, as prototyping lets them “see” the future system’s interface.
  • A prototype allows for early user interaction and feedback.
  • A throw-away prototype is an inexpensive means to quickly uncover and confirm a variety of requirements that go beyond just the interface such as processes, data, business rules.

BABOK limits prototyping to working out the user interface requirements: “Prototyping… details the interface requirements and integrates them with other analysis requirements such as use cases, scenarios, data and business rules.”

Prototyping is a great and very useful technique, however, in order to get to the stage where a prototype can be built, you need to have at least some understanding of most of the high-level requirements. Is there a way to get the benefits of prototyping at an earlier stage in the requirements gathering process? Well, I have found that presenting information visually is a great way of achieving just that.

For example, I could make something like this diagram:


This diagram lets me outline the “big picture” and to “test” structural integrity and logical behaviour of the solution (both software and non-software based), inputs/outputs of the components. It also allows me to find out the users’ expectations of the functionality to interact with the solution.

It’s very informal and doesn’t take much time to produce. It shows a lot of diverse information: hardware components, business software applications, office applications and two manual processes for entering business data into a spreadsheet, plus it’s all mapped to the key users of the solution.

The diagram can easily be extended to show data flows in certain parts of the solution (for example) in order to provide more context and get more detailed requirements in a later session with the same stakeholders.

Let’s see how this technique compares to the benefits of prototyping:

  • It’s great for “visual” people. In fact, in my experience it’s beneficial to the vast majority of stakeholders. For most people it’s far easier to see what’s going on in a diagram compared to processing the same information as text.
  • It makes it easy to walk through the system and get feedback, and consequently work out the requirements at different levels of detail.
  • It makes communication with stakeholders a lot more efficient, saving a lot of time and money, adding a bit of fun to business routines and thus contributing to the success of the project.

In other words, I get all the advantages of prototyping a lot earlier in my projects by leveraging the core trait of prototypes - giving the stakeholders something they can immediately grasp and discuss, and easily provide feedback on. This technique is also easy for you as a BA to start using - just start sketching a diagram for your current project!

If you liked this post, please share it with other people!