Paul Mulvey

In the business analysis profession, there is no one-size-fits-all solution. As you develop your project type, you need to know all the tools available to you; think through all the variables related to the people, project characteristics, and the process; and then determine what tasks you need to complete. Data warehouse projects A data warehouse is a solution that brings together information from diverse sources and puts it in a format that stakeholders can easily access when making complex business decisions.

The data flow diagram is a helpful diagram for business analysts that shows the parties and systems involved with a particular process, as well as the data and interfaces involved when dealing with external agents (those parties or systems that exchange information with the project but over which your project has no control).

In prototyping, you create a model of the proposed solution. In business analysis, a prototype, or mockup, generally means a representation of a computer screen and examples of how the user will interact with the application to accomplish a task to solve the business problem. The business analyst creates the prototype, usually with help from the technical team.

Verification is what most people think of when they hear the word testing — it’s the process of testing whether a business analysis solution does what it’s designed to do. During verification, the testing team (which may consist of developers, quality assurance [QA] people, and some business analysts [BAs]) put the software through its paces to both confirm that it operates as expected and ensure that it conforms to the design specifications laid out earlier in the project.

In a business analysis report, you should have a subsection of the requirements section dedicated to external agents and actors so that you can better zero in on that aspect of the business. An external agent is the first person, organization, or system identified in requirements. Typically identified during the very early scoping part of a project, external agents are those with which the business area interacts.

Your unique responsibility as a business analyst is to write and communicate excellent requirements. This job is important because requirements consumers depend on the requirements in order to effectively design and construct solution components. Excellent requirements leave no room for interpretation, create no cause for confusion, and omit no critical detail.

Not only do you need to identify the sources within an organization that you need for your business analysis, but you also need to choose an approach with which to elicit information. You can use 11 major elicitation techniques to draw information from your stakeholders: Document analysis: Look through existing documentation to figure out questions you want to ask stakeholders during your elicitation sessions.

Aside from fulfilling a business analyst (BA) role at a company, you may have the opportunity apply your various business analysis skills to other roles. You can parse out individual business analysis skills to make yourself more marketable, take advantage of opportunities, and meet a company’s specific needs for growth and improvement.

When verifying and validating solutions, you perform a requirements review, a structured audit in which you give participants the opportunity to ask questions and make suggestions in order to improve the quality of the product being reviewed. Keeping the requirements review session moving forward is the facilitator’s job; because you may be wearing that hat during the meeting, here are some tips for conducting the requirements review session: Put on a thick skin when documents you authored are being reviewed.