Using wireframes or prototypes to elicit, analyze, and validate software requirements

My recent post on user interface specifications created some interesting commentary on prototyping vs. specifying. From the perspective of publishing blog posts, writing about UI specs before prototyping put the cart before the horse. In normal project work prototyping or wire-framing activities actually come before any sort of user interface specification work.

As Harris Lloyd-Levy so succinctly put it:

Users engage with UI mock-ups more than any other sort of model – the fact that it’s not in UML or detailed in BABOK doesn’t really matter.

Even the most rudimentary prototypes elicit requirements that no one thinks of otherwise. We’ve all heard that a “picture is worth a thousand words”. It’s absolutely true when it comes to building good software requirements. However, the debate still reigns about whether how the application will look and how the screens will be laid out is technically part of requirements or design. This debate centers around the wrong question.

The right question is “When is the most effective time to introduce visual prototypes into your requirements process?”. My answer: as soon as it makes sense to do so. Another good question to consider is “What requirements do a prototype or wireframe represent?” My answer: it depends. It depends on where you are at from a requirements process perspective (eliciting, validating, analyzing, or a bit of each), what types of requirements management practices you have in place, and what level of user interface expertise is available across members of the team. I’ve worked on teams where the UI prototypes, coupled with some textual rules, formed the main body of functional requirements. I’ve also worked on teams where the prototypes were thrown away or merely used to capture representative screen shots. I’ve also partnered with a UI/UX Designer who creates the CSS/HTML for implementation alongside the functional requirements.

Regardless of where wireframes fit into the requirements package, they can be useful in all phases of the requirements process, from defining the scope to the implementation hand-off.

During the initiation of a new project, some rudimentary mock-ups can help create elicit new requirements and create alignment around project scope. These mock-ups might look nothing like the finished product, but showing one possible solution to a set of high-level business requirements can help get everyone is on the same page. It’s important to keep these wireframes very rudimentary, separating out look-and-feel to focus on the basic concepts to be introduced with the application.

As you start to dive deeper into the project requirements, wireframes become more tangible. I often create wireframes for an end-to-end work-flow, leaving gaps for areas that are open to trigger discussion points. It’s not uncommon for me to hold a walk-through and show off wireframes with bright red text and an arrow indicating “how should this work?” or “what should happen if the user clicks this button?” or “what if this rule is true?”.  Walking through a new work-flow using visuals helps elicit hidden business rules, alternate paths and creates good discussions. Taking the wireframes through an end-to-end work-flow also helps drive some analysis. I often find gaps as I try to get from point A to point B to realize we have missed a field or an entire screen and overlooked an important requirement as well.

In the final stages, prototypes can also be used as a tool to vet the final rules. These rules are probably documented in a separate document, such as a UI specification, use case, or business rules spec. But rather than do a comprehensive document review, I sometimes talk through the rules in reference to the user interface.  An example of this might be in an integrated environment  when you are looking at a screen that is going to feed data to a native application. These rules will likely be documented in a spreadsheet of some kind with all the data mapping details, but instead of reviewing the spreadsheet I’ll bring up the UI screens and visually reference the mapping. So this field will go there…and then if the this field meets this condition, we’ll map it over there…etc, etc.

So there you have it. An approach to leveraging wireframes or prototypes during the requirements process. What other tips and techniques have you found helpful in using visuals as part of requirements?

By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg

Related posts:

1. What to focus on in a wireframe
2. How to create a user interface specification
3. Reverse Engineering Requirements: Synthesize, Document, and Validate!