A Guide to the Business Analysis: "Business Analysis Planning and Monitoring" - Part 3

How many tasks are included in the Business Analysis Planning and Monitoring?

The Business Analysis Planning and Monitoring knowledge area includes the following tasks:

1.  Plan Business Analysis Approach
2.  Plan Stakeholder Engagement
3.  Plan Business Analysis Governance
4.  Plan Business Analysis Information Management
5.  Identify Business Analysis Performance Improvement

3. Plan Stakeholder Engagement

3.1. Purpose

 The purpose of Plan Business Analysis Governance is to define how decisions are made about requirements and designs, including reviews, change control, approvals, and prioritization.

Business analysts ensure that a governance process is in place and clarify any ambiguities within in. A governance process identifies the decision makers, process and information required for decisions to be made. A governance process describes how approval and prioritization decisions are made for requirements and designs.

When planning the governance approach, business analysts identify:

•  how business analysis work will be approached and prioritized,
•  what he process for proposing a change to business analysis information is,
•  who has the authority and responsibility to propose changes and who should be involved in the change discussions,
•  who has responsibility for analyzing change requests,
•  who has the authority to approve changes, and
•  how changes will be documented and communicated.

3.2. Inputs

• Business Analysis Approach: incorporating the overall business analysis approach into the governance approach is necessary to ensure consistency across the approaches.
• Stakeholder Engagement Approach: identifying stakeholders and understanding their communication and collaboration needs is useful in determining their participation in the governance approach. The engagement approach may be updated based on the completion of the governance approach.

3.3. Elements

3.3.1. Decision Making

Decisions are made throughout the initiative. A stakeholder may serve in various roles in the decision-making process such as:

•  participant in decision-making discussions,
•  subject matter expert (SME) lending experience and knowledge to the decision-making process.
•  reviewer of information, and
•  approver of decisions.

The decision making process defines what happens when teams cannot reach consensus, by identifying escalation paths and key stakeholders who hold final decision-making authority.

3.3.2. Change Control Process

When business analysts develop a change control process, they:

• Determine the process for requesting changes: specify with requirements and designs the change control process covers and determine whether it applies to all changes or only to changes of a specific size, cost, or level of effort. This process details the steps for proposing a change, when changes can be proposed, who can propose changes and how change requests are communicated.
• Determine the elements of the change request: identify the information to be included in a proposal to support decision making and implementation iif it is approved. Possible components to consider on a change request are Cost and Time Estimation, Benefits, Risks, Priority, Course of Action.
• Determine how changes will be prioritized: the priority of the proposed change is established relative to other competing interests within the current initiative.
•  Determine how changes will be documented: configuration management and traceability standards establish product baselines and version control practices that identify which baseline is affected by the change.
• Determine how changes will be communicated: how proposed changes, changes under review, and approved, declined, or deferred changes will be communicated to stakeholders.
• Determine who will perform the impact analysis: specify who is responsible for performing and analysis of the impacts the proposed change will have across the initiative.
• Determine who will authorized changes: include a designation of who can approve changes and what business analysis information their authority covers.  

3.3.3. Plan Prioritization Approach

Timelines, expected value, dependencies, resource constraints, adopted methodologies, and other factors influence how requirements and designs are prioritized.

When planning the prioritization process, business analysts determine the:

•  formality and rigors of the prioritization process,
•  participants who will be involved in prioritization,
•  process for deciding how prioritization will occur, including which prioritization techniques will be utilized, and
•  criteria to be used for prioritization.

3.3.4. Plan for Approvals

An approval formalizes the agreement between all stakeholders that the content and presentation of the requirements and designs are accurate, adequate, and contain sufficient detail to allow for continued progress to be made.

The timing and frequency of approvals are dependent on the size and complexity of the change and associated risks of foregoing or delaying an approval. 

The business analyst must determine the type of requirements and designs to be approved, the timing for approvals, the process to follow to gain approval, and who will approve the requirements and designs. 

When planning the appropriate approval process, business analyst consider the organizational culture and type of information being approved.

Planning for approvals also includes the schedule of events where approvals will occur and how they will be tracked. Stakeholder availability, attitude, and willingness to engage determine the efficiency of the approval process and may significantly affect delivery timelines.

3.5. Guidelines and Tools

