Business Analysis Deliverables List For Software Development Projects

Olena Gorban,
PM/BA Team Leader at MobiDev

Having an IT project manager involved in a project implies the opposite of what most business people are used to thinking. You may say: “Let’s start from the business analysis stage.”

But why is this? And is it the best approach? This often occurs because business analysis in software development is not only about the business itself.

The story below will help you to understand what I am talking about.

Sam, the managing director at a San Francisco mall, was meeting with Oliver, the IT project manager at a software development company.

“We are looking to build a smart parking solution for the mall.”

1. The system should track available and occupied parking spaces and show users which spaces are available.

2. Users should have a mobile app installed to search for available spaces, automatically charging them once they choose a suitable location.

“As we’d like to launch it this year, let’s start the development process quickly. What kind of budget we should allocate for this solution?” — Sam said.

“That’s great, Sam. Should we outline requirements for the first rough version of a system, and we will start as soon as possible?” — Oliver asked.

“I just listed them all, didn’t I?” — Sam asked a bit astonished.

You might think that this sounds impossible. But it doesn’t.

It’s all based on a true story. We face such cases quite often-the absence of requirements influences the success of a software development project.

Next comes the business analysis process in the context of designing the software product. It’s not only about the creation of initial documentation to launch software product development.

Business Analysis Documents

The core benefit of this analysis is setting ongoing processes to update documentation with new features during development.

Information technologies and business processes that change daily have a tangible effect on our everyday life. Just look at Netflix, Uber, and Airbnb, and we can see how each one’s industry under went radical changes to their models in recent years. It’s reasonable to assume then that the rise of digital BA is inevitable.

In this article, I will describe how a business analyst can add value to software development projects by getting a clear vision of a future software product and optimizing the development team’s workflow.

Project Vision

The first thing to start with is the creation of a project vision document. And while there are several different definitions available-to our company, “project vision” means a general description of the product in the context of business goals. This 2–3 page document allows for a brief but substantial project overview.

The process is as follows: the product owner describes their own vision and business goals of a future software product, and then a business analyst helps to structurize and complement these goals.

All of the data included in the project vision should answer the following questions:

1. What is the strategic intent of the software product?
2. What problem(s) will the product solve?
3. What benefit(s) will the product offer compared to competitor’s products?
4. Who will use these benefits?
5. How will the software product’s success be measured?

Here’s what may be achieved with a well-defined project vision:

1. Fewer miscommunications
2. Сlear vision of a future software product
3. Determination of non-defined product features
4. Documentation and structuring of product goals
5. Creating the basis for ongoing planning of software architecture
6. Helping all software development teams understand a project’s goals and strategy

Functional Requirements

The second business analysis document after project vision is the functional requirements. Depending on the product goals, functional requirements can come in a variety of different formats. The most common ones include:

• User stories and acceptance criteria
• Use cases
• Wireframes and sketches
• BPMN models
• UML diagrams

Functional requirements enable an understanding of how the software product will interact with its users. This section answers the question: “What will the software product do to meet user needs?”

From our company’s experience, user stories are incredibly useful for most of our clients. They help to define user goals and business benefits altogether in one concise statement.

User stories are short descriptions of the software product’s functionality from the user’s point of view. They consist of the following:

“As a […], I want to […] so, that […].”

Here’s an example of a user story:

As a user, I want to view all music available on the device in order to select and play it.

Our functional requirements document contains:

1. A set of user stories for each piece of functionality
2. Acceptance criteria for each user story
3. Visualizations for each user story

All functional requirements should be specific and measurable, which is why we have the “Acceptance Criteria” columns. The criteria for each user story provides a better understanding to software development teams about whether a requirement has been met.

Working with MobiDev client’s projects, we created business analysis artifacts involving UI/UX designers and software developers.

Designers help to define requirements through sketches, wireframes, flow charts, and user personas.

Software developers recommend the optimal technology solutions that will influence the product. Technical analysis may run either parallel to or after the business analysis stage.

Well-defined functional requirements may achieve:

1. A clear vision of future software product functions
2. Beginning estimations for the UI/UX design and software development stages
3. An opportunity to choose optimal technical and design solutions for a better realization of a software product’s functionality
4. Concise documentation for guidance during software product design, development, quality assurance, and project vision stages
5. Avoidance of discrepancies between expectations and results when working on software functionality

Non-Functional Requirements

Along with the functional requirements document, we create the non-functional requirements document. It describes how a system is going to work and contain software product technical characteristics, system properties, and the product environment.

At MobiDev, we create non-functional requirements once we have a list of software product functions in a user story format. This document tracks measurable and clear terms that define the system’s constraints and properties.

It’s good to involve a QA specialist here. They help to specify the testability of requirements and the quality assurance criteria for future software products.

What may be achieved by well-defined non-functional requirements:

1. Assurance of usability and effectiveness of the entire software system
2. Identification of mandatory requirements imposed by standards and adjusting the system to meet them
3. Defining of restrictions and constraints for the software development process
4. Assurance about the compliance of the system with users’ environment
5. Reduced development rework

Project vision, as well as functional and non-functional requirements, are required business analysis deliverables, but business analysis is not limited to them. There are a variety of custom documents provided separately for each particular project.

Competitor’s Analysis

The competitor’s analysis is an example of additional deliverable that the business analysis stage provides.

It analyzes the main features, advantages, and disadvantages of existing software product offerings. Companies can improve their own solutions through such an investigation.

A well-defined competitor’s analysis may achieve:

1. A general vision of already existing solutions
2. Insights about additional improvements in a current solution
3. An understanding of what solutions worked and didn’t work

All the business analysis deliverables mentioned above are not strict and universal rulesets. Every project we run is unique and requires different approaches.

Some of our clients have already approached us with pre-defined requirements. In these cases, we helped modify them during the development stage.

The takeaway is that business analysis in software development is not about the business itself-it’s all about realizing the solutions while taking into account current business goals, problems, and limitations. The result is not only the optimization and structuring of a software development process, but also a well-designed software product that meets user needs.

Of course, there are wonderful software products built without any analysis and documentation that use only raw ideas, enthusiasm, and brilliant skills. But is this approach viable in the modern tech world where competition is fierce?

Full article originally published at https://mobidev.biz.