“Why is business analysis so important?” — In fact, some software projects may go without business analysis, but they may take an unpredictably long amount of time.
In this article, I describe the role of a business analyst at each software project stage and share thoughts on how to become a successful business analyst.
Carnegie Mellon University (CMU), which is considered to be the best in preparation of IT specialists, gathered the following statistics about the influence of business analysts on projects:
Skills of a Successful Business Analyst
Soft skills are essential for an IT business analyst since such a job involves a lot of communication both with clients and development teams. Here is a list of soft skills that I consider important:
For those who are at the beginning of a BA career path, the most optimal way to gain soft skills is real-life practice. Theoretical knowledge can be beneficial, and some books I recommend to gain that knowledge are:
- Nonviolent Communication, by Marshall Rosenberg
- Start with No, by Jim Camp
- Everything is Negotiable!, by Gevin Kennedi
- Business Letters for Busy People, by J. A. Carey and J. Dugger
- The Inmates Are Running the Asylum, by Alan Cooper
Hard skills mostly depend on a project, but I would emphasize the following:
As for recommended theory:
- Software Requirements (3d edition), by Karl Wiegers and Joy Beatty
- BABOK
- Business Analysis Techniques, by Debra Paul
- Business Analysis, by James Cadle, Debra Paul, and Donald Yeates
- UML for the IT Business Analyst, by Howard Podeswa
- The User Experience Guidebook for Product Managers, by Marcin Treder
Business Analysis During the Project Lifecycle
PRESALE STAGE
Presale is a pre-contract project stage. It is the time when the client explains a business idea to the project team, asks questions, and decides whether the company meets expectations.
The role of a business analyst at this stage is to elicit high-level requirements, figure out who your clients are, understand their domain area, and estimate BA activities on a future project. There are also sales managers and tech experts who negotiate with clients, suggest the optimal tech solutions, and provide estimations for the development stage.
BA Artifacts in the presale stage that one must have are:
- RFP (request for proposal) document
- Proposal
RFP — Request for Proposal is the document provided by a potential client or a sales manager based on the received information from a client. The document should contain a brief explanation of a business idea, key functions, and features of a future product, terms, and budget.
The analysis of this information helps one to:
- Understand the basic ideas to meet the main requirements.
- Evaluate the possibility of implementation by the company’s tech experts.
- Estimate the time and efforts required for the implementation of future projects.
- Assess chances of success for future projects.
When analyzing the RFP document, business analysts should figure out answers to the following questions:
If the existing information doesn’t show the full picture, and we can’t answer most of the above questions, it’s recommended to ask the client additional questions. Here is an example:
Once the RFP analysis is done, a proposal is created and sent to the client.
How to estimate the time required for business analysis?
Business analysis as any other project activity should be estimated. It is required for both the client for budget planning and the company for better team allocation. There are two common estimation methods used by business analysts:
ROM (Rough Order of Magnitude) estimation that is well suited when the potential client makes a decision about the next steps. The error of such estimation varies from -25% to +75%.
Definitive Estimation, which is frequently requested at the development stage. The error varies here from -10% to +10%.
Things to consider during the BA estimation:
Design
– If there are any existing designs, BA experts may find out unique screens and establish the time required for the description of each screen.
– If there is no design, BA experts may divide the project into modules and estimate unique features in each module.
Previous experience
The more extensive the previous BA experience is the more accurate estimation he/she can provide.
Communication time
It’s important to consider the time spent on communication with the client and the team while clarifying requirements. The good practice is time logs into separate tasks that help compare the estimated and the real spent time.
Risks
BA experts allocate 10–15% of the total estimation for unpredictable situations like clarification of non-obvious requirements or a long wait for a client’s response.
IDEATION & PLANNING STAGE
A business analyst’s role in this stage is to interview the client, elicit and analyze project requirements, provide ideas, analyze the client’s domain area, find out killer features, and create the general project vision.
BA Artifacts at this stage involve documents like these:
- Project Vision & Scope — must have
- Competitors’ Analysis — nice to have
UI/UX DESIGN & PROTOTYPING STAGE
The main goal of the UI/UX Design and Prototyping stage is to create a visual representation and user interactions for a future product. The efficiency of results depends on how well a designer and business analyst understand user needs, abilities, and limitations. It is equally important to consider the project’s business goals and objectives while creating the UX/UI part of a future product.
The role of a business analyst is to focus on a general thrust of a project and conceptually consider the UX design before making the UI.
BA Artifacts are wireframes, mockups, and prototypes. Depending on a project, business analysts may create these materials together with UI/UX designers or by themselves.
Wireframes are low-level images of a product’s interface which schematically show its structure and defines the placement of images, text, buttons, tabs, the header, footer, etc. This artifact is not a ready-to-use design that might be changed or deleted. It is a rough visual representation that should clearly reflect the logic of a future product.
Mockups are a more detailed visualization of a future product. They contain many color schemes, visual styles, and fonts. This artifact may be delivered both by designers and by business analysts, depending on the case.
Prototype is a high-level presentation of a final product interface that supposes a simulation of user interaction. It is a clickable product prototype that fully shows what user actions lead to what output.
In order to create wireframes and prototypes, business analysts may use the following tools:
It’s important to understand that efforts performed by business analysts and designers should work together. While a business analyst is responsible for the business logic of a future product, a UX/UI designer conducts user expectations via visualization methods.
SOFTWARE DEVELOPMENT STAGE
Software development is one of the most time and budget-consuming stages during a project. It requires close attention to detail and analytical skills. Clear and detailed specifications allow optimization of the development process and minimize the need for changes on the go.
The role of a business analyst here is to describe a software system behavior, create and manage the project documentation, and support the relevance of requirements. BA workflow here may differ depending on the project. Commonly, business analysts choose one of the next two schemes:
BA Artifacts at the software development stage comprise:
Functional Requirements Document
Functional requirements may be formed in different ways. At MobiDev, we found the following methods useful:
- User Stories
- Use Cases & Use Case Scenarios
- UML Diagrams
- BPMN Diagram
User Stories are short descriptions of functionality pieces from the user perspective, where user roles comprise not only end-users but also administrator, editor, moderator, author, and others. The template is the following:
As a [user’s role in the system],
I want [some goal]
so that [some reason].
User Stories are often complemented with acceptance criteria that serve as metrics of expected output. Simply put, these are statements describing what exactly should be done to meet user requirements. For example:
The main goal of Use Cases & Scenarios is the description of behavioral requirements for system functionality.
Use Case is a description of how a user (actor) will interact with a future system. It describes how the system is expected to behave in response to certain actions from the user’s side.
Scenario is a sequence of interactions with a system intended to achieve the user’s goal and results in response to the user’s actions.
The next big thing in business analysis is diagrams. At MobiDev we commonly create Use Case and BPMN diagrams. The main goal of these diagrams is a visual description of a system behavior understandable for both clients and the software development team.
The most used diagramming tools in our team are:
Use Case Diagram is a visual representation of expected system behavior. It is a modeling technique which helps business analysts design the concept of system behavior from a user perspective, and then translate it into functionality solutions and development priorities. Here it is an example:
BPMN Diagram is a visual representation of business processes workflow. BPMN serves as Business Process Modelling Notation which is a standardized modeling language understandable for most non-technical stakeholders and software developers.
There are four main categories of elements:
- Common BPMN symbols (events, activities, and gateways)
- Connecting objects (sequence flow, message flow, and association)
- Swimlanes (Roles)
- Artifacts (annotations, groups, and data objects)
Here it is an example of a BPMN diagram:
Non-Functional Requirements
Non-functional requirements (NFR) describe the quality metrics of software performance. Simply put, the NFR document contains direct descriptions of software components that are supposed to ensure:
- Functional Suitability
- Performance Efficiency
- Compatibility
- Usability
- Reliability
- Security
- Maintainability
- Portability
Business analysts commonly use the ISO 25010 quality model in terms of software development requirements. The example of NFR might sound as follows:
“Any page on the website should have a maximum load of up to 1000 users.”
You can see the example of the NFR document here.
Software Requirements Specification
Software Requirements Specification (SRS) is a set of documents that contains the full description of the features, behavior, environment, and purpose for software under development. It may have any format and contain any type of requirements, depending on whom it is created for, development methodology, project standards, etc. Here are examples of SRS components:
As for tools used to create SRS documentation, we commonly utilize Confluence, as it helps to create a well-organized page hierarchy and use macros and formatting features. But it is also possible to create SRS in Google Docs.
QA TESTING
The role of BA experts here is to provide consultations and context of any requirements’ part helping understand how the system is expected to work.
Business analysts should also update requirements in case of any changes and monitor their relevance. When a project team presents a demo to a product owner, business analysts also directly participate in this process.
RELEASE
At the release stage, business analysts manage the implementation of an expected functionality, providing support to a project team, and preparing relevant SRS documentation to be transferred to a product owner.
Optional BA Activities
Aside from main BA activities during a project cycle, it’s also a good practice to make SWOT analysis and Gap analysis. These types of analysis help to compare the current result with the planned one, and figure out if the product is being developed according to the right roadmap. They are not 100% required, but in some cases, they can help to keep the project on the right path.
SWOT
SWOT analysis in BA practice can be used for the evaluation of a current state of a project or product. It is used to find out what the real situation is from an external perspective. It is a framework which includes the following evaluation attributes:
- Strength
- Weaknesses
- Opportunities
- Threats
Gap Analysis
Gap analysis is the discovery of possible objectives by evaluating if a currently developed functionality meets business needs or not. The Gap analysis involves four common steps:
- A current state analysis
- The ideal scenario identification
- Discovering of gaps and finding optimal solutions
- Creating and implementing a plan to overcome gaps
It may seem that a business analyst is a kind of a “Jack-of-all-trades” — and this is the truth. In the ideal world, business analysts are expected to have superpowers from the beginning of a career path. However, from my own experience, I’d say that only a real-life experience and a strong desire for self-development can help one become a successful business analyst.
Written by Iryna Gurskaya, Business Analyst at MobiDev
Full article originally published at https://mobidev.biz . It is based on MobiDev technology research and experience providing software development services.