• Business Analysis Performance Assessment: provides  results of previous assessments that should be reviewed and incorporated into all planning approaches.
• Business Policies: define the limits within which decisions must be made. They may be described by regulations, contracts, agreements, warranties, certifications or other legal obligations.
• Current State Descriptions: provides the context within which the work needs to be completed. This information can help drive how to make better decisions.
• Legal / Regulatory Information: describes legislative rules or regulations that must be followed, and can be used to help develop a framework that ensures sound business decision making.

3.6. Techniques

•  Brainstorming: used to generate an initial list of potential stakeholder names who may need approval roles in the defined governance process.
•  Document Analysis: used to evaluate existing governance processes or templates.
•  Interviews: used to identify possible decision-making, change control, approval, or prioritization approaches and participants with an individual or small group.
•  Item Tracking: used to track any issues that arise when planning a governance approach.
•  Lessons Learned: used to find if past initiative have identified valuable experiences with governance that can be leveraged on current or future initiative.
•  Lesson Learned: used to find if past initiatives have identified valuable experiences with governance that can be leveraged on current or future initiative.
•  Organizational Modelling: used to understand roles/responsibilities within the organization in an effort to define a governance approach that involves the right stakeholders.
•  Process Modelling: used to document the process or method for governing business analysis.
•  Reviews: used to review the proposed governance plan with key stakeholders.
•  Survey or Questionnaire: used to identify possible decision-making, change control, approval, or prioritization approaches and participants.
•  Workshops: used to identify possible decision making, change control, approval, or prioritization approaches and participants within a team setting. 

3.7. Stakeholders

• Domain Subject Matter Expert: may be a possible source of a requested change or may be identified as need to be involved in change discussions.
• Project Manager:  works with the business analyst to ensure that overall project governance aligns with the business analysis governance approach.
• Regulator:  may impose rules or regulations that need to be considered when determining the business analysis governance plan.
• Sponsor:  can impose their own requirements for how business analysis information should be managed. Participates in change discussions and approves proposed changes.
  
  

3.8. Outputs

" Governance Approach identifies the stakeholders who will have the responsibility and authority to make decisions about business analysis work including who will be responsible for setting priorities and who will approve changes to business analysis information. It also defines the process that will be utilized to manage requirement and design changes across the initiative. " 

Appendix: Plan Business Analysis Governance Input / Output Diagram

A Guide to the Business Analysis: "Business Analysis Planning and Monitoring" - Part 2

How many tasks are included in the Business Analysis Planning and Monitoring?

The Business Analysis Planning and Monitoring knowledge area includes the following tasks:

1.  Plan Business Analysis Approach
2.  Plan Stakeholder Engagement
3.  Plan Business Analysis Governance
4.  Plan Business Analysis Information Management
5.  Identify Business Analysis Performance Improvement

2. Plan Stakeholder Engagement

2.1. Purpose

The purpose of Plan Stakeholder Engagement is to plan an approach for establishing and maintaining effective working relationships with stakeholders.

Plan Stakeholder Engagement involves conducting a thorough stakeholder analysis to identify all of the involved stakeholders and analyze their characteristics. The results of the analysis are then utilized to define the best collaboration and communication approaches for the initiative and to appropriately plan for stakeholder risks.

2.2. Inputs

• Needs: understanding the business need and the parts of the enterprise that it affects helps in the identification of stakeholders. The need may evolve as stakeholder analysis is performed.
• Business Analysis Approach: incorporating the overall business analysis approach into the stakeholder analysis, collaboration, and communication approaches is necessary to ensure consistency across the approaches.

2.3. Elements

2.3.1 Perform Stakeholder Analysis

Stakeholder analysis involves identifying the stakeholder (who will be directly or indirectly impacted by the change) and their characteristics, as well as analyzing the information once collected. Stakeholder analysis is performed repeatedly as business analysis activities continue.

A thorough and detailed stakeholder list ensures that stakeholders are not overlooked. Understanding who the stakeholders are, the impact of proposed changes on them, and the influence they may have on the change is vital to understanding what needs, wants, and expectations must be satisfied by a solution. If stakeholders are not identified, the business analyst may miss uncovering critical needs. Stakeholder needs uncovered late will often require a revision to business analysis tasks that are either in progress or are completed. This can result in increased costs and decreased stakeholders satisfaction. 

Business analysts identify stakeholder roles in order to understand where and how the stakeholders will contribute to the initiative. It is important that the business analyst is aware of the various roles a stakeholder is responsible for within the organization.

