Business Analysis

Business analysis is an important, but sometimes overlooked, function within any IT organization. Stakeholders in a business have various ideas about problems they need to solve, and in some cases have ideas about how to solve them, but they may not know much about technology or what is feasible. Software developers are good at building systems but aren't always good at understanding the core business problems and how solving them will bring value. This is where a Business Analyst (BA) comes in. A BA specializes in identifying and defining business needs and determining solutions to business problems. These solutions often include a software component, but may also consist of process improvement, organizational change or strategic planning. A good BA can speak the language of the business and also speak the language of technology, functioning as a translator between the two.

SwitchLane has a track record of providing BA consultants to clients that either don't have this skillset in house, or who need to supplement their own team for a specific project. Our consultants have experience doing this in the context of traditional waterfall processes as well as in the context of more modern agile processes. We focus on separating the definition of requirements (which define a set of problems) from solutions (what should be built or done to solve those problems), which is often muddled together. The tabs below show more information about some of the core functions our BAs perform for clients.

• Requirements
• Functional Design
• Process Engineering

A key step in every software project is defining the requirements. What problems is the business trying to solve? Why are these problems important? Who needs a particular problem solved? These are all important questions to ask, and a BA excels at asking questions to elicit this kind of information as part of meetings with the business stakeholders. Once they have the problem defined, they also excel at clearly and consisely documenting the requirements so that other people who weren't involved in the meetings can understand.

A popular method of documenting software requirements involves writing what are called user stories, using the general form shown above. The "who" is most often some type of user. The "what" is the crux of the requirement, something the system needs to do or a feature it needs to provide. The "why" is the justification for why the "what" is needed, and thinking this through will often cause you to change the "what" a bit. It can also cause a BA or a developer to consider different possibilities for the solution because they know "why" the what is needed.

Once requirements have been documented and the problems to solve have been defined, it's time to solve them! When it comes to building software, this involves designing a solution from both a functional standpoint (what should screens look like, what should happen when a certain button is clicked, etc) and a technical standpoint (what technologies will be used, what responsibilities should a certain component have, etc). BAs often take the lead in documenting the functional design for a solution and working with architects and developers to ensure that what they envision is technically feasible to implement.

In many cases, a BA will produce screen mockups that demonstrate approximately what a screen should look like. These are typically "low fidelity" and meant to convey concepts as opposed to the exact look and feel, colors, etc. Once stakeholders approve the mockups, a BA will typically add narrative descriptions for the developers to describe how things should work, where a link should take the user, etc.

In addition to defining requirements and design for software solutions, BAs often document processes and suggest ways to make processes better or more efficient. These processes often include steps that involve using software but they also include steps that may have nothing to do with software at all. Defining and refining processes becomes very important when many people have to perform different functions in concert to achieve a particular goal or outcome. Documenting the processes also becomes valuable for training new people as the size of your team grows.

The most effective way to document processes generally involves drawing diagrams. One of the more common types that a BA uses for this is called a swim lane diagram. Each role that a person will play in the process gets a "swim lane" which is a row or column. Then, flowchart shapes are used to describe the various steps and decision points in the process. Placing a shape within a particular swim lane depicts which type of person is responsible for a given step.