65 Business Analysis Techniques

The business analyst’s toolbox is chock full of dozens of business analysis techniques.

Here is a list of 65 business analysis techniques that are useful to know about. Not that you would use every technique on every project (though some of these are definitely my tried-and-true, go-to, techniques), but so you have a toolbox of ideas to refer back to when your business analysis process isn’t flowing like it should, so you can get your project unstuck and moving forward again.

**If you’d like to expand your business analyst toolbox, take a look at our business analyst templates. At $97 for each toolkit (or $347 for the Bundle of all 5), these provide an affordable way to bring a wider variety of techniques to your business analysis work.**

And please feel free to add a business analysis technique in a comment below. Just be sure to include a description so we know what it is and/or link to an article that shares more detail about it.

1. Active Listening – A communication technique that involves paraphrasing back what you heard during a conversation to confirm understanding.
2. Agenda – A document containing the pertinent details for a meeting, including an objective and list of topics to be discussed.
3. As Is Process Analysis – Defines the current state of a business process in an organization.
4. Brainstorming – A spontaneous group discussion designed to generate ideas without initial critique or evaluation.
5. Business Analysis Plan – Document that summarizes the business analysis approach, list of deliverables, and schedule for completing the business analysis deliverables.
6. Business Domain Model – A visual model that logically represents the business concepts to be fulfilled by the system and how they relate to one another.  It should not be confused with a data diagram, which represents the actual database design or architecture.  Although they may look similar, a business domain model should use terms that are in the business domain.
7. Business Process Model – A step-by-step description of what one or more business users does to accomplish a specific goal. Those steps can be manual, paper-based, or software-based.
8. Business Process Modeling Notation (BPMN) – A standardized notation for creating visual models of business or organizational processes.
9. Business Rules – A statement that defines or constrains some aspect of business.
10. Change Request – A document or collection of information summarizing a change to be made. Often associated with a formal approval process.
11. Competitive Comparison – Document or matrix comparing the current or potential future state of a product or system to that of an organization’s competitors.
12. Conference Call – A meeting conducted via a conference bridge, with multiple participants joining from different physical locations via a phone line.
13. Data Dictionary – Also called a Data Definition Matrix, provides detailed information about the business data, such as standard definitions of data elements, their meanings, and allowable values.
14. Data Feed Specification – A document containing the business and technical details involved in exchanging data between organizations. Can be used as part of managing API integrations or other types of ongoing data feeds.
15. Data Flow Diagram – Illustrates how information flows through, into, and out of a system. They are especially useful when evaluating data-intensive processes and looking at how data is shared between systems or organizations.
16. Data Mapping – A specific type of data dictionary that shows how data from one information system maps to data from another information system. Creating a data mapping specification helps you and your project team avoid numerous potential issues, the kind that tends to surface late in development or during user acceptance testing and throw off project schedules, not to mention irritating your stakeholders.
17. Deliverables List – A list of deliverables to be created as part of the business analysis effort for a project or initiative.
18. Document Analysis – The process of analyzing documentation to discover information related requirements.
19. Entity Relationship Diagram (ERD) –  A data model describing how entities (or concepts or things) relate to one another. When created by business analysts, ERDs can be used to understand the business domain, clarify business terminology, and connect business concepts to database structures (see Business Domain Model above).
20. Feature Map – A visual representation of multiple features, often user stories on a product backlog, that shows their relationships.
21. Given When Then Statements – A formula for writing acceptance tests for a user story. Given (some context). When (some action is carried out). Then (description of observable consequences, or requirements).
22. Glossary – A deliverable that documents terms that are unique to the business or technical domain. A glossary is used to ensure that all stakeholders (business and technical) understand what is meant by the terminology, acronyms, and phrases used inside an organization.
23. Grooming the Product Backlog – A process for reviewing new product backlog items for clarity, estimation, and priority, prior to or during sprint planning.
24. Interface Analysis – The process of analyzing an interface, such as a user interface to connect between two software systems, to discover information related to the requirements.
25. Interview – A session with one to multiple stakeholders to ask and answer questions related to any aspect of the problem, project, or requirements.
26. Issues List – A document or repository that contains a list of all issues relating in any way to the requirements for a project.
27. Meeting Notes – A document capturing the essence of topics discussed during a meeting, along with any resulting decisions and action items.
28. Mind Map – Suggested by Bola Adesope, a visual model with a topic in the center that shows a hierarchical relationship between different concepts and ideas. This is a great tool for brainstorming.
29. Observation – The process of observing people using a system or executing a process, often in their actual work environment, to discover information related to the requirements.
30. Organizational Chart – A visual model representing the organizational hierarchy in place for an organization or a part of an organization.
31. Performance Measurement – Process of collecting, analyzing and/or reporting information regarding the performance of an individual, group, organization, system or component.
32. Performance Report – Document or model showing the results from a project, project phase, or business activity.
33. Portfolio Management – Process for organizing, prioritizing, and showing relationships between multiple active and proposed projects for an organization.
34. Problem Definition – The process of discovering and defining the actual problem to be solved by a project or solution.
35. Process Improvement Progress Report – Visual model showing the improvements made to a business or technical process as the result of a project or initiative.
36. Process Walk-Through – A working session in which subject matter experts walk through a future state process to validate it.
37. Product Backlog – List of all requirements under consideration (written using a user story syntax), rank ordered, and matrixed with other key characteristics that facilitate planning and prioritization for an agile software development team.
38. Project List – A single list of prioritized projects under consideration by a team or organization.
39. Prototype – A functional visual model that shows the user interface of a not-yet-built software system. Often prototypes allow for some limited interaction based on sample data.
40. Requirements Questionnaire – A list of questions about the project requirements. Typically the questions are organized by feature (or business requirement or project objective).
41. Requirements Review –  A meeting gathering stakeholders together to walk through the requirements documentation, page-by-page, line-by-line, to ensure that the document represents everyone’s complete understanding of what is to be accomplished in this particular project.
42. Retrospective – The process of reviewing a work completed (often for a project or segment of a project) to discover and bring forward lessons learned.
43. Root Cause Analysis – The process of analyzing a problem to discover the underlying causes, or true issues, creating the problem.
44. Scope Model –  A visual representation of the features, processes, or functionality in scope for a specific project, solution, or system.
45. Stakeholder Analysis – A document defining who is part of the project team and what they are responsible for.
46. Stakeholder Map –  A visual diagram that depicts the relationship of stakeholders to the solution and to one another.
47. Stakeholder Request List – List of requests related to a project or solution prior to defining scope.
48. Survey – A series of questions posed to multiple stakeholders in an asynchronous format, such as an online questionnaire. Useful for gathering lots of information from multiple people.
49. SWOT Analysis – A visual model showing information about the Strengths, Weaknesses, Opportunities, and Threats an organization faces.
50. System Architecture Diagram – Visual model that identifies the system components and how they interact as part of the solution and can help you figure out how to best organize the detailed requirements.
51. System Context Diagram – A visual model defining the primary system to be addressed during a project or initiative and the relationships between the primary system and other systems.
52. To Be Process Analysis – Defines the future state of a business process in an organization to clarify how the business process will work, at some point in the future, once changes are made.
53. Traceability Matrix – Suggested by Nikkita Nguyen, this document is used to map business requirements to functional requirements.
54. Triple Constraint – A model showing the balance between project budget, schedule, scope, and quality.
55. Use Case – Use cases are a type of textual requirements specification that captures how a user will interact with a solution to achieve a specific goal. They describe the step by step process a user goes through to complete that goal using a software system.
56. Use Case Diagram – A UML (Unified Modeling Language) diagram that shows the actors, use cases, and the relationships between them.
57. User Acceptance Testing – A validation process in which business users use a new solution, often before it’s deployed, to confirm it will meet their needs.
58. User Interface Specification –  A document defining the rules of engagement for a user interacting with a specific page on a website or screen within an application.
59. User Story – A short document capturing a description of a software feature from an end-user perspective. User stories are often written in the following syntax: As a ____ {user}, I want ____ so that ______. User stories are often coupled with acceptance criteria (see Given When Then Statements).
60. Video Conferencing – An expansion on a web conference, where participants are also able to share video of themselves.
61. Vision Document – A document describing the business objectives and scope of a project.
62. Web Conference – A meeting held via a webinar, online meeting, or combination of screen-sharing software and conference bridge, with multiple participants joining from different physical locations via an internet connection being able to all see one visual screen and talk to one another.
63. Wireframe (Also called a Mock-Up, Related to a Prototype) –  A visual representation of a user interface screen, typically one that is fairly low-fidelity.
64. Workflow Diagram (Also called Activity Diagram) – A simple visual model that captures the steps, decisions, start point, and end point of a functional, technical, or business process.
65. Workshop – A meeting in which real-time collaboration on one or more work products, such as requirements deliverables, occurs inside the working session.

What business analysis techniques do you use most often? Do you have a favorite technique that’s not included on the list? Please share it via comment below and be sure to include a short description to define what it is and when to use it.

And, if you’d like to expand your business analyst toolbox, take a look at our business analyst templates. At $97 for each toolkit (or $347 for the Bundle of all 5), these provide an affordable way to bring a wider variety of techniques to your business analysis work.