Business Analysis (BA) Tasks & Techniques: Foundation - 3

Mathieu Gouanou's Foreword:

Key Concepts  (IIBA® BABOK® v2.0)

Domains:

A domain is the area undergoing analysis. It may correspond to the boundaries of an organization or organizational unit, as well as key stakeholders outside those boundaries and interactions with those stakeholders.

Solutions:

A solution is a set of changes to the current state of an organization that are made in order to enable that organization to meet a business need, solve a problem, or take advantage of an opportunity. The scope of the solution is usually narrower than the scope of the domain within which it is implemented, and will serve as the basis for the scope of a project to implement that solution or its components.

Most solutions are a system of interacting solution components, each of which are potentially solutions in their own right.

Business analysis helps organizations define the optimal solution for their needs, given the set of constraints (including time, budget, regulations, and others) under which that organization operates.

Requirements:

A requirement is:

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2). As implied by this definition, a requirement may be unstated, implied by or derived from other requirements, or directly stated and managed. One of the key objectives of business analysis is to ensure that requirements are visible to and understood by all stakeholders.                                               The term “requirement” is one that generates a lot of discussion within the business analysis community. Many of these debates focus on what should or should not be considered a requirement, and what are the necessary characteristics of a requirement.                            When reading the BABOK® Guide, however, it is vital that “requirement” be understood in the broadest possible sense. Requirements include, but are not limited to, past, present, and future conditions or capabilities in an enterprise and descriptions of organizational structures, roles, processes, policies, rules, and information systems. A requirement may describe the current or the future state of any aspect of the enterprise.

Requirements Classification Scheme: 

The the BABOK® Guide (IIBA® BABOK® v2.0), use the following classification scheme to

describe requirements:

• Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. Thy describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success. Business requirements describe needs of the organization as a whole, and not groups or stakeholders within it. Thy are developed and defied through enterprise analysis.
• Stakeholder Requirements are statements of the needs of a particular stakeholder
  or class of stakeholders. They describe the needs that a given stakeholder has and
  how that stakeholder will interact with a solution. Stakeholder requirements serve
  as a bridge between business requirements and the various classes of solution requirements. They are developed and defied through requirements analysis.
• Solution Requirements describe the characteristics of a solution that meet business

  requirements and stakeholder requirements. Thy are developed and defied through

  requirements analysis. Thy are frequently divided into sub-categories, particularly

  when the requirements describe a software solution:

     ▷ Functional Requirements describe the behavior and information that the solution                    will manage. Thy describe capabilities the system will be able to

         perform in terms of behaviors or operations—specific information technology

         application actions or responses.

     ▷ Non-functional Requirements capture conditions that do not directly relate to

         the behavior or functionality of the solution, but rather describe environmental

         conditions under which the solution must remain effective or qualities that

         the systems must have. Thy are also known as quality or supplementary

         requirements. These can include requirements related to capacity, speed,

         security, availability and the information architecture and presentation of the

         user interface.
• Transition Requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete. Thy are differentiated from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defied. Thy typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state. They are developed and defied through solution assessment and validation.

Source for Business Analysis Tasks and Techniques: IIBA® BABOK® v2.0 or IIBA® BABOK® v3.0. For additional information, please visit http://www.theiiba.org. 

IIBA® is a trademark owned by International Institute of Business Analysis.

Business Analysis Body of Knowledge® and BABOK® are registered trademarks owned by International Institute of Business Analysis.