Requirement Analysis and Pre-sales Consulting: A Business Analyst Approach
Get more insights on how a Businesss Analyst approaches towards the Client’s Requirements
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.
- What your company is good at
- Key Point Indicators(KPIs) that set your business apart
- Availability of skilled and knowledgeable in-house resources
- Tangible assets such as capitals, Intellectual properties, proprietary technologies, etc.
- Capabilities that your company lacks
- Competitor activities that outperform yours
- Limitations of your resources
- Lack of clarity in your USPs
- Low competitor activity in your turf
- The popularity of your company
- Increased demand for your product or service
- Emerging need for your product or service
- Unstable regulatory environment
- Negative customer reviews
- Unpredictability in customer attitudes towards your company
- New Competitors
SWOT analysis for new software requirement as follows:
- Good domain knowledge due to past experience in delivering similar projects.
- The Client is well sure of what they need and what they don’t.
- Is the budget assigned to this project sufficient?
- Smart working ergonomics and good peer to peer relations with the employees.
- Is our company have skilled developers who know the new technology that clients require
- Does the part of the project need to be outsourced
- Is the proposed schedule of project delivery is realistic
- This project can be Golden feather to the company
- The company can showcase this client in the future.
- Partnering with this client will increase the brand value and moral of the company. The brand value will attract skilled professional to the company
- More projects can be received from this client in the future.
- Can we dominate our competitors with this project
- Could national or global economic conditions affect the project
- Any key employees proposed to this project are in notice period or going for long leave.
- How reliable is the client and do they drop the project in the middle.
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).
- It should be completely relevant for the software
- It should be estimable
- It should provide business value
- It should be small enough to fit in a sprint or iteration
- It should be testable as well
- XP (Extreme Programming) uses the term User Stories to describe features.
- Scrum uses the term Product Backlog item to narrate features.
- DSDM (Dynamic systems development method) uses the term Requirement for features
- Agile UP (Unified Process) uses the term Use Cases to mention features.
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.
9. Freezing the Requirements
Freezing a project requirement is significant because it helps in moving the project ahead towards the deployment. Freezes can be different types like specification freeze, feature freeze, code freeze, UI/UX freeze based on the project.
In Agile, freezing is done before a sprint starts and it will help you to meet the roadmap. Whereas in Waterfall freezing is done before the kickoff.
If it’s necessary, the client can unfreeze the requirement but it will incur more cost and time of the entire production team and it will delay the project delivery. Thus, always discuss and authenticate with your client before freezing the requirement.
Get connected with our offshore development center
GET QUICK QUOTE