What Is Business Analysis for IT?
Business analysis is the process of studying a business or any other organization to identify business opportunities / problem areas and suggest potential solutions. A wide range of people with various titles, roles and responsibilities actually apply business analysis techniques within an organization.
There are three fundamentally different flavors or levels of business analysis:
Strategic Business Analysis
Strategic Business Analysis is the study of business visions, goals, objectives, and strategies of an organization or an organizational unit to identify the desired future. It encompasses the analysis of existing organizational structure, policies, politics, problems, opportunities, and application architecture to build a business case for change. This analysis employs business analysis techniques such as Variance Analysis, Feasibility Analysis, Force Field Analysis, Decision Analysis, and Key Performance Indicators to support senior management in the decision-making process.
The primary outcome of this work is a set of defined, prioritized projects and initiatives that the organization will undertake to create the desired future. If the initiative includes the development of software using an Agile Software Development Methodology (SDM), strategic business analysis techniques identify themes and/or epics, and initiate a product backlog.
Tactical Business Analysis
Tactical Business Analysis is at the project or initiative level to flush out the details of the proposed solution and to ensure that it meets the needs of the business community. Commonly used business analysis techniques at this level include Stakeholder Identification, Interviewing, Facilitation, Baselining, Coverage Matrices, MoSCoW Analysis, Benchmarking, Business Rules Analysis, Change Management, Process and Data Modeling, and Functional Decomposition.
In an Agile environment, Tactical Business Analysis adds to the Product Backlog and/or Release Plans expressed in Themes, Business Epics, Architecture Epics, User Stories, and User Story Epics. In a traditional setting, the primary outcome of Tactical Business Analysis is a set of textual and/or modeled Business and Stakeholder Requirements.
Operational Business Analysis
Operational Business Analysts work on specific business applications. In an Agile approach, they are members of the development team and will be heavily involved in User Story elaboration and Iteration or Sprint Planning. If they are the stewards of a packaged application, they will deal primarily with identifying how to manage the application parameters to meet evolving business needs.
Their primary business analysis techniques include Meeting Facilitation, Checklist Management, Prioritization, Process Mapping and Analysis, Business Rule Analysis, Lessons Learned Analysis, and Interface Analysis. Few organizations staff all three levels of business analysis and even fewer use the terminology of Strategic, Tactical, and Operational Business Analyst. In many organizations, “Business Analyst” is not a job title.
In very large organizations, individuals with job titles such as Product Manager, Product Owner, Developer, Manager, Subject Matter Expert, etc. actually do business analysis at every level. In smaller organizations, a single individual is often responsible for all scales of business analysis. Regardless of who is wearing the business analysis hat, he or she may or may not have the title Business Analyst.
Most Commonly Used Business Analysis Tools and Techniques
The Requirements Solutions Group (RSG) recently surveyed over 1700 individuals with many different job titles who used business analysis techniques at some level of detail irrespective of the SDM their organization applied to identify the tools they most commonly needed:
- Eighty percent model and identify business processes with tools such as Business Process Modeling Notation (BPMN), Activity Diagrams from the Unified Modeling Language (UML), and Data Flow Diagrams (DFD).
- Seventy-five percent model and identify business data requirements using tools such as Business Analytics, Entity/Relationship Diagrams (ERD). Business data requirements express data elements, entities, types, structures, and user views that subject matter experts need to know to be able to do their job effectively.
- Seventy-five percent identify business rules as a routine part of their jobs. Business rules describe how the organization wants to conduct its business independent of the information technology.
- Seventy-five percent do User Story and End User Acceptance Testing to ensure that the delivered IT components meet the business needs. Seventy-five percent use backlog maintenance procedures, traceability matrices, RACI (Responsible, Accountable, Contributing, and Informed) matrices, to manage product and iteration backlogs and other forms of requirements.
- Sixty-five percent facilitate Story Workshops, Release Planning Sessions, Iteration Planning Sessions, and Requirements Gathering Workshops to identify business problems and express business, stakeholder, and solution requirements.
- Sixty-five percent use Story Points, Function Points, and other estimating techniques for release planning and project scoping Fifty-five percent write Business Use Cases, a specific form of functional solution requirements that focus on the interaction between the technology solution and the people using it.
… [end of excerpt]