Business Analysis Tools and Techniques

After the Explain many times, many ways post, I’ve received a lot of feedback.  In this post, I will follow-up on the most popular question:

“Based on the different learning types and stakeholder needs, what business analysis methods or techniques would be the best for each person?”

For each stakeholder from the original image that learns and understands in their own way, let’s look at sample tools and techniques to achieve a shared understanding of requirements.

Of course, this will not be a one-to-one relationship. Some stakeholders might appreciate a few of these methods, and each method will have its fans. Different stages of the business analysis process may also call for different methods. However, each stakeholder should find something suitable within easy reach.

---

Let’s now drill down and give the business analyst a few choices for explaining and clarifying requirements to each of the personalities:

Use a requirements walkthrough or a one-one meeting to:

• Recap key requirements
• Focus on complex requirements – review them in detail
• Use scenario matrices, diagrams or business rules tables to supplement complex requirements
• Use a decision table to review and confirm complex business rules
• Use a decision tree to explain and validate a decision table or its fragment
• Ask the stakeholder to explain the requirement to you – do your interpretations match?

Validate business problem, requirements and scenarios through data analysis:

• Use existing business intelligence insights to prove or disprove hypothesis (or to ask the right questions)
• Request custom data extract to answer a question or to validate a scenario
• Learn how and run exploratory queries on the data to research anomalies or exceptions
• View examples in the production system (live or using screenshots)

Facilitate group reviews with target audiences:

• Requirements walkthrough (with project stakeholders)
• Peer review (by another business analyst)
• Problem-solving workshop (with selected stakeholders, designers and architects)
• Root cause analysis workshop (with business stakeholders and subject matter experts)
• Roleplay (with “voice of the customer” experts)

Validate analysis results through comparison:

• Provide a side-by-side comparison of business scenarios or process steps
• Highlight variations in the business process steps and link to factors that create variations
• Assess how the user stories differ based on the acceptance criteria
• Create test case variations that capture different business scenarios
• Validate factors and variations, confirm whether they are essential and must be accommodated in a future solution
• Collect all business rules in a coherent set, list or table, and review rules applicable to each distinct scenario

Create a logical set of diagrams to support understanding of the problem and project requirements:

• Start from high-level models and elaborate through detailed diagrams: from a context model, to a semantic diagram, to use case diagram, to process flows, state machines etc.
• Choose diagrams appropriate for your analysis approach
• Review and validate diagrams with stakeholders
• Refer to diagrams during requirements discussions
• Refine and update diagrams as solution design is defined
• Maintain the baseline models that reflect the current state, as well as a future state view

Maintain a full requirements package with all supporting materials in an accessible location:

• The whole package must be easy to find and review as a set of linked documents, entries in a requirements management tool, user story management system, or through a hyperlinked requirements map
• Provide stakeholders with access to the requirements at any time during the project, including draft requirements at the start of the analysis phase
• Include business glossary, artifacts, examples, reports, diagrams, business rule sets and anything else you have collected or created to support a shared understanding of requirements
• Support stakeholders that prefer to conduct their individual review, and be available for their questions and feedback

Collect artifacts and examples during your discovery process to illustrate business problems, understand the terminology and business rules, and avoid arguments:

• Artifacts of existing processes and systems: screenshots, reports, data, system outputs
• Analysis of the current state: use case descriptions, scenario matrices, data segmentation, examples of business rules and calculations, evidence of business problems

Illustrate your points, findings and root cause analysis using examples, data and summaries:

• Statistics, reports and business intelligence insights
• Analysis of cause and effect
• Customer satisfaction survey results
• Feedback, comments and recommendations from customers, users, auditors or regulators
• Defect and process breakdown evidence
• Independent evaluations of the business process or application deficiencies

Choose a suitable technique to visualize and present the future state, future process, or future user experience:

• Product breakdown structure
• User experience maps
• Future process maps
• Storyboards and future designs
• Screen mock-ups and prototypes
• Scenario matrices
• Proof-of-concept
• Sprint demos

---

Does this look like a lot?  You don’t have to know all of these techniques to be successful.

Start with a few techniques that you can apply right away and keep expanding your arsenal. And remember that people you will work with may learn and absorb information in different ways.

Rich requirements supported by the information presented in a variety of formats create a shared understanding of the goal and future solution. And this what business analysis is about.

Contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.