Requirement Analysis and Pre-sales Consulting: A Business Analyst Approach

In the present world of Software development, a business analyst as a ‘Pre-sales Consultant’ plays a key role in identifying the client’s business objectives and bringing out the finest solutions. A business analyst should always step into the customer’s shoes to investigate their problems and generate solutions that are so-called as requirement specifications. All the requirements gathered from the client are the inputs to the developers for creating the application. Therefore, requirement gathering is a cautious and risky task. Being a business analyst you would be always working with risks; if not it is a strange thing.

This article helps you to learn about the steps involved in the requirement management and analysis before a project kickoff and how a business analyst deals with that. Here we go!

The requirement management life cycle usually starts with your sales team and ends up with a business analyst. The steps involved in requirement management life cycle as follows:

1. Understand your customer

In most cases, failure in closing a potential prospect in the software development industry happened because of not fully understanding the customer’s requirements and their budget. Each customer is different and their needs are dissimilar, your customer can be a tech-savvy or a complete tech illiterate or can be even a programmer. So as a business analyst it is your responsibility to deliver according to your customer.

Approaches towards each customer will be poles apart because there is no default thumb rule to deal with your customer. It is something like, you are using technical jargon while talking to a customer who is a programmer or you are using simple layman terms to a customer who is not that technically good.

Sometimes customers would be describing a complete gaffe product idea with lacking sense, don’t feel the bitterness, you can teach them the right solutions for their problem. Sometimes a customer would have an overall business idea about the main purpose of the software, but they may not be aware of how to execute it. Here also you can teach your customer by learning the customer’s business and finding its opportunities.

In some scenarios, customers will have a large project plan to be built, which refers to an existing application working successfully in the market, that too within a minimal budget. In these cases, educate your customer about developing a Minimum Viable Product (MVP) first, and let’s watch out how that works with the business and then amplifying it in the next phases. It is always better to create an MVP first with adequate features to satisfy early adopters and complete the remaining set of features after considering feedback from the application’s initial users.

2. Collect Software Requirements

If you are in a hotel and order something and you have received something different. Even it was close or similar to your requirement, though I have to return my food back to the kitchen to get it fixed. It’s just a waste of time for me and for the cook. This happened because the waiter hasn’t listened to me properly or he has noted down something different. This same experience will happen to software development as well. Here, similar to the attender if a business analyst took an inaccurate requirement gathering it would affect the whole process, therefore listening to the customer and collecting their requirements is careful as well as a serious task.

The total quality management’s (TQM) notion of “prevention rather than correction’’ can be applied to the software development life cycle (SDLC) successfully. Requirement Management covers the first phase of the SDLC, therefore it is important to collect the requirements in the right manner so that we could minimize corrections and risks in the upcoming phases.Sometimes in Agile, there can be situations where the component built by the developer is not exactly what the requirement specified. How can that be possible after hours of discussions? The answer is simple, it’s just human nature! What someone hears can be interpreted differently by others. Therefore listening is a topmost skill for requirement gathering.

3. Domain / Market Research

For collecting the requirement for a Cargo Management Application, we should think of ourselves as a delivery boy or an end-user who is using the application. For nourishing and application a business analyst should acquire immense knowledge on that particular domain. Every industry would have its own jargon and technical things, so learn it before drilling down the features.

Domain research is the process of acquiring information about your client’s business, targeted audience, and determining how the customer is viable and useful by your software. Domain research also tells you what is trending now in the industry and what influences the users to use this application so that we can advise the customer if needed.

4. SWOT Analysis

As the name ‘Analyst’, it’s important to analyze before getting into one project, for that SWOT analysis is important. SWOT analysis will help to find your company’s strengths, weaknesses, opportunities, and threats with respect to the current project requirement.

If you get a project requirement, initially perform a SWOT analysis because it will list out all the strengths, weaknesses, opportunities, and threats of your organization and which can reduce the uncertainties in the future.

SWOT analysis for new software requirement as follows:

These types of analysis will help you to understand where you do good to address, where you’re lacking, to reduce risks, and to take the considerable possible advantage of chances for victory. It also evaluates many activities of the project in order to improve the potential as well as to evaluate risks to determine the most suitable way of mitigating those risks.

5. Drill down the scope and features

A feature list is the summarized document that lists out the specifications of the proposed software. A project is divided into modules and then it is drilled down into features that together make software. On top of that, you would cover your user interface visions as well as what technologies should be used here. If it is Agile development, you can use the feature breakdown structure approach (FBS) and for Waterfall development, it’s better to breakdown the work rather than features in a Work Breakdown Structure approach (WBS).

Ultimately the objective is the same to break down the complete application and to deliver business value frequently in an incremental manner.

6. Conduct valuable Brainstorming sessions

Once the features are drilled down and user flows are fixed, next you could conduct a meeting with your colleagues to discuss your approach. A brainstorming session is must and important because it uplifts open and ongoing participation to solve a problem and will sow the seed with innovative ideas. The brainstorming session will definitely help you to get a large number of ideas in a very short time, which can be filtered and amalgamated to your feature list.

7. Wireframes, Mockup and Prototyping with UI/UX objectives

A wireframe is a software UI/UX blueprint or a mockup in a visual way. We usually draw static wireframes with expressive, communicative, and visual UI because it represents a realistic model of what the final product will look like. A wireframe will communicate the functionality of the application to the client and it will make sure the client’s requirement and your understanding are the same. Wireframes will also help the clients to understand the structure and functionality of the application without getting sidetracked or swung by design elements such as color combinations, images, videos, and other animated UI functionalities.

Major wireframing tools that commonly used are Sketch, Balsamiq, Figma, Axure, Adobe XD and Moqups, etc.

8. Documentation of Requirements

Documenting the software requirements is important because it ensures stakeholders and we are on the same page of the application in terms of purpose, goal, scope, functional requirements, and constraints. Software documentation is mostly a lengthy and time-consuming process because short documents are more vulnerable to errors, misinterpretation, and inconsistency. So it is always important to specify each feature and functionalities in the document which will avoid fallacy between you and the client.

A Software Requirements Document (SRD) also known as Software Requirements Specifications (SRS) is a document that states the features and the intended characteristics of the application. This document states our understanding of the client’s wants and dependencies as well as any constraints on the application.

In most cases, the Feature List document and User flow document are initially sent to the customer in order to verify the requirement and the scope. Then the documents like Approach documents, BRD, SRS, FRS, etc are sent later before the kickoff of the project.