I have worked in IT for more than 20 years and at the beginning of my career, there really wasn’t a defined business analysis role. Once it became a defined role, we were taught to “gather” requirements. This word is out of sync with what we do today as business analysts. However, there are many companies still using this term in their job descriptions and recruiters still using it in their search for the best candidates.
Business analysts may still need to use this term when job hunting, but when it comes to interviews and doing our jobs, we need to ensure that we’re eliciting requirements, not just gathering.
Most of my clients tell me they have a difficult time understanding how to get started when it’s a new product. because there’s nothing already built, they don’t know where to begin. While this may be a little more challenging than a project for enhancements to an existing application, it can also be more fun. Yes, i did say fun. if you aren’t enjoying your job, then it’s either the wrong company, the wrong culture, or the wrong job for you.
Let’s assume it is the right job for you and you do enjoy doing it, but you feel unsure in there “new product” situations.
I like the way Joe Barrios (a fellow BA career coach) explained it, but with one exception. Joe indicates you should ask a question reagrding “how”. Keep in mind that this is at the very beginning of the analysis process when you are speaking at a high level with executives, sponsors, etc. you aren’t “in the weeds” yet. My suggestion is to leave the how question until you are deeper into the requirements discussion – and then it should be focused on functionally how, not back-end systems/architecture focus.
Joe said 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.
You need 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.
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.
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.
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.
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.
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.
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.
via Joe Barrios, Career Coach |www.joebarrios.com | How should the Business Analyst begin the requirements elicitation process for a new product or solution?