Business Analyst Role and Deliverables for Software Development Projects
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 and it’s not only about the creation of initial documentation to launch software product development. So, in what way can BA (business analyst) bring value to the project?
First and foremost, business owner might have a few concerns about the structure of the workflow, the timeline, the connection with the team and the general ability of the company to understand business goals in combination with technical aspects of implementation. For this reason BA analyzes, structures and supplements the client’s view of the project so that it`s clear both for the team and for the client.
Another aspect of BA`s expertise is to ask questions that can encourage the client to think through some business/product details more precisely. Transparent communication is one of the primary steps for future project to go in the right direction and simplify the process for the customer – and this is expected from BA. With that said, throughout the project BA specialist:
Saves the Client’s time
- Builds a complete process of requirements elicitation and documentation. It means that having knowledge of both the technical aspects and business processes BA can write the required documents so that the client doesn’t have to do it:
- Creates all requirements documents to communicate the aims of a project in a clear, concise way – this ensures that all participants are on the same page and no essential details are missing.
- Clarifies requirements for the team, so the client doesn’t have to spend a lot of time clarifying requirements to the development team.
- Organizes requirements prioritization – BA is a unique specialist who defines requirements from the essentials to nice-to-have, so he/she clearly understands which requirement may provide the most value to the business.
Saves the Client’s budget
- Optimizes efforts of the dev team, focuses the team on functionality implementation rather than business requirements clarification. BA works ahead of the developers team, so the requirements are clear and there`re no blockers for developers to focus on their job.
- Minimizes the number of change requests for ongoing features while developing. The document requirements are checked upfront by BA, so the risk of rework is minimized.
Adds extra value
- BA minimizes the impact of different time zones between the client and the development team on the project. Since the BA has a higher level of business understanding than the development team, he/she can advise the dev team immediately without waiting for clients to wake up.
- The client receives reasonable suggestions from BA. They have experience in several domains and knowledge in technology trends and can extrapolate their knowledge to the client’s business. That being said, they may highlight some obvious but missed cases. In addition, BAs are proficient in brainstorming techniques.
- BA plans and estimates the development of new features more precisely. Having ready-made requirements and the ability to ask a BA for advice, the developer can give more accurate estimates. So, releases` planning becomes easier.
- BA simplifies the requirements tracking process by adding integration between jira tasks, requirements, design and change requests. The requirements documents have a hierarchy structure, so the simple connection of devs jira tasks with the requirements tree allows the client to see the progress of the development more precisely.
While communicating with the BA, the customer can be ensured that everything has the right set up for the future work – we understand the issues mentioned above and can provide the needed documentation for a more structured view of the project.
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.
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:
- What is the strategic intent of the software product?
- What problem(s) will the product solve?
- What benefit(s) will the product offer compared to competitor’s products?
- Who will use these benefits?
- How will the software product’s success be measured?
An example of the project vision document:
Here’s what may be achieved with a well-defined project vision:
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:
- A set of user stories for each piece of functionality
- Acceptance criteria for each user story
- Visualizations for each user story
An example of the functional requirements document:
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:
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.
An example of the non-functional requirements document:
What may be achieved by well-defined non-functional requirements:
- Assurance of usability and effectiveness of the entire software system
- Identification of mandatory requirements imposed by standards and adjusting the system to meet them
- Defining of restrictions and constraints for the software development process
- Assurance about the compliance of the system with users’ environment
- 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.
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?
Want to get in touch?
contact us
