Go ahead and admit it — you write great requirements! You follow a solid process and create software requirement specifications that sparkle with stakeholder signoff. But if you’re like me, this is not enough. It’s a long way from SRS to deployment, and the myriad of design choices that happen in between can derail a strong set of software requirements. How can you be sure that what goes live will really be successful?

As business analysts, we need to keep users focused on what they need, not how they need it to be done. When developing a software requirements specification, I like to imagine a system implemented with stone tablets and flying monkeys. In other words, the design should not matter during requirements development; let it be something crazy to make that as clear as possible to everyone involved.

Unfortunately, most people do not seem to think this way. Although they might not admit to prematurely thinking of design, internally they start building a picture of what the system should look like from day one. Sooner or later, we have to deal with these unspoken visual requirements. We can dramatically improve our chances of a successful project by modeling these software requirements through iterative prototyping.

A prototype is a model or partial implementation of a system. Prototypes may take many different forms, ranging all the way from rough napkin sketches to fully interactive mock-ups of a user-interface. Each of these can be valuable. As Karl Wiegers says in Software Requirements (Second Edition), “Software prototyping makes the requirements more real, brings use cases to life, and closes gaps in your understanding of the requirements.” Of course, some prototypes may be more effective than others given the circumstances of your project.

A Slice of Life
Prototypes can be categorized as either horizontal or vertical, based on the view that they take of the system. Horizontal prototypes model a shallow slice of the architecture. These are most often used to evaluate user-interface design. Vertical prototypes provide a proof of concept by modeling a deep slice of the system, from the front-end to the back-end. These are primarily used to evaluate technical feasibility of a proposed solution, or even provide a solid foundation for building the actual system.

To Keep or Not to Keep — That is the Question
Prototypes can also be classified as throwaway or evolutionary, depending on how long they are intended to be used. Throwaway prototypes, as the name implies, are short-lived, yet that does not diminish their potential value. They can usually be developed very quickly (at low cost) and help drive rapid user feedback. Examples of throwaway prototypes include screen mock-ups and storyboards, both of which can be developed with tools like Visio or simply pencil and paper. On the downside, these models stop short of allowing users to completely validate a potential solution. This is where evolutionary prototypes take over.

Evolutionary prototypes are functional systems that permit users to fully-evaluate the implementation. Unlike throwaway models, these are not intended to be short-lived. They ultimately should evolve into the final system through iterative incorporation of user feedback. The main drawback to evolutionary prototypes is that they take longer to develop (and incur a higher cost) than their throwaway counterparts.

Fortunately, prototype models can be combined for stellar results.

Pulling it All Together
The best way to build confidence in your requirements and drive project success is through use of all four prototype models that we have discussed. The process assumes that you have already created a first draft of the Software Requirements Specification (SRS) that includes use cases, functional/non-functional requirements, etc. This serves as the foundation for horizontal and vertical prototypes that will help refine and validate your work. The diagram below provides an overview of the process:

Horizontal Prototype
The User Experience (UX) team works with business analysts to produce the User-Interface Specification. At each step along the way, collect feedback and update the prototypes as necessary. The UX team should work with business analysts to update the SRS and/or User Interface Specification if refinements to the requirements have been identified.

1. The UX team uses throwaway screen-mockups to review potential UI implementations.
2. Once a general approach for the UI has been decided upon, the UX team produces a throwaway set of low-fidelity wireframes that represent a complete walk-through of the UI. In other words, all use cases should be addressed, and all screens in the system should be represented.

• The wireframes should show all interactive elements of the UI. For example, the wireframe for a billing details screen would include text fields for a customer’s address, but the wireframe would not include a static banner image for the form.
• Keep the wireframes in black and white, and use Lorem Ipsum text to keep users focused on workflow and requirements (not “look and feel” or real data). The wireframes are intended to help users visualize and validate the SRS.
• PowerPoint is well-suited for producing a set of wireframes. Do not waste time making the presentation interactive. Users should be able to easily understand the workflow by simply clicking from slide to slide.
• Consider exporting the presentation to HTML for easy accessibility to people who will be reviewing the wireframes.

• Functionality implied by the screenshots must match the wireframes, but the screenshots include “look and feel”. The screenshots set specific expectations for the user-interface between business owners and the development team.
• A tool like PhotoShop is great for producing the screenshots (with extensive use of layers to minimize maintenance). Like the wireframes, consider exporting the images to HTML for easy accessibility to reviewers. Users should be able to simply click from screen to screen. Photoshop PSD files can be given to developers for precise layout guidelines, and developers may even cut assets directly from the images.

Vertical Prototype
The development team produces an evolutionary prototype that ultimately becomes the delivered system. At each step along the way, collect feedback and update the prototype as necessary. Send feedback to the UX team. Work with business analysts to update the SRS and/or User Interface Specification if refinements to the requirements have been identified.

1. The development team uses throwaway vertical and horizontal prototypes to evaluate technical feasibility of various architectures.
2. Once a general approach for the architecture has been decided upon, the development team produces an evolutionary prototype with a limited set of functionality from the SRS. The UI is implemented in accordance with the wireframe deck.
3. The development team updates the prototype with additional functionality in accordance with the SRS. The UI is implemented in accordance with the wireframe deck and interaction requirements.
4. The development team updates the prototype with additional functionality in accordance with the SRS. The UI is implemented in accordance with the UI Specification (screenshots with interaction requirements).

Seeing is Believing
Developing a great Software Requirements Specification is a step in the right direction, but it’s not enough. First, develop a User Interface Specification to establish a clear expectation for visual design. Second, develop an evolutionary prototype to drive iterative end-user feedback. Both techniques can also help identify missing requirements, as well as refine existing requirements. Use prototypes to build confidence that your requirements will lead to a triumphant project success.