Kupe Kupersmith

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 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.

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.

After the business has decided a problem is worth pursuing in its analysis, you should create a problem statement. A problem statement is the conglomeration of four key elements into one expression to convey the issue at hand: Root cause problem Impacted stakeholders/product users Impacts of the issues Effects a successful solution must include The problem statement is a critical component of a project’s statement of purpose or charter.

“Why” is such a powerful question that it’s the basis for a root cause analysis technique called the 5 whys. The thought is that by the time you ask a stakeholder “Why?” 5 times, you generally have arrived at the root cause. Consider this example: Q: “Why did you submit a purchase requisition for $750?” A: “Because we need to purchase 150 staplers!

When you write business and stakeholder requirements in your business analysis, you want to capture the problem or opportunity and explain what has to be done (rather than how you’re going to solve the problem or take advantage of the opportunity). As the person performing the business analysis, you’re generally the main person capturing the business requirements because you have a unique ability to drill into the real problem or opportunity rather than just gather a solution request (which is why your process is called “elicitation” and not “gathering”).

Business requirements are derived from the needs of the business; a good business analyst will recognize that they’re the things that must be in place to benefit the business or enterprise as a whole. They characterize and quantify outcomes desired for the business, and document what business the business decides to be in, what products the business will offer, or what markets the business will expand into or exit.

Before you discount or leap to an electronic or particularly feature-full tool for your business analysis, consider how specific the analysis or collaborative exchange needs to be and whether the technology you have in mind is truly the vehicle to get you there. Don’t make the mistake of falling in love with features you don’t need.