A Case for Prototyping

As a BA, prototyping is an essential function. In fact, I feel it’s probably the single most important thing to do when gathering requirements from users, yet how often do we engage in it? Fred Brooks, a Turing award winner [equivalent to a Nobel Prize for computer science], writes in his now famous article about software engineering, “No Silver Bullet”, about the importance of prototyping when creating software. See excerpt below.

Requirements refinement and rapid prototyping.
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem in the detail necessary for specification. Even the simple answer--"Make the new software system work like our old manual information-processing system" --is in fact too simple. One never wants exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software-design activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.

I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.

Therefore, one of the most promising of the current technological efforts, and one that attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as prototyping is part of the iterative specification of requirements.

A prototype software system is one that simulates the important interfaces and performs the main functions of the intended system, while not necessarily being bound by the same hardware speed, size, or cost constraints. Prototypes typically perform the mainline tasks of the application, but make no attempt to handle the exceptional tasks, respond correctly to invalid inputs, or abort cleanly. The purpose of the prototype is to make real the conceptual structure specified, so that the client can test it for consistency and usability.

Often times, UAT [User Acceptance Testing] is the first time the user gets a chance to look at the system. And this is way too late in the game to change things (although it is often done anyway). In one project I heard about, the lead BA hadn’t seen a working screen until a month before deployment of the software, after an initial 8 month development cycle!

BAs do use prototyping tools such as PowerPoint and Visio to create screenshots for their users. In some cases, groups may be fortunate to have an Information Architect (IA) on their team who is well-versed in using Adobe Photoshop, or InDesign to quickly do mock-ups and wireframes. This is a great thing to do because it gives the end-user the ability to visualize what s/he will be seeing. However, (1) end-users may glance at a screenshot and just nod and say OK without really digesting it and (2) screenshots still fall short in that behavior of the application is not described or experienced.

Prototyping is the next best thing to having a real application on one’s desktop. A simulation of the software or a raw version of the actual to-be-delivered software makes the user experience much richer and elicits more accurate feedback than any static screenshot can. Prototypes with use cases or scripts are a very powerful combination to drive a focused requirements gathering exercise.

A few prototyping tools that simulate behavior are out in the market already. Mockupscreens (from Mockupscreens.com), iRise (iRise.com) and Axure (axure.com) are three tools that seem to be popular. Indeed, I have used Axure to create a working html prototype (6 webpages) of a car website in 45 minutes.

Furthermore, in many projects currently, software cycles are planned so that the front-end, back-end and middle-tiers are developed and arrive at the same time, all to be released to the end-user. My argument is that we go ahead and concentrate on building the front-end first as a prototype, and deploy it to specific end-users and stakeholders with the intention of eliciting feedback. Clicking on buttons and menus will bring up windows and pop-ups with tables of dummy data that can be prepared beforehand by the BA. This will give as close an approximation to what the end-user will see in UAT but much earlier on in the process. BAs can correct requirements and obtain new ones as the end users ‘demo’ the software.

In each iteration of the cycle, working software is always in place and a constant flow of new functionality is added as the software grows. Again as Brooks says:

The system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below… I have seen most dramatic results since I began urging this technique [Incremental Development] on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness…The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system.

The end users will also get excited as the system takes on the look and feel they desire. Constant back and forth between IT and the business occurs and a positive feedback loop emerges. Collaboration becomes the new name of the game. As IT tweaks the prototype to align with what the business wants, the end users see that IT is responsive to their needs immediately and a collaborative spirit ensues.

One hazard with this method is that end users may be too eager for the system once they see it (even if it’s only a prototype) but these expectations can be managed. The focus should be on building a collaboration; a business user who is much more engaged and eager to deal with IT is far more preferable to one who sits back and has to wait until UAT to finally see a working system that may or may not fill their needs.