Business Analysis Deliverables List For Software Development Projects
By 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, by saying: "Let's start from the business analysis stage." This is because business analysis in software development is not only about business itself.
The story below will help you to understand what I am talking about.
Sam, the managing director at 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 slots and show users available places.
2. Users should have a mobile app installed in order to search for available slots, automatically charging them once they choose a suitable place.
As we'd like to launch it this year, let's start the development fast. What kind of budget we should allocate for such a solution?" - Sam said in one shot.
"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.
"But I've just listed them all, haven't I?" - Sam asked a bit astonished.
You might think that this sounds impossible. But no. It's all based on a true story. We face such cases quite often - the absence of requirements influences the project success.
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 the product development.
Business Analysis Documents
The core value of this analysis is setting proper ongoing processes to extend and update documentation with new features while the development is being done.
Informational technologies have a tangible effect on our everyday life, as well as business processes that are being transformed day-by-day. Thinking about Netflix, Uber or Airbnb, we see how industries radically redefined their models in recent years. Taking this into account, it's reasonable to assume that the rise of digital BA need is predictable.
In this article, I will describe the business analyst role in software development projects. I want you to know how to get a clear vision of a future software product and optimize the development team's workflow so as not to waste time and money.
The first thing to start with is the creation of a project vision document. There are different definitions, but in our company, "project vision" means a general description of the product in the context of business goals. Typically comprised of 2-3 pages, this 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 product, and then a business analyst helps to structurize and complement these goals.
All the data included in project vision should be answer the following questions:
1. What is the strategic intent of the software product?
2. What problem will the product solve?
3. What benefits will the product give compared to competitor's products?
4. Who will use these benefits?
5. How will the product success be determined?
Here it is an example of the project vision document:
What may be achieved by a well-defined project vision:
1. Fewer miscommunications
2. Сlear vision of a future software product
4. Documentation and structuring of product goals
5. Creating the basis for ongoing planning of software architecture
6. Understanding of a project's goals and strategy by all software development teams
The second business analysis document being created after the project vision are the functional requirements. Depending on the product goals, functional requirements can come in a variety of different formats. The most common are:
• User Stories and acceptance criteria
• Use Cases
• Wireframes and sketches
• BPMN models
• UML diagrams
Functional requirements allow to understand how the software product is going to interact with its users. In simple terms, it is the answer to the question: "What will the product do to meet user needs?"
Taking into account our company's experience, user stories work well for most of our clients. They help to define user goals and business benefits all together in one concise statement.
User Stories are short descriptions of the software product's functionality from the user's point of view. As a rule, they are made up as follows:
"As a [...], I want to [...] so, that [...]."
The example of the 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. Set of user stories for each piece of functionality
2. Acceptance criteria for each user story
3. Visualizations for each user story
An example of the functional requirements document:
All functional requirements should be specific and measurable. That is why we add the "Acceptance criteria" columns. Criteria for each user story gives a fuller understanding to software development teams about whether a requirement has been met.
Designers help to define requirements through sketches, wireframes, flow charts and user personas.
Software developers recommend optimal technology solutions that will influence the product. Technical analysis may run either parallel or be initiated after the business analysis stage.
What may be achieved by well-defined functional requirements:
1. Clear vision of product functions to be released
3. Opportunity to choose optimal technical and design solutions for better realization of a product's functionality
4. Concise documentation to be used as guidance during product design, development, quality assurance and project vision stages
5. Avoidance of discrepancies between expectations and results when working on software functionality
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 user stories format. This document keeps only measurable and clear terms which define the system's constraints and properties.
It is good to involve a QA specialist here. He/she helps to specify the testability of requirements and the quality assurance criteria for future software products.
An example of the non-functional requirements document:
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 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.
The competitor's analysis is an example of an additional deliverable that may be provided during a business analysis stage.
It allows analysis of the main features, and the advantages, and disadvantages of existing software product offerings. By getting such a vision, it's possible to improve own solution.
An example of competitor's analysis document template:
What may be achieved by a well-defined competitor's analysis:
1. General vision of already existing solutions
2. Insights about what else might be improved in a current solution
3. Understanding of what solutions work or don't work
All the business analysis deliverables mentioned above are not strict dogma used for each case. Every project we run is unique and requires different approaches.
Some of our clients have already had requirements organized when we started our cooperation. In such cases we just helped to modify them during the development stage.
The important thing I'm trying to explain is that business analysis in software development is not about the business itself. It's all about solutions realization, while taking into account current business goals, problems and limitations. The result is not only optimization and structuring of a software development process but a well-designed product that meets user needs.
Of course, there are wonderful products built without any analysis and documentation, using only raw ideas, enthusiasm and brilliant skills. But does it make sense in the modern tech world?