• July 29, 2020 4:43 am
  • by Adith Suresh, Business Analyst

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

  • July 29, 2020 4:43 am
  • by Adith Suresh, Business Analyst

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.

Get expert help for your IT stratergies

Check our IT consultation service

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.

Here, the Skate board is the MVP

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.

S
Strengths
  • 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.
W
Weaknesses
  • Capabilities that your company lacks
  • Competitor activities that outperform yours
  • Limitations of your resources
  • Lack of clarity in your USPs
O
Opportunities
  • 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
T
Threats
  • Unstable regulatory environment
  • Negative customer reviews
  • Unpredictability in customer attitudes towards your company
  • New Competitors



SWOT analysis for new software requirement as follows:


Strength

  • 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.

Weakness

  • 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

Opportunities

  • 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

Threats

  • 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).

The features should meet certain parameters like:

  • 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
Different project management methodologies use different terms to refer to the features.

  • 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 in Touch with Us

Guaranteed Response within One Business Day!

Latest Posts

March 24, 2024

How to Manage Communication & Collaboration With Your Offshore Software Development Team

March 10, 2024

What Is the Importance of Software Maintenance

February 29, 2024

How Agile And DevOps Speed Up Product Development

February 16, 2024

Custom Software Development: The Challenges & Solutions of Cybersecurity

February 06, 2024

A Comprehensive Guide to Hiring the Right Mobile App Developers

Subscribe to our Newsletter!