How to Bring Requirements to Life
One challenge that business analysts face is early solutioneering. There are times when stakeholders are reluctant to discuss their needs or desires in terms of requirements but just love to outline the specific technological solution they want.
Perhaps they’ve seen a great new application that will solve all of their problems, or perhaps they’ve concluded that rolling out tablet PCs will increase productivity. In these situations, it’s important to help stakeholders understand the root problem and the desired end state by acting as a critical friend through enterprise analysis.
It’s worth taking a step back to consider why this scenario presents itself in the first place. As a business analyst, you’re probably comfortable with conceptual and logical thinking. You can think in multiple levels of abstraction, and you’re comfortable dealing with ambiguity and working toward a vision for the future.
You can ensure that requirements are written in a solution-agnostic way—perhaps writing requirements like “authenticate user” rather than “validate password”—as even using the word “password” pre-supposes that they’ll be a password. We might use a thumbprint, key, or retina scan instead.
While in many projects defining solution-agnostic requirements is important—particularly when the solution is not yet known—it can be a challenge to gain consensus and wider understanding. Take the following hypothetical mixture of high-level requirements:
We need to build, procure, or lease a solution that will provide living space for two adults. It must authenticate the user before granting them access and must have a mechanism for allowing authenticated users to temporarily grant access to guest users.
It must have five distinct zones; the first area will be reserved for the preparation of foodstuffs. The second will be for sanitation. The third will be for relaxing and living; the remaining two will be suitable for recuperation and resting. However, it should be noted that resting and recuperation can also take place in the living zone.
This is a rather facetious example of what an extremely high-level logical requirement set might look like for a two-bedroom house or apartment. Did you find it easy to read? Did it make sense? I certainly think it could be made clearer. I suspect you’d have a better understanding if I had sketched out a potential floor plan or used an analogy.
A key skill of the business analyst is to elicit and analyze requirements and to help stakeholders consider a range of possible solutions. However, abstract and logical requirements can be extremely hard to digest, as the example above illustrates.
Low-fidelity prototypes is a low cost way to help bring logical requirements to life. When used well, they don’t need to constrain design. They can be used to draw all stakeholders to a common view of the requirements that can be revisited and built upon during the design phase.
In addition, tools like scenarios, models, and rich pictures can really help. The key aim is to act as the bridge between the abstract solution and the concrete reality of the world.
