We’ve all heard that a “picture is worth a thousand words”. It’s absolutely true when it comes to building good software requirements. In the case of building a software application, even the most rudimentary prototypes elicit requirements that no one thinks of otherwise.
Within the business analysis community, 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 user interface wireframes or 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.
Using Prototypes During Initiation
During the initiation of a new project, some rudimentary mock-ups can help 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.
Using Prototypes To Get to Detailed Requirements
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.
Using Prototypes to Validate Requirements
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.
Interesting in seeing how prototypes can be part of your next project?
Learn to Create Useful Prototypes
Join us for Use Cases and Wireframes – a virtual, 4-week course. You’ll learn a time-tested approach for creating a use case and associated wireframes. With the professional credit option, you can earn 8 PDs/CDUs too.