In the software application development domain, a Business Analyst is typically responsible for gathering, analyzing, and writing requirements. A Requirement, in the simplest of terms, is a statement of need. So why do many software application development projects fail? Many times, incomplete or incorrect requirements are the source of the problem. How does this happen? I was thinking about this the other day while I was driving around, looking at homes in various stages of construction. It dawned on me, the answer is quite clear.

Would you ever buy a home based on a floor plan and a few sketches? Probably not (unless you really trust the architect, construction company, and have the extra money to spend on the eventual cost overruns to build your dream home). These days, even custom home builders usually have a model home or two to show the potential customer. Why? It’s simple, a customer wants to see what he or she is getting for his or her money. For a custom home builder, the quality and beauty of a home is paramount; the model home is a demonstration of the builder’s capability. A customer may request available floor plans, sketches, and a list of potential upgrades. But usually this isn’t enough, why? It is difficult to conceptualize and translate floor plans, into a real world home. Floor plans, detailed sketches, and specifications are great for construction crews building the house; but not great for the customer who’s buying the home.

This is the same problem we experience in the software application development domain. We can be extremely detailed in gathering, analyzing, and documenting requirements; we can even use visuals (like storyboards) to give Stakeholders a rough idea of what they are getting. Written requirement specifications are great for developers, just like architectural plans, specifications, and detailed drawings are great for construction crews. Storyboards and low fidelity prototypes are akin to floor plans and sketches; they are sometimes enough to make good decisions and develop a quality product. However, most times, Analysts should go further (if it is within their skill set). High fidelity prototypes are akin to a model home, a real world translation of what the customer wants and will get. The customer knows what they are buying (or close to it), and are usually happier with the end product. The downside of this approach is that it requires a Business Analyst to have artistic design skills and the technical expertise to use specialized software applications to build high fidelity prototypes. Having a working knowledge of prototyping applications will become increasingly in demand for the Business Analyst. To be successful, Analysts must be able to elicit and correctly interpret requirements, translate these requirements into written specifications, and have the skill set to transform approved requirements into tangible prototypes. Business Analysts, in this analogy, will need to be able to construct the model home for the customer.

Like this post? Share it!