Business Analysis office
At RubyGarage we don’t start on projects until a business analyst has defined your requirements and figured out how to transform them into the most effective and realistic technical solution. Now you might be thinking, Why don’t we just skip the analysis and go right to coding? Here’s why we don’t:
Our BAO adds tremendous value to projects
Reduced development costs
Business analysis makes projects cheaper. But isn’t it a line item on the budget? It is, but business analysts reduce rework. Implementation is always more complex than it seems at first glance. As change requests come in and unexpected risks appear, software developers often have to rework the same code again and again. We prevent project cost overruns with our meticulous requirements engineering.
Reduced delivery time
Without business analysis preceding development, teams tend to spend many hours figuring out what it is they actually need to deliver. And because they also want to get the product out the door as soon as possible, quite often they go in the wrong direction. As a result, they end up having to go back and make changes to what they’ve already built. Business analysis helps teams focus on the right requirements and reduce unnecessary rework.
Effective problem-solving
In Agile software development, new needs and requirements are bound to be discovered during implementation. Our business analysts are involved in a project throughout its development life cycle. They facilitate problem-solving and help teams address newly discovered constraints without all the hassle. By supporting project implementation, they make sure that what’s being built meets stakeholders’ expectations.
Increased returns
Because BAs analyze your current business processes to understand your workflow, they help you discover new business benefits. Sometimes, just a small tweak in the system’s functionality can add a lot of value to your business. Features that add the most value should be implemented first. Having a business analyst on the team makes the development process more predictable and more successful and increases the return on investment.
How business analysis is done at RubyGarage
Quality software is the result of well-executed design and development, which can only happen if requirements are accurate and complete. Here’s how our business analysts at RubyGarage define project needs and help our clients find the most cost-effective solutions.
Stage 1
We dive into a project to discover our client’s needs, operating processes, problems their product is going to solve and for whom, and metrics that we’ll use to see if the solution has been implemented successfully. Business modeling ends when we’ve outlined the vision of the project and are ready to define the requirements.
Stage 2
At the stage of requirements engineering, we define user roles and a product feature set, create user activity diagrams and epics, decompose those epics into user stories, and build a data model. We also define acceptance criteria that a product must satisfy and get our client’s approval to move the project forward.
Key tools, techniques, and deliverables
We use lots of methods to visualize requirements and align our vision of the project with that of the project’s stakeholders. Here’s a quick overview of our business analysis toolkit and key deliverables from our Business Analysis Office:
Business Model Canvas
We share a Business Model Canvas with our clients to get a clear understanding of the problems that their products will solve. For our startup clients, we use Lean Canvas, an adaptation of the Business Model Canvas. The canvas describes:
- Key value propositions
- Customer segments
- Competitive landscape
- Pricing model
- KPIs
Operating Model Canvas
The purpose of the Operating Model Canvas is to describe the value delivery chain and explain how an organization operates. This framework helps us discover how the current operating strategy can be optimized with software. It shows:
- Parties involved in production and delivery
- How information is exchanged between different business units
- Locations and assets that are critical for delivering value to customers
Requirements architecture
After a series of interviews and workshops as well as brainstorming sessions and questionnaires, we start architecting the requirements. To structure and organize requirements in an understandable and elegant format, we use the following techniques:
- Business Process Modeling and Notation (BPMN) in the form of flowcharts and UML activity diagrams
- Prototypes in the form of mind maps, paper interfaces, low-fidelity prototypes, and wireframes
Requirements specification
We describe detailed project requirements in the form of a specification that’s shared with all stakeholders. With this document, developers know what to develop and testers know what to test. Everybody has everything they need to perform their job. The specification includes:
- User roles with goals and activities for each of these roles
- Functional specifications with a feature breakdown list, epics, and user stories
- A data model with entities, their attributes, and relationships among entities
- A data access diagram with different types of permissions for different user roles
Requirements validation
Once all requirements are clearly defined, our business analysts need to complete one more step to be able to move the project forward: they need to make sure the requirements are aligned with the business needs and operating processes. This involves all stakeholders and consists of the following activities:
- Defining acceptance criteria
- Analyzing the specification document
- Analyzing and managing risks
- Getting feedback from clients