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.