Attitude of Stakeholders can positively or negatively impact a change. Business Analysts identify stakeholder attitudes in order to fully understand what may impact a stakeholder's actions and behaviors. Knowing how a stakeholder perceives the initiative allows an opportunity for the business analyst to specifically plan their collaboration and engagement with that stakeholder.

Business analyst analyze stakeholder attitudes about:

•  business goals, objectives of the initiative, and any proposed solutions
•  business analysis in general
•  the level of interest in the change
•  the sponsor
•  team members and other stakeholders, and
•  collaboration and a team-based approach.

Stakeholders with positive attitudes may be strong champions and great contributors. Other stakeholders may not see value in the work, may misunderstand the value being provided, or may be concerned about the effect the change will have on them.

Also, business analysts have to identify the authority level a stakeholder possesses over business analyst activities, deliverables, and changes to business analysis work.

Understanding authority levels upfront eliminates confusion during the business analysis effort and ensures the business analyst collaborates with proper stakeholders when looking for a decision to be made or seeking approvals. In additional, understanding the nature of influence and the influence structures and channels within an organization can prove invaluable when seeking to build relationships and trust. Understanding the influence and attitude each stakeholder may can help develop strategies for obtaining buy-in and collaboration. If there is a mismatch between the influence is needed to implement a change compared to the amount of influence and key stakeholders can bring.

2.3.2 Define Stakeholder Collaboration

To be ensuring effective collaboration with stakeholders is essential for maintain their engagement in business analysis activities. Collaboration can be a spontaneous event. However, much collaboration is deliberated and planned, with specific activities and outcomes determined ahead of time during planning activities. 

The business analyst may plan different collaboration approaches for internal and external stakeholders, and approaches may differ by business analysis activity.

The objective is to select the approaches that work best to meet the needs of each stakeholder group and ensure their interest and involvement is maintained across the initiative. Some considerations when planning collaboration include:

•  timing and frequency of collaboration,
•  location,
•  available tools such as "wikis" and online communities,
•  delivery method such as in-person or virtual, and
•  preference of the stakeholders.

2.3.3 Stakeholder Communication Needs

The business analyst evaluates:

•  what needs to be communicated,
•  what is the appropriate delivery method (written or verbal),
•  who the appropriate audience is,
•  when communication should occur
•  frequency of communication,
•  level of detail appropriate for the communication and stakeholder, and
•  level of formality of communications.

2.4 Guidelines and Tools

- Business Analysis Performance Assessment: provides results of previous assessments that should be reviewed and incorporated.

- Change Strategy: used for improved assessment of stakeholder impact and development of more effective stakeholder engagement strategies.

- Current State Description: provides the context within which the work needs to be completed. This information will lead to more effective stakeholder analysis and better understanding of the impact of the desired change.

 2.5 Techniques

- Brainstorming: used to produce the stakeholder list and identify stakeholder roles and responsibilities.

- Business Rules Analysis: used to identify stakeholders who were the source of the business rules.

- Document Analysis: used to review existing organizational assets that might assist in planning stakeholder engagement.

- Interviews: used to interact with specific stakeholders to gain more information or knowledge about stakeholder groups.

- Lesson Learned: used to identify an enterprise's previous experience (both successes and challenge) with planning stakeholder engagement.

- Mind Mapping: used to identify potential stakeholders and help understand the relationships between them.

- Organizational Modelling: used to determine if the organizational units or people listed have any unique needs and interests that should be considered. Organizational models describe the roles and functions in the organization and the ways in which stakeholders interact which can help to identify stakeholders who will be affected by a change.

- Process Modelling: used to categorize stakeholders by the systems that support their business processes.

- Risk Analysis and Management: used to identify risks to the initiative resulting from stakeholder attitudes or the inability of key stakeholders to participate in the initiative.

- Scope Modelling: used to develop scope models to show stakeholders that fall outside the scope of the solution but still interact wit it in some way.

- Stakeholder List, Map, or Personas: used to depict the relationship of stakeholders to the solution and to one another.

- Survey or Questionnaire: used to identify shared characteristics of a stakeholder group.

- Workshop: used to interact with groups of stakeholders to gain more information about stakeholder groups.

 2.6 Stakeholders

Stakeholders in this section include:

- Customers: a source of external stakeholders.

- Domain Subject Matter Expert: may help to identify stakeholders and may themselves be identified to fulfill one or more roles on the initiative.

- End User: a source of internal stakeholders.

- Project Manager: may be able to identify and recommend stakeholders. Responsibility for stakeholder identification and management may be shared with the business analyst.

- Regulator: may require that specific stakeholder representatives or groups be involved in the business analysis activities.

- Sponsor: may request that specific stakeholders be involved in the business analysis activities.

- Suppliers: a source of external stakeholders.

 2.7 Outputs

Stakeholder Engagement Approach contains a list of the stakeholders, their characteristic which were analyzed, and a listing of roles and responsibilities for the change. It also identifies the collaboration and communication approaches the business analyst will utilize during the initiative. 

Appendix: Plan Stakeholder Engagement Input / Output Diagram

A Guide to the Business Analysis: "Business Analysis Planning and Monitoring" - Part 1

How many tasks are included in the Business Analysis Planning and Monitoring?

The Business Analysis Planning and Monitoring knowledge area includes the following tasks:

1.  Plan Business Analysis Approach


2.  Plan Stakeholder Engagement


3.  Plan Business Analysis Governance


4.  Plan Business Analysis Information Management


5.  Identify Business Analysis Performance Improvement

1. Plan Business Analysis Approach:

Plan Business Analysis Approach describes the planning of business analysis work from creation or selection of a methodology to planning the individual activities, tasks, and deliverables.

The businesss analyst may also identify an initial set of techniques to use. This list may change as the initiative proceeds and the business analyst gains a deeper understanding of the change and its stakeholder.

The Business Analysis approach may be defined by a methodology or by organizational standards. In some organizations, elements of the business analysis approach may be standardized and formalized into a repeatable business analysis process which can be leveraged for each effort.

If organizational standards do not exist, the business analyst works with the appropriate stakeholders to determine how the work will be completed. For example, if the change is delivered via a project, the standards and approach may be developed during the project planning phase.

The Business analysis approach should:

  - align to the overall goals for the change,
  - coordinate the business analysis tasks with the activities and deliverables of the overall change,
  - include tasks to manage any risks that could reduce the quality of business analysis deliverables or
    impede task efficiency, and

  - leverage approaches and select techniques and tools that have historically worked well.

1.1 Inputs

Needs: the business analysis approach is shaped by the problem or opportunity faced by the organization. It is necessary to consider what is known about the need at the time of planning, while acknowledging that understanding evolves throughout business analysis activities.

1.2 Elements

A. Planning Approach

There are various planning methods used across perspectives, industries and enterprises. Many planning methods fit somewhere along a continuum between predictive and adaptive approaches.

Predictive approaches focus on minimizing upfront uncertainty and ensuring that the solution is defined before implementation begins in order  to maximize control and minimize risk. These approaches are often preferred in situations where requirements can effectively be defined ahead of implementation, the risk of an incorrect implementation is unacceptably high, or when engaging stakeholders presents significant challenges.

Adaptive approaches focus on rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding the overall delivery of the solution. These approaches tend to be preferred when taking an exploratory approach to finding the best solution or for incremental improvement of an existing solution.

Different approaches may be used within the same initiative. Among other factors, the business analyst may consider the organization's standards, tolerance for uncertainly, and previous experience with different approaches when planning for business analysis activities.

B. Formality and Level of Detail of Business Analysis Deliverables

When defining the business analysis approach, consider the level of formality that is appropriate for approaching and planning the initiative.

Predictive approaches typically call formal documentation and representations. Business analysis information may be captured in a formal document or set of representations following standardized templates. Information is captured at various levels of detail. The specific content and format of business analysis information can vary depending on the organizational methodologies, process and template in use.

Adaptive approaches favor defining requirements and designs through team interaction and gathering feedback on a working solution. Mandatory requirements representations are often limited to a prioritized requirement list. Additional business analysis documentation may be created at the discretion of the team, and generally consists of models developed to enhance the team's understanding of a specific problem. Formal documentation is often produced after the solution is implemented to facilitate acknowledge transfer.

C. Business Analysis Activities

A business analysis approach provides a description of the types of activities that the business analyst will perform. Frequently the organization's adopted methodologies influence the activities that are selected. 

Integrating business analysis activities in the business analysis approach includes;

- identifying the activities required to complete each deliverable and then breaking each activity into tasks,

- dividing the work into iterations, identifying the deliverables for each iteration and then identifying the associated activities and tasks, or

- using a previous similar initiative as an outline and applying the detailed tasks and activities unique to the current initiative.

D. Timing of Business Analysis Work

Business analyst determine when the business analysis tasks need to be performed and if the level of business analysis effort will need to vary over time. This type of planning includes determining whether the business analysis tasks performed within the other knowledge areas will be performed primarily in specific phases or iteratively over the course of the initiative. 

The timing of business analysis activities can also be affected by:
- the availability of resources,
- priority and/or urgency of the initiative,
- other concurrent initiative, or 
- constraints such as contract terms or regulatory deadlines.
E. Complexity and Risk

The complexity and size of the change and the overall risk of the effort to the organization are considered when determining the business analysis approach. As complexity and risk increase or decrease, the nature and scope of business analysis work can be altered and reflected in the approach.

The approach may also be altered based on the number of stakeholders or business analysis resource involved in the initiative. As the number of stakeholders increases, the approach may be adjusted to include additional process steps to better manage the business analysis work. 

Other factors that can impact complexity include:

* size of the change

* number of business areas or systems affected,

* technological complexities, and

* an risks that could impede the business analysis effort.

Factors that can impact the risk level of a business analysis effort include:

* experience level of the business analyst,

* extent of domain knowledge held by the business analysis,

* level of experience stakeholders have in communicating their needs,

* stakeholder attitudes about the change and business analysis in general,

* amount of time allocated by stakeholders to the business analysis activities,

* any pre-selected framework, methodology, tools, and/or techniques imposed by organizational policies and practices,

* cultural norms of the organization.

F. Acceptance

The business analysis approach is reviewed and agreed upon by key stakeholders. In some organizations, the business analysis process may be more structured and require key stakeholders to sign off on the approach to ensure all business analysis activities have been identified, estimates are realistic, and the proposed roles and responsibilities are correct. Any issues raised by stakeholders when reviewing the approach are documented by the business analyst and resolutions are sought. Stakeholders also play a role in reviewing and accepting changes to the approach as alterations are made to accommodate changing conditions across the initiative.

1.3 Guidelines and Tools

• Business Analysis Performance Assessment: provides results of previous assessments that should be reviewed and incorporated into all planning approaches.
•  Business Policies: defines the limits within which decisions must be made. They may be described by regulations, contracts, agreements, deals, warranties, certifications, or other legal obligations. These policies can influence the business analysis approach.
•  Expert Judgment: used to determine the optional business analysis approach. Expertise may be provided from a wide range of sources including stakeholders on the initiative, organizational centers of excellence, consultants or associations and industry groups.
•  Methodologies and Frameworks: shapes the approach that will be used by providing methods, techniques, procedures, working concepts, and rules.
•  Stakeholder Engagement Approach: understanding the stakeholders and their concerns and interests may influence decisions made when determining the business analysis approach.

1.4 Techniques

•  Brainstorming: used to identify possible business analysis activities, techniques, risks and other relevant items to help build the business analysis approach.
•  Business Cases: used to understand whether elements of the problem or opportunity are especially time-sensitive, high-value, or whether there is any particular uncertainty around elements of the possible need or solution.
•  Document Analysis: used to review existing organizational assets that might assist in planning the approach.
•  Estimation: used to determine how long it may take to perform business analysis activities.
•  Financial Analysis: used to assess how different approaches (and the supported delivery options) affect the value delivered.
•  Functional Decomposition: used to break down complex business analysis processes or approaches into more feasible components
•  Interviews: used to help build the plan with an individual or small group.
•  Item Tracking: used to track any issues raised during planning activities with stakeholders. Can also track risk related items raised during discussions when building  the approach.
•  Lesson Learned: used to identify an enterprise's previous experience (both successes and challenges) with planning business analysis approach.
•  Process Modelling: used to define and document the business analysis approach.
•  Reviews: used to validate the selected business analysis approach with stakeholders.
•  Risk Analysis and Management: used to assess risks in order to select the proper business analysis approach. 
•  Scope Modelling: used to determine the boundaries of the solution as an input to planning and to estimating.
•  Survey and Questionnaire: used to identify possible business analysis activities, techniques, risks and other relevant items to help build the business analysis. 
•  Workshops: used to help build the plan in a team setting.

1.4 Outputs

Business Analysis Approach identifies the activities that will be performed across an initiative including who will perform the activities, the timing and sequencing of the work, the deliverables that will be produced and the business analysis techniques that may be utilized. The remaining outputs of the Business Analysis Planning and Monitoring knowledge area may be integrated into an overall approach or be independent based upon methodology, organization, and perspective.

Appendix 1: Plan Business Analysis Approach Input / Output Diagram

Appendix 2: Formality and Level of Detail of Business Analysis Deliverables

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