ANSWER

When beginning analysis on a product or solution that is needed to meet a business need, the Business Analyst needs to obtain a basic understanding of the pain points that the business wants to address.

At this stage of this process there is only a need to get the equivalent of a business executive’s point of view. That is, the analyst needs to get a high level understanding of the pain points, framed through the six basic questions someone needs to ask in order to understand any object: Who, What, Where, When, How, and Why. Let’s take each of them in turn.

Who

It’s necessary to understand who has the pain point the business wants to address, as well as who the beneficiary of the product or solution will be. These are often the same people, but may not be. For example, the company may lose customers because a product doesn’t work properly or doesn’t have a necessary feature, and a business executive may “feel the pain” by being accountable for that loss. You want to know about both of these types of people, as well as other stakeholders who are significantly impacted by the proposed change.

What

It’s also important to know about the data and information that are relevant for the pain point and proposed solution. At the highest level, this is a question of concepts— “the user,” “the customer,” “the billing history data”—and their relationships to one another. They’re the kinds of things you would see in a conceptual data model. You need this information so that you understand all of the “objects” involved apart from the people, whether objects are inventory, authoritative data, or whatever is relevant.

Where

This question is of lesser importance early on, but becomes more so as you define your requirements better.  Where is the location of any object or person relevant to the pain point or solution? This may refer to physical locations, computer server or cloud locations, and so on. The underlying issue here is the network—you want to know what kind of impact the pain point and proposed solution affect the relevant network and the things connected to it.

When

You need to know the time strictures that the solution is under. When must a solution be delivered, and what are the reasons for that? Knowing the answer to “when” helps you start thinking about the feasibility of implementing particular requirements as you gather them.

Why

This is pretty important to know. What is the pain point, anyway? What are the business drivers behind the requested product or solution? The answer to this question provides the impetus for the entire project, so it’s necessary to know the answer on Day one.

How

This question is not as useful as you would think at first. When business needs and pain points are first being expressed, the focus should be on defining what those needs are. Although the business may have a general idea of the kind of solution or product they want, closer analysis may reveal an entirely different approach than what was first envisioned. The question of “how” becomes a lot more useful when you have defined requirements and are conducting business process modeling and re-engineering. It is also more useful for the systems analyst or architect later down the line who must actually make decisions about the technologies and approaches to use.

Nevertheless, you should get a basic idea of what the business has in mind in terms of changing its processes and possible solution options to help begin framing the project. Just don’t let that framework bind you too tightly later on down the line.

Once you have answered these six basic questions you are in a better position to proceed to full requirements analysis.

--

Joe Barrios, Career Coach

Your Business Analyst Career, from Resume to Job Offer

www.joebarrios.com