A Guide to the Business Analysis: "Business Analysis Key Concepts"

What are the elements of the "Business Key Concepts"?

The Business Key Concepts include the information that provides a foundation for all the other contents, concepts, and ideas in order to provides the business analysts with a basic understanding of the central ides necessary for understanding and employing in the daily practice of business analysis.

The Business Key Concepts consist of:

1. Business Analysis Core Concept Model™ (BACCM™)

2. Key Terms

3. Requirements Classification Schema

4. Stakeholders

5. Requirements and Designs

1. Business Analysis Core Concept Model™ (BACCM™)

The Business Analysis Core Concept Model™ (BACCM™) is a conceptual framework for business analysis. It encompasses what business analysis is and what it means to those performing business analysis tasks regardless of perspective, industry, methodology, or level in the organization. It is composed of sex terms that have a common meaning to all business analysts and helps to discuss both business analysis and its relationships with common terminology.

The Six Core Concepts in the BACCM™ are: CHANGE, NEED, SOLUTION, STAKEHOLDER, VALUE and CONTEXT. 

Figure 1: The Descriptions of BACCM™

2. Key Terms

The Key Terms are very important for all business analysts to understand about the process and what we have to analyze.

2.1. Business Analysis Information

Business analysis information refers to the broad and diverse sets of information that business analysts analyze, transform, and report. It is information of any kind - at any level of detail- that is used as and input to, or an output of, business analysis work.

It is essential to expand the object of many business analysis activities from “requirements” to “information” to ensure that all inputs and outputs of business analysis are subject to the tasks and activities described in the guidance.

2.2. Design

A design is a usable representation of a solution. Design focuses on understanding how value might be realized by a solution if it is built. The nature of the representation may be a document (or set of documents) and can vary widely depending on the circumstances.

2.3. Enterprise

An enterprise is a system of one or more organizations and the solutions they use to pursue a shared set of common goals. These solutions (also referred to as organization capabilities) can be processes, tools or information. For the purpose of business analysis, enterprise boundaries can be defined relative to the change and need not be constrained by the boundaries of a legal entity, organization or organizational unit. An enterprise may include any number of business, government, or any other type of organization.

2.4. Plan

A plan is a proposal for doing or achieving something, Plans describe a set of events, the dependencies among the events, the expected sequence, the schedule, the results or outcomes, the material and resources needed, and the stakeholders involved.

2.5. Requirement

A requirement is a usable representation of a need. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled. The nature of the representation may be a document (or set of documents) but can vary widely depending on the circumstances.

2.6. Risk

Risk is the effect of uncertainty on the value of a change, a solution, or the enterprise. Business analysts collaborate with other stakeholders to identify, assess, and prioritize risks, and to deal with those risks by altering the likelihood of the conditions or events that lead to the uncertainly: mitigating the consequences, removing the source of the risk, avoiding the risk altogether by deciding not to start or continue with an activity that leads to the risk, sharing the risk with other parties, or accepting or even increasing the risk to deal with an opportunity.

3. Requirements Classification Schema

The following classification schema describes requirements:

Business requirements: statements of goals, objectives, and outcomes that describe why a change has been initiated. They can apply to the whole of an enterprise, a business area, or a specific initiative.

·     

     Stakeholder requirements: describe the needs of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business and solution requirements.

·    Solution requirement: describe the capabilities and qualities of a solution that meets the stakeholder requirements. They provide the appropriate level of detail to allow for the development and implementation of the solution. Solution requirements can be divided into two sub-categories:

* functional requirement that describe the capabilities that a solution must have terms of the behavior and information that the solution will manage, and

* non-functional requirements or quality of service requirements: do not relate directly to the behavior of functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must have.

·    

     Transition requirements: describe the capabilities that the solution must have and the conditions the solution must meet to facilities transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training and business continuity.

4. Stakeholders:

Stakeholders, here, are refer to a list of participants who are more likely participate in the execution of the analysis tasks or who will be affected by it. A stakeholder is an individual or group that a business analyst is likely to interact with directly or indirectly. Any stakeholder can be a source of requirements, assumptions, or constraints.

The generic list of stakeholders includes the following role:

Business Analyst: is inherently a stakeholder in all business analysis activities and is responsible also accountable for the execution of these activities. In some cases, the business analyst may also be responsible for performing activities that fall under another stakeholder role.

Customer: uses or may use products or services produced by the enterprise and may have contractual or moral rights that the enterprise is obliged to meet.

Domain Subject Matter Expert: is any individual with in-depth knowledge of a topic relevant to the business need or solution scope. This role is often filled by people who may be end users or people who have in-depth knowledge of the solution such as managers, process owners, legal staff, consultants, and others.

End User: are stakeholders who directly interact with the solution. End users can include all participants in a business process, or who use the product or solution.

Implementation Subject Matter Expert: is any stakeholder who has specialized knowledge regarding the implementation of one or more solution components. Some of the most common roles are project librarian, change manager, configuration manager, solution architect, developer, database administrator, information architect, usability architect, usability analyst, trainer and organizational change consultant.

Operational Support: is responsible for the day-to-day management and maintenance of a system or product. While it is not possible to define a listing of operational support roles that are appropriate for all initiatives, some of the most common roles are operations analyst, product analyst, help desk or release manager.

Project Manager: are responsible for managing the work required to deliver a solution that meets a business need, and for ensuring that the project’s objectives are met while balancing the project factors including scope, budget, schedule, resources, quality and risk.

Regulator: are responsible for the definition and enforcement of standards. Standards can be imposed on the solution by regulators through legislation, corporate governance standards, audit standards, or standards defined by organizational centers of competency. Alternate roles are government, regulatory bodies or auditors.

Sponsor: are responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize the work to be performed and control the budget and scope for the initiative. Alternate roles are executive and project sponsor.

Supplier: is a stakeholder outside the boundary of a given organization or organizational unit. Suppliers provide products or services to the organization and may have contractual or moral rights and obligations that must be considered. Alternate roles are providers, vendors, or consultants.

Tester: are responsible for determining how to verify that the solution meets the requirements defined by the business analyst, as well as conducting the verification process. Testers also seek to ensure that solution meets applicable quality standards, and that the risk of defects or failures is understood and minimized.

5. Requirements and Designs

Eliciting, analyzing, validating, and managing requirements have consistently been recognized as key activities of business analyst. However, it is important to recognize that business analyst is also responsible for the definition of design, at some level, in an initiative. The level of responsibility for design varies based on the perspective within which a business analyst is working.

Requirements are focused on the need; designs are focused on the solution. The distinction between requirements and designs is not always clear. The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may drive the discovery and analysis of more requirements.

The classification as a requirement or a design may become less significant as the business analyst’s work progresses to a greater understanding of and eventual fulfillment of the need.

Business analysis can be complex and recursive. A requirement (or set of requirements) may be used to define a design. That design may then be used to elicit additional requirements that are used to define more detailed designs. The business analyst may hand off requirements and designs to other stakeholders who may further elaborate on the designs. Whether it is the business analyst or some other role that completes the designs, the business analyst often reviews the final designs to ensure that they align with the requirements.

The following table provides some basic examples of how information may be viewed as either a requirement or a design.

Table 1: Requirements and Designs

Table 2: Requirements and Designs Cycle