Business Analysis for Practitioners: A Practice Guide

Project Management Institute (2015)

Visit this Practice Guide's PMI.org Page for details and to directly support the Project Management Institute.

1. INTRODUCTION

1.2. Need for this Practice Guide

Location 441: When business analysis is properly accounted for and executed on programs and projects, the following benefits are achieved:

Location 443: High-quality requirements are produced resulting in the development of products and services that meet customer expectations; Stakeholders are more engaged in the process and buy-in is more readily achieved; Projects are more likely to be delivered on time, within scope, and within budget; Implemented solutions deliver business value and meet stakeholder needs; and Organizations develop competencies in business analysis that are reusable for future projects.

1.5. What is Business Analysis?

Location 482: Business analysis is the application of knowledge, skills, tools, and techniques to:

~ Determine problems and identify business needs;
~ Identify and recommend viable solutions for meeting those needs;
~ Elicit, document, and manage stakeholder requirements in order to meet business and project objectives;
~ Facilitate the successful implementation of the product, service, or end result of the program or project.

In short, business analysis is the set of activities performed to identify business needs and recommend relevant solutions; and to elicit, document, and manage requirements.

1.6.1. Skillset and Expertise Needed for the Business Analysis Role

Location 504: Many of the interpersonal skills leveraged by project managers are equally important to the practice of business analysis. The following is a partial list of some important skills and expertise for anyone performing business analysis activities on programs and projects:

1. Analytical skills,
2. Business and industry knowledge,
3. Communication skills, including strong business writing and verbal communication skills,
4. Conflict management,
5. Creative and critical thinking,
6. Cultural awareness,
7. Decision making,
8. Facilitation,
9. Familiarity with multiple project and development methodologies,
10. Influence,
11. Issue management skills,
12. Leadership skills,
13. Learning skills,
14. Negotiation skills,
15. Organizational skills,
16. Political awareness,
17. Presentation skills,
18. Problem solving,
19. Systems thinking,
20. Technical awareness, and
21. Ability to work effectively in a team environment, including virtual teams.

1.6.2. How Organizations Implement Business Analysis

Location 526: Ultimately for project success, the important factor is that the business analysis activities are being performed effectively, consistently, and with sufficient quality. It is less important to know the title of the person performing the business analysis work.

1.6.4. The Need to Build the Relationships

Location 552: When the project manager and business analyst are not in sync, there are tangible and intangible impacts to project success. When there is a lack of synergy between project managers and business analysts, there are project inefficiencies, critical work is overlooked or duplicated, stakeholders are confused, and the project team fails to operate at an optimum level of efficiency.

1.7. Definition of Requirement

A requirement represents something that can be met by a product or service, and can address a need of the business, person, or group of people. A requirement should be independent of the design of the solution that addresses it. A requirement may explain a feature that is to be met by a product or software component. When a specific type of requirement is under discussion, the term requirement is preceded by a qualifier such as stakeholder, business, or solution.

1.7.2. Requirement Types

Location 571: To provide clarity and context to the issue, requirements are often categorized by type. In the PMBOK® Guide – Fifth Edition, the primary types of requirements discussed include project requirements, product requirements, quality requirements, and stakeholder requirements.

Business Requirements: Describe the higher-level needs of the organization as a whole, such as business issues or opportunities, and reasons why a project has been undertaken.

Stakeholder Requirements: Describe the needs of a stakeholder or stakeholder group, where the term stakeholder is used broadly to reflect the role of anyone with a material interest in the outcome of an initiative, and could include customers, suppliers, and partners, as well as internal business roles.

Solution Requirements: Describe the features, functions, and characteristics of a product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements.

Functional Requirements: Describe the behaviors of the product. Nonfunctional Requirements. Describe the environmental conditions or qualities required for the product to be effective.

Transition Requirements: Describe temporary capabilities, such as data conversion and training requirements, and operational changes needed to transition from the current state to the future state.

Location 586: Two other types of requirements are project requirements and quality requirements. These requirement types are not part of the business analysis effort.

In business analysis, nonfunctional requirements are often referred to as quality of service requirements.

Location 599: When requirements are managed with a requirements management tool, the requirement type is a characteristic of the requirement that is determined when the requirement is added to the online repository.

2. NEEDS ASSESSMENT

2.1. Overview of this Section

Location 655: A needs assessment consists of the business analysis work that is conducted in order to analyze a current business problem or opportunity. It is used to assess the current internal and external environments and current capabilities of the organization in order to determine the viable solution options that, when pursued, would help the organization meet the desired future state.

Location 660: Thinking through business problems and opportunities with stakeholders is important for all programs and projects; the degree to which a needs assessment is formally documented depends upon organizational and, possibly, regulatory constraints.

2.2. Why Perform Needs Assessments

Location 662: In business analysis, needs assessments are performed to examine the business environment and address either a current business problem or opportunity. A needs assessment may be formally requested by a business stakeholder, mandated by an internal methodology, or recommended by a business analyst prior to initiating a program or project.

Location 667: Needs assessment work is undertaken before program or project work begins, therefore it is said to involve the pre-project activities. However, during the course of a project, should external factors change (e.g., corporate merger, large percentage loss of market share etc.), which influence or impact the project in process, the business analyst will need to revisit the needs assessment and decisions made previously to ensure they are still valid for the situation the business is addressing.

A needs assessment involves the completion of a gap analysis that is used to analyze and compare the actual performance of the organization against the expected or desired performance.

Location 672: Much of the analysis completed during the needs assessment is then used for the development of a business case. It is the needs assessment and business case that build the foundation for determining the project objectives and serve as inputs to a project charter.

Location 677: When a formal needs assessment is sidestepped, the resulting solution often fails to address the underlying business problem or fails to solve the problem completely; it is also possible to provide a solution that is not needed or one that contains unnecessary features.

2.3. Identify Problem or Opportunity

Location 680: Part of the work performed within needs assessment is to identify the problem being solved or the opportunity that needs to be addressed. To avoid focusing on the solution too soon, emphasis is placed on understanding the current environment and analyzing the information uncovered.

The business analyst needs to ask “what problem are we solving?” or “what problems do our customers have that this opportunity will address?”

2.3.1. Identify Stakeholders

Location 684: Stakeholder identification is conducted as part of the needs assessment to assess which stakeholders are impacted by the area under analysis.

Location 690: During needs analysis, it is helpful to identify the following stakeholders:
~ Sponsor who is initiating and responsible for the project,
~ Stakeholders who will benefit from an improved program or project,
~ Stakeholders who will articulate and support the financial or other benefits of a solution, Stakeholders who will use the solution,
~ Stakeholders whose role and/or activities performed may change as a result of the solution,
~ Stakeholders who may regulate or otherwise constrain part or all of a potential solution,
~ Stakeholders who will implement the solution, and
~ Stakeholders who will support the solution.

Location 698: The affected stakeholders for a needs assessment can be categorized into one of four categories using a responsibility assignment matrix such as a RACI model:
R—Responsible => Person performing the needs assessment,
A—Accountable => Person(s) who approves the needs assessment, including the business case, when warranted,
C—Consult => Person or group to be consulted for input to understand the current problem or opportunity, and
I—Inform => Person or group who will receive the results of the needs assessment.

Collaboration Point: Both project managers and business analysts have an interest in stakeholder identification and RACI analysis. While the project manager is concerned about analyzing the roles across the project, business analysts may perform their analysis to a lower level of detail or may focus on one specific area, such as a needs assessment or requirements elicitation. Each may lend support to the other and work together to perform this work. It is important to ensure efforts are not duplicated.

2.3.2. Investigate the Problem or Opportunity

Location 714: The business analyst focuses on learning enough about the problem or opportunity to adequately understand the situation, but avoids conducting a complete requirements analysis at this stage.

Location 717: Initially, the business analyst may conduct interviews with stakeholders to investigate the situation and learn about the current environment. The business analyst may also review any existing documentation about current processes, methods, or systems that support the business unit.

Process modeling is one technique used to document current “as is” processes of the business.

2.3.3. Gather Relevant Data to Evaluate the Situation

Location 722: Once a broad understanding of the situation is obtained, it is necessary to gather relevant data to understand the magnitude of the problem or opportunity (also known as “sizing up” the situation).

Location 727: When no internal data exists or when it cannot be feasibly collected, benchmarking may be performed.

Benchmarking is a comparison of the metrics or processes from one organization against a similar organization in the industry that is reporting or finding similar industry averages. Data may not be readily available since competitors will guard nonpublic data closely.

Location 738: Once the desired data is assembled, techniques such as Pareto analysis and trend analysis can be used to analyze and structure the data.

2.3.4. Draft the Situation Statement

Location 739: Once the problem is understood, the business analyst should draft a situation statement by documenting the current problem that needs to be solved or the opportunity to be explored.

Location 744: The format of a situation statement is as follows: Problem (or Opportunity) of “a” Has the effect of “b” With the impact of “c”

Location 750: Before the development of a project charter, the business analyst drafts a situation statement for inclusion in a formal business case. Using the knowledge gained through the initial needs assessment work, the business analyst considers the identified business need and any initial assessment of the impact that the problem is having on the business.

2.3.5. Obtain Stakeholder Approval for the Situation Statement

Location 759: Once the situation statement is drafted, agreement is obtained from the affected stakeholders that were previously identified. This is a key step because the situation statement guides subsequent work for assessing the business need. When a formal situation statement and its approval are skipped, it is difficult to determine whether the essence of the current situation has been captured.

Location 764: The business analyst initiates and facilitates the approval process, which may be formal or informal, depending on the preferences of the organization.

Location 766: The business analyst leverages skills such as facilitation, negotiation, and decision making to lead stakeholders through this process.

2.4.1.1. Goals and Objectives

Goals are typically broad-based and may span one or more years. Objectives, on the other hand, are used to enable goals; these are more specific and tend to be of shorter term than goals, often with durations of 1 year or less.

Location 787: The most common link between goals and objectives and programs and projects is the business case.

2.4.2. SWOT Analysis

Location 808: In the absence of formal plans, the business analyst may use SWOT analysis to help assess organizational strategy, goals, and objectives.

Location 814: Internally:
Shows where the organization has current strengths to help solve a problem or take advantage of an opportunity.Reveals or acknowledges weaknesses that need to be alleviated to address a situation.

Location 819: Externally:
Generates potential opportunities in the external environment to mitigate a problem or seize an opportunity.Shows threats in the market or external environment that could impede success in solving business needs.

2.4.3. Relevant Criteria

Location 829: Goals and objectives provide criteria that may be used when making decisions regarding which programs or projects are best pursued.

Location 835: Criteria that were identified when reviewing the organizational goals and objectives will be useful later when comparing and rank-ordering potential solution options.

2.4.4. Perform Root Cause Analysis on the Situation

Location 838: Once a situation is discovered, documented, and agreed upon, it needs to be analyzed before being acted upon. After agreeing on the problem to be solved, the business analyst needs to break it down into its root causes or opportunity contributors so as to adequately recommend a viable and appropriate solution.

Location 842: Root Cause Analysis:
An analytical technique used to determine the basic underlying reason that causes a variance, defect, or risk. When applied to business problems, root cause analysis is used to discover the underlying cause of a problem so that solutions can be devised to reduce or eliminate them.

Location 848: Opportunity Analysis:
A study of the major facets of a potential opportunity to determine the viability of successfully launching a new product or service to enable its achievement. Opportunity analysis may require additional work to study the potential markets.

2.4.4.2. Cause-And-Effect Diagrams

Location 856: Cause-and-effect diagrams decompose a problem or opportunity to help trace an undesirable effect back to its root cause.

Location 858: They are typically high-level views of why a problem is occurring or, in the case of an opportunity, these views represent the main drivers for why that opportunity exists.

Location 896: Fishbone Diagrams. Formally called Ishikawa diagrams, these diagrams are snapshots of the current situation and high-level causes of why a problem is occurring.

Location 903: The problem to be solved is placed at the head of the fish, which can be either facing to the right or left.

Location 905: Use between three to eight causes or categories as an optimum number of causes associated with the problem. Standard categories, when used, can help guide the process and include machines, methods/systems, materials, measurements, people/customers, policies, processes/procedures, and places/locations.

Location 907: For each cause identified, ask why that cause is occurring and label any subcauses discovered. Generally, two to three levels will be sufficient to gain insights into the problem to understand its root causes.

Location 909: Look for patterns of causes, which are useful items to measure, model, or otherwise study in more detail. They are more likely to lead to the root cause of the situation. Circle those significant factors.

Interrelationship Diagrams. This special type of cause-and-effect diagram is helpful for visualizing complex problems that have seemingly unwieldy relationships among multiple variables.

Location 917: Constructing an interrelationship diagram helps participants isolate each dimension of a problem individually without it being a strict linear process. Focusing on the individual dimension allows participants to concentrate on and analyze manageable pieces of a situation.

Location 920: Here are some guidelines for using interrelationship diagrams: Identify the potential causes and effects, up to a maximum of ten to be practical.

Location 922: Draw lines between the effects and their causes. The arrows represent the direction of the cause. The arrow starts from the cause factor and points to the effect.

Location 924: When two factors influence each other, understand which of the two is stronger and note which one. Interrelationship diagrams are most effective when arrows are limited to one direction, namely the stronger influence.

Location 926: Factors with the largest numbers of “incoming”arrows are those that are key outcomes of other factors, that is, effects. These often provide good measures of success or can be good items to quantify and monitor.

Location 928: Factors that have a large number of “outgoing” arrows are the sources of the problem, that is, causes. Label the factor numbers in and out.

Location 931: The significant cause and effect factors can be depicted in bold to emphasize them.

Location 937: Process flows are not useful when analyzing opportunities. Process flow modeling can be used in conjunction with root cause analysis as it focuses on how aspects of current processes may contribute to the problem at hand.

Location 940: Some guidelines for using process flows for problem analysis include: Select the situation and place it at the top of the process map to emphasize the problem to be solved. Here it will remain highlighted.

Location 943: Identify the steps in the process that result in the problem. Try and keep the number of steps at a high level, often around ten or fewer steps.

Location 944: For each step, ask how that step may be contributing to the identified problem. For each cause, probe to find any subcauses and add them in a similar fashion to a fishbone diagram.

Location 947: Look for steps that have several issues as the best places to find changes or improvements, or perform further investigations to verify and/or measure. Circle the factors that are felt to be significant causes and subcauses of the problem being assessed.

2.4.5.1. Capability Table

Location 961: By examining each problem and the associated root causes, a needed capability can be discovered. One tool to help facilitate this analysis is a capability table, where the business analyst lists each limiting factor or problem, specifies the associated root causes, and then lists the capability or feature required to address the problem. Capabilities may also be represented in a visual model like a feature model.

2.4.5.2. Affinity Diagram

Affinity diagrams show categories and subcategories of ideas that cluster or have an affinity to each other. For problem solving, an affinity diagram is used to help organize and structure major cause categories and organize them by the capabilities needed to solve them.

Location 990: Affinity diagrams are used for multiple purposes.

Location 991: These are handy for drawing out common themes when faced with several disparate and potentially unorganized findings. These diagrams can be used to help connect related issues of a problem or opportunity.

Location 992: They can also provide insights into collections of factors to help understand root causes and possible solutions to problems. The latter point makes them useful for generating the necessary capabilities to address a problem or opportunity.

2.4.5.3. Benchmarking

Location 1001: A competitive analysis study typically falls into one of three types:

1. Casual review of other organizations’ public documents such as corporate reports or web pages,
2. Study of the major variables factoring into a solution or “secret shopping” at competitors’ stores or websites,
3. Reverse-engineering a specific product to determine its component details and the capabilities needed.

Location 1007: Benchmarking of capabilities provides insights that the organization would not have thought of on its own or would have used valuable time to discover them by trial and error.

2.4.6. Assess Current Capabilities of the Organization

A capability framework is a collection of an organization's capabilities, organized into manageable pieces, similar to business architecture.

2.4.7. Identify Gaps in Organizational Capabilities

Location 1036: Gap analysis is the technique of comparing the current state to the future state to identify the differences or gaps.

2.5.1. Include a High-Level Approach for Adding Capabilities

Location 1049: The business analyst should solicit preliminary feedback from business and technical architects when the recommendation is going to include new or modified hardware or software. For complex situations, when developing the approach, the business analyst should work with the architects to develop a high-level view of how the new capabilities will be interfaced with existing systems and applications, noting any major dependencies that will exist when the new capabilities are added.

2.5.2. Provide Alternative Options for Satisfying the Business Need

Location 1060: The primary reason for providing alternatives is to show that the alternatives were considered and to forestall objections from those who favor them.

Location 1061: Another reason for including alternatives is because the preferred approach may not be acceptable. Constraints such as cost, schedule, staffing, or vendor bias may preclude an option from being chosen, therefore, potentially, one alternative will be an acceptable choice.

Location 1063: While the business analyst does not decide which solution may be the best one, the business analyst is usually expected to make a recommendation and to support the recommendation with facts and evidence.

The solution decision is made primarily by the business sponsor or problem owner with additional input about solution feasibility from the solution team or those responsible for developing the solution.

2.5.3. Identify Constraints, Assumptions, and Risks for Each Option

Collaboration Point—Business analysts may draw on a project manager's expertise in risk planning and mitigation. Both roles are concerned with risk management. Project managers are focused on assessing the risks of the project as a whole, while the business analyst is focused on assessing the product risks. Business and technical architects can support this work too, as they may help uncover additional constraints or opportunities.

2.5.3.1. Constraints

Location 1074: Constraints are any limitations on a team's options to execute a program or project and may be business- or technical-related.

2.5.3.2. Assumptions

Location 1079: Assumptions are factors that are considered to be true, real, or certain, without actual proof or demonstration.

2.5.3.3. Risks

Location 1084: Risks are uncertain events or conditions that may have a positive or negative effect on one or more project objectives if they occur.

2.5.4. Assess Feasibility and Organizational Impacts of Each Option

Location 1090: The assessment involves comparing potential solution options for how viable each appears to be on key variables or “feasibility factors” (explained below). This comparison along with the elimination of any options that are not deemed sufficiently feasible is called feasibility analysis.

Location 1092: Another reason for analyzing the feasibility of alternatives is to reserve the often painstaking work of cost-benefit analysis for only the most feasible option.

2.5.4.1. Operational Feasibility
Location 1097: Operational feasibility represents how well the proposed solution fits the business need. It also encompasses the receptivity of the organization to the change and whether the change can be sustained after it is implemented.

2.5.4.2. Technology/System Feasibility

Location 1105: Technology feasibility pertains to whether or not the technology and technical skills exist or can be affordably obtained to adopt and support the proposed change. In addition, it includes whether the proposed change is compatible with other parts of the technical infrastructure.

2.5.4.3. Cost-Effectiveness Feasibility

Location 1111: Before conducting a full-fledged cost-benefit analysis of a potential solution, a high-level assessment of the financial feasibility of potential solutions is essential. Cost-effectiveness during feasibility analysis is not intended to be a complete cost-benefit analysis, but an initial and high-level feasibility estimate of costs and value of the benefits.

2.5.4.4. Time Feasibility

Location 1118: A potential solution will be feasible if it can be delivered within time constraints.

2.5.5. Recommend the Most Viable Option

Location 1132: Assuming that more than one option remains viable after feasibility analysis, the business analyst should recommend the most feasible option.

Location 1133: If only one option is judged to be feasible, that option, in most cases, would be recommended. When there are no viable options to address the need, one option is to recommend that nothing be done.

Location 1134: When faced with two or more feasible options for solutions, the remaining choices can be rank-ordered based on how well each one meets the business need.

2.5.5.1. Weighted Ranking

Location 1139: A weighted ranking matrix or table combines pair-matching with weighted criteria to add objectivity to a recommendation. Pair-matching is performed by taking each option and comparing it one by one to all other options, and then voting or ranking which option is the most preferred.

Location 1141: Weighted ranking is also useful to test an initial or intuitive choice against other options.

The criteria used for ranking should align with the goals and objectives identified earlier in the needs assessment.

Location 1144: Guidelines for constructing and using a weighted ranking table are:

1. Include between three and nine criteria as a practical range for the number of criteria.
2. If a problem has fewer than three criteria, then a weighted ranking matrix is rarely needed to analyze each option.
3. If there are more than nine criteria, it will be difficult for stakeholders to judge and compare the alternatives.
4. Additionally, the problem may be overly complex and may need to be broken into subsets to properly analyze it.

2.5.6. Conduct Cost-Benefit Analysis for Recommended Option

Location 1166: Before recommending a preferred option, a cost-benefit analysis should be performed.

2.5.6.1. Payback Period (PBP)

Location 1173: The payback period (PBP) is the time needed to recover a project investment, usually in months or years. The longer the PBP, the greater the risk.

2.5.6.2. Return on Investment (ROI)

Location 1176: The return on investment (ROI) is the percentage return on an initial project investment. ROI is calculated by taking the projected average of all net benefits and dividing them by the initial project cost.

Location 1177: This valuation method does not take into account ongoing costs of new products or services, but is still a widely used metric.

2.5.6.3. Internal Rate of Return (IRR):

Location 1180: The internal rate of return (IRR) is the projected annual yield of a project investment, incorporating both initial and ongoing costs.

Location 1181: IRR is the estimated growth rate percentage that a given project is expected to attain.

2.5.6.4. Net Present Value (NPV)

Location 1184: The net present value (NPV) is the future value of expected project benefits expressed in the value those benefits have at the time of investment. NPV takes into account current and future benefits, inflation, and it factors in the yield that could be obtained through investing in financial instruments as opposed to a project.

Location 1186: Any NPV greater than zero is considered to be a worthwhile investment, although a project with an NPV less than zero may be approved if the initiative is a government mandate, for example.

Collaboration Point—When estimating benefits and costs, a business analyst may work with a project manager with expertise in preparing estimates. Business analysts should also seek the support of financial analysts within the organization who can assist with the application of the valuation methods against the alternatives.

2.6. Assemble the Business Case

Location 1199: As described previously, a business case explores the nature of the problem or opportunity, determines its root causes or contributors to success, and presents many facets that contribute to a complete recommendation.

Note: The formality of a documented business case and project charter is commonly required in large or highly regulated companies.

2.6.1. Value of the Business Case

Location 1218: When a business case is created, it becomes a valued input to project initiation, providing the project team with a concise and comprehensive view of the business need and the approved solution to that need. More than a simple input, a business case is a living document that is constantly referenced throughout a program or project of work. It may be necessary to review and update a business case based on what is discovered as a program or project progresses over time.

Location 1222: When a business case is inadequate or nonexistent, the product scope may be unclear or poorly defined. This in turn often leads to scope creep, which results in rework, cost overruns, and project delays.

Collaboration Point—Business analysts work closely with the sponsor to create a business case. When the project manager is known, the business analyst consults with the project manager to achieve a stronger business case through close collaboration. The project manager may better understand the business need, feasibility, risks, and other major facets of the business case. When a project or program is approved, the business analyst and project manager may work together during initiation to ensure the business case is properly translated into a project charter and/or similar document.

3. PLANNING

3.1. Overview of this Section

Location 1234: Within business analysis, planning consists of the activities that are performed in order to ensure that the optimal business analysis approach is selected for the project and that:

1. Stakeholders are thoroughly identified and analyzed;
2. Business analysis activities and deliverables are defined and agreed to;
3. Processes that will be used for validating, verifying, and approving requirements and solutions are acceptable to key stakeholders;
4. The process for proposing changes to requirements is defined and understood; and
5. Key stakeholders are aware of and support the activities and time commitments required to complete the requirements effort.

The business analysis approach is simply the method the business analyst uses when managing and performing the business analysis activities on the project.

3.2. The Importance of Business Analysis Planning

Location 1251: When business analysis planning is bypassed, it is difficult to understand the scope of work, stakeholder's expectations, and the appropriate amount and level of business analysis required for the project. This in turn makes the estimation process difficult and can result in unrealistic expectations by those involved in the requirements-related activities. Business analysts who begin elicitation sessions without a well thought out roadmap of how they will address the work will often find themselves pressed for time and rushing through activities to meet a schedule to the detriment of the project.

3.2.1. Rationale

Location 1260: Business analysis planning achieves the following:

1. Sets expectations with the sponsor, project team, and key stakeholders as to the business analysis activities that will be performed;
2. Ensures that roles are identified, understood, and communicated to everyone participating in the business analysis process;
3. Achieves buy-in and support for the business analysis process before work begins;
4. Provides context to support estimation of the business analysis activities;
5. Produces a more efficiently run business analysis process, because activities are not missed or excessively performed.

When using a predictive life cycle, planning is performed up-front prior to elicitation. In adaptive life cycles, some planning is performed up-front and plans are adapted or evolve over the course of the program or project.

Location 1270: Too much planning can be counterproductive, therefore the business analyst needs to plan a sufficient level of detail to address the specific needs of the project such as the size, complexity, and risk level.

3.2.2. Business Analysis Planning and Project Management Planning

Business analysis planning and scheduling is not performed independent of project management scheduling activities. It is a best practice to have the project manager and business analyst working closely together while the business analysis approach and plan is formulated.

3.3. Conduct or Refine the Stakeholder Analysis

Location 1281: A stakeholder is an individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a program or project.

Location 1282: Stakeholder analysis is a technique used to systematically gather and analyze quantitative and qualitative information to determine whose interests should be taken into account throughout the project. Stakeholder analysis is often conducted during the planning phase so that the project team can understand the stakeholder impacts and influences on the business analysis process as early as possible. Stakeholder analysis is performed iteratively and is revisited throughout the project as new stakeholders are discovered or existing stakeholders are determined to no longer be impacted by the proposed solution.

3.3.1. Techniques for Identifying Stakeholders

Location 1298: Existing documentation, such as organizational charts or process flows, can help to identify user groups. Common techniques that can be used in the discovery of stakeholders are brainstorming, decomposition modeling, interviews, surveys, or organizational modeling, to name a few.

3.3.1.1. Brainstorming

Location 1301: Brainstorming is a data gathering technique that can be used to identify a list of ideas in a short period of time (e.g., list of risks, stakeholders, or solutions to issues). Brainstorming is conducted in a group environment and is led by a facilitator.

Because the discussion occurs in a group setting, participants feed off of each other's inputs to generate additional ideas.

Location 1307: Brainstorming is comprised of two parts: idea generation and analysis. The analysis is conducted to turn the initial list of ideas into a usable form of information. In business analysis planning, brainstorming can be leveraged to build the initial list of stakeholders, to discover new stakeholders, or to identify a list of tasks to be included in the business analysis work plan.

3.3.1.2. Organizational Charts

Location 1311: The business analyst reviews the chart to locate stakeholder groups who may be impacted by the product or service. This may include departments who operate or maintain a system, produce a product or service, support customers, or influence product or service decisions within the area under analysis.

3.3.2.1. Attitude

Location 1329: Stakeholders who are positive about the project and solution may serve as project champions; these stakeholders will assist the project team in building excitement and support for the solution.

Location 1330: Identifying non-supportive stakeholders can help identify areas where additional collaboration is needed. Spending more time with these stakeholders may uncover unspoken business needs, requirements, training issues, resource constraints, or past and current experiences important for the project team to understand.

Location 1334: A stakeholder who exerts dislike or disinterest in a project may simply see no value in the initiative or final solution. The stakeholder group may be included in the project because its business processes are impacted, but these stakeholders may not be recipients of direct value from the work.

Location 1336: Stakeholder groups may be recipients of additional work after a project is implemented and therefore never display a high level of interest. Those stakeholders whose workload is likely to increase may never become supportive of the project.

3.3.2.2. Complexity

Location 1339: A stakeholder group can be considered complex for a number of reasons, including but not limited to whether the group:
~ Is comprised of a large number of stakeholders,
~ Is made up of stakeholders with vastly different needs,
~ Has a number of business processes impacted by the project,
~ Exhibits a lack of uniformity across business processes,
~ Interacts with a number of business units to complete their work, or
~ Performs work across a number of IT systems, and/or systems external to the organization.

Location 1346: Understanding complexity levels will help when quantifying and planning the number of requirement sessions to conduct, when determining the right amount of requirements-related documentation to produce, and when determining the level of formality to apply in those deliverables.

Location 1348: Complexity levels are also helpful to understand when assessing solution options and the change impacts that a project will have on stakeholder groups.

Location 1349: PMI's Pulse of the Profession® In-Depth Report: Navigating Complexity identified multiple stakeholders, followed by ambiguity in project features as the top reasons for project complexity

Collaboration Point—Project managers are interested in understanding the complexity level of the project in order to allocate sufficient time for project activities, including collaboration and communication with stakeholders. The business analyst assesses complexity to understand how best to approach business analysis activities and to understand the impact that the change will have on stakeholders.

3.3.2.3. Culture

Location 1361: Culture can impact how the business analyst proposes communicating with stakeholders, eliciting requirements, conducting requirement walkthroughs, and running the prioritization, approval, and change processes. Culture and location are not the same thing. Even when all the stakeholder groups reside in one location, there are cultural differences among the groups.

Location 1363: Cultural differences impact how stakeholders:
~ Perform their work,
~ Interact with other team members,
~ Contribute to the decision-making process,
~ Interpret nonverbal communication,
~ Understand the primary written and spoken language of the team,
~ Question or interact with authority,
~ View their role on the team,
~ Raise questions or issues,
~ Negotiate, and
~ Deal with conflicts.

3.3.2.4. Experience

Location 1373: Elicitation may be completed more efficiently when stakeholders have prior experience participating in requirement workshops or validating requirements than with a team of stakeholders who are unfamiliar with business analysis or do not understand the value of the business analysis activities.

Location 1378: The business analyst will also find it important to analyze experience across stakeholder groups to ensure that a sufficient breadth of business knowledge is represented on the requirements team.

3.3.2.5. Level of Influence

Location 1383: A person's level of influence is often tied to his or her position within the organization; however, influence is not solely associated to a person's rank, reporting structure, or job title. A person's level of influence is also affected by business relationships, reputation, knowledge or level of experience, or successes within the organization. Analyze the level of influence to understand the power an individual or stakeholder possesses.

3.3.2.6. Location and Availability

Location 1400: Location affects a number of business analysis planning decisions such as:
~ Determining the techniques that are most effective to elicit requirements,
~ Estimating how much time is required to complete business analysis activities,
~ Deciding on the formality and level of detail required for the business analysis deliverables,
~ Deciding on the types of models to use,
~ Determining the approach and frequency of collaboration, and
~ Determining how requirements will be managed, maintained, and shared with project stakeholders.

3.3.3. Techniques for Grouping or Analyzing Stakeholders

There are several techniques that can be used to group or analyze stakeholders such as job analysis, organizational modeling, personas, process modeling, risk analysis, and stakeholder maps

3.3.3.1. Job Analysis

Location 1415: Job analysis is a technique used to identify the job requirements and competencies needed to perform effectively in a specific job or role. The technique is often used when a new job is created or when an existing job is modified.

Location 1418: The output of job analysis may include a number of details such as the description of the work, a depiction of the work environment, a detailed list of the activities a person will perform, a listing of the interpersonal skills required to perform well in the job, or a list of required training, degrees, and certifications.

3.3.3.2. Persona Analysis

Location 1425: Persona analysis is a technique that is conducted to analyze a class of users or process workers. It is a powerful tool for understanding stakeholder needs and for targeting product design and behavior for each class of user.

A persona is a fictional character created to represent a user group or group of stakeholders who have similar needs. Personas are often used in IT systems development and product development to help design or map out a user's experience.

Location 1432: The objective is to analyze usage information or draw out user requirements to determine how a user class interacts with a system or how a user class would use a product.

Location 1433: The difference between a persona and a stakeholder is that the persona includes much more detail about how it interacts with the problem or solution space, such as, device literacy and preferences, preferred method for searching, and frequency of performing specific actions, etc.

Location 1439: A persona is written in the form of a narrative and tells a story about the user class. Personas describe the goals, behaviors, motivations, environment, demographics, and skills of the user class.

Location 1441: The information provided in the persona is behavioral in nature versus the information that is obtained from a job analysis that would be descriptive in nature. A persona is usually one to two pages in length.

3.3.4. Assemble the Stakeholder Analysis Results

As stakeholder characteristics are analyzed, the business analyst may choose to document the results of the analysis in a way that can be shared with the project manager, project team, and sponsor. Much of the information being gathered and analyzed could be considered sensitive in nature; therefore, the business analyst should exercise care when distributing the analysis to a broad distribution group.

3.4. Create the Business Analysis Plan

Location 1451: A business analysis plan is created to document how the business analysis process will be performed, including the plan decisions agreed to by the project team.

Location 1461: In some cases, it may not be possible or desired to plan the entire approach up-front. Rolling wave planning may be used, which involves planning from a high-level first and a more detailed level later on in the project when the activities are ready to be performed.

Collaboration Point—The business analyst should build the business analysis plan collaboratively with key stakeholders to attain buy-in. A plan that is constructed by the team provides a sense of ownership to those involved and sets expectations by bringing awareness to how the work will be performed.

3.4.1. Business Analysis Plan vs. Requirements Management Plan

Location 1469: In the project management discipline, a requirements management plan is a component of the project management plan and describes how the overall requirements of the project will be elicited, analyzed, documented, and managed across the project. The requirements management plan covers planning decisions for both the product and project requirements.

Collaboration Point—The business analysis plan works in conjunction with the requirements management plan. The business analyst should work closely with the project manager to ensure content is not duplicated between the documents and that the planning decisions for both the project requirements and product requirements are covered.

3.4.2. What to Include in the Business Analysis Plan

Location 1481: The business analysis plan is focused on the scope of the business analysis effort. This includes a list of the activities to be conducted and the business analysis deliverables to be produced. A list of the roles required to successfully conduct the business analysis process is included in the business analysis plan. Key process decisions are also included, for example, the approach for prioritizing, documenting, validating, communicating, approving, and changing requirements.

Location 1484: All planning decisions should be documented in a straightforward and clear manner so that stakeholders know what to expect when business analysis activities begin.

Location 1485: Where team members disagree with one or more of the decisions being made, the business analyst assumes responsibility for negotiating and bringing the team to consensus.

Location 1493: Generally, decisions that are reflected in the business analysis plan and are influenced by the selected project life cycle include:
~ Type of elicitation activities to be conducted;
~ Requirements analysis models that are required or expected;
~ How requirements will be documented and communicated to stakeholders, including the use of any specialized tools;
~ Business analysis deliverables to be produced;
~ Roles and responsibilities for those participating in the requirement activities;
~ How requirements will be prioritized, approved, and maintained;
~ List of requirement states that will be tracked and managed in the project;
~ How requirements will be validated and verified; and How the acceptance criteria will be determined for the requirements and solution validation.

3.4.2.1. Determining the Proper Level of Detail

The business analyst should avoid being too prescriptive and try to find a balance in the amount of planning performed.When developing a business analysis plan, the business analyst should not attempt to document every aspect of the business analysis approach as that tactic is time-consuming and ineffective.Do not sacrifice good management practices for flexibility.

3.4.3. Understand the Project Context

Location 1520: Before planning decisions are made, the business analyst analyzes the characteristics of the project in order to determine the approach, including but not limited to the following:
~ Project size,
~ Project complexity,
~ Type of project,
~ Risk level,
~ Risk tolerance,
~ Geographic distribution of stakeholders,
~ Aggressiveness of project timelines,
~ Selected project life cycle, Imposed constraints and/or regulations,
~ Market conditions and/or competitive landscape,
~ Technology trends,
~ Level of detail and formality required for deliverables,
~ Time to market requirements, and
~ Experience level of the business analysts assigned to the project.

3.4.4. Understand how the Project Life Cycle Influences Planning Decisions

Location 1535: A project life cycle is the series of phases that a project passes through from its initiation to its closure.

Location 1541: Predictive Life Cycle:
~ Emphasis is on minimizing uncertainty.
~ Scope is entirely defined up-front.
~ Time and cost estimates are determined for the entire project when scope is defined.
~ Business analysis is conducted mostly up-front;
~ Requirements are completed before product development begins.
~ Deliverables are determined at the onset of the project.
~ Changes to scope are carefully managed.
~ Business value is delivered through one implementation.
~ The need and solution are known and do not change throughout the project.

Predictive life cycle methods are also referred to as plan-driven, traditional, or waterfall methods.

Location 1550: Iterative/Incremental Life Cycle:
~ Project is split into phases and project phases are intentionally repeated.
~ Project work is performed sequentially or with some overlap in iterations.
~ High-level scope is defined up-front and the detailed scope is elaborated upon for each iteration.
~ Scope for future phases is defined when the prior phase starts or completes.
~ Product is developed iteratively as features are added incrementally.
~ Business analysis is performed up-front and then in small amounts throughout the project.
~ Requirements analysis is performed in time-boxed iterations.
~ The need and solution become more stable as the project progresses.

Location 1558: Adaptive Life Cycle:
~ Business value is emphasized over minimizing uncertainty.
~ Time and cost estimates are fixed for each iteration.
~ Iterations are conducted quickly.
~ Overall scope is agreed to early.
~ Detailed scope and product requirements are defined for a single iteration at a time.
~ Changes are expected; when new requirements are presented, these are captured in a product backlog, and then the backlog is reprioritized.
~ Business value is delivered iteratively.
~ Business analysis is constant.
~ The need and solution are unknown and unstable.

Adaptive life cycle methods are also referred to as change-driven or agile methods.

Location 1567: The project life cycle impacts a number of decisions about the business analysis process, such as:
~ Business analysis activities that are to be performed,
~ Order in which the activities will be completed,
~ Timing of activities, Deliverables,
~ Level of formality required for deliverables,
~ Approach for prioritizing requirements, and
~ Methods for addressing requirement changes.

3.4.5. Ensure the Team is Trained on the Project Life Cycle

Collaboration Point—Business analysts are responsible for stakeholder engagement in the business analysis process and the project manager is responsible for stakeholder engagement across the project. There is an opportunity for the roles to work together to determine the readiness and willingness of key stakeholders to participate in project activities.

3.4.6.1. Lessons Learned

Location 1583: Lessons learned is the knowledge gained during a project, which shows how project events were addressed or should be addressed for the purpose of improving future performance.

Location 1586: Lessons learned sessions are typically scheduled after the conclusion of a major phase or completion of a project.

Collaboration Point—Project managers and business analysts may each conduct lessons learned sessions; the project manager obtains feedback on completed project activities and the business analyst focuses on completed business analysis work. Instead of working independently, the roles should collaborate and facilitate the session together.

3.4.6.2. Retrospectives

Location 1595: In adaptive life cycle projects, retrospectives are meetings that are scheduled on a regular basis or conducted when a body of work is completed, such as the conclusion of an iteration or at the end of a project phase. Retrospectives have been used for many years in the development process of Kanban, agile approaches (e.g., Scrum and eXtreme programming), and in Lean methods, such as Kaizen and continuous improvement.

Location 1598: The purpose of a retrospective is to task the project team with identifying those areas where team performance can be improved. The team reflects on their successes and areas for improvement. The facilitator takes responsibility to ensure everyone in the room participates and works together to determine a course of action.

Typically retrospectives use the following steps:
~ Set the stage => The context and tone for the meeting is established.
~ Gather data => Factual and relevant data is pulled together to support feedback.
~ Generate insights => The team looks for commonality in the feedback including cause and effect.
~ Decide what to do => The team collaborates to determine a course of action for improvement.
~ Close the Retrospective => The session is ended.

Location 1606: This process is often facilitated with a list of simple questions: What is working? What is not working? What needs to change? The facilitator uses charts and other visual methods to capture the information presented. The process is highly collaborative.

Location 1609: The biggest differences between lessons learned and retrospectives are in the timing and speed by which issues raised are addressed and the formality around documenting the learnings. Because adaptive life cycles offer more opportunity, retrospectives occur regularly and frequently, such as at the end of each sprint, or at the end of a Kanban delivery. Retrospectives may also be scheduled on a once-a-week basis, irrespective of delivery. Retrospectives are conducted in a highly collaborative fashion and decisions made are most often implemented with little formal documentation.

Location 1613: Lessons learned are conducted at the end of stage gates or a phase such as a project closeout or when events occur that are worth learning from. Although lessons learned can be conducted more frequently, these are used less frequently than retrospectives and may be driven by the occurrence of an event versus a fixed schedule. Learnings discussed are formally documented and stored in a repository for future reference. Project teams leverage the lessons learned repository as an input prior to planning work on subsequent projects.

Due to the frequency by which retrospectives occur and because they are held multiple times over the course of a single project, improvements can be applied immediately, allowing the value to be gained from the proposed improvement in the next iteration.

Location 1622: To ensure that the frequency of retrospectives does not diminish their value, it is important that retrospectives are kept fresh to avoid mundane gatherings where time is not well spent. The team needs to meet often enough to conduct valuable sessions but not too often that the task is considered a waste of time.

Location 1624: Retrospectives assist in generating ideas to improve team performance but are not a replacement for training and coaching staff on process. Retrospective and lessons learned data are valuable inputs when formulating an approach for how to conduct the business analysis work for a project.

3.4.7. Plan for Elicitation

Location 1628: At this stage of planning, the business analyst should begin to think about how and when to elicit, which techniques to use, and the sequence of the elicitation activities.

Location 1633: There are a number of factors to consider when planning for elicitation:
~ Stakeholder group characteristics and dynamics,
~ Project life cycle,
~ Characteristics of the technique (e.g., speed of use, particular advantages),
~ Type of project,
~ Time constraints,
~ Budget,
~ Number of stakeholders,
~ Location of stakeholders,
~ Types of requirement deliverables being produced,
~ Level of detail required in business analysis deliverables, and
~ Techniques that are familiar to the business analyst and key stakeholders involved.

Location 1643: The business analyst balances the needs of the project against the quantity of requirements elicitation conducted with the goal of eliciting the right amount to sufficiently define the product solution.

Location 1648: When insufficient time is allocated for elicitation activities, dependent downstream tasks may be delayed when business activities extend past the projected timelines.

3.4.7.1. Strategies for Sequencing Elicitation Activities

Location 1657: There are a number of strategies the business analyst may consider when determining which areas of requirements elicitation to address first. Suggested areas of focus are where there are:
~ Significant amounts of business value to be gained,
~ Greater risks,
~ Many project unknowns or uncertainties,
~ Significant technical challenges,
~ Dependencies on other components or interfaces,
~ Required third-party resources that the project is dependent on, and
~ Limited number of resources or a risk that a key resource may leave the project or company.

Collaboration Point—When deciding the order of business analysis activities, the project manager and business analyst should work together to determine how the resource availability will impact sequencing decisions.

3.4.8. Plan for Analysis

Location 1669: Planning for analysis occurs at a high level in much the same manner as elicitation planning.

At the planning stage, the business analyst is just starting to think about how to approach the analysis activities and much of what is considered here may change as the elicitation activities proceed. Planning for analysis is iterative and occurs throughout the project.

3.4.9. Define the Requirements Prioritization Process

Location 1680: To minimize conflict during the requirements prioritization activities, the business analyst should define the process for establishing priorities before the requirements are elicited. Setting expectations early with stakeholders helps to minimize situations where stakeholders become unhappy when their requirements are prioritized to the bottom of the list.

Location 1684: Some common factors to consider when defining the prioritization process are:
~ When requirements prioritization will occur,
~ The likelihood that priorities will change,
~ Stakeholders who will be involved in the prioritization process,
~ Techniques that will be used for prioritization,
~ Criteria that will be used to prioritize, and
~ Stakeholders who will approve the prioritization decisions.

The project life cycle influences the prioritization process and often dictates the frequency, timing, and techniques for performing prioritization. For example, adaptive life cycles use prioritization techniques for each iteration in order to determine the features to be provided in the next release of the product. Projects using a predictive or waterfall life cycle will conduct prioritization up-front before product construction begins. Priorities may still shift in a waterfall project, but incorporating such changes is more difficult than in a project following an iterative development cycle.

Location 1695: Requirements are prioritized based on a number of factors such as: Value.
~ Addressing high-value requirements first to reap the financial or goodwill benefits up-front.
~ Cost.
~ Evaluating requirements based on financial costs or opportunity costs.
~ Difficulty.
~ Considering how difficult the requirement is to fulfill.
~ Regulatory.
~ Addressing regulatory or legislative requirements that have imminent compliance deadlines first.
~ Risk.
~ Implementing high-risk requirements first to uncover issues early.

Location 1702: Some common techniques for determining priority are MoSCoW, multivoting, timeboxing, and weighted ranking.

3.4.10. Define the Traceability Approach

Location 1706: Traceability involves documenting requirement relationships and is used in business analysis to maintain product scope.

Location 1707: When a traceability approach is defined and adhered to, requirement relationships are created, which allow the project team to trace backwards to identify the origin of a requirement, trace forward to identify how the requirement was tested and implemented, or trace in-between requirements to provide insight into the value a group of related requirements can deliver.

Requirements that are documented but fail to trace to a business need are considered out of scope.

Location 1712: Those requirements affected by a change can be evaluated to understand how a change in that requirement impacts (a) the related project components already built to satisfy the requirement or (b) test cases already created to test the feature, etc.

Location 1718: The types of traceability decisions the business analyst should consider are:
~ Types of requirements to be traced,
~ Level of detail to trace to,
~ Relationships that will be established and maintained,
~ Requirement attributes to be tracked,
~ Requirement states that drive the requirements life cycle (for example, approve, defer, reject, etc.),
~ Tools used to perform the traceability, and
~ Process decisions regarding how traceability will be established and maintained.

Location 1727: To ensure the traceability approach is adequately sized for the project, the value of the process should be compared against the time and cost required to establish and support it. Risks should also be analyzed to ensure additional risks are not introduced by proposing a traceability process that increases the likelihood of missing requirements in the final product.

Collaboration Point—The right amount of traceability helps to reduce project risks, but too much traceability works against the project team and incurs costs and schedule impacts unnecessarily. The project team has an opportunity to collaborate and define a traceability approach that is suitable for the needs of the project. Business analysts should not define the traceability approach independently as decisions on traceability are very interrelated to project factors that the project manager is responsible for managing.

3.4.11. Define the Communication Approach

Location 1736: A communication approach describes how business analysis information will be structured and when communication to stakeholders will occur. The approach can be formally documented in the business analysis plan or in a separate business analysis communication plan if the project or organizational needs require this level of structure or formality.

Location 1740: When defining the business analysis communication approach, consider the following: Types of requirements and requirements-related information that will be communicated, Who requires communications and what information they expect, Stakeholder preferences for receiving information (e.g., summary level or detail), Preferred delivery methods for distributing or accessing requirements and requirement related information, Level of formality required in the communication, and Tools, including requirement repositories, which stakeholders will need access to.

Location 1752: The time zone and physical locations of the stakeholder should be considered when defining the communication approach.

Collaboration Point—The business analyst should not create the communication plan independently of the project manager. If the business analysis communication plan is formally documented, agreement should be reached on whether the information will be kept as a subplan or included within the project manager's communication plan.

3.4.12. Define the Decision-Making Process

Location 1762: When there are differences regarding how decisions should be made, the business analyst facilitates agreement and clears up conflicting viewpoints prior to the execution of the business analysis activity.

Location 1765: The following information can be considered when defining the decision-making process: Types of decisions that will be made, including how requirements will be approved, Roles and authority levels, for example, who is involved in the discussions and who makes decisions, etc., Process to follow when consensus cannot be reached and requirements-related issues need to be escalated, Required turn-around time for a decision to be reached, How decisions are documented and communicated, including requirements signoff, and Special tools or techniques that may be used to help teams evaluate alternatives, for example, decision analysis, decision modeling, decision trees etc.

3.4.13. Define the Requirements Verification and Validation Processes

Location 1774: According to the PMBOK® Guide –Fifth Edition, verification is the evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. Validation is the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. Requirements and associated requirement models are both verified and validated.

Location 1778: In business analysis, requirements verification is the process of reviewing requirements and models to ensure they meet quality standards.

Verification can be conducted iteratively as requirements are in development. All requirement types should be verified, for example, business requirements, stakeholder requirements, solution requirements, etc.

Location 1782: Requirements validation is the process of ensuring that all requirements accurately reflect the intent of the stakeholder and that each requirement aligns to one or more business requirements. Validation is performed through the use of structured walkthroughs and traceability.

Quality standards should be defined in planning so they are known prior to requirements development and verification activities. Verification processes often leverage checklists to define the quality attributes. When a checklist will be leveraged for the verification process, the business analyst ensures that the checklist is created before the verification activities begin.

3.4.15. Define the Solution Evaluation Process

Location 1817: Defining the solution evaluation process identifies how a solution is evaluated during the evaluation phase, which activities will be performed, what techniques will be applied, and how information will be analyzed.

Location 1820: Evaluation is performed before and after a solution is implemented. When evaluation is conducted after a solution is implemented, new or changed requirements may be identified, which can lead to refinement of the solution or can generate new projects for the purpose of creating a new version of the product. The project life cycle influences the timing and frequency of the evaluation activities.

Location 1824: Solution evaluation planning involves defining the following:
~ Evaluation criteria and acceptance levels;
~ Qualitative and quantitative evaluation activities to be performed;
~ How the solution will be evaluated;
~ When and how often evaluation will be performed;
~ Evaluation techniques that will be used, for example, focus groups, observations, surveys, etc.;
~ Whether any special measurement tools will be required; and
~ How results will be analyzed and reported.

3.5.1. Determine who Plans the Business Analysis Effort

Collaboration Point—Planning is an area where project managers and business analysts will find that their roles overlap. Ultimately the project manager is responsible for the project management plan and is accountable for managing all project activities. The business analyst can help support the project manager, because the business analyst has expertise with the business analysis process and can provide specifics on the business analysis work that is recommended to meet project objectives.

3.5.2. Build the Business Analysis Work Plan

Location 1850: The business analysis work plan is the project plan that covers the work to be performed during the business analysis process. The business analyst is responsible for identifying this work using all the project and environment information known to them, for example, selected project life cycle, project size, known risks, organizational process assets, etc.

Location 1852: It is critical that the project manager be included and involved as the business analyst lays out this work, because ultimately the business analysis work plan will be integrated within the project management plan.

The first step in building the plan is identifying the deliverables that the business analyst is responsible for producing.

3.5.2.1. Identify the Deliverables

Location 1857: According to the PMBOK® Guide –Fifth Edition, a deliverable is any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project.

Agendas, meeting minutes, parking lot lists, and some types of models, although necessary to organize work and perform effectively, are not required to be produced and, therefore, are not considered a business analysis deliverable. These items are often referred to as work products and are created in order to perform the work, but are not a promised deliverable that will be tracked and managed through the project management plan.

Location 1862: During planning, the business analyst should think about the work products and how they will be created, stored, accessed, and used by the project team. Planning for work products is much less formal than deliverables.

Location 1864: Deliverables, on the other hand, are required and often impact the work of individuals who perform activities later on in the project life cycle. These documents are usually formatted for consistency across projects and often have an approved structure or template that the business analyst is required to use.

Location 1868: Examples of these include, but are not limited to:
~ a high-level requirements document,
~ software requirements specification,
~ user stories,
~ business rules catalog, and
~ a non-functional requirements list.

Location 1871: The business analyst should consider the following when planning the business analysis documentation:
~ What deliverables will be produced;
~ How deliverables will be used by other team members and key stakeholders;
~ How changes to deliverables will be managed;
~ Required formality of the deliverables;
~ How deliverables will be accessed and by whom;
~ Tools that are required to produce, maintain, or store deliverables; and
~ Whether requirements will be reused on future projects.

Collaboration Point—The business analysis deliverables produced for the project are determined by the business analyst but these decisions are not made independently. The business analyst solicits input from the sponsor, project manager, and key stakeholders to ensure that expectations are met. The business analyst should work closely with the project manager, because deliverables impact the project schedule and can create dependencies for other downstream project work.

3.5.2.2. Determine the Tasks and Activities

Location 1884: After agreeing on the list of deliverables that will be produced to satisfy the project objectives, the business analyst begins to define the activities required to produce them. Each deliverable requires the completion of one or more activities. The project team should work together to define the task list.

Location 1886: Task identification is an iterative process. The business analyst may use a number of techniques to help identify a complete list. Brainstorming, decomposition modeling, interviews, and lessons learned are a few of the techniques that can be used.

Decomposition model. A decomposition model is an analysis model used to break down a high-level object into smaller more discrete parts. Typical objects often analyzed with decomposition may be solution scope, organizational units, work products, processes, functions, or any other object types that can be subdivided into smaller elements. A decomposition model is easy to produce and the models are easily constructed and understood by stakeholders.

Location 1893: Decomposition models cannot be used to show sequence and process steps.

Location 1894: In business analysis planning, a decomposition model is used to identify business analysis tasks, activities, and deliverables by detailing out the business analysis work. When conducting stakeholder analysis, a decomposition model is used to analyze the organization with the goal of discovering stakeholder groups. On IT projects, this type of model is helpful to break down solutions into solution components to further understand their features.

Decomposition models are also referred to as decomposition diagrams.

3.5.2.3. Determine the Timing and Sequencing of Tasks

Location 1898: The timing of business analysis tasks is directly influenced by the selected project life cycle. Sequencing is also influenced by a natural order, because some tasks require the completion of outputs produced by other activities.

Location 1900: The business analyst analyzes these factors and may consider one or more of the following when determining the sequence of activities for the work plan:
~ Availability of resources required to perform or contribute to the work,
~ Needs of downstream recipients whose work relies on the business analysis deliverables,
~ Relationship of project work to other work being performed within the organization,
~ Contractual and statement of work obligations,
~ Dependencies on training and tools to perform the business analysis work,
~ Staffing and new hire needs, and
~ Risk and complexity level of tasks.

3.5.2.4. Determine the Roles and Responsibilities

Location 1909: RACI analysis is also performed in business analysis when determining roles and responsibilities for the business analysis effort. The business analyst cannot assume that everyone involved in the business analysis process knows their role or what they are accountable for.

Location 1912: While the RACI is used to document the role responsibilities across the team, it is also valuable to use this technique to define the role responsibilities between the project manager and the business analyst.

Determining roles and responsibilities at the start of the project helps to minimize confusion and conflicts, especially in areas where responsibilities appear to overlap.

Location 1915: In business analysis activities, it is essential to understand who is responsible for providing requirements, who has authority to approve requirements, who can make decisions or settle differences when they arise, and who is involved when changes to requirements are proposed. The RACI technique can be used to facilitate, sort through, document, and gain approval on these decisions.

Location 1917: In addition, the RACI can be used as a communication tool. It can be referenced throughout the business analysis work when conflicts arise over authority and responsibility levels.

Location 1919: Once completed, the RACI matrix can be included as part of the business analysis plan to ensure these decisions are approved and managed.

Collaboration Point—The business analyst and project manager share a common interest in ensuring that key stakeholders fully understand and agree to the roles and responsibilities they hold on a project. While the project manager is managing these expectations across the project, the business analyst is managing these expectations during the business analysis activities.

3.5.2.5. Identifying the Resources

Location 1926: As a minimum, the business analyst needs to ensure that all functional areas impacted by the project are represented by a resource during requirements elicitation, validation, and approval activities. As subject matter experts are often coveted across the organization and often allocated on multiple projects, business analysts should raise any concerns obtaining commitments from resources once the resources are assigned to the project.

Collaboration Point—The business analyst can lend their expertise and personal insight to the project manager as they work collaboratively to determine the optimal number of subject matter experts to engage on the business analysis activities.

3.5.2.6. Estimate the Work

Location 1934: As the work plan details begin to emerge, the business analyst plays a key role in defining the level of effort required for the defined activities and deliverables.

Location 1937: To help improve the reliability of the estimates, the business analyst may seek the support of peers within the organization who have more years of experience in estimating similar projects within the industry or line of business. These resources may review proposed estimates and suggest adjustments based on their experience. Business analysts may consider consulting with the key stakeholders who will be involved in the work. Business analysts may validate estimates by reviewing the planning information from past projects that used similar elicitation and analysis techniques.

Location 1941: The following considerations should be factored into the estimates:
~ Project size and complexity,
~ Selected project life cycle,
~ Amount of ambiguity surrounding the proposed solution (e.g., ambiguity will be higher when taking advantage of an emerging technology or using a solution that the organization has little experience with),
~ Number of stakeholders and stakeholder groups involved in the elicitation activities,
~ Types of elicitation techniques being considered,
~ Location of those involved in the business analysis activities (including the product development and testing resources who the business analyst will interface with),
~ Schedule and budget constraints,
~ Any known assumptions,
~ Number of business analysis deliverables being produced,
~ Formality and level of detail required for the business analysis deliverables, and
~ Experience level of the project team (including the business analysis team assigned to the project and the stakeholders participating in the requirements-related activities).

Location 1953: Estimation is an iterative process and estimates should always be revisited as the project progresses and more information becomes known to the project team.

Collaboration Point—The project manager and business analyst should determine how revisions to the business analysis estimates will occur.
Project managers facilitate the estimation work when building the project management plan.
Business analysts may be asked to facilitate the estimation work for the business analysis activities, since they are responsible for the business analysis process and more familiar with the specifics.
Estimating the business analysis activities is a potential area of overlap between the two roles; therefore, the business analyst and project manager will benefit greatly by collaborating to determine who should complete and revise these estimates throughout the project.

3.5.3. Assemble the Business Analysis Work Plan

Location 1961: Once the business analysis deliverables, tasks and activities, and required resources for completing the work are known, the information is assembled in a plan that clearly depicts the timing of the work and any dependencies. This is a point of integration between business analysis and project management. The business analyst and project manager need to agree on the level of detail needed for the project management plan.

Location 1964: The level of detail maintained in the project management plan can vary based on a number of factors minimally depending upon:
~ Complexity of the business analysis effort,
~ Size of the project,
~ Amount of business analysis work being tracked, and
~ Type of project life cycle.

Location 1968: The business analysis work plan may be included within the business analysis plan along with the other planning decisions or organizational preferences, and the selected project life cycle can influence the approach used to document and communicate the work.

Collaboration Point—It is beneficial for the project manager and business analyst to collaborate on how to document and communicate the work plan to ensure that the business analysis activities and schedule properly integrate into the project management plan. When the business analysis process is highly complex, the project manager may prefer that the low-level details regarding the business analysis activities be tracked by the business analyst in a separate business analysis work plan.

Location 1975:
Table 3-1. Sample Business Analysis Work Plan Task Name Resource Level Of Effort Use Case Diagrams S. Bhomack 34 hours Use Case Specifications Use Case 1 Interview SMEs A. Manach 10 hours Draft Use Case A. Manach 32 hours Review Use Case A. Manach 2 hours Refine Use Case A. Manach 5 hours Approve Use Case A. Manach 1 hour Use Case 2 Interview SMEs E. Simone 12 hours Draft Use Case E. Simone 41 hours Review Use Case E. Simone 3 hours Refine Use Case E. Simone 6 hours Approve Use Case E. Simone 1 hour Use Case 3 Interview SMEs S. Bhomack 7 hours Draft Use Case S. Bhomack 22 hours Review Use Case S. Bhomack 1.5 hours Refine Use Case unassigned 3.5 hours Approve Use Case unassigned 1 hour

3.5.4. Document the Rationale for the Business Analysis Approach

Location 2016: Documenting the basis for the decisions made during the planning efforts helps to reduce uncertainty. Sharing the rationale with the stakeholders provides assurance that the plan is thought out and purposeful.

Location 2019: For the project manager, understanding the rationale for the business analysis approach provides the context needed to support and fund the work, manage it, and justify the roles and resources required to complete the work. The sponsor should understand the approach to champion, lend support, and rally stakeholders around the importance of the business analysis activities.

The business analysis plan along with the documented rationale provides valuable information for future project teams. When business analysis work is being planned for a new project, reviewing past plans and lessons learned assists with the planning work and allows analysis decisions to be based on experience. A Center of Business Analysis Practice may help to formalize the collection and storage of these assets, but for organizations that do not operate a center, an informal process for storing this information in a shared repository serves the organizational need.

3.5.5. Review the Business Analysis Plan with Key Stakeholders

Location 2027: Once the business analysis plan is completed, the business analyst reviews the plan with the key project stakeholders. Reviews are conducted in person; however, when stakeholders are distributed in different geographical locations, a collaborative approach may be used that allows stakeholders to raise questions and receive direct feedback to their concerns.

The objective for the review is to reduce the risk of stakeholders failing to support business analysis activities when the work begins.

Location 2031: Stakeholders need to be comfortable with their role in the process, be aware of the time commitment to participate in the process, and understand how decisions about requirement priorities and changes are handled. Conducting these discussions up-front helps to obtain buy-in early and minimizes the risk of stakeholder conflict when the activities are underway.

When stakeholders feel a sense of ownership about the process, they are more likely to demonstrate a higher level of interest and remain more engaged in the business analysis activities.

Location 2035: The review process is a way to reduce the possibility of overlooking a stakeholder characteristic, concern, or limitation that could negatively influence the business analysis process. Reviews can reveal areas where stakeholders are confused or unclear about the requirements-related activities. Reviews sometimes uncover unknown risks such as a shortage of resources, schedule conflicts, or concern over assigned roles.

Location 2039: Key stakeholders in the business analysis activities should be invited to participate in the review process.

Collaboration Point—The business analyst should ensure to discuss the business analysis process with those who are tasked with performing the work. Key stakeholders who have an opportunity to provide input to structure the process are more likely to support the requirements-related activities.

3.5.6. Obtain Approval of the Business Analysis Plan

Location 2049: The business analysis plan may need to be revised to accommodate the feedback received from stakeholders.

Location 2051: The business analyst works through the issues raised and facilitates resolutions in order to avoid discouraging or disengaging stakeholders.

Location 2052: Once all concerns are resolved, the business analyst takes steps to obtain approval on the plan.

Location 2053: Obtaining approval on the plan helps to reduce the following project risks:
~ Stakeholders do not support the business analysis process once it starts.
~ Project team underestimates the amount of time that business analysis activities will take.
~ Funding allocated to the requirements phase of the project is inadequate.
~ Key stakeholders underestimate the level of involvement or participation necessary for the requirement activities.
~ Key resources are unavailable to participate in requirement activities, when required.
~ Stakeholder expectations with regard to how requirements are documented and communicated are missed.

Location 2060: Approval may be formal and require a signature or may be informal and only require verbal acceptance. There may be an organizational process that defines how this approval should be attained, but when a process does not exist, the practitioner or project team should define the process. It is recommended to obtain approval from the sponsor and key stakeholders, such as the subject matter experts who will be participating in the requirements activities or anyone who approves requirements or participates in change activities.

Location 2064: Once the business analysis plan is approved, updates to the plan should be made in a controlled fashion.

When the project uses an adaptive project life cycle, the team may forego a formal review and approval process since, in this case, much of the planning would have occurred as a result of extensive team dialogue and collaboration.

4. REQUIREMENTS ELICITATION AND ANALYSIS

4.1. Purpose of this Section

Location 2073: Requirements elicitation and analysis is the iterative work to plan, prepare, and conduct the elicitation of information from stakeholders, to analyze and document the results of that work, and to eventually define a set of requirements in sufficient detail to enable the definition and selection of the preferred solution.

4.2.1. Elicitation is More than Requirements Collection or Gathering

Location 2083: Requirements are not ready and waiting in the stakeholders’ minds or in documents within the business community. While stakeholders may not have actual requirements, they do often have wants and needs; however, they may not be able to express them clearly. They may know there is a problem, but may not know exactly what the problem is. They may want to take advantage of an opportunity, but not know how to get started.

4.2.2. Importance of Eliciting Information

Location 2093: Information is not only elicited to generate requirements or answer questions from the solution team, but the information becomes the basis to effectively complete other business analyst tasks, such as:
~ Support executive decision making.
~ Apply influence successfully.
~ Assist in negotiation or mediation.
~ Resolve conflict.
~ Define problems.

The art of elicitation is to obtain enough information to be able to validate requirements through a process of learning in order to confirm that the project team is delivering the right solution.

4.3. Plan for Elicitation

Location 2111: Because planning is iterative, other planning is performed closer to when the activities are ready to begin. Prior to elicitation, the business analyst begins to focus on more specific details such as how to conduct elicitation, which stakeholders to involve, and which order to schedule elicitation sessions.

Location 2114: A well thought out approach to elicitation provides the following benefits:
~ Clearer idea of the necessary information to define a problem, affect an improvement, or produce a solution;
~ Fewer unnecessary elicitation activities;
~ More valuable results from each elicitation session;
~ More efficient and predictable use of stakeholder time to elicit the information;and
~ Better overall focus on the entire elicitation process.

4.3.1. Develop the Elicitation Plan

Location 2120: An elicitation plan is a device used by business analysts to help formulate ideas about how to structure the elicitation activities. The plan is not a formal document and does not take a lot of time to create. It can be documented or can be the thought process used to prepare for the forthcoming elicitation efforts.

Location 2123: Some of the elements in an elicitation plan include but are not limited to:
~ What information to elicit.
~ What does the business analyst need to know in order to define the problem, solve the problem, or answer the question?
~ Where to find that information. Where is that information located: in what document, from what source, in whose mind?
~ Identify who has the information or where it is located.
~ How to obtain the information.
~ What method will be used to acquire the information from the source?
~ Sequencing the Elicitation Activities.
~ In what order should the elicitation activities be sequenced to acquire the needed information?

4.3.1.1. Finding Information

Location 2132: Individuals in the elicitation plan should be identified by role rather than name.

Location 2132: When information cannot be provided by individuals, the business analyst should consider leveraging basic elements of the enterprise architecture when one exists. Components within the enterprise architecture often contain reusable artifacts such as process flows, logical data models, business rule models, business domain models, etc.

It is a good practice to try to identify at least two sources for each topic or question to be explored during elicitation, in order to avoid proposing any requirement or solution that is based on the opinion or information derived from a single source.

4.4. Prepare for Elicitation

Location 2147: Elicitation preparation is the planning performed to conduct an effective elicitation session.

Location 2148: The business analyst may create informal preparation notes to organize and to help facilitate the session. Preparation notes can be used to measure the progress achieved in a session against what was planned to be achieved and can be used to adjust expectations for future sessions.

4.4.1. Determine the Objectives

Location 2151: To ensure elicitation activities are effectively performed, the business analyst should set an objective for each session to achieve. The objective is the reason why the elicitation activity is being undertaken.

4.4.3. Determine the Questions for the Session

Location 2161: Using interviews, focus groups, facilitated workshops, or other techniques used to elicit information directly from stakeholders, the business analyst may want to prepare some questions prior to conducting the elicitation in order to ensure the session objectives are achieved.

Location 2164: The business analyst should know the rationale for each question and be able to explain why a question is important or why it is being asked. Questions that do not move the session forward to achieving the desired objectives or those questions that obtain data that do not have a specific purpose should be avoided.

Location 2169: The business analyst may organize the questions with easy, nonthreatening questions at the beginning and end, with the more challenging, complex, or contentious questions in the middle of the session. Doing so helps the group make progress in the session early before needing to address the challenging questions, as well as ensuring the session ends on a positive note.

4.5. Conduct Elicitation Activities

Location 2174: There are four stages during the actual elicitation activity in which information is gathered:
~ Introduction => The introduction sets the stage, sets the pace, and establishes the overall purpose for the elicitation session.
~ Body => The body is where the questions are asked and the answers are given.
~ Close => The close provides a graceful termination to the particular session.
~ Follow-Up=> The follow-up is where the information is consolidated and confirmed with the participants.

4.5.1. Introduction

Location 2183: During the introduction, the business analyst establishes the frame for the session and sets the tone and rapport with the participants. The frame is created at the beginning of each session by stating the problem and by providing an overview of the session objectives.

The frame is a cognitive technique that causes the participants in a session to subconsciously focus on the subject at hand. The structure keeps the participants on track and thinking about the objectives.

Location 2188: The business analyst should consider use of a “parking lot” as a tool to keep participants on track. Parking lots are used to minimize sidetracking, derailing, or hijacking of the meeting by participants. The parking lot, created on easel pads, white boards, or electronic equivalent, is a place to store topics that have been raised by the participants which do not relate to the session objectives.

4.5.2. Body

Location 2192: The body of the elicitation session is where the business analyst's soft skills come into play: active listening, empathy, body language, selection of questions to ask, sequencing of questions, influencing skills, etc.

Location 2196: The body is the portion of the session where momentum is built and the team is highly performing and engaged in providing a large amount of information.

4.5.2.1. Types of Questions

Location 2202: The types of questions that can be asked are as follows:
~ Open-ended question => A question that allows the respondents to answer in any way they desire.
~ Closed-ended question => A question that calls for a response from a limited list of answer choices. Types of closed-ended questions are forced choice, limited choice, and confirmation.
~ Contextual question => A question that requires an answer regarding the subject at hand; namely, the problem domain or the proposed solutions.
~ Context-free question => A question that may be asked in any situation. Context-free questions are also used as lead-ins to obtain information to define the solution.

4.5.2.2. How to Ask the “Right” Questions

Location 2213: One way to know whether the right questions were asked is to analyze the results of the elicitation and assess the outcomes to see if the objectives of the session were achieved.

4.5.2.3. Listening

Location 2216: Active listening is the act of listening completely with all senses. Active listening entails paraphrasing or reciting back what is heard to ensure an accurate understanding of what has been communicated. It involves suspending all judgment about what is being heard so that information flows freely. When discrepancies in information are identified, the business analyst should not call attention to the discrepancy, but instead continue to draw out other clarifying information through questioning.

One goal of active listening is to clear up discrepancies without raising the possibility of conflict.

4.5.3. Close

Location 2225: The close occurs at the end of an elicitation session. The purpose of the close is to wrap up the activities and focus on next steps.

Location 2226: When the elicitation conducted was in the form of a workshop, the business analyst may consider a rundown of the assignment of action items so participants are aware of their responsibilities at the conclusion of the session.

Location 2227: When the elicitation session was conducted in the form of an interview, the business analyst provides direction to the interviewee regarding next steps.

Location 2229: Three questions a business analyst may consider asking at the end of each elicitation session are as follows:
~ Do you have any additional questions?
~ Is there anything we missed or anything that we should have talked about but didn't?
~ Is there anyone else who might have information that would contribute to the elicitation objectives?

Location 2236: The questions that arise during analysis become the materials to help structure the objectives for the follow-up sessions.

4.5.4. Follow-Up

Location 2238: In a follow-up session, after taking time to analyze and consolidate the information, the business analyst shares any revised notes and takes the opportunity to obtain confirmation from participants on the information obtained during the prior elicitation session.

Location 2239: It is preferable to hold the follow-up after stakeholders have read the consolidated notes; however, business analysts will often find that participants do not have time to do so. The business analyst should use collaboration techniques to lead the participants through discussions to validate the consolidated information for accuracy and completeness before moving ahead.

Location 2242: A one or two paragraph summarization of the information elicited provides the following benefits:
~ Provides an opportunity to fully analyze all the information received and to eliminate extraneous material;
~ Allows time to verify and clarify the notes taken during the session, especially acronyms and abbreviations used in an effort to capture all of the information being provided;
~ Uncovers any questions that should have been asked during the meeting;
~ Reinforces to participants that their information is valuable enough for someone to spend the time to digest, analyze, and summarize it;
~ Gives each participant a chance to respond to the summarization with additional information; and
~ Provides participants with an opportunity to clarify or correct anything said previously.

Note: An alternative approach business analysts can employ is to produce all notes on a whiteboard during the elicitation session. Attendees can clarify and correct information on the spot to avoid a read-review process. The business analyst determines the appropriate process based on the size of the project and the complexity of the information being elicited.

4.5.5. Elicitation Techniques

Location 2254: Some common techniques used for elicitation are as follows:

4.5.5.1 Brainstorming

Location 2256: Brainstorming is a technique used to prompt innovation and creativity by asking groups to consider novel or different solutions. Output generated from the group is often greater than the output from the same group when solutions are recorded individually.

4.5.5.2. Document Analysis

Location 2259: Document analysis is an elicitation technique used to analyze existing documentation and identify information relevant to the requirements. Business analysts can start their analysis work with this technique to gain some understanding of the environment and situation prior to engaging directly with stakeholders.

Location 2262: Document analysis provides the following benefits:
~ Information received from individuals is subjective, whereas documented information tends to be more objective.
~ While it is always good to have the subjective viewpoints of a number of different individuals on the same topic, it is best to have the objective and factual information first to use as a baseline to understand the subjectivity variations.
~ Documents may contain information that no one individual has. This is found in older descriptions of a system or business process, source material for regulations, and other mandatory procedures.
~ Individuals may not have a totally accurate view of the information, whereas written documentation has been researched and is more accurate.
~ Written documentation provides more background and explanations than an individual explaining the same material, because the individual may assume that the business analyst already knows much of the information or that common knowledge has already been documented elsewhere.
~ Up-to-date documentation can be a good source of information regarding the structure and capabilities of any product, ranging from physical structures (e.g., buildings) to devices with embedded systems (e.g., cellphones, pacemakers, or thermostats) to software (e.g., a claims payment system).
~ A suite of up-to-date regression tests may serve the same purpose for obtaining accurate information about software and embedded system functionality.

Location 2274: The downside of the document analysis method is that documentation may not be available or the existing documentation may be out of date, thereby providing erroneous information. Even when documentation is maintained and considered current, there is a risk that previous system constraints or limitations will be documented as current business practices.

4.5.5.3. Facilitated Workshops

Location 2278: Facilitated workshops, also known as requirements workshops, are focused sessions that bring key cross-functional stakeholders together to define product requirements.

Location 2281: Workshops are considered a primary technique for quickly defining cross-functional requirements and reconciling stakeholder differences. Due to their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus.

Location 2283: In addition:
~ There is synergy when ideas from various people help to stimulate new thoughts from others.
~ Disagreements among business units or individual stakeholders are resolved as they come up during elicitation, saving time later.
~ Issues are discovered and resolved more quickly than in individual sessions.
~ Obtaining agreement on issues is easier when the group is assembled together.
~ Engagement is higher when stakeholders are urged to participate.
~ There is a perception that no one stakeholder will have a higher influence on the solution, because everyone is in the meeting together.

Location 2290: The benefits of a cross-functional facilitated workshop are as follows:
~ There is a team building aspect that unites the group.
~ There is a better chance for a binding agreement between the solution team and the product stakeholders.
~ The solution team is more committed when they are able to meet directly with the stakeholders for whom they are building the solution.
~ The solution team or its lead learns the context of the problem, solution, and decisions, which provide a more informed basis for developing a solution.
~ The requirements resulting from a combined meeting are more likely to be implemented, because the work was developed collaboratively.

Location 2299: In order to ensure the workshop gets off to a strong start, the business analyst should prepare as follows:
~ Collaborate with the project team and stakeholders to agree on the agenda topics ahead of time.
~ Produce an agenda and distribute it with the workshop invitation. If it cannot be sent with the invite, provide at least two business days’notice.
~ When the workshop will involve decision-making activities, ensure the team has already determined their decision-making process prior to the start of the workshop. This information should have been agreed upon during business analysis planning; however, in any event, it needs to be agreed upon before the start of the workshop.
~ When any form of technology is being used to run the meeting, the meeting organizer needs to set up and start up all technical components prior to the start of the meeting. This may require that the organizer book the conference room 30 minutes to an hour prior to the start of the session so all technology is up and running prior to the start of the workshop.

Location 2310: Sufficient workshop materials are planned for and obtained prior to the start of the session. Stopping a workshop to retrieve materials loses the momentum.

Location 2312: Invite participants by roles. When conducting a workshop or other form of elicitation within a group setting, invite attendees by role to avoid two persistent problems that often occur in elicitation sessions: Interlopers or those who are not invited or do not need to attend the meeting.

Location 2315: Lack of attendance by those who are needed for the meeting but do not show. Instead of a broadcast invitation to everyone having anything to do with the project, the business analyst should direct the invitations only to the roles required to achieve the workshop objectives.

Location 2317: Inviting by role establishes expectations for participation and encourages attendance. Participants are more apt to prepare and provide the information needed from the perspective of their role, and are less likely to miss the meeting because they now have a specific responsibility to play in the meeting.

Tips for running a workshop.
~ Introduce participants or have the participants introduce themselves by role.
~ Keep cross discussions and personal topics to a minimum to generate the most effective information.
~ Start the meeting on time to send a message that everyone's time is important.
~ To maintain momentum and focus, do not stop the meeting for latecomers but instead brief them during the break.
~ Consider assigning separate roles, including a facilitator, a scribe, and a workshop owner to ensure a smoother session.
~ It is a good practice to write directly on a whiteboard or some form of electronic medium so that the attendees can review the notes during the workshop. This reduces the need to conduct multiple reviews of the workshop results.

Location 2328: Facilitators help the business analyst and the meeting attendees to achieve the meeting objectives. The scribes help to ensure that the results are documented and the workshop owner makes the business decisions. Separating the roles often results in collecting more information as the practitioner is less distracted having to deal with multiple responsibilities.

Collaboration Point—It is not always practical for multiple business analysts to be present in a single facilitated workshop. This is an opportunity for the project manager and the business analyst to team up. The project manager may support the effort by fulfilling one of the roles, such as the scribe, thereby allowing the business analyst to focus on the questions and elicitation of information.

Location 2334: Closing tips. Make it clear to the participants when the elicitation session will end. If there is a question and answer portion of the workshop, ensure that the participants know how many more questions can be raised and responded to. This allows for a nice transition to wrap up the meeting and does not leave attendees concerned that their questions will go unanswered.

Location 2337: Follow-Up Tips. Schedule time to thoroughly analyze the information received as soon after the workshop as possible. Information and context may be lost when the meeting notes are not completed soon after the working session.

Location 2339: Try to provide the summarized results back to the participants in a time frame that meets the participant's expectations. The participants will benefit from reviewing the session results soon after the meeting closes to ensure their recollection of the discussions is not forgotten.

4.5.5.4. Focus Groups

Location 2344: A focus group is an elicitation technique that brings together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. Focus groups are used to gain feedback on completed work or prototypes. Generally, group members are prequalified or prescreened to ensure they meet the desired or targeted representation. A group size of 8 to 12 is optimal. The person chosen to facilitate the session should have experience moderating sessions of this type.

Location 2351: Focus groups work well to allow participants to share ideas and build off of the feedback that is being shared among the group. The business analyst should watch reactions, facial expressions, and body language in addition to taking in the information being provided by the group. Due to their format and structure, focus groups are not a suitable method for eliciting information about a problem domain.

One drawback of a focus group is that participants may be influenced by group pressure to agree with the stronger-willed participants. The facilitator plays an important role to engage the entire group and to ensure no one participant is demonstrating signs of being influenced by group pressure.

4.5.5.5. Interviews

Location 2358: Interviews are often conducted on an individual basis between an interviewer and an interviewee, but may involve multiple interviewers and/or multiple interviewees. Interviewing experienced project participants, stakeholders, and subject matter experts helps to identify and define the features and functions for the desired solution.

Location 2360: Interviews work well when:
~ An individual has been identified as being able to provide a variety of information on a variety of topics.
~ Confidential or sensitive information is needed that should not be discussed in an open forum.
~ Information needs to be acquired from an upper-level manager.
~ The business analyst needs to probe deeply into the issues surrounding the problem or problem domain and needs unfettered access and time from a specific individual who may have that information.

Location 2366: There are two basic types of interviews:
~ Structured interviews => Begin with a list of prepared questions with the goal of asking and obtaining answers to every question on the list or within the allotted time.
~ Unstructured interviews => Begin with a list of prepared questions, but the only question that is definitely asked is the first. After that, the subsequent questions are based on the answers to the previous questions. The interview takes on a life of its own and requires skill to keep the information focused on reaching the objective.

Location 2371: Interviews may be conducted synchronously or asynchronously: ~ Synchronous Interviews => These interviews are performed live or in real time. These can be conducted in a number of ways, such as face-to-face where the business analyst and the interviewee are in the same room, or they can be conducted over the telephone, with video conferencing, internet collaboration tools, etc. The key is that the interview is being conducted with the interviewee and interviewer at the same time.
~ Asynchronous interviews => These interviews are not conducted in real time; the business analyst or interviewer is not involved in the interview at the same time as the interviewee. Asynchronous interviews can be conducted through email or recorded, for example, where the interview questions are scripted and the interviewee records their responses to the questions through video.

Location 2378: There are a number of advantages to conducting an interview in person, for example:
~ Having the undivided attention of the interviewee,
~ Ability to see the body language and facial expressions accompanying the answers, perhaps more clearly than with video conferencing or collaboration tools, and
~ Providing a more comfortable setting for the interviewee, especially if they are discussing sensitive information, for example, flaws with the current system.

Location 2386: Some of the disadvantages associated with conducting virtual interviews are:
~ Interviewees multitask during the session, resulting in lost information;
~ Participants call into the session from various locations, such as airports, parking lots, other client sites, etc., with the accompanying distractions; Lack of experience on the part of the interviewer and the interviewee participating in virtual meetings; and
~ Equipment failure or poor performance of collaboration tools.

All of these obstacles can be overcome with proper training and with the establishment of ground rules for conducting virtual meetings.

4.5.5.6. Observation

Location 2394: Observation is a technique that provides a direct way of viewing people in their environment to see how they perform their jobs or tasks and carry out processes.

Location 2396: It is particularly helpful for detailed processes when people who use the product have difficulty or are reluctant to articulate their requirements.

Observation is also called job shadowing.

Location 2397: It is usually performed externally by an observer who views the business expert performing his or her job. It can also be performed by a participant observer who performs a process or procedure to experience how it is done so as to uncover hidden requirements. The objective of the technique is to elicit requirements by observing stakeholders in their work environment. Observation often results in the transfer of a greater amount of unbiased, objective, real information about the problem domain than with other forms of elicitation. When asked in a meeting to describe how to go about performing their work, it is probable that a stakeholder may miss steps or under-communicate.

Location 2405: In business analysis, the business analyst fulfills the role of observer or participant observer. Observation in business analysis is not used to evaluate the performance of the worker, that is, to collect performance related information for input into a performance evaluation process. When the worker is suspicious of the observer, the value of observation may be diminished.

Location 2408: Additional benefits of observation are:
~ Provides more insight into tasks and activities that are difficult to describe,
~ Provides an opportunity to request a demonstration of complicated tasks or specific interactions with a system or product and to obtain an explanation of the process being performed,
~ Provides information and visualization together, and
~ Provides context around the activity.

Location 2413: There are four types of observation; each is used in a different situation:

~Passive observation => The business analyst observes the worker at work without interrupting, asking questions, or seeking clarification. The observer records the observations, often in the form of a process flow with timings recorded on the diagram. At a later date, the business analyst can ask the worker about the activities observed in order to clarify and validate notes.

An advantage of passive observation is the minimal interruption to the workflow.
A disadvantage is that the worker may not trust the observer and may perform the work in a nonroutine fashion.

~ Active observation => During active observation, the observer interrupts the process or activity, asks questions about what the worker is doing, seeks clarification, and asks for opinions, etc.

The advantage of active observation is in the immediacy of information elicited and the increased amount of information collected.
Active observation does, however, interrupt the flow of work which reduces productivity and possibly changes behaviors during the observation.

~ Participatory observation => During participatory observation, the observer takes part in performing the activities being observed. It allows the observer to generate questions that would never have been thought of otherwise. In addition, the observer has an opportunity to experience what workers are going through when they perform these activities.

The observer may discover functions, features, and improvements that would never come up during a facilitated workshop or interview.

~ Simulation => The observer simulates the activities, operations, or processes of the work using a tool that recreates the work of a process worker in a simulation. With simulation, the business analyst follows up with the process worker through an interview to elicit further details.

The main drawback to observation is that people act differently when they are being observed. In addition, some managers may not support interruptions or may not allow firsthand observations.

4.5.5.7. Prototyping

Location 2433: Prototyping is a method of obtaining early feedback on requirements by providing a working model of the expected product before building it.

Location 2435: Prototypes support the concept of progressive elaboration in iterative cycles of mockup creation, user experimentation, feedback generation, and prototype revision.

Location 2437: A prototype can be a mockup of the real result as in an architectural model, or it can be an early version of the product itself.

Location 2438: Allowing the users and customers to see the product or system as it is being built provides an opportunity for the business to identify issues, clarify requirements, and provide additional information that may have been omitted originally.

The key element to prototyping is the iterative process of creating the prototype, reviewing it with the pertinent stakeholders, making adjustments and modifications to the prototype, and reviewing it again. This process continues until all parties agree that the prototype has provided the needed information to the solution team.

Location 2443: There are two types of prototypes:
low-fidelity prototypes and high-fidelity prototypes.

~ Low-fidelity prototype => Low-fidelity prototypes are completed with a pen and paper, marker and whiteboard, or modeling tool on the computer. Examples of low-fidelity prototypes include: Wireframes, Mockups of interface screens or reports, Architectural renderings of a building, Floor plans, Sketches of a new product, and Any design that is evolving.

A typical use for a low-fidelity prototype is to mock up user interface screens and share them with the intended users to provide a visual representation of what the product/solution will look like and how it will function.

~ High-fidelity prototyping => High-fidelity prototypes create a representation of the final finished product and are usable by the stakeholders who are reviewing them. Typically, the prototype has limited data, is restricted to a single computer device, and has partial functionality.

High-fidelity prototyping is performed in an iterative fashion. Reviewers can manipulate the screen, enter some data, and move from screen to screen to experience firsthand how the screen will work.

Location 2456: There are two types of high-fidelity prototypes: throwaway and evolutionary.
~ Throwaway prototypes are discarded once the interface has been confirmed. This is similar to the product prototypes developed by manufacturing companies. The prototype is used to help define the tools and process for manufacturing the product but the prototype itself is not sold.
~ Evolutionary prototypes are the actual finished product in process. The first prototype that is reviewed is the earliest workable version of the final product. With each successive prototyping session, more functionality is added or the existing functionality is modified to achieve a higher level of quality.

Note: With agile project teams, evolutionary development is how the product is built. The work is not considered to be a prototype but is an actual slice of the product itself.

Location 2464: Two examples of prototyping techniques are:

~ Storyboarding => Storyboarding is a prototyping technique showing sequence or navigation through a series of images or illustrations. In software development, storyboards use mockups to show navigation paths through webpages, screens, or other user interfaces. Storyboards are graphical representations that represent the sequence of events. Storyboards are typically static and thrown away.

Prototypes focus on what the product will look and feel like, while storyboards focus on the experience.

~ Wireframes => A wireframe is a diagram representing a static blueprint or schematic of a user interface and is used to identify basic functionality. A wireframe separates the look and feel of a site from its function. It presents a stripped-down, simplified version of the page, devoid of distractions.

The purpose of the wireframe is to illustrate the flow of specific logical and business functions by identifying all entry and exit points or actions the users will experience.

Location 2472: A typical wireframe contains:
~ Key page elements such as header, footer, navigation, content objects, branding elements, and their respective locations;
~ Groupings of elements such as side bars, navigation bars, and content areas; Labeling, page title, and navigation links; and
~ Placeholders, content text, and images.

Wireframes drive communication and help to support evolutionary discovery of requirements.

4.5.5.8. Questionnaires and Surveys

Location 2479: Questionnaires and surveys are written sets of questions designed to quickly accumulate information from a large number of respondents. Respondents represent a diverse population and are often dispersed over a wide geographical area. This method is beneficial for collecting a large amount of information from a large group over a short period of time at a relatively small expense.

Location 2481: However, questionnaires and surveys also have these disadvantages:
~ There is no opportunity for clarification, which could render the answers meaningless. In a face-to-face meeting, questions can be clarified when the answer is not what is expected.
~ The formulation of the questions are often closed-ended, which could also render the answers meaningless.
~ The number of responses the business analyst receives may not be significant enough to serve as a representative sample.

Location 2486: A return rate of approximately 4 to 7% is not uncommon for a survey conducted within an organization. This means that without careful consideration of the survey sample, the information may be significantly prejudicial and draw the wrong conclusions.

Location 2491: Some ways of limiting the risks associated with surveys are as follows:
~ Determine the number of respondents that will be required.
~ Use a sample size calculator to determine the sample size needed for a statistically significant response.
~ Analyze for skewed information when the surveys are returned. This will require that the survey includes some type of demographic or segmenting question to enable this analysis.
~ Share information regarding why the survey is important to the organization and project.
~ Send out reminders during the survey window to encourage and promote participation.
~ Ask an upper management representative to champion the effort and emphasize its importance.
~ Make the survey results available to those who participate in the process as a follow-up and thank them for taking the time to complete the survey.

4.6. Document Outputs from Elicitation Activities

Location 2501: It is important to document the results of elicitation activities, either formally or informally. Documentation can range in formality from snapshots of whiteboards to fielded information recorded in requirements management tools.

Location 2504: When the elicitation results are analyzed, the results are documented into the deliverables and forms geared to the audiences who will use them.

4.7. Complete Elicitation

Location 2506: The elicitation process is an iterative process of alternating the steps of eliciting information and analyzing the information obtained. It can be considered a progressive elaboration of information. When information is analyzed, the quantity sometimes decreases, because extraneous information is removed.

Location 2509: A typical business analysis quandary is determining when the elicitation stops and the analysis starts and for how long the work continues. Analysis generates additional questions to clarify ambiguities, solidify vagueness, and add in more information about a particular topic, etc.

Location 2511: This results in another round of elicitation activity, which increases the quantity of information, followed by another round of analysis decreasing the quantity of information. This continues until the analysis produces no further questions and the information is reduced down to a depiction of the solution to the business problem or when the risk of problems emerging from the lack of complete information is considered to be acceptable; and that is when elicitation ends.

Note: Projects using an adaptive life cycle need to plan sufficient time for elicitation and analysis, but analysis is not usually estimated separately. Instead, analysis is taken into consideration and understood to be part of an estimate for the delivery of features or functionality within an iteration. Analysis occurs throughout the project as part of defining the initial backlog, grooming the backlog as the project moves forward, and analyzing details for each iteration.

Location 2519: The following may indicate when sufficient information has been elicited:
~ The stakeholder or problem owner approves the results.
~ The model on which the information is based can be completed.
~ A dry run or successful prototype is completed. The objective has been reached.
~ The solution(s) has been identified.
~ Stakeholders begin repeating themselves and providing redundant information.
~ It takes longer to get answers out of the same stakeholders.
~ Stakeholders are trying to come up with new information that is different from what they previously gave, because elicitation is still in process.
~ All information pertaining to high-priority requirements has been confirmed by at least two independent sources.

Note: For a project following an adaptive project life cycle, the project team pushes toward replacing up-front analysis in favor of eliciting details within the increment in which the features will be delivered.

4.8. Elicitation Issues and Challenges

Location 2530: There are a number of difficulties associated with elicitation, for example:
~ Conflicting viewpoints and needs among different types of users,
~ Conflicting information and resulting requirements from different business units,
~ Unstated or assumed information on the part of the stakeholders,
~ Stakeholders who are resistant to change and may fail to cooperate and possibly sabotage the work,
~ Inability to schedule time for interviewing or elicitation sessions because stakeholders cannot take time away from their work,
~ Inability of stakeholders to express what they do or what they would like to do, and inability of stakeholders to refrain from focusing on a solution.
~ The business analyst cannot gain access to the right stakeholders.
~ The business analyst can address this issue by focusing on the information not the individual.
~ Stakeholders do not know what they want. To address this challenge, using techniques such as prototyping or storyboards may help the stakeholders visualize each of the possible solutions.
~ Stakeholders are having difficulty defining their requirements.

To address this challenge, the business analyst should ask the business stakeholders for help in understanding the problem domain and focus their attention on the problem or opportunity they wish to address. After clarifying the situation, the discussion should be focused on the high-level requirements.

Location 2541: When the business analyst helps to break down the high-level requirements and walks the stakeholders through the process, the stakeholders will be prevented from moving directly to the solution. When it becomes difficult to elicit needs and high-level requirements from the stakeholders, the business analyst needs to continue to ask clarifying questions to draw out the requirements.

Location 2559: Stakeholders are not providing sufficient detail to develop the solution. To address this issue, the business analyst should try to elicit requirements through visual modeling techniques. Engaging stakeholders in modeling can open up dialogue that may not be possible through interview questions, surveys, or straight discussion.

4.9.1.1. Analysis Defined

Location 2569: Analysis is the process of examining, breaking down, and synthesizing information to further understand it, complete it, and improve it. Analysis entails looking closely at the parts of the information and how they relate to one another. Analysis involves progressively and iteratively working through information to lower levels of detail and often entails abstracting to higher levels of detail. Analysis is used to provide structure to the requirements and related information.

4.9.1.2. Thinking Ahead about Analysis

Consider which analysis tools could be applied, such as modeling tools, and which templates could be used. Decide in advance which modeling language to use, if any. Determine what existing models in the organization could be used as a starting point for the current project. Plan for analysis based on known information but also be able and ready to adjust plans to the unexpected discoveries that occur throughout the business analysis process.

4.9.1.3. What to Analyze

Location 2584: Use visual models to help establish a boundary on exactly what needs to be analyzed and to help facilitate discussions with stakeholders and subject matter experts when determining the key pieces of information.

Most often, business analysts conduct analysis on the outputs of elicitation activities.

Location 2587: Regardless of the business analysis approach used, elicitation and analysis are usually iterative.

4.10.1. Description of Models

Location 2589: In this practice guide, the model refers to a visual representation of information, both abstract and specific, that operates under a set of guidelines in order to efficiently arrange and convey a lot of information in a concise manner. In its simplest form, a business analysis model is a structured representation of information. Models are diagrams, tables, or structured text.

Location 2593: Examples of information related to business analysis that can be modeled include business objectives, requirements, business rules, and design.

4.10.2. Purpose of Models

Location 2595: Business analysis models are helpful to find gaps in information and to identify extraneous information. Models provide context to better understand and more clearly convey information. Requirements are modeled and refined to achieve further clarity, correctness, and to elicit additional information to define the details necessary for the product to be built.

4.10.3. Categories of Models

Table 4-2. Models Organized by Category

1. Scope Models: Models that structure and organize the features, functions, and boundaries of the business domain being analyzed.
Examples:
~ Goal and business objectives model
~ Ecosystem map
~ Context diagram
~ Feature model
~ Organizational chart (described in Business Analysis Planning)
~ Use case diagram
~ Decomposition model (described in Business Analysis Planning)
~ Fishbone diagram (described in Needs Assessment)
~ Interrelationship diagram (described in Needs Assessment)
~ SWOT diagram (described in Needs Assessment)

2. Process models: Models that describe business processes and ways in which stakeholders interact with those processes.
Examples:
~ Process flow
~ Use case
~ User story

3. Rule models: Models of concepts and behaviors that define or constrain aspects of a business in order to enforce established business policies.
Examples:
~ Business rules catalog
~ Decision tree
~ Decision table

4. Data models: Models that document the data used in a process or system and its life cycle.
Examples:
~ Entity relationship diagram
~ Data flow diagram
~ Data dictionary
~ State table
~ State diagram

5. Interface models: Models that assist in understanding specific systems and their relationships within a solution
Examples:
~ Report table
~ System interface table
~ User interface flow
~ Wireframes
~ Display-action-response

4.10.4. Selection of Models

Location 2638: The business analyst should consider the following when choosing which models to use:

~ Methodology: The choice of models or formality and depth of models can be methodology independent. However, certain models are more suited to one methodology than another.

~ Characteristics of the project: Project characteristics, such as, business process, automation, custom development, commercial-off-the-shelf, cloud or software as a service, data migration, workflow, mobile, hardware, software, number of users, analytics, and reporting are considerations when selecting the correct models for the project.

~ Timing within the project life cycle: Some models are better used early in a project when defining the project's value and scope, or when identifying stakeholders. Other models are more appropriate as the project progresses and the low levels of details are being described.

~ Categories of models: Models from every category (see Table 4-2) should be considered on every project.

~ Level of abstraction: Models represent different abstraction levels. Some are better suited for analyzing a whole solution, others for elements of a solution, and others for details within an element. or example, an agile project will likely use user stories as opposed to use cases. A reporting or analytics project will likely use data models, including a data dictionary and report tables. A system migration project will probably have scope models such as an ecosystem map or context diagram, as well as data models like a data dictionary and a business rules catalog. Early in a project, business analysts usually create context diagrams, ecosystem maps, and high-level process flows. Later in a project, business analysts may create state models, decision models, and user interface models. A project that involves automating operational functions benefits from process models to elicit information about how work is currently conducted and how work will be performed after the automation is implemented.

4.10.5. Use Models to Refine Requirements

Location 2660: Models are used during elicitation sessions to refine requirements with stakeholders or subject matter experts. Through an iterative process, the details become sharper and sharper until there is a clear enough picture as to what is important and what is not.

4.10.6. Modeling Languages:

Location 2669: Modeling Language and Overview of Usage:

~ Business Process Modeling Notation (BPMN) => Used to model complex business processes for the purpose of making changes to these processes.

~ Requirements Modeling Language (RML) => Used to visually model requirements for easy consumption by all stakeholders, particularly business stakeholders.

~ System Modeling Language (SysML): Used to analyze complex systems and includes a subset of UML.

~ Unified Modeling Language (UML): Primarily used to specify design models but can work well to specify requirements.

Location 2677: Various other modeling languages Used when a specific modeling language isn't appropriate or not part of the organizational standards. For example, process models are frequently created using ISO-standard flowchart symbols. Data models often use Information Engineering “crow's foot” notation.

Location 2684: It is helpful to add a key or legend to a model to ensure that everyone understands what the symbols represent.

4.10.7. SCOPE MODELS

In general, scope models are used to structure and organize the goals, objectives, features, functions, and boundaries of the business domain being analyzed.

4.10.7.1. Goal Model and Business Objective Model

Goal models and business objective models are diagrams for organizing and reflecting goals, business problems, business objectives, success metrics, and high-level features.

Location 2708: Usage => It may be helpful to create the model as soon as possible so that teams and business owners can start assigning the numbers to the features they are attempting to develop for a particular product. It can be used to justify budgets as well as to reveal to executives exactly what they are receiving from a project. When business objectives are mapped to the requirements, scope control becomes much easier as the particular value of a specific requirement is better understood.

Location 2712: Each functional requirement produced for a project should be traceable to the identified business problems and objectives. Maintaining a focus on the top-level business problems and business objectives guides the delivery of valuable solutions and shapes the scope of the features.

Location 2714: Relationship to Requirements => The value of requirements or features can be quantified based on how these requirements contribute to the business objectives in the model; this helps to identify the most important features to implement or identifies the minimally marketable features (MMFs).

4.10.7.2. Ecosystem Map

An ecosystem map is a diagram that shows all the relevant systems, the relationships between them, and optionally, any data objects passed between them.

Location 2719: An ecosystem map is made up of boxes representing the systems and lines between the boxes that depict the relationships. When data is shown in the diagram, the labels on the lines identify the data objects and the arrows show the direction that the data flows.

Location 2728: Usage => An ecosystem map is used to understand all of the systems that may be affected by or that will impact the in-scope systems. It is a good model to represent systems that are in scope early in a project. In particular, the model is used to determine where there are possible interface requirements or data requirements.

Location 2730: This model is slightly different than a context diagram, because ecosystem diagrams may include interfaces and systems that the solution under analysis does not interact with directly.

Location 2738: Relationship to Requirements => An ecosystem map is a high-level representation of system interfaces, but it does not contain specific requirements about these interfaces. System interface tables should be completed for each of the interfaces identified in an ecosystem map. Data models should be created to define data requirements for each of the data objects passed between the systems.

4.10.7.3. Context Diagram

A context diagram shows all of the direct system and human interfaces to systems within a solution. The diagram shows the in-scope system or systems and any inputs or outputs including the systems or actors providing or receiving them.

Location 2744: A context diagram typically shows the system under development in the center as a circle, interfacing systems as boxes, human actors as people shapes or boxes, and lines connecting them to show the actual interfaces and the data passed between them. Context diagrams are sometimes referred to as Level 0 of a data flow diagram.

Location 2752: Usage => Context diagrams are particularly useful early in a project to specify the scope of the project, including any interfaces that have to be developed. It also shows all of the external touch points between the system under development and other systems or people. Context diagrams are also helpful in determining where there could be interface requirements or data requirements. Context diagrams have begun to be used by business analysts more broadly (i.e., to model business, user, and data contexts), because context diagrams are easy to build and understand. Context diagrams can also model the as-is and the to-be states in order to help with gap analysis.

Location 2757: Relationship to Requirements => Context diagrams do not specify requirements but summarize the product scope and related information that are analyzed to identify requirements.

Location 2759: This model often leads a business analyst to create system interface tables, user interface flows, display-action-response models, or other interface models that help to specify interface requirements.

4.10.7.4. Feature Model

A feature model is a visual representation of all of the features of a solution arranged in a tree or hierarchical structure. The structure can be horizontal or vertical. A feature is a group of related requirements described in a few words.

Location 2765: Most feature models will have three or fewer levels of features. A given branch of the feature model always has a feature at the end of it, with lower level features hanging off the branch. Feature models can be embellished using color or patterns to indicate scope.

Location 2773: Usage => Feature models are helpful to show how features are grouped together and which features are sub-features of other ones. Feature models are useful because they can easily display up to 200 features across different levels on a single page, which may represent an entire solution's feature set.

Location 2775: Relationship to Requirements => Feature models usually do not show requirements, but rather sets of requirements (features). Feature models help to determine how to organize requirements for business analysis efforts or lay out features in a requirements document. The features found within a feature model may also be used to trace requirements to ensure that no features or requirements are forgotten.

4.10.7.5. Use Case Diagram

A use case diagram shows all of the in-scope use cases for a system. In a use case diagram, a use case is represented by an oval with the name of the use case within it

Location 2781: An actor is shown as a stick figure. Straight lines in the diagram associate the use cases that the actor interacts with. The association does not represent the flow of information into or out of the use case.

Location 2787: Usage => Use case diagrams can be used to summarize the scope of a solution, highlighting the main features to be added (i.e., the use cases). Use case diagrams can also indicate use cases that are out of scope, which is helpful to manage stakeholder expectations.

Location 2791: Relationship to requirements => Use case diagrams help the project team plan and track progress in building a solution. These diagrams help to summarize the scope of features and the relationship of features to actors. Use case diagrams do not show requirements, but help to organize requirements for business analysis efforts or layout in a requirements document.

4.10.8. PROCESS MODELS

Location 2794: Process models describe the user or stakeholder elements of a solution, process, or project.

4.10.8.1. Process Flow

Process flows, also called swimlane diagrams, process maps, process diagrams, or process flow charts, visually depict the tasks that people perform in their jobs.

Location 2797: Typically, process flows describe the steps that people take, although they may describe system steps and could be called system flows. In process flows, boxes depict steps, diamonds indicate decision logic, and arrows show the order of flow. Process flows may also contain swimlanes, which group steps together that are performed by the same person, group of people, or system. It is helpful to describe only people or system process steps in a given diagram to reduce shifting the context for the reader between the human and system processes.

Location 2801: Process flows are developed to model the as-is processes (e.g., how activities are currently performed) in an organization as well as the to-be processes (e.g., proposed process revisions or new proposed processes).

Location 2806: Usage => Process flows are valuable on most types of projects where there are people performing tasks in the solution. Process flows are particularly useful for facilitating conversations during elicitation with business stakeholders because process flows are intuitive to create and read.

Location 2808: During analysis, process flows are used to identify missing features or requirements by tracking requirements to individual steps within the process flows. Process flows can be drafted ahead of time or created real-time during sessions and are an easy model for business stakeholders to review as part of requirements verification.

Location 2812: Process flows are also used to show key performance indicator (KPI) metrics, either the baseline or target metrics. Each KPI is shown in brackets over the step or steps the metric applies to. This is useful when creating solutions to replace existing solutions where there is already a performance level threshold that needs to be maintained.

Location 2815: Relationship to requirements => Process flows are an easy model for deriving requirements by consideration of the functionality or qualities needed to support each step of a business process. This is done during elicitation sessions or during analysis. When requirements are already specified, these can be traced back to the process flow steps to see if there are requirements missing (steps that do not have sufficient requirements mapped) or requirements that are unnecessary (requirements that do not support any steps in a process).

4.10.8.2. Use Case

A use case describes a set of scenarios. A scenario is any single pass through a system to achieve a goal for the primary actor. A use case is a series of activities, actions, and reactions that take the primary actor from initiation to successful completion of the goal.

Location 2822: Use cases represent the functional aspects of a system or operation and, as such, are not used to document the nonfunctional aspects of a system (e.g., how fast the product should work, how durable it needs to be, what the capacities will be, etc.). When documenting nonfunctional requirements on a project with use cases or user stories, consider placing the nonfunctional requirements into a separate document.

Location 2826: Common fields include:

~ Name => A verb phrase that indicates the goal of the use case. Description. A simple explanation of the use case.
~ Actors => Roles that are active participants in the use case.
~ Organizational benefit => Describes why the use case is important to the project or organization; used for prioritization.
~ Trigger => The event that causes the use case to start.
~ Preconditions => Describes everything that should be in place prior to the use case starting in order for the use case to succeed.
~ Normal flow => The normal course of steps to move from the preconditions to the post conditions.
~ Post conditions => Everything that has changed in the environment at the end of a use case.
~ Alternate flows => Alternative sets of steps an actor can take to achieve the goal other than what is described in the main flow. These flows are often branch points from steps in the main flow.
~ Exception flows => Errors or disruptions in the normal flow that require an actor or system to perform a different action to respond to the exception. These are often branch points from steps in the main flow and will usually terminate a use case. Exception flows result in failure or nonachievement of the goal.

Location 2841: The normal flow is commonly referred to as the happy path or main success scenario.

Location 2844: Usage => Use cases are used when there are complex back and forth interactions between users and systems. These can be used during elicitation sessions to discover and describe complex interactions. Use cases are used during analysis and then later reviewed with stakeholders.

Location 2847: Use cases are helpful as a starting point for creating tests, including user acceptance tests. Use cases can be built and implemented iteratively. A use case diagram is not required when creating use cases, but it is a quick way to visually depict which actors are associated with multiple use cases and what the full scope of a use case is.

Location 2850: Relationship to requirements => Use cases typically are not standalone requirements but help to identify functional and nonfunctional requirements. During analysis, each step is analyzed to look for requirements to support the step.

Location 2855: While use cases help to identify nonfunctional requirements, it is often preferred to document nonfunctional requirements external to a particular use case, because these often apply to the whole system.

4.10.8.3. User Story

A user story is a statement, written from the point of view of the user, and describes the functionality needed in a solution.

Location 2858: Typically, a user story is used in an adaptive methodology, such as agile development, but can be used in any methodology approach.

A user story often takes the format of: As an <<>>, I want to be able to <<>>, so that I can <<>>.

Location 2901: The function provides a small discrete piece of business value or function. The elements of the INVEST acronym can be applied to all requirements, regardless of the format, to ensure quality of the user stories:

~ Independent => Each story should stand alone, avoiding the creation of dependencies between stories, as much as possible.
~ Negotiable => The story is subject to negotiation at all times regarding the content, priority, form, and function of the story, and becomes more concrete just before implementation.
~ Valuable => The story only defines features or functions that are valuable to the business and that help solve the business problem.
~ Estimable => The story should be clear enough to generate a valid estimate or lead to a discussion that will generate an estimate.
~ Small => Stories should be small enough to be implemented, adding an increment of real value, within a single iteration.
~ Testable => Each story should be independently verifiable.

When a user story is too large to be completed in a single iteration, it is considered to be an epic.

Location 2913: Epics are decomposed further into stories (or additional epics). Stories are used by the development team to build the product.

Location 2935: Usage => User stories focus on what the user is looking to accomplish and are written from the user's perspective. They can be derived from process flows when the model is used. User stories are helpful on projects, because they are easy models for business stakeholders to engage in creating. In agile methodologies, user stories populate a backlog and are used as a basis for prioritizing future development.

Location 2938: As user stories get closer to the top of the backlog, these should be elaborated using relevant modeling techniques to generate enough details for development to occur (known as “grooming the backlog”). Acceptance criteria should be developed at this

Location 2941: Relationship to requirements => A user story contains many requirements; therefore, it serves as a functional grouping of requirements. Stories can be traced directly to business objectives to substantiate the value of the requirements and can also be traced to elements in other models.

Location 2943: User stories can be used to manage, prioritize, trace, and allocate functionality to releases and iterations. Although user stories are not detailed, they contain acceptance criteria and express user needs.

4.10.9. RULE MODELS

Rule models help to identify and document the business rules, business policies, and decision frameworks that need to be supported by the solution.

Location 2947: Business rules are constraints about how the organization wants to operate and are usually enforced by data and/or processes and tend to be true over time. When analyzing business rules, the objective is to capture what should or should not be allowed in a business enterprise.

Location 2948: An important aspect of analyzing business rules is identifying the source of a rule. A key element of business rules analysis is the absence of technology.

4.10.9.1. Business Rules Catalog

A business rules catalog is a table of business rules and related attributes.

Location 2951: Common attributes to capture in a business rules catalog include a unique ID for the business rule, the rule description, and the type of business rule (there are multiple types of business rule classifications that can be followed), and references to other related documents.

Location 2953: Business rules themselves are not processes or procedures, but rather describe how to constrain or support a behavior. Business rules apply across processes and procedures and guide the organization's activities. Business rules should not be nested and each should be able to stand independently. When creating business rules, the rules need to be correct, verifiable, and consistent. The catalog can be used to refer to related requirements or governance documents.

Location 2961: Usage => Business rules should be maintained in a repository such as the business rules catalog.

Location 2962: The business rules catalog can be maintained at a level above an individual project, because business rules are often not specific to one project. Business rules catalogs can be traced to business objectives and other requirements types or analysis models in a traceability matrix to ensure that all business rules are captured. For example, decision trees help to identify business rules, so a mapping of business rules to decision trees would help to ensure completeness in this catalog.

Location 2966: Relationship to requirements => It is common for business rules to be identified in the normal course of eliciting and analyzing requirements. These rules could lead to functional requirements that are necessary to support the business rules. Rules also emerge in discussions of functional requirements that involve decisions.

4.10.9.2. Decision Tree and Decision Table

Decision trees and decision tables depict a series of decisions and the outcomes they lead to. Decision trees and tables are often used to model business rules. Decision trees work best with binary choices (i.e., yes or no), and decision tables can be used when more choices exist and the analysis is becoming complex.

Location 2971: Decision trees are described in a tree of decision points where each branch represents a different choice. The far right of a decision tree (the leaves) represent the outcomes for a decision or series of decisions. Decision points in a decision tree are commonly represented as text at the branch points or in diamond shapes at the branch points. Decision outcomes are typically shown in boxes. Decision trees are drawn horizontally or vertically (with outcomes at the bottom).

Location 2975: Decision tables use a tabular format where the upper rows in the table represent the decision points and the bottom rows in the table represent the outcomes. Each decision point row enumerates a set of all valid choice combinations.

Location 2977: A dash in the cell indicates that the choice does not matter in determining the outcome in that column. Each outcome row is marked to indicate which choice combination is valid. Each column of the table is a business rule that describes the set of choices for each decision point and the outcomes it leads to.

Location 2979: When an outcome is unachievable, it is considered indifferent in a decision table. The decision table consists of four areas as follows:

~ Condition stub => Lists all of the possible conditions in the process or activity being analyzed.
~ Conditions => Indicate which conditions are met.
~ Action stub => Defines the possible actions as a result of the process or activity being analyzed.
~ Actions => Indicate which actions are taken as a result of the conditions that are met.

Location 2988: Usage. Both decision trees and decision tables are used to model complex branching logic. During elicitation or analysis, when a business analyst uncovers a series of “if this, then that”statements, either type of decision model is appropriate to use.

Location 2990: Decision trees are helpful to identify ways to reduce complex decision logic by looking for redundancies in the structure. Decision tables are useful to ensure all possible combinations of decision choices are considered.

Location 2992: Relationship to requirements. Decision trees and decision tables are used to identify and represent business rules. Both models stand alone as representations of the business rules because they can be implemented directly, as a process or in development. These models can also help to identify any requirements related to supporting those business rules or the specific outcomes.

4.10.10. DATA MODELS

Data models document the data used in a process or system and its life cycle.

Location 2998: These models are used to depict relationships between data, to show how data is related to processes, and to further help extract requirements and related business rules.

4.10.10.1. Entity Relationship Diagram

The entity relationship diagram (ERD), also called a business data diagram, shows the business data objects or pieces of information of interest in a project and the cardinality relationship between those objects.

Location 3002: Business data objects are the conceptual pieces of data that the business thinks and cares about and are not intended to refer to exact data objects in a database. Business data objects represent the people, places, things, and concepts that the business cares about. Business data objects are shown as boxes, relationships as lines, and cardinality as labels on the lines.

Location 3004: Multiplicity is indicated on the relationship line to represent the number of times (cardinality) that one entity occurs in relationship to the other entity in the relationship, and whether the relationship is required or optional.

Location 3013: Usage => The entity relationship diagram is a cornerstone model for a project that has a data management component, because it helps with identifying the data that is created in, consumed by, or output from the system. This model is used to define the business data objects and their relationships to one another. The specific attributes of these objects are specified in a data dictionary.

Location 3016: Relationship to requirements => Systems typically manipulate business data objects through functions to allow business data objects within an entity relationship diagram to be traced directly to requirements for these functions. The data objects can be traced to data flow diagrams, ecosystem maps, data dictionaries, and state transition models.

4.10.10.2. Data Flow Diagrams

A data flow diagram illustrates the relationships between systems, actors, and the data that is exchanged and manipulated over the course of one or many processes. It is a model that can be used after business data diagrams, process flows, and an ecosystem map have been created.

Location 3027: Usage => A data flow diagram can be used to describe the movement of data between actors and systems over the course of a process or several processes. Data flow diagrams identify data inputs and outputs for processes, but do not specify the timing or sequence of operations.

Location 3030: Relationship to requirements => Data flow diagrams relate to requirements through the business data objects and processes. While requirements can be traced to the model, it is better used as a tool to help stakeholders and developers understand how data flows through the systems, which then leads to identifying specific data requirements.

4.10.10.3. Data Dictionary

A data dictionary is a tabular format and shows data fields and attributes of those fields. Common attributes include name, description, size, and validation rules. However, any relevant attributes can be captured in a data dictionary.

Location 3040: Usage => Data dictionaries are used to specify very detailed aspects of data and to capture data fields and attributes from the business stakeholder's perspective. The information captured does not need to explicitly reflect a database design. However, database designers use data dictionaries as an input to create the database architecture.

Location 3043: Relationship to requirements => Data dictionaries are used to capture very detailed requirements and their business rules. This model can stand alone and does not need redundant requirements statements.

4.10.10.4. State Table and State Diagram

State tables and state diagrams model the valid states of an object and any allowed transitions between those states.

Location 3046: State tables are in a tabular format with all of the valid states in the first column and across the first row. Each cell represents the transition from the state in the row to the state in the column. Transitions that are not allowed have cells that are marked with “X,”“N/A”or “no.”Allowed transitions are represented in cells with either “yes”or a description of the transition event that leads to the transition.

Location 3049: State diagrams show exactly the same information as state tables, but it is easier to visualize the valid states and transitions by showing only the allowed transitions. Ovals are used for states, and lines with arrows show the transitions and transition events between states. Some state diagrams are drawn by showing an initiation state and a termination state.

Location 3057: Usage => State tables and state diagrams help business analysts specify the life cycle of an object in the solution. For example, objects that go through workflow (e.g., an approval process) are aided by using state models. State tables are useful to ensure that state transitions are not missed, because every possible transition is represented by a cell in the table; when every cell in the life cycle is considered, no transitions can be forgotten. It is more difficult to ensure that state diagrams are complete, but much easier to quickly visualize the life cycle of an object.

Location 3061: Relationship to requirements => State table and state diagrams are models that stand alone and do not require additional requirements statements to be developed and tested correctly. The exception to this is when the transition events are too complicated to fit in the cell or on the arrow, in which case, additional detail is included outside of the model. State tables are also used to confirm or find gaps in data and processes that have been specified by other models and are used often to model business rules.

4.10.11. INTERFACE MODELS

Interface models depict the relationships within a solution to gain an understanding of which interfaces there are and the details of those interfaces.

4.10.11.1. Report Table

A report table is a model that captures the detailed level requirements for a single report.

Location 3069: Common attributes of a report include: name, description, decisions made from the report, objectives, audience, trigger, data fields, data volume, frequency, display format, and calculations. These attributes should be specified alongside a prototype or example of the actual report, when possible, because it adds context for the textual information in the report table. While it is not necessary to complete all fields, the fields can be used to help identify what to think about when eliciting reporting requirements.

Location 3082: Usage => Report tables are straightforward, can be created for each report, and are helpful to provide additional details about reports that cannot be gleaned by looking at a mockup. Using a report table with attributes allows the business analyst to specify the type of information to be included in the reports, thereby ensuring that details are not forgotten or overlooked in the solution.

Location 3089: Relationship to requirements => The information in a report table model represents the actual report requirements; therefore, no additional requirements are necessary. Stakeholders can use the report table and a mockup of the report to fully understand the report requirements.

4.10.11.2. System Interface Table

A system interface table is a model of attributes that captures all of the detailed level requirements for a single system interface.

Location 3093: The system interface table is in a tabular format and typically includes attributes such as source system, target system, volume of data passed, security or other rules, and the actual data objects passed.

Location 3098: Usage => System interface tables are used to specify the details for each interface between the systems in the solution. Typically these tables specify requirements for both the source and/or target system, but it could be only one of these.

Location 3101: Relationship to requirements => System interface tables are detailed enough to represent the actual interface requirements and do not need to have other requirements written.

4.10.11.3. User Interface Flow

A user interface flow displays specific pages or screens within a functional design and plots out how to navigate the screens according to various triggers.

Location 3104: The boxes in this diagram are the main screens in the user interface. The lines show the flows allowed between screens.

Location 3109: Usage => Typically, user interface flows are used in the solution definition stage of a project and help track all of the screens that need to be further defined. This model is applicable only when there is a user interface as part of a solution. Interface flows can be used during elicitation sessions to determine more details about the functions that take users between the screens.

Location 3112: Relationship to requirements => This model does not reflect individual requirements statements. The user interface flow can be traced to other requirements models such as the display-action-response models, process flows, and individual requirements.

4.10.11.4. Wireframes and Display-Action-Response

The display-action-response model is used in conjunction with wireframes or screen mockups to identify page elements and the functions, if any, they are attached to.

Location 3116: Each wireframe is broken down into user interface elements, which are then described from a display perspective and a behavior perspective. A user interface (UI) element table is created for every element on the screen that has user interface requirements. Each table describes the user interface element's display requirements under different preconditions and behavior requirements under different preconditions and user actions.

Location 3121: In general, user interface analysis focuses on profiles of the users who interact with the system, and precedes interface design. The business analyst, working in conjunction with the user experience analyst when one is assigned, analyzes the user interfaces to see how well these interfaces meet the general principles of human-machine interface:

~ Compatibility => Minimize the amount of information recoding that will be necessary for operators/users (Write Once, Read Anywhere).

~ Consistency => Minimize the difference in dialog both within and across various human computer interfaces; follow a user interface standard such as common user access (CUA).

~ Memory => Minimize the amount of information that users need to maintain in short-term memory (use reference tables or default information to prefill forms).

~ Structure => Show users the structure of the system so that they are able to navigate through the interface intuitively (effective grouping of similar data elements).

~ Feedback => Provide users with feedback and error correction capabilities (something happens on the interface every half second).

~ Workload => Keep user mental workload within acceptable limits.

~ Individualization => Allow customization of the interface to determine the requirements for individualization.

Collaboration Point—Because the information elicited is complementary, the user interface analyst and business analyst should work together to support each other when eliciting requirements.

Location 3138: Usage => This model is helpful when there is a user interface for a solution. The display-action response model is typically used when precision is needed for detailing the display and interactions in a user interface. This could occur when defining user interfaces for a large number of users, high-risk user interfaces, or when a development team is unfamiliar with the product. These models are helpful for specifying user interface requirements because the model places the individual requirements statements in the context of the elements on the screen.

Location 3142: Relationship to requirements => Display-action response models trace directly to wireframes, user stories, user interface flows, and data dictionaries. These models contain user interface requirements and do not need further specification.

4.11. Document the Solution Requirements

Location 3149: Regardless of the form the requirements take, when packaged together, a set of requirements defines the solution scope to the business problem or opportunity. The business analyst prepares the requirements package so that the solution team understands how to develop the solution.

4.11.1. Why Documentation is Important

Location 3154: Documented requirements serve a multitude of purposes, such as the following:
~ Baseline to validate the stakeholder needs;
~ Baseline definition of the solution for the business problem or opportunity;
~ Primary input to the design team, the developers, testers, and quality assurance;
~ Basis for user manuals and other documentation whether written or embedded;
~ Supporting detail for contractual agreements, when applicable (e.g., the requirements are a core input to a statement of work (SOW) for a request for proposal (RFP));
~ Starting point for the evolution of the solution;
~ Foundation for reusability by other project teams who need an understanding of the project details while it is in process or after implementation; and
~ Baseline for an audit of regulated industries and high-risk projects that are required to have documented requirements.

Location 3164: Despite the importance of documenting the requirements, keep some factors in mind about requirements documentation:
~ Requirements documentation is only one of several techniques to ensure consensus among all of the stakeholders as to the behavior of the solution.
~ Documentation should not replace communication and collaboration.

4.11.2. Business Requirements Document

Business requirements are the goals, objectives, and higher-level needs of the organization and provide the rationale for a new project. Business requirements recognize what is critical to the business and why it is critical before defining a solution.

Location 3172: Business requirements may be assembled in a business requirements specification or may be part of a larger document that contains all of the requirements.

Location 3173: Organizations that use spreadsheets to capture requirements may use a hierarchical structure, with the business requirement as the starting point. In a requirements management tool, business requirements are often grouped by assigning a category or attribute.

4.11.3. The Solution Documentation

Solution documentation is the documentation that is comprised of the features, functions, and characteristics of the product or service that will be built to meet the business and stakeholder requirements.

Location 3180: The business stakeholders have a role to review, validate, and approve the solution documentation. The level of formality for these processes is dependent on the selected project life cycle.

Location 3182: The solution documentation may be rendered in any number of forms. Some common forms include:
~ Requirements document, which may be a business requirements document and/or a functional requirements specification and/or a system or software requirements specification, etc.;
~ Deck of user stories written;
~ Set of use cases with accompanying nonfunctional requirements; or
~ List of items on a product backlog.

The format of the solution documentation is defined in business analysis planning.

4.11.3.1. Requirements

Location 3188: Product requirements are written at different levels of detail and are associated with different requirement types, for example, business, stakeholder, solution, and transition requirements, where solution requirements are further categorized as functional and nonfunctional.

While product requirements describe what is being built or the outcome of the project or solution to the business problem, project requirements describe the constraints and necessities for successful completion of the project.

Location 3194: For example, product requirements describe the length and width of the sidewalk to be constructed in front of a building, along with such aspects as color and texture. The project requirements for laying the sidewalk could include the number of laborers required, qualifications of the laborers to handle the equipment, size of the equipment, time frame for usage, and any restrictions on labor hours.

Collaboration Point—Product requirements are the responsibility of the business analyst. Project requirements are the responsibility of the project manager.

4.11.3.2. Categorization

Location 3200: Requirement categories are used to help group and structure requirements within the documentation.

Location 3203: The process of categorization helps expose vague, misstated, ambiguous, or otherwise poorly written requirements. When the business analyst is unable to place information or a requirement in a category, the requirement is likely to be invalid and may need to be revised, expanded, or removed. Categorization used in this way filters out the bad or poorly written requirements.

Location 3206: Examples of possible filters are:

~ Scope filter => Determine whether a requirement or information is in scope, out of scope, or unknown. "Unknown" refers to requirements that are possibly invalid and need to be revised or omitted.

~ Functional filter => Once the functional categories have been determined, any defined functional requirement not fitting into one of the categories can be filtered out, revised, or discarded.

~ Prioritization filter => An arbitrary level of priority (e.g., needs, wants, and desires), is defined and used as a filter to determine which requirements stay or are removed.

~ Testability filter => All requirements need to be testable, and all requirements should be examined to determine if they are testable. Any requirements that are not testable are filtered out and need to be revised.

Note: Filters may indicate the need for an additional classification, implying that the original list of filter elements is incomplete.

4.11.4. Requirements Specification

Location 3217: The requirements specification attempts to specify all circumstances, conditions, actions, reactions, results, and error conditions that could possibly occur in the defined solution. The concept is to create a manual that is followed by the development team to create the solution.

Requirements specification is a generic term that includes all documents that contain requirements. These requirements may be high-level, business-oriented wants and needs, or very detailed specifications required to build the new product or service.

Location 3223: Formal requirements specifications are more lightweight on projects using agile, lean, or hybrid methods. These teams may produce a one- to two-page specification and may include user acceptance testing and trace matrices to holistically describe the product.

4.11.4.1. Documenting Assumptions

An assumption is a factor that is considered to be true, real, or certain, without proof or demonstration. Analysis starts with assumptions and these assumptions are either proven or disproven over the course of a project.

Location 3227: There are many situations where assumptions are valid and warranted such as:
~ Complete information is unavailable; for example, the business analyst assumes that the technical resources to implement the solution will be available when needed.
~ The success of the project is dependent upon something happening in the future; for example, an increase in customer population, or a change in consumer interest.

Note: Assumptions are made based on factors that exist currently, but those factors may not exist in the future. The common assumption about a project, for example, is that all members of the team will stay on the project until the project is completed. The longer the project, the less likely that this assumption is true.

Location 3235: The business analyst identifies a contingency for each documented assumption so there is a course of action should that assumption turn out to be false.

Location 3236: Assumptions, once documented, should be monitored by the business analyst and project manager. As the project progresses and more information is known, assumptions may be deemed invalid or not relevant. When this occurs, the assumption is closed and a reason is provided as to why the assumption is no longer valid.

4.11.4.2. Documenting Constraints

Location 3239: The project management view of a constraint is that it is a limiting factor that affects the execution of a project, program, portfolio, or process. In business analysis, a constraint is a limiting factor placed on the product or solution.

Collaboration Point—The business analyst is primarily concerned with the product or solution constraints, although frequently project constraints are voiced by stakeholders during elicitation. Therefore project constraints are documented by the business analyst and passed along to the project manager for follow-up.

Location 3247: The difference between constraints and requirements is that requirements are written in the positive voice, because they define something that should be done. Requirements should not state that something not be done. While requirements define the solution by stating the “what,” solution constraints are typically written in negative or constraining language and limit the solution by stating actions that cannot be performed. These constraints are placing limitations on how the problem described by the requirements is solved.

Location 3251: Solution constraints are best highlighted by being placed in a separate and distinct section of the requirements document.

Location 3252: Solution constraints may fall into a few specific categories:
~ Geography,
~ Regulations,
~ Organizational policy, and
~ Culture.

Location 3255: Some examples of solution constraints are:
~ Restricting access to sales information to the region that the customer is located in (geography),
~ Prohibition against using certain building materials (regulation),
~ Security restrictions preventing the use of certain data or systems by unauthorized personnel (policy), or
~ Limitations on the amount of change that the organization can withstand over any period of time (culture).

Location 3260: Project constraints may include:
~ Direction to use predetermined equipment, organizational standards, or a preferred supplier;
~ Restrictions, such as resource utilization, message size and timing, software size, maximum number of and size of files, records, and data elements; or
~ Time (deadline), cost (budget), and scope.

4.11.5. Guidelines for Writing Requirements

Location 3268: Requirements are often written in a text-based format when developing business requirement documentation or solution requirement documents, and written in the format of user stories for projects that follow an adaptive life cycle.

4.11.5.1. Functional Requirements

Location 3272: A well-formatted requirement consists of the following elements:
~ Condition,
~ Subject,
~ Imperative,
~ Active verb, Object,
~ Business rule (optional), and
~ Outcome (optional).

Example — A well-formed detail level requirement might be as follows:

When the new account button is pressed (condition), the system (subject) will (imperative) display (active verb) the new account entry screen (object) allowing the creation of a new account (outcome).

Location 3280: The following characteristics are present in all requirements when they are of a high level of quality:

~ Unambiguous = > If the requirement is not clear before requirements are baselined, stakeholders may have different interpretations of the requirements.Location 3286A written requirement should be reviewed to see if it can be stated in a simpler or more straightforward manner

~ Precise => As a whole, the solution document states precisely what the solution to the business problem is—no more, no less. Precision also refers to choosing the right words. With adaptive life cycle methods, the business analyst should specify at what point the requirement will need to be precise, as the requirements will unfold into details through incremental elaboration; therefore, it is understood early on that all details may not beLocation

~ Consistent => Each requirement should be included one time in the solution document to avoid contradiction and redundancy. The business analyst maintains consistency through rewrites, revisions, changes, and modifications to the solution document. These revisions occur naturally in the iterative nature of business analysis. A traceability matrix helps to ensure consistency. Traceability is used to verify consistency and is achieved when determining the relationships between requirements. One way to prevent contradicting requirements is to assign only one business analyst the responsibility for writing the finished document.

Location 3337: Contradictions occur when stakeholders have opposing requirements. For example, two different business units or constituencies may each want their own requirements regardless of how their requirement may impact another stakeholder group. There are a few ways of resolving this particular situation: The most direct route is to bring the contradicting parties together in the same room and have them work through the inconsistency. Information can be added to one requirement, which details special circumstances that remove the contradiction. It may be necessary to support both requirements; in these cases, requirements for each user group are captured in the form of stakeholder requirements. When requirements are repeated, there is a risk that a change is reflected in one requirement and left unchanged in the duplicated one. One way to avoid ambiguity incurred through redundancy is to remove the redundancy.

~ Correct => Each requirement should accurately describe the functionality to be built. Correctness is not absolute; the solution document is only as correct as the information that has been obtained up to that point. As more information is uncovered, adding new information makes the solution document more correct by removing some assumptions, clarifying ambiguities, and adding new information in a progressive, elaborative approach. The following basic rules help to ensure correct requirements: Only the product stakeholder can confirm that a requirement is correct. In general, no single requirement should be committed to the solution document until it has been confirmed by a second source.

~ Complete => Completeness is also not absolute. The requirements can be made more complete with more information. Therefore, the guidelines that apply to correctness also apply to completeness. The business analyst should ensure that enough information is gathered and documented to complete the requirement; however, too much information makes the requirement difficult to follow and convey.

Location 3375: Guidelines concerning requirements completeness are as follows:
~ Document all known requirements, especially those that are confirmed by the stakeholders. This includes all conditions that apply to a requirement.
~ Include in each requirement all of the information necessary for the solution team to design, build, and test the solution component. A requirement is said to be “self-contained” when this is true.

Location 3396: A requirements specification is complete when it contains the following:
~ All necessary requirements,
~ Responses specified for all inputs,
~ Requirements that produce all necessary outputs, and
~ Labels and references to all figures, tables, and diagrams.

Note: What constitutes completeness is dependent on the selected project life cycle.

~ Measurable => Each requirement needs to be independently measurable. A requirement that is measurable provides the necessary detail to understand the criteria for testing. Measurability is usually a prerequisite to testability; a requirement that is not measurable cannot be tested

~ Feasible => The focus of the feasibility analysis performed at the forefront of the business analysis work pertains to the work to determine the feasibility of various solution options.Feasibility here is conducted at a much more specific and detailed level. The same categories of feasibility used in the needs assessment when evaluating a solution option can be applied here to evaluate the feasibility of a requirement. For example:

=> Operational feasibility: When the solution requirement is met, will the implementation of it within the solution be supported by all stakeholders who use the new product or solution? Ensure a solution requirement for one stakeholder group does not make the use of the product inefficient or unusable to another stakeholder group.

=> Technology/system feasibility: Can the requirement be fulfilled based on the technologies that have been selected for the solution? While the solution as a whole was assessed for technical feasibility, the focus here is on each specific requirement. Involve the solution development team to ensure that each requirement is technically feasible. When following a predictive or iterative life cycle, ensure requirements are evaluated for feasibility by the solution development team before they are baselined.

=> Cost-effectiveness feasibility: Does the cost to fulfill the requirement make sense with respect to the value the requirement will deliver to the business? Work with the solution development team, business stakeholders, and the project manager to ensure the cost-effectiveness of each requirement is analyzed. A requirement makes sense when the value it provides is greater than the cost to implement it.

=> Time feasibility: Can the defined requirement be met within the time allocated for the project phase or should the feature be considered for a future release? A project delay may occur from a single requirement; therefore, it is better to know up-front when a requirement will require a level of effort by the solution development team that exceeds the time allocation for the entire development phase.

~ Traceable => Traceable requirements are those that can be mapped back to the source of the requirement and mapped forward through the development life cycle to a test case that proves that the requirement was successfully satisfied. Requirements may also be traced between requirements and back to business goals, objectives, and higher level requirements.

It is important to be able to trace any given requirement back to a source in the event that there are changes to the requirement or other changes that impact the requirement. The business analyst uses the source to identify who to contact when the requirement changes.

~ Testable => Requirements should be written in a way that allows them to be tested. When a requirement is not testable, it is typically because the requirement is vague, unclear, ambiguous, or has violated some other principles or writing guidelines for quality requirements. Testable requirements allow for an assessment of pass/fail.

4.11.6. Prioritizing Requirements

Location 3450: How requirements are prioritized should be fully defined in the business analysis plan.

Location 3452: The business analysis work in requirements elicitation and analysis is performed to use one or more prioritization techniques in order to facilitate priority decisions from the key stakeholders. The key stakeholders here are those stakeholders who have the authority to prioritize requirements as specified during planning.

4.11.6.1. Prioritization Schemes

Location 3457 Drive the prioritization decisions from the business by using one or more of the following techniques to help support the prioritization activity:

~ MoSCoW => MoSCow establishes a set of prioritization rules which are:

=> Must haves: (fundamental to project success),
=> Should haves: (important, but the project success does not rely on them),
=> Could haves: (can easily be left out without impacting the project), and
=> Won't haves: (not delivered this time around).

~ Multivoting => There are many forms of multivoting that are designed to gain active participation from stakeholders. This technique provides a process for participants to apply votes to a list of items to determine an answer based on number of votes received. When using multivoting for setting priorities, the requirement with the most votes is deemed the higher priority item.

~ Time-boxing => Time-boxing is a prioritization technique that is used when the project has a fixed timeline and the timeline is not negotiable. Time-boxing approaches the prioritization of requirements by analyzing the amount of work the project team is capable of delivering during a prescribed period of time. The project team determines the scope based on what work can be completed within the fixed window of time. If the time-box is 90 days, the project team evaluates the list of requirements and determines what can be delivered within that 90-day window.

~ Weighted ranking => Weighted ranking begins in business analysis planning before the possible solution options are listed. Prior to performing weighted ranking, the business analyst facilitates a decision regarding which criteria the decisions will be based on. Possible options are efficiency, ease-of-use, attractiveness, etc. Once a short list of criteria has been selected, the criteria are ranked with a score. The highest score is assigned to the criterion considered to be most important, thereby creating the weighted rankings.

4.11.7. Technical Requirements Specification

Location 3485: Technical specifications may contain such elements as:
~ Wireframes describing the appearance of a user interface,
~ Screen mockups specifying the details of a user interface screen,
~ Data models and schema,
~ Detail process flows such as data flow diagrams or activity diagrams, and
~ Detailed requirements that include technical references.

Collaboration Point—For IT projects, some organizations have a systems analyst who produces the technical specification, dividing the requirements documentation between the business analyst and the IT analyst. The business analyst then produces the business requirements specification and the systems analyst prepares the technical requirements specification.

4.11.8. Documenting with use Cases

Location 3497: A use case may represent one or more functional requirements. Use cases may supplement text-based requirements and are developed for areas of the system where the interaction of the system and the user are more complex.

The decisions regarding the preferred documentation approach for the project is made in business analysis planning.

4.11.9. Documenting with user Stories

Location 3503: A documented user story is sometimes written on an index card. Writing the story on a card enforces brevity and concision. When cards are not used, maintain the stories in a document, spreadsheet, or requirements management tool. When packaged together, user stories represent a high-level version of solution requirements.

Location 3505: User stories are a documentation method for breaking down features into manageable parts and provide a simple and effective mechanism to segment a complex set of features into simple, definable elements.

4.11.10. Backlog Items

A backlog is a prioritized listing of product requirements and deliverables to be completed, often written stories, and prioritized by the business to manage and organize the project's work.

Location 3513: In agile approaches, the business analyst is often assigned to help the product owner groom the product backlog, which involves adding and removing backlog items and reprioritizing based on changing business conditions and priorities.

4.12. Validate Requirements

Validation is defined as the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. In business analysis, requirements validation is the process of ensuring all requirements accurately reflect the intent of the stakeholder; thereby ensuring the requirements meet their expectations.

4.12.1. The Concept of Continual Confirmation

Location 3520: Confirmation is not an activity that is performed once at the end of the requirements process. Confirmation occurs whenever the business analyst reviews the information gathered during an elicitation session with the stakeholder or any part of the developing solution is shown to the stakeholder.

Confirmation is not approval—only authorized stakeholders can approve. Confirmation means obtaining agreement from the stakeholders that the solution under development is good and will accomplish the objectives.

Location 3525: It is easier to obtain low-level confirmation on a continuing basis than to try to have the entire solution document confirmed and approved at the same time. When the requirements are broken up into small, self-contained units, the review sessions involve fewer participants and take less time.

Location 3527: It may also be helpful to divide the requirements document up by functional area and ask stakeholders to confirm the requirements that impact their area. This requires more work, but stakeholders will appreciate being able to focus specifically on their own requirements.

4.12.2. Requirements Walkthrough

Requirements walkthroughs are used to review the requirements with the stakeholders and to receive confirmation that the requirements as stated are valid.

Location 3533: To conduct a requirements walkthrough, the business analyst schedules the session providing the stakeholders enough time to prepare. Reviewers may be asked to read the materials before attending and, by doing so, the reviewers will be able to:

~ Think about the stated solution ahead of time, better preparing their feedback,
~ Avoid providing emotional reactions to the material in the session, and
~ Take time to discuss the materials with their organizational units and peers so that feedback provided is representative of the larger stakeholder group.

Location 3539: The flow of information should come from the reviewers as much as possible. This session is one of the final opportunities for the stakeholders to raise questions, seek clarity, and voice concerns. The business analyst can use this session as an opportunity to field questions and seek to close down any open requirements-related issues in preparation for receiving final approval of the requirements.

4.13. Verify Requirements

Verification is the process of reviewing the requirements for errors and quality. Verification may occur before or after validation. Verifying requirements after they have been validated or confirmed by product stakeholders ensures that only the requirements that are considered to be “good” requirements are verified.

Location 3545: Validation is concerned about ensuring that the requirements solve the problem—verification is not. Verification is performed by members of the solution team to ensure that the requirements meet quality standards or any other business analysis deliverable in the process meets the standards of excellence for the organization.

Location 3547: There are two types of verification processes: peer reviews and inspections.

4.13.1. Peer Review

Location 3549: Peer reviews can be conducted at any point during the requirements process.

In business analysis, a peer review is a formal or informal review of the requirements by the peers of the business analyst.

Location 3552: The purpose for the peer review is to ensure that the written business analysis deliverables, including all forms of requirement documentation, are in compliance with the organizational standards and generally held principles of requirements writing.

Location 3554: An informal peer review may be held with a couple of business analysts before conducting a requirements review meeting with business stakeholders. This helps to ensure there are no glaring errors in the requirements that could cause problems during the review. Peer reviews may also be held after the review sessions with the business stakeholders to ensure the final document is understood and accepted by the solution team and development community in general.

Location 3562: For organizations who use a requirements management tool, there are a number of features that can be used to track the comments provided by document reviewers.

Collaboration Point— Ask testers and those involved in developing training manuals to be part of the verification review. This provides these team members with the project background and context early on. These team members will focus on the details and check for consistency, completeness, and testability of the requirements, which is beneficial for the verification review.

4.13.2. Inspection

Location 3568: Inspections are a more rigorous form of a peer review. Inspections were initially targeted for hardware development and were later modified to be applicable for anything that needs to be reviewed for accuracy, completeness, and relevance, etc.

Location 3570: In a predictive life cycle process, requirements inspections are typically performed once at the end of the requirements process when the document is ready for final approval.

The objective is for the business to ensure that the requirements are acceptable in their current form. Inspections can also be performed on groupings or chunks of completed requirements.

Location 3573: The inspection is performed by peers who participated in the creation and documentation of the requirements and are the recipients of the requirements document. Business stakeholders and management are excluded from an inspection session, especially the line management of the inspectors.

Location 3576: A requirements inspection checklist could include the following items:
~ Are all internal cross-references to other requirements correct?
~ Are all requirements written at a consistent and appropriate level of detail?
~ Do the requirements provide an adequate basis for design?
~ Is the implementation priority for each requirement included?
~ Are all external hardware, software, and communication interfaces defined?
~ Have algorithms intrinsic to the functional requirements been defined?
~ Is the expected behavior documented for all anticipated error conditions?

A checklist differentiates an inspection from a peer review. A peer review depends on the knowledge of the reviewers whereas the inspection uses a checklist of known defects for the product being inspected. Inspections also follow a more rigorous process than peer reviews and use a series of rules to govern how they are performed.

4.14. Approval Sessions

Location 3586: Approval sessions are conducted separately from confirmation sessions. After the solution is confirmed and validated, the business analyst obtains signoff on the requirements. Signoff may be formal or not and may be predetermined in business analysis planning.

When signatures are sought, there are three signatures that are usually requested:

Business owner, such as the executive in charge of the business area, who agrees that the requirements represent a complete and accurate solution to the problem.
Solution team recipient, who accepts the document and acknowledges that it is sufficient to build the documented solution.
Business analyst, who prepared the deliverable.

Location 3597: Problems in obtaining approval arise when the lower-level managers or process workers have not seen the requirements yet and are unable to provide a positive opinion about them to the senior manager.

4.15. Resolve Requirements-Related Conflicts

Location 3603: The business analyst mediates the situation by discussing the differences and by understanding the points of view of each stakeholder. Several discussions may need to occur before a resolution is reached. When unable to reach a decision, the issue needs to be escalated.

Location 3604: The process for making decisions, resolving requirements-related conflicts, and the escalation path to follow when negotiating efforts fail should have been defined during business analysis planning.

Location 3606: Business analysts require soft skills in negotiation and need to learn how to bring opposing sides to consensus. Facilitating a win-win solution is key. The business analyst also should be capable of analyzing the reasons as to why the conflict exists. There are numerous techniques that can be used to help a team reach a decision or resolve a conflict. Techniques remove subjectivity and emotion from the process.

4.15.1. Delphi

Location 3611: The Delphi technique is an information-gathering technique used as a way to reach consensus from experts on a subject. Experts on the subject participate in this technique anonymously. A facilitator uses a questionnaire to elicit ideas about the important points related to the subject. The responses are summarized and are then recirculated to the experts for further comments.

The Delphi technique helps to reduce bias in the data and prevents any one person from having undue influence on the outcome. The Delphi method relies on peer pressure and the wisdom of crowds to produce the correct decision or solution. This technique works well for teams operating from diverse locations.

4.15.2. Multivoting

Location 3617: When applying the multivoting technique to resolve a conflict, the team brainstorms to generate a possible list of options for resolving the conflict. The team decides how many items will be on the final list. All of the items remaining after a first cut of the brainstormed answers or solutions are then numbered. Each participant receives a limited number of votes and is asked to place the votes against the unranked choices.

4.15.3. Weighted Ranking

Location 3624: The same weighted ranking technique used to rank solution options in needs assessment and to prioritize requirements in requirements elicitation and analysis, is applied to resolve requirements-related conflicts.

5. TRACEABILITY AND MONITORING

5.1. Overview of this Section

Location 3631: From the perspective of the PMBOK® Guide – Fifth Edition, traceability and monitoring consist of the activities completed to ensure that requirements are approved and managed throughout the project life cycle.

Location 3633: During traceability and monitoring, the traceability matrix and associated attributes are created and applied to help monitor and control the product scope. Approved requirements are baselined and tracked. As new requirements surface, these are documented, added to the traceability matrix, assessed for their impacts to the project and product, and presented to stakeholders for approval.

Location 3635: Throughout traceability and monitoring, the status of all requirements is communicated using the communication methods defined and approved within the business analysis plan.

Location 3639: Traceability principles that enable change impact analysis are the basis for confirming fulfillment of objectives and ensuring test coverage. Traceability enables the discovery of missing and extraneous requirements.

Location 3642: Traceability should be maintained, at a minimum, for the entire duration of the project, even when someone with a business analysis role is no longer associated with the project.

5.2.1. What is Traceability?

Traceability provides the ability to track product requirements from their origin to the deliverables that satisfy them. Traceability is sometimes qualified as bidirectional or forward and backward, because requirements are traced in more than one direction.

From the perspective of the PMBOK® Guide – Fifth Edition, traceability includes, but is not limited to tracking the following requirements:
~ Business needs (business problems or opportunities), goals, and objectives;
~ Project objectives;
~ Project scope/WBS deliverables;
~ Product design components;
~ Product development components;
~ Test strategy and test scenarios;
~ High-level to more detailed-level requirements;
~ Detailed to higher-level requirements; and
~ Different types of functional requirements that are related to each other. For example, adding a new customer type requires changes to several business processes that use customer data.

Additionally some practitioners trace:
~ Use cases to acceptance tests, as well as to other types of requirements, and
~ Models and diagrams to their related requirements.

For projects using an adaptive life cycle:
~ Epics or user stories may be traced to features and acceptance tests.
~ A Kanban Board may provide some amount of traceability.

Collaboration Point—Decisions about how the traceability process will be conducted are determined during business analysis planning. Conducting minimal traceability can incur project risks, and using an extensive traceability process can consume a lot of time and require extensive management of the traceability links. The business analyst should work with the project manager to determine how much traceability is appropriate for the project, because traceability impacts the usage of resources and the level of project risk.

5.2.2. Benefits of Tracing Requirements

Location 3678: Tracing requirements provides significant benefits:

~ Helps to ensure that each requirement adds business value => Tracing each requirement to the business need, goals, and objectives helps ensure its relevancy. On the other hand, when the requirement is unable to be traced to a business need, goal, or objective, its relevance needs to be analyzed. In this case, the business analyst should consider such things as:
=> Have the business needs, goals, and objectives been articulated in enough detail? A requirement may be relevant, but there may be an incorrectly stated problem or missing objective.
=> Are there missing requirements? Project objectives with no associated requirements indicate that the objective will not be met. Without defined requirements, the end product, service, or result will not add the value that the organization anticipates.
=> Does a specific project objective belong in the project? When there are project objectives without requirements, the objective is misaligned with the current project, in which case it belongs elsewhere or should be eliminated.

~ Helps to meet customer expectations => Traceability provides a means to track requirements throughout the project life cycle, helping to ensure that approved requirements are delivered at the end of the project. For example, a data field on a user interface (UI) is an approved requirement, but if it is not developed, tested, or delivered, the expected data field will be missing from the UI in the implemented solution.

~ Helps to manage scope => It is more difficult for requirements that do not add value to make their way into the product, because approval is provided only to requirements that add value.

Collaboration Point—There is often confusion between project managers and business analysts as to who manages scope. The project manager is responsible for managing project scope while the business analyst is responsible for managing product scope. The process of tracing requirements is a clear example of the involvement that the business analyst has in scope management at the product level.

5.2.3. The Traceability Matrix

A traceability matrix is a grid that allows for the linkage of product requirements from the source to the deliverables that satisfy them throughout the project life cycle.

Location 3704: The implementation of a requirements traceability matrix supports the goal that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. The matrix also provides a structure for managing changes, thereby helping to manage the product scope.

Location 3707: For formal traceability, a traceability matrix contains a short description of each requirement and facts about the requirements, which are called attributes. Requirement attributes help define key information about the requirement. Each attribute forms a column on the traceability matrix.

5.2.3.1. Requirements Attributes

Location 3723: From the perspective of the PMBOK® Guide – Fifth Edition, typical attributes used in the requirements traceability matrix include but are not limited to:

~ Requirement ID, which uniquely identifies each requirement;
~ Short textual description of the requirement;
~ Objectives: Business need, Business goals and objectives, and Project objectives;
~ Product development stage: Design, Build, Test, Implement, and Verify;
~ WBS (work breakdown structure), a cross reference to deliverables as identified in the WBS;
~ Status, such as active, approved, deferred, canceled, added;
~ Rationale for inclusion (why the requirement is important to include);
~ Priority (how important the requirement is);
~ Owner;
~ Source (where the requirement came from);
~ Version;
~ Date completed;
~ Stakeholder satisfaction;
~ Stability;
~ Complexity; and
~ Acceptance criteria.

5.2.3.2. Traceability Matrix Hierarchy

Location 3744: A formal traceability matrix is usually built hierarchically, starting with high-level requirements and filling in the details as the requirement is progressively elaborated. This hierarchy is similar to an outline that is filled in as more detail is known.

Location 3746: There are several advantages to creating a hierarchical grid:

~ It provides a logical order for the requirements, one that is not disrupted when new requirements are added.
~ Traceability can be started as soon as the first requirement is defined and detailed, because the requirements are progressively elaborated, allowing for the incremental development of the requirements.
~ There is no implied sequence, which enables work to be easily divided up among the team.

Location 3757: The matrix also helps to evaluate new requirements against associated high-level and lower-level requirements when they are added to ensure alignment in all directions.

Collaboration Point—Some organizations develop a traceability matrix template as a starting point. During business analysis planning, the business analyst collaborates with the project manager and business stakeholders to determine which components of the template are to be used during the project, which components complete the matrix, and at what point during business analysis is traceability considered to be complete.

5.3. Relationships and Dependencies

Location 3762: The traceability matrix is a tool that supports dependency analysis and impact analysis. Requirements are often related to other requirements; therefore, sometimes a requirement is not able to be satisfied in a solution without the other(s) being present.

Dependency analysis is a technique used to discover these dependent relationships. Once analyzed, the set of requirements on the traceability matrix is recorded by grouping dependent requirements together. Some requirements management tools illustrate the dependencies visually by creating traceability trees.

Location 3766: Some examples of dependent relationships are as follows:

5.3.1. Subsets

Location 3768: A requirement may be a subset of another requirement.

Example—An organization may have different types of customers—retail customers and business customers—which are considered subsets or subtypes of a customer. All customers may have some common data, such as customer ID, name, and contact information, in addition to some common processes performed on the common data, such as ordering products. Each subset of customer may have data and processes unique to them. Retail customers may have a frequent buyer program and may allow customers to select preferred pickup times for products they purchase. Business customers may have a tax identification number and a line of credit, and may also be permitted to purchase products that are not available to retail customers. The hierarchical relationships of these requirements are easy to portray in a traceability matrix.

5.3.2. Implementation Dependency

Location 3775: Some requirements are dependent on the implementation of other requirements before they can be implemented.

Example—An organization is interested in developing a new sales report but discovers that some of the data to be included on the new report is not being captured. In this case, the reporting requirements are dependent on additional functional requirements to allow the new data elements to be captured on the customer order entry screen.

5.3.3. Benefit or Value Dependency

Location 3780: Sometimes the benefit of a requirement is unable to be realized unless another requirement is implemented first.

Example—An organization interested in improving wait times for customers calling into their phone reservation center finds out that a requirement to add a new phone line has been identified as a high-priority feature, but unfortunately the existing phone system is unable to accommodate any additional phone lines. This particular requirement's value will not be achieved until a new phone system is implemented.

5.4. Approving Requirements

Location 3787: The approval process is determined, documented, and approved up-front in business analysis planning. Determining the process early on helps to avoid conflicts later when the approvals are being sought. The approval process may include any of the following:

5.4.1. Work Authorization System

Location 3790: The work authorization system defines the process for authorizing work. It may include process steps, documents, tracking systems, and approval levels. The work authorization system is one of many organizational environmental factors that lie outside the control of the project team and therefore constrain the project team's options.

Location 3795: An agile team may agree that when the team wants to add any user stories, the product owner needs to approve them before they are put on the backlog, or it may decide that the team can add the items to the backlog, in which case the product owner's prioritization of the items becomes the mechanism for approval.

5.4.2. Approval Levels

Location 3800: Approval levels provide the detail regarding who has the authority to approve new and changed requirements. In absence of a work authorization system or when the current system does not cover requirements approval, the business analyst, project manager, and sponsor determine requirement approval levels in business analysis planning. Tools such as a RACI are helpful in facilitating discussions and decisions about approval levels.

Location 3803: There are different types of approvals. Distinguishing among these different types helps to avoid confusion about who gets to approve what. Some examples are:

~ Approval vs. signoff => In one organization, business stakeholders may approve a set of requirements during a facilitated workshop and the sponsor may sign off on the requirements, knowing that the business provided verbal approval. In this example, there is a difference between approval and signoff. The sponsor is designated as the only person responsible for signoff. In another organization, the business analyst, the project manager, all business stakeholders, and the project sponsor are required to sign off on each business analysis deliverable including all requirements documents.

~ Reviewer vs. approver => On one project, it was explained to the testers that they would review the requirements and their input was welcome, but they were not authorized to approve or reject requirements. On another project, testers review the requirements and when any are not clear, the testers have full veto power to reject any of the requirements.

~ Approval authority vs. accountability => In one organization, business analysts were expected to be responsible for managing the requirements, the project manager was accountable for ensuring that the requirements were managed, and the sponsor was accountable for the end product and, therefore, the requirements of that product.

~ Rejection of requirements => It is not always clear who can reject requirements. In some organizations, the power to reject requirements is granted only to those who are permitted to sign off on them. In other organizations, all participants in the requirements process may be provided with veto power, regardless of whether they have been granted approval authority or not.

~ Change Control Board (CCB) and approval of changes => A CCB is a formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project, and for recording and communicating such decisions. The CCB is often the ultimate source for approving requirements when there is a significant scope change beyond the project manager's ability to approve. Approved requirements are then baselined, and changes are proposed through the CCB. The CCB may choose to have change requests under a prescribed dollar limit approved by business stakeholders and/or the sponsor, and change requests over the limit approved by the CCB. There are many ways for an organization to use a CCB within the requirements process. The process for the current project should be described and documented in the business analysis plan.

Collaboration Point—Organizations that use an adaptive life cycle may also have CCBs. When they exist, teams on adaptive life cycle projects and the CCB need to determine an optimal way to interact with each other.

~ Expert judgment and the approval process => In addition to the business analyst, stakeholders may be asked to provide their expertise. Subject matter experts may be asked to sit on the CCB periodically or when specific changes arise based on their expertise relating to the proposed change. Their judgment and expertise are leveraged when assessing whether the change makes sense.

5.5.1. What is a Requirements Baseline?

The requirements baseline is the boundary that contains all of the approved requirements for the project, project phase, iteration, increment, release, or any other part of a project.

Location 3833: The baseline provides a mechanism for comparison, thereby allowing the project team to recognize that a change has occurred. All approved work is inside the boundary or baseline. Everything outside the boundary needs to be approved. Once requirements are approved, these can be changed only through the change control procedures defined for the project.

5.5.2. Relationship of Requirements Baseline, Product Scope, and Project Scope

The project scope is the work performed to deliver a product, service, or result. The product scope is comprised of the features and functions that characterize the product, service, or result. Requirements describe features and functions of the final product, service, or result for the project; therefore, there is a direct relationship between the number of requirements and the product scope.

Location 3843: The more approved requirements there are, the larger the product scope and the project scope.

5.5.3. Maintaining the Product Backlog

Location 3846: For projects that follow an adaptive life cycle, baselining requirements is performed by maintaining the product backlog.

The product backlog is the list of requirements, usually written in the form of user stories.

Location 3849: On adaptive life cycle projects, a subset of the backlog is approved for each iteration.

Location 3853: The priority of user stories can change at any time. A requirement thought to be a high priority at the beginning of a project may be changed to a lower priority as the project progresses. On the other hand, the product owner could elevate the priority of other requirements that were originally thought to be unimportant.

Location 3856: As requirements are added to the product backlog or changes in priority result in the movement of requirements from one release or iteration to another, the changes are tracked and communicated to the appropriate stakeholders as agreed upon in the communication plan, either formally or informally.

5.6. Monitoring Requirements using a Traceability Matrix

Location 3859: Once the requirement attributes are determined, the traceability matrix created, and requirements approved and baselined, the requirements are monitored throughout the project life cycle. At this point, every detailed requirement should align with a business requirement.

Location 3862: Projects with an adaptive life cycle that use a traceability matrix may build the matrix incrementally in a consistent manner as details are elicited and analyzed.

5.6.1. Benefits of using Traceability to Monitor Requirements

Location 3864: Monitoring requirements throughout the life cycle using a traceability matrix or similar structure helps to ensure that:

~ More detailed requirements that surface are linked to the baselined requirements. As the requirements are progressively elaborated and additional details surface, the relationships are progressively elaborated. Every detail relates back to a higher-level requirement.

Example—An organization has a baselined requirement to support multiple customer types. Through business analysis requirement workshops, it is uncovered that there is a difference in how complaints are handled for each customer type. Detailed requirements emerge for a concierge service for business customers, which trace back to the initial requirement.

~ A complete set of baselined requirements has the detail needed to build the feature or set of features. When a high-level requirement exists with no associated detail requirements, this points to an area needing further requirements elicitation to uncover the details.

~ Supporting business analysis work products are created for each baselined requirement when needed.

~ Work products created across phases, such as design and test documents, are created for each approved requirement. Requirement relationships are monitored to their related work products to help ensure that gaps between the approved requirement and what has been built and tested are not missed.

When gaps are identified, the business analyst should:
~ Cancel or defer the approved requirement, or
~ Create the missing work product.

~ Scope creep is prevented.

PMI defines scope creep as the uncontrolled expansion to product or project scope without adjustments to time, costs, and resources.

Location 3885: Projects using a predictive life cycle with many work products can monitor requirements relationships and also review each work product that is created throughout the project to ensure that it links back to an approved requirement.

For example, when requirements are included on a traceability matrix, it is easier to see this linkage and spot missing requirements. By routinely comparing work products to requirements on the traceability matrix as they are created, gaps can be questioned and appropriate action taken.

Location 3895: Product owners on projects using an adaptive life cycle manage scope creep through regular reprioritization of the backlog. For adaptive projects, traceability matrices may be used to help manage scope creep or less formal techniques may be used to achieve the same level of thought.

5.7. The Requirements Life Cycle

The state of a requirement characterizes where it is in the requirements life cycle. The requirements life cycle, not to be confused with the project life cycle, represents the various phases that a requirement moves through as it is maintained across the project.

Location 3904: An authorizing body influences the requirement state when making decisions on requirements, such as:
~ Approving a requirement but postponing it to another project, iteration, or project phase;
~ Deferring a requirement to some unspecified future project, iteration, or project phase;
~ Replacing an approved requirement that has not been started with another requirement;
~ Canceling an approved requirement;
~ Rejecting a requested requirement; or
~ A combination of the above. For example, the authorizing body could approve one part of the requirement but defer another part.

Location 3914: The requirement state is used when reporting requirement status to project stakeholders. For example, the state is required in order to report how many requirements are documented and how many are approved, deferred, or rejected in order to provide a fuller understanding of the conditions of the requirements on the project at any given point in the life cycle.

5.8. Managing Changes to Requirements

Change requests are a part of the overall change control process. The PMBOK® Guide –Fifth Edition defines a change request as a formal proposal to modify any document, deliverable, or baseline.

Location 3926: The change control process defines how changes are submitted.

Location 3928: A change request process defines the information required to be gathered before a request can be considered for approval.

5.8.1. Change Management as it Relates to Business Analysis

Location 3933: Within change management, the role of the business analyst is to maintain the integrity of the requirements and the associated deliverables and work products and to ensure that each new requirement aligns with the business need and the business and project objectives.

Location 3935: The key benefit of a requirements change process is to allow for changes to documented requirements while reducing product and project risk, which often arises from making changes without consideration to the overall impact to the product and project, as well as considerations related to dependencies.

Location 3940: Project managers and business analysts both have an interest in change management. The project manager is concerned with all things associated to project scope. The business analyst is interested in understanding the impacts to product scope, such as how the change request will impact documented requirements, existing and approved business analysis work products (e.g., process flows and models), and any product components that have been built and tested from existing approved requirements.

Collaboration Point—Assessing the impacts a proposed change will have on project and product scope requires the collaborative efforts of both the project manager and business analyst. It is important for the business analyst and project manager to have frequent communication about the proposed changes and their disposition. For projects using an adaptive life cycle, the team determines the details for most of the requirements on a just-in-time basis. Most details are elicited during the iteration or increment in which the requirement or user story will be delivered. Because requirements details emerge along the way, product owners and their teams expect changes during an adaptive project. The product owner regularly reprioritizes what is to be delivered, usually at the start of a new increment. Since adaptive projects rapidly deliver small increments, while changes tend to be frequent and each change is often small, it is more likely that small changes will be assessed on an informal basis. Changes that add value can be accepted and prioritized.

5.8.2. Change Control Tools and Techniques

Location 3959: When a change control tool is being introduced on a project, the needs of all stakeholders involved in the change control process should be considered.

Collaboration Point—The business analyst and project manager need to work together to ensure that both business and technical stakeholders’ needs are met when defining the change control process and the supporting tools.

6. SOLUTION EVALUATION

6.1. Overview of this Section

Location 4082: Evaluation consists of business analysis activities performed to validate a full solution—or a segment of a solution—that is about to be or has already been implemented. Evaluation determines how well a solution meets the business needs expressed by stakeholders, including delivering value to the customer. Some evaluation activities result in a qualitative or coarsely quantitative assessment of a solution.

Location 4086: Comparisons between expected and actual results obtained from a solution are usually expressed quantitatively. For solutions involving software, analyzing comparisons between expected and actual values of data manipulated by the high-level functionality of the solution can be part of the evaluation.

Location 4088: Nonfunctional characteristics of a solution (sometimes known as quality attributes) are often evaluated with measurements. For example, measurements are required to evaluate whether performance service-level agreements are being met. Additionally, comparing estimated and actual costs and benefits may be part of an evaluation of a solution.

Location 4094: Many of the techniques used during evaluation activities are also used during analysis or testing and sometimes during needs assessment. In addition, there is some overlap between evaluation techniques and traceability. The use of analysis techniques for multiple purposes is natural because one of the overarching goals of all analysis activities is to obtain a clear, unambiguous understanding of all aspects of a problem under consideration.

Location 4099: Techniques for defining acceptance criteria are also used as part of planning and analysis, as a basis for testing, and for defining service-level agreements and nonfunctional requirements.

6.2. Purpose of Solution Evaluation

Location 4101: Solution evaluation activities provide the ability to assess whether or not a solution has achieved the desired business result. Evaluation provides input to go/no-go business and technical decisions when releasing an entire solution or a segment of it.

For projects using iterative or adaptive life cycles, and for multiphase projects using predictive life cycles, evaluation may identify a point of diminishing returns. An example of this is when additional value could be obtained from a project, but the additional effort needed to achieve it is not justified.

6.3.1. Evaluate Early and Often

Location 4111: When evaluation criteria are defined early, they can be applied to a project in progress and provide input into the development of test strategies, test plans, and test cases. Early uses of lightweight evaluation techniques identify which areas of a solution need the most testing. Early articulation of evaluation criteria is an excellent way to specify or confirm both functional and nonfunctional requirements.

6.3.2. Treat Requirements Analysis, Traceability, Testing, and Evaluation as Complementary Activities

Location 4115: Adaptive life cycles explicitly define acceptance criteria with concrete examples as part of the elaboration of a user story. The acceptance criteria and the user story definition support each other. Together, these establish mutual agreement between business stakeholders and those responsible for developing the solution for what is required and how to know that the requirement has been met. Predictive and iterative life cycles also recognize the value of early testing in a project.

Collaboration Point—Business analysts, project managers, and testers should work together early on to create consistent and complementary approaches to analysis, testing, and evaluation activities. Testers can help check for completeness and consistency of all forms of requirements and evaluation criteria, and business analysts can help check for sufficient test coverage for areas of the solution that have the highest business priority.

6.3.3. Evaluate with the Context of usage and Value in Mind

Location 4127: Validation not only ensures that the solution is working as designed, but also confirms that it enables the usage and value that the business expected.

6.3.4. Confirm Expected Values for Software Solutions

Location 4139: For automated solutions, it is essential to validate functionality that manipulates data by using the solution's data retrieval functionality. However, the sufficiency of the solution also needs to be evaluated by confirming that the actual data is accurately stored, because that data may potentially be retrieved in other ways for other users and uses.

Location 4150: Evaluation of a software solution is usually conducted against a system that is either about to be released or has already been released; therefore, testing during evaluation usually encompasses a larger body of data than the initial testing.

6.4. Plan for Evaluation of the Solution

It takes time and effort to identify and confirm evaluation criteria, implement anything necessary for taking measurements that is not already built into the solution or its infrastructure, take the measurements, and report on and analyze the measurements.

Location 4156: Factors to consider when planning for evaluation activities include:

~ What project or organizational goal, objective, or risk does this evaluation activity monitor or track or confirm? It is important to tie every evaluation activity and every individual metric to organizational or project priorities.
~ Who will cover costs for the time and effort needed to conduct evaluation? The organizational area that is going to assume the costs for evaluation should be involved in approving the estimates for the evaluation activities. These estimates should be provided as early as possible in the project life cycles.
~ Does the solution or its infrastructure have built-in measurement capabilities for the evaluation criteria?
~ Are there already ways to extract measurement data to use in the evaluation?
~ Is the chosen evaluation method effective and relatively inexpensive?
~ Are there already existing ways to report and publish the results of an evaluation?

6.5. Determine what to Evaluate

Location 4198: There are a number of factors to think about when identifying evaluation criteria. This section presents a list of these items for consideration.

6.5.1. Consider the Business Goals and Objectives

Location 4201: Business goals and objectives and priorities enable a project to launch and hopefully result in a solution. The solution needs to be evaluated against those goals and objectives. In this practice guide, Section 2 on Needs Assessment emphasized that goals and objectives need to be SMART. The measurements specified in the goals and objectives serve as good clues as to what needs to be measured during the evaluation of the solution.

6.5.2. Consider Key Performance Indicators

Location 4205: Key performance indicators (KPIs) are metrics that are usually defined by an organization's executives.

These indicators can be used to evaluate an organization's progress in achieving its objectives or goals.
Typical broad categories of KPIs are:
~ finance,
~ customer,
~ sales and marketing,
~ operational processes,
~ employee,
~ environmental/corporate, and
~ social responsibility/sustainability.
~ Sometimes information technology is rolled into the operational processes category and sometimes it is considered a separate KPI category.

6.5.3. Consider Additional Evaluation Metrics and Evaluation Acceptance Criteria

Location 4213: While many of the metrics and acceptance criteria for evaluating the solution fall out of the goals, objectives, or KPIs, there may be additional metrics and acceptance criteria to consider. Some examples of additional metrics and acceptance criteria are:

6.5.3.1. Project Metrics as Input to the Evaluation of the Solution

Location 4215: When considering project metrics as input to the evaluation of a solution, it is important to distinguish between those metrics that support evaluating the solution and those that focus on project execution.
Location 4219
Metrics derived from measurements of cost, effort, and duration, such as variances between estimated amounts and actual values, are used to track project progress and performance. Some organizations use earned value calculations for this purpose. While variances and earned values are important metrics for many organizations when evaluating projects, they do not explicitly evaluate the solution, and in any event, are usually within the purview of project management rather than business analysis.

Projects using an adaptive life cycle, such as Scrum or Kanban, often use other metrics to reflect a project team's rate of progress on a project. The measurements are often expressed in terms of burndown (the number of backlog items remaining at any point in time) and velocity (the number of backlog items completed during a delivery interval). These measurements reflect the efficiency of the project, what the project has delivered, what was deliberately not delivered (descoped), and what remains to be delivered.

Collaboration Point—Business analysts and project managers should work together with stakeholders to consider which project metrics should be incorporated into evaluation activities.

6.5.3.2. Customer Metrics

Location 4236: From a customer perspective, evaluation sometimes focuses on qualitative aspects, such as satisfaction, but even qualitative aspects can be measured semiquantitatively.

6.5.3.3. Sales and Marketing Metrics

Location 4243: Sales and marketing may have ranges of measurable goals for the project (e.g., a range of expected values for overall increased market share or a range for percentage increase in the amount of business done with existing customers). The solution can be evaluated to determine whether or not these expectations have been met.

6.5.3.4. Operational Metrics and Assessments

Location 4246: Operational metrics may be functional or nonfunctional and can be considered from a systems perspective, a human perspective, or both. For organizations that define and measure operational KPIs, it may be possible to reuse one or more of the metrics to evaluate the solution, provided it is possible to determine the impact of the solution on the KPI.

6.5.3.5. Functionality

Location 4254: With the exception of situations where errors in the solution could result in an unacceptable level of risk to life, property, or financial solvency, evaluation should not require a review of the results of the individual tests conducted during the development of the solution, other than to confirm that the test coverage was sufficient. Nonfunctional requirements are used to specify overall system-wide characteristics of the solution, such as performance, throughput, availability, reliability, scalability, flexibility, and usability.

Example—What is the availability of the new mobile application? Can it support an x% increase in the number of users using it simultaneously (where “x”is defined by the business)?

Location 4260: Organizations that already define and measure information technology KPIs may already have instrumentation to measure system-wide, nonfunctional requirements, such as availability. Nonfunctional requirements can also be evaluated at a usage level. Example—In the insurance example, from a usage perspective, how easy was it for a customer to file a claim (where “easy” is defined in a measurable way)? How fast did an automatic adjudication occur?

Clearly specified nonfunctional requirements should be written to identify their measurable acceptance criteria. Measurable acceptance criteria can also be the basis of service-level agreements.

6.5.4. Confirm that the Organization can Continue with Evaluation

Location 4267: As measurements are identified, review any estimates for the costs of evaluation and update them as needed. When necessary, reconfirm that the organization or department who is sponsoring the evaluation and covering costs is still able or willing to do so.

6.6. When and how to Validate Solution Results

For a predictive project life cycle, validate the solution at the end of the project life cycle either immediately before release or at an agreed-upon time after release.For an iterative or adaptive project life cycle, validation is performed at the end of every iteration, sprint, or release, when the team provides production-ready functionality for the stakeholders to evaluate.

Location 4274: The following evaluation techniques can be used to evaluate solution results:
~ Surveys and focus groups,
~ Results from exploratory testing and user acceptance testing,
~ Results from day-in-the-life (DITL) testing,
~ Results from integration testing,
~ Expected vs. actual results for functionality,
~ Expected vs. actual results for nonfunctional requirements, and
~ Outcome measurements and financial calculation of benefits.

6.6.1. Surveys and Focus Groups

Location 4282: As previously mentioned in Section 4 on Requirements Elicitation and Analysis, surveys can be used to gather information and elicit requirements from a very large and/or geographically dispersed population. Survey questions can solicit qualitative or semiquantitative feedback about satisfaction with the solution, how it is performing, or what aspects of the solution present challenges to its users. All of the advantages and concerns mentioned in the analysis section of this practice guide also apply to the use of surveys for evaluation.

Focus groups provide an opportunity for individuals to offer thoughts and ideas about a topic in a group setting and to discuss or qualify comments from other participants.

Location 4288: Like surveys, focus groups are useful either as an elicitation technique or as an evaluation technique to obtain feedback from stakeholders in general and, more specifically, from users of the solution.

6.6.2. Results from Exploratory Testing and user Acceptance Testing

Exploratory testing is an unscripted, free-form validation or evaluation activity conducted by someone with in-depth business or testing knowledge. Generally, exploratory testing should be conducted in addition to (not in place of) formal testing.
User acceptance testing is a formal testing activity which validates that the solution meets the defined acceptance criteria. It is conducted by someone with in-depth business knowledge.

Location 4294: For evaluation, the results obtained from exploratory testing and user acceptance testing are used to determine whether or not a product, service, or solution is working as intended with regard to functionality and ease of use, and when applicable, performance.

When done well, exploratory testing also attempts to uncover whether or not a product, service, or solution responds properly to unintended uses (does not permit them) or whether it can be used in ways that were not intended.

6.6.3. Results from Day-In-The-Life (DITL) Testing

Location 4507: DITL testing is a semiformal activity, conducted by someone with in-depth business knowledge.

Location 4507: For software solutions, DITL testing consists of a set of use case scenarios or several user stories or functional requirements to exercise in sequence against a specific segment of data, in order to compare the expected results with the actual results.

For evaluation, the results obtained from DITL testing help to determine whether or not a product, service, or solution provides the functionality for a typical day of usage by a role that interacts with the solution.

6.6.4. Results from Integration Testing

Location 4514: Integration testing is used to validate or evaluate whether a solution does what is expected in the larger context of other ongoing business and systems operations in the organization. From the perspective of software solutions, integration testing is more encompassing than systems testing. Systems testing is a form of verification that proves when a solution being developed can interoperate with other systems and organizations that request services from it or vice versa.

Integration testing places the solution in an environment that is either identical to or nearly identical to the production environment. For software solutions, organizations that have the resources to maintain an isolated separate production-like test environment are able to conduct integration testing prior to the release of the solution. Organizations with smaller test environments can conduct an integrated evaluation in their preproduction environment.

Location 4521: By examining the results of integration testing, it is possible to evaluate a solution in the larger context, because new and different kinds of anomalies may be uncovered when a solution is introduced into a production environment.

6.6.5. Expected vs. Actual Results for Functionality

Location 4523: This section provides a generic way to capture acceptance criteria and expected vs. actual results for functionality. During requirements elicitation, broad acceptance criteria are sometimes defined in terms of the actual usage of a solution.

Location 4525: Acceptance criteria defined as part of evaluation need to be broad, yet still have expected results that are compared to the actual results. A DITL test, such as a day-in-the-life of a claim submitter or claims adjuster, can be constructed from one or more functional acceptance criteria.

Location 4548: Functional acceptance criteria may be tabulated or by placing all of the fields in one row, thereby making each functional acceptance criterion a row entry below the field names. Many business analysts add an additional field for actual results to aid in the analysis of expected vs. actuals.

6.6.6. Expected vs. Actual Results for Nonfunctional Requirements

Location 4554: When the acceptance criteria for nonfunctional requirements are defined quantitatively within reasonable ranges, these criteria can also serve as the basis for service-level agreements.

6.6.7. Outcome Measurements and Financial Calculation of Benefits

Location 4585: Some expected benefits for a project are readily tied to factors that can be measured; others may need to be derived or inferred.

Example—Using the insurance example, one of the benefits was to decrease the time to process a claim. The average time to process a claim should be measurable and the solution should be evaluated as to how well it was achieved. Beyond the actual measurement, as part of evaluation, it may be important for claims operations to derive the financial benefit of decreasing the time to process a claim.

6.7. Evaluate Acceptance Criteria and Address Defects

Location 4619: As evaluations occur, regardless of the type of life cycle, one or more of the following activities in Sections 6.7.1 through 6.7.3 occurs.

6.7.1. Comparison of Expected vs. Actual Results

Location 4621: For functional or nonfunctional requirements or user stories or use cases with defined acceptance criteria, the expected results can be compared with the actual results.

Example—In the insurance example, the worst-case value and target values defined in the acceptance criteria for customer ease of use indicate values that can be compared with the actual ease of use. This comparison may also be accomplished for qualitative evaluations, such as surveys, where worst-case and target values provide a way to compare expected with actual values.

6.7.2. Examine Tolerance Ranges and Exact Numbers

Location 4629: Evaluations based on an exact-value prediction of expected results have often been conducted in project management by comparing estimated costs and efforts to actual values and providing an explanation or reason for the variances.

Location 4631: For acceptance criteria for nonfunctional requirements, expected values take the form of tolerance ranges, where the worst-case value corresponds to the minimum acceptable value, the best-case value corresponds to the wished-for value, and the most likely value corresponds to the target value. Thus, the expected value range is from worst-case to best-case, with the target lying somewhere in between the two. Using ranges as evaluation criteria for comparing expected values to actual results provides a way to recognize the inherent real uncertainties involved in developing a solution.

At the same time, the minimum acceptable value represents a commitment by the project team to remain mindful of business needs. If the actual solution delivers less than the minimum acceptable value, the solution is defective in that regard.

6.7.3. Log and Address Defects

Location 4637: When the actual results of an evaluation for a solution do not match the expected results, it is important to analyze the cause for the discrepancy. Sometimes evaluations uncover defects that were not previously found, and these should be logged and assigned for resolution.

Location 4639: Sometimes evaluations identify that a service-level agreement is not being met, and these situations should also be logged and assigned. Depending on the organization, defect logging and tracking can be performed on an informal or formal basis.

Location 4642: Evaluation may discover or confirm that the actual values do not meet the expected goals, and the reasons may or may not be something that the solution is expected to accommodate.

As with all defects, when a defect is found during evaluation, it should be addressed by additional requirements analysis, impact analysis, and change requests, as applicable.

6.8. Facilitate the Go/No-Go Decision

Location 4440: When evaluation takes place prior to the release of a full solution or a segment of a solution, stakeholders need an opportunity to decide whether or not the solution should be released in whole or in part or not released at all.

Location 4441: The stakeholders in the RACI matrix who were identified as having a role to approve or sign off on the solution are generally the individuals who make the go/no-go decision.

Whenever possible, the evaluation results should be presented in tabular or visual form (i.e., charts/graphs/pictorial) to help decision makers grasp the impact and render a decision.

Location 4445: Whenever possible, go/no-go decisions should be made during an in-person meeting to allow all stakeholders to hear the rationale for the decisions from their counterparts. Like any well-run meeting, the use of a time-boxed agenda that is shared with all of the stakeholders prior to the meeting is recommended for go/no-go decision meetings.

A “go” permits the release of the solution. A “no-go” either delays or disapproves the release of the solution.

Location 4450: The individual who analyzed the actual vs. expected results should attend the decision meeting. In some organizations, that individual also facilitates the meeting, although the role that facilitates this meeting depends on organizational preferences. In any event, the individual who conducts the meeting should be experienced as a facilitator.

Location 4452: Sometimes, an evaluation result reveals an overriding reason to delay the release.

Location 4457: Sometimes an evaluation reveals a “show stopper,” which forces a no-go decision. Such decisions can occur in projects that present extreme risks for life or property or large-scale finances.

6.9. Obtain Signoff of the Solution

Location 4669: The RACI developed previously in Section 3 on Business Analysis Planning designates who is accountable for signoff on the solution. The formality of signoff depends upon the type of project, the type of product, the project life cycle, and corporate and regulatory constraints.

Location 4671: For example, formal signoffs for projects are a common protocol when one or more of the following characteristics are present:

~ Projects with a line of business-wide or enterprise-wide impact;
~ Products where errors or failure to achieve tolerances could result in death or an unacceptable level of risk to life, property, or financial solvency;
~ Projects in organizations following strict predictive life cycles; and
~ Heavily regulated industries, such as banking and insurance or medical devices, clinical research, or pharmaceutical companies.

Location 4677: Organizations with any kind of formal signoff should reach agreement about the format of a signoff document, how it should be recorded, how it should be stored, and whether signoff needs to be obtained when all the signatories are physically together or whether it is acceptable to sign remotely.

Location 4681: Organizations with informal signoff practices need to obtain signoff in the manner that is acceptable to the organization.

Collaboration Point—The project manager and the business analyst, working with auditing and project stakeholders, should work together to determine the signoff practices required by the organization and for the project.

Location 4684: For a predictive project life cycle, signoff often occurs at the end of the project life cycle either immediately prerelease or post-release.

For an iterative or adaptive project life cycle, informal signoff generally occurs at the end of each sprint or iteration, with formal signoff occurring prior to release of the solution.

6.10. Evaluate the Long-Term Performance of the Solution

Location 4688: Evaluating long-term performance is part of assessing the business benefits realized by implementing the solution.

Location 4689: Long-term performance is a broad concept and applies to the execution or accomplishment of work in any form by people or systems or both. Almost anything in a solution that was identified for measurement prior to release can be evaluated at regular intervals over the long-term to identify positive or negative performance trends.

Location 4691: For businesses that make use of business intelligence techniques, once a solution is released, any and all information captured as part of that solution can be analyzed to identify accomplishments and trends. Modern marketing organizations rely on analytics/business intelligence capabilities to evaluate whether or not marketing campaigns achieved the desired changes in customer behavior in the long-term.

Example—In the insurance example, analytics can be used to evaluate whether a business rule that was created to automate some of the claim payments is contributing to increased or decreased overall costs for the company.

6.10.1. Determine Metrics

Location 4699: When evaluation is planned (see Section 6.4), the key metrics are identified well before evaluation takes place. Business intelligence/analytics applied to the information captured by the solution may reveal additional metrics.

Location 4701: Additionally, post-release, stakeholders may identify new metrics that tie to the current or new objectives.

Location 4703: Businesses with established KPIs often use the metrics associated with them as an input to long-term evaluation of performance. Organizations with more modest performance measurement capabilities may prioritize a subset of metrics to use for long-term evaluation.

Collaboration Point—Project managers and business analysts should work together with stakeholders to identify and prioritize which performance aspects should be monitored over the long-term and to confirm that the business is willing to cover the costs for the continued measurements and evaluation.

6.10.2. Obtain Metrics/Measure Performance

Location 4709: Realistic planning for evaluation (see Section 6.4) is essential for obtaining metrics to measure performance. It can be costly to obtain metrics when the capability to capture them is not already present in the organization and its infrastructure, prior to the release of the solution, or when it is not built into the solution as part of its development.

Location 4711: Usually, the same techniques selected to obtain, extract, and report on metrics during solution evaluation can be used to obtain metrics to measure long-term performance. Measuring long-term performance requires comparing individual and cumulative metrics collected during two or more comparable time periods (e.g., current year vs. prior year, or this quarter vs. last quarter vs. the quarter prior to last quarter).

6.10.3. Analyze Results

Location 4715: Analysis of long-term performance examines the measurements, identifies stable metrics (plateaus), and metrics that are trending upward or downward, and discovers anomalies in the measured values or trends. Once the behavior of the metrics is known, further research and root cause analysis can identify the problem that is adversely affecting performance.

Example—In the insurance example provided in Section 6.6.7, the expectation was that the claims adjusters’ productivity would increase over time, as evidenced by a decreased average time to adjudicate a claim. If instead, the productivity “flat lined” or trended downward over several quarters, it is important to find out why this is happening. Research and root cause analysis may reveal one or more reasons for not meeting the business objectives, such as:
~ There was a severe spike in the complexity of claims due to natural disasters.
~ The solution does not provide sufficient support to assist the adjusters.
~ The solution provides sufficient support, but it is awkward to use.
~ It takes too much time for a claims adjuster to confirm damages.
~ Work is expanding to fill the available time.

6.10.4. Assess Limitations of the Solution and Organization

Location 4728: With analyzed metrics and root causes in hand, many of the same analysis techniques used to understand the problem and organization can be used again to assess the limitations of the solution and the organization.

Example—Referring back to the insurance example,
~ A cost-benefit analysis could be formulated to determine whether it is worthwhile to try to improve productivity by adding more claims adjusters during periods of peak claims submittals.
~ Further research could be conducted to find out which types of claims take the longest to process and to examine what level of support the solution provides for adjudicating those claims.
~ Interviews and usability studies could be conducted to identify awkward aspects of the solution.
~ Process flows—perhaps annotated with timings—could be used to identify opportunities for improvement in the claims adjusters’ workflow.
~ If work expanded to fill the available time, interviews or focus groups could reveal a root cause.

6.10.5. Recommend Approach to Improve Solution Performance

Location 4739: As with other aspects of evaluation, the analysis techniques used to propose the initial solution can also be applied to recommend an approach for improving solution performance. The work to implement the recommended approach needs to be prioritized as part of whatever ongoing planning activities the organization uses.

Example—Continuing with the same insurance example,
~ The results of the cost-benefit analysis is input into a recommendation either to add more adjusters during peak claims or to find ways of helping the existing adjusters be more productive (training, additional rule-based processing, etc.).
~ The results of the research regarding which types of claims take the longest to process and how well the solution supports adjudicating those claims could lead to recommendations to provide additional training for adjusters or to support additional rule-based processing.
~ Awkward aspects of the solution could be redesigned, based on feedback from interviews and usability studies, and then retested.
~ Facilitated work sessions could be conducted with decision makers to devise a future-state process flow to improve claims adjuster productivity.
~ For work that expands to fill the time available, interviews or focus groups could help formulate a recommendation centered on training or management intervention, without any change to the solution.

6.11. Solution Replacement/Phase Out

Location 4752: In general, there are four strategies for solution replacement/phase-out. These strategies apply equally well to automated, manual, and mixed solutions:

~ Massive one-time cutover prior to installing the replacement and phasing out whatever existed prior to it.

~ Segmented cutover to the replacement prior to phaseout of whatever existed prior to it (e.g., segment by region, by role, opportunistically/on first usage). Segmented cutover implies temporary coexistence of the replacement with whatever is being phased out.

~ Time-boxed coexistence of the replacement and what is being phased out, with a final cutover on a specific future date. For this strategy, work conducted with the replacement follows all of the replacement's policies, procedures, and rules, while work conducted with whatever is being phased out continues to operate under its policies, procedures, and rules until the cutover date. This strategy is sometimes used for software projects involving architectural or database changes.

~ Permanent coexistence of the old and replacement solutions (with all new business using the replacement solution).

Location 4762: Generally, massive cutovers present more business risk than any kind of cutover that is segmented or time-boxed. Occasionally, however, that risk needs to be accepted.

Location 4763: A cost-benefit analysis can be conducted to determine which approach to use. Whether or not a formal cost-benefit analysis is conducted, some sample questions or research that could be undertaken to determine the most appropriate strategy include:

~ What is the operational impact of having two solutions? => Subjectively, having two solutions may seem like a bad idea from an operational standpoint. However, when there is a great deal of complexity associated with the previous solution, it may be more cost effective to have both solutions coexist with all new business going to the replacement (e.g., when it is difficult to align the previous solution with its replacement and the amount of business conducted using the previous solution is very small).

Example—In the insurance company example, the company created a new consolidated way to handle all life insurance products and decided to retain a small number of individuals to handle claims and questions for a previous product rather than converting that product to the new consolidated solution because:
(a) there is only a small amount of life insurance business for the product and it is no longer offered to new customers,
(b) the subject matter experts for the previous product are all retired,
(c) there is limited documentation to support how to convert the business for this product to the new solution, and
(d) it is not possible or practical to exchange policies under that product for policies under another product.

~ Are there any customer-facing or marketing conditions that would require all customers to interact with the new solution at the same time? => Logo changes are an example of a change that would require all business to use the new logo on the same date.

~ Does the replacement solution involve software? => For solutions involving software, cutover usually includes conversion of data from the previous solution. Segmented or time-boxed cutovers are good choices when data conversion is involved.

~ Is it acceptable for some of the customer base to use the previous solution while others use the replacement solution? => Many businesses choose to offer replacement and previous solutions together as part of a segmented or time-boxed replacement strategy. This is especially true where software operating systems and interfaces to software are involved. For example, cellphone users who have the same brand of cellphone may use different versions of its operating system; the new version may be rolled out in segments, where some customers in a specific area may obtain the new version earlier than others; also older phones may not function with the new operating system. The applications offered on these cell phones may have slightly different user interfaces depending on the underlying operating system.

No matter what strategy is selected, care should be taken to develop all of the communication and rollout collateral needed to successfully cutover and adapt to a new solution.

Location 4786: These activities include but are not limited to:
~ Sufficient communication to the stakeholders who will be directly or indirectly impacted by the new solution;
~ Completion of required training materials and delivery of training;
~ Completion or update to standard operating procedures (SOPs) and work instructions;
~ Purchase, licensing, and installation of any necessary hardware and third-party software needed to support the solution;
~ Coordination with other activities within the organization to ensure that implementation occurs at a time when the business can accept the changes, and the rollout is not in conflict with other in-process programs and project work; and
~ Coordination to ensure any interruption of business is clearly identified, communicated, and acceptable by customers.

Collaboration Point—When devising communication and rollout activities and collateral, the project managers, training, communication, organizational development, and change management areas should leverage the business analysts’ knowledge of the existing solution and the replacement solution as input into their work.

GLOSSARY

Acceptance Criteria. A set of conditions that is required to be met before deliverables are accepted. [Note: In business analysis, acceptance criteria is built to evaluate the product requirements and solution.]

Active Listening. The act of listening completely with all senses so as to pick up all of the information that is being communicated. Active listening entails paraphrasing or reciting back what is heard to ensure accurate understanding of what has been stated.

Activity. A distinct, scheduled portion of work performed during the course of a project.

Adaptive Life Cycle. A project life cycle, also known as change-driven or agile methods, that is intended to facilitate change and requires a high degree of ongoing stakeholder involvement.

Affinity Diagram. A group creativity technique that allows large numbers of ideas to be classified into groups for review and analysis.

Approved Change Request. A change request that has been processed through the integrated change control process and approved.

Architecture. A method to describe an organization by mapping its essential characteristics, such as people, locations, processes, applications, data, and technology.

As-Is Process. A depiction of the current state of a process, representing how a process is currently performed in the organization.

Assumption. A factor that is considered to be true, real, or certain, without proof or demonstration.

Asynchronous Interview. An interview in which the participants are not engaged in the interview at the same time. Asynchronous interviews can be conducted through email or can be prerecorded by the interviewer and provided to the interviewee at a later time.

Backlog. A listing of product requirements and deliverables to be completed, written as stories, and prioritized by the business to manage and organize the project's work.

Baseline. The approved version of a work product that can be changed only through formal change control procedures and is used as a basis for comparison.

Benchmarking. The comparison of actual or planned practices, such as processes and operations, to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance.

Brainstorming. A general data gathering and creativity technique that is used to identify risks, ideas, or solutions to issues by using a group of team members or subject matter experts.

Burndown. A visual chart depicting the number of backlog items remaining at any point in time in a project. Burndown charts are used on projects using an adaptive life cycle.

Business Analysis. The set of activities performed to identify business needs; recommend relevant solutions; and elicit, document, and manage requirements.

Business Analysis Approach. A description of how the business analysis process will be conducted for the project or program. The business analysis approach is documented in the business analysis plan.

Business Analysis Center of Excellence. An organizational structure created whereby business analysts are managed centrally or are provided mentorship centrally for the purpose of improving the business analysis discipline across the organization. Also called Center of Business Analysis Practice.

Business Analysis Documentation. The set of business analysis information produced as an output of the business analysis work conducted on a program or project. Such output may be comprised of business analysis deliverables, business analysis work products, or a combination thereof.

Business Analysis Plan. A subplan of the project management plan that defines the business analysis approach, including the tasks that will be performed, the deliverables that will be produced, the roles required to carry out the process, and process decisions regarding how requirement-related decisions will be made; how requirement priorities will be set; how changes to requirements will be proposed, approved, and managed; how requirements will be validated, verified, monitored, and traced; and how business analysis communication will be performed.

Business Analysis Planning. The domain of business analysis that involves planning all of the business analysis activities and reaching the necessary process decisions required for running an effective business analysis process for a program or project.

Business Architecture. A collection of the business functions, organizational structures, locations, and processes of an organization, including documents and depictions of those elements.

Business Case. A documented economic feasibility study used to establish the validity of the benefits of a selected component lacking sufficient definition and used as a basis for the authorization of further project management activities.

Business Need. The impetus for a change in an organization, based on an existing problem or opportunity. The business need provides the rationale for initiating a project or program.

Business Objectives Model. A business analysis model that relates the business problems, business objectives, and top-level features. This model encompasses the justification for a project.

Business Requirements. Requirements that describe the higher-level needs of the organization, such as the business issues or opportunities, and which provide the rationale for why a project is being undertaken.

Business Rule. Constraints about how the organization wants to operate. These constraints are usually enforced by data and/or processes and are under the jurisdiction of the business.

Business Rules Analysis. A process for evaluating, designing, and implementing the rules that govern the organization, its processes, and its data.

Business Rules Catalog. A business analysis model that details all of the business rules and their related attributes.

Business Value. A concept that is unique to each organization and includes tangible and intangible elements. In business analysis, business value is considered the return, in the form of time, money, goods, or intangibles in return for something exchanged.

Capability. The ability to add value or achieve objectives in an organization through a function, process, service, or other proficiency.

Capability Framework. A collection of an organization's capabilities, organized into manageable pieces, similar to a business architecture.

Capability Table. A table that displays the capabilities needed to solve a problem or seize an opportunity. This tool can show the relationship between a situation, its root causes, and the capabilities needed to address the situation.

Cause-and-Effect Diagram. A decomposition technique that helps trace an undesirable effect back to its root cause. See also fishbone diagram.

Change Control. A process whereby modifications to documents, deliverables, or baselines associated with the project are identified, documented, approved, or rejected.

Change Control Board (CCB). A formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project, and for recording and communicating such decisions.

Change Control Tools. Manual or automated tools used to assist with change and/or configuration management. At a minimum, the tools should support the activities of the change control board (CCB).

Change Management Plan. The plan that defines the process for managing change on the project. Change Request. A formal proposal to modify any document, deliverable, or baseline.

Closed-Ended Question. A question that calls for a response from a limited list of answer choices. Types of closed-ended questions are forced choice, limited choice, and confirmation.

Communications Management Plan. A component of the project, program, or portfolio management plan that describes how, when, and by whom information about the project will be administered and disseminated.

Configuration Management. A collection of formal documented processes, templates, and documentation used to apply governance to changes to the product, service, result, or subcomponent being developed.

Configuration Management System. A subsystem of the overall project management system. It is a collection of formal documented procedures used to apply technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a product, result, service, or component; control any changes to such characteristics; record and report each change and its implementation status; and support the audit of the products, results, or components to verify conformance to requirements. It includes the documentation, tracking systems, and defined approval levels necessary for authorizing and controlling changes.

Constraint. A limiting factor that affects the execution of a project, program, portfolio, or process.

Context Diagram. A visual depiction of the product scope showing a business system (process, equipment, computer system, etc.) and how people and other systems (actors) interact with it.

Contextual Question. A question that can only be answered as it references the subject at hand; namely, the problem domain or the proposed solutions.

Context-Free Question. A question that can be asked in any situation.

Cost-Benefit Analysis. A financial analysis tool used to determine the benefits provided by a project against its costs.

Cost-Effectiveness Feasibility. The high-level economic feasibility of a potential project or program, taking into account both financial benefits and costs.

Data Dictionary. A business analysis model that catalogs the attributes of specific data objects.

Data Flow Diagram. A business analysis model that combines processes, systems, and data to show how data flows through a solution.

Day in the Life Testing (DITL). A semiformal activity, conducted by someone with in-depth business knowledge. The results obtained from DITL testing enable validation or evaluation of whether or not a product or service or solution provides the functionality for a typical day of usage by a role that interacts with the solution.

Decision Table. An analysis model that uses a tabular format to display complex business rules by representing decision points in the upper rows and outcomes in the bottom rows with the purpose of providing all combinations of choices.

Decision Tree. An analysis model that shows business rules associated with complex branching logic. Rules are depicted by modeling the decisions and their outcomes in a tree structure.

Decomposition Model. A model that is used to divide and subdivide a high-level concept into lower-level concepts, for example, dividing the project scope and project deliverables into smaller, more manageable parts for the purpose of analysis. Also known as decomposition diagrams.

Defect Repair. An intentional activity to modify a nonconforming product or product component.

Deliverable. Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project.

Dependency Analysis. A technique that is used to discover dependent relationships.

Display-Action-Response Model. A business analysis model that dissects a screen mockup into its display and behavior requirements at the page element level.

Document Analysis. An elicitation technique that analyzes existing documentation and identifies information relevant to the requirements.

Ecosystem Map. A business analysis model that shows the systems involved in a project and how they interrelate with each other.

Elicitation. See requirements elicitation.

Elicitation Plan. An informal device used by a business analyst to prepare for the elicitation work.

Elicitation Session. A session or activity conducted for the purpose of obtaining information from participants. In business analysis, elicitation sessions are conducted in order to obtain the information needed to define the requirements.

Enterprise Architecture. A collection of the business and technology components needed to operate an enterprise. The business architecture is usually a subset of the enterprise architecture and is extended with the applications, information, and supporting technology to form a complete blueprint of an organization.

Entity Relationship Diagram. A business analysis model that shows the business data objects involved in a project and the relationships between those objects, including the cardinality of those relationships.

Estimate. A quantitative assessment of the likely amount or outcome. It is usually applied to project costs, resources, effort, and durations and is usually preceded by a modifier (i.e., preliminary, conceptual, feasibility, order-of-magnitude, definitive). It should always include some indication of accuracy (e.g., ± x %).

Expert Judgment. Judgment provided based upon expertise in an application area, Knowledge Area, discipline, industry, etc., as appropriate for the activity being performed. Such expertise may be provided by any group or person with specialized education, knowledge, skill, experience, or training.

Exploratory Testing. An unscripted, free-form validation or evaluation activity conducted by someone with in-depth business or testing knowledge to validate the product and discover product errors.

Facilitated Workshops. An elicitation technique using focused sessions that bring key cross-functional stakeholders together to define product requirements. In business analysis, facilitated workshops use a structured meeting that is led by a skilled, neutral facilitator, in which a carefully selected group of stakeholders collaborate to explore and evaluate product requirements.

Feasibility Analysis. A study that produces a potential recommendation to address business needs. It examines feasibility using one or more of the following variables: operational, technology/system, cost-effectiveness, and timeliness of the potential solution.

Feature. A set of related requirements typically described as a short phrase.

Feature Model. A business analysis model that shows the first, second, and third level of features involved in a project.

Fishbone Diagram. A version of a cause-and-effect diagram that depicts a problem and its root causes in a visual manner. It uses a fish image, listing the problem at the head, with causes and subcauses of the problem represented as bones of the fish. See also cause-and-effect diagram.

Five Whys. A technique for conducting root cause analysis suggesting anyone trying to understand a problem needs to ask why it is occurring up to five times to thoroughly understand its causes.

Focus Groups. An elicitation technique that brings together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result.

Functional Requirements. Requirements that describe the behaviors of a product.

Gap Analysis. A technique for understanding the gap between current capabilities and needed capabilities. Filling the gap is what comprises a solution recommendation.

Grooming the Backlog. A process used on agile projects where the product team works with the product owner to gain more depth about the user stories in the backlog list. A groomed backlog is an input for sprint planning meetings, which are used to determine which user stories to cover in the next iteration.

Happy Path. See normal flow.

High-Fidelity Prototyping. A method of prototyping that creates a functioning representation of the final finished product to the user. High-fidelity prototyping is performed using a programming language or a pseudo language of the product to be demonstrated.

Impact Analysis. A technique for evaluating a change in relation to how it will affect other requirements, the product, the program, and the project.

Iterative Life Cycle. A project life cycle where iterations develop the product through a series of repeated cycles, while increments successively add to the functionality of the product.

Interrelationship Diagram. A special type of cause-and-effect diagram that depicts related causes and effects for a given situation. Interrelationship diagrams help to uncover the most significant causes and effects involved in a situation. See also cause-and-effect diagram.

Internal Rate of Return (IRR). The projected annual yield of a project investment, incorporating both initial and ongoing costs into an estimated percentage growth rate a given project is expected to have.

Interviews. A formal or informal approach to elicit information from a group of stakeholders by asking questions and documenting the responses provided by the interviewees.

Ishikawa Diagrams. See fishbone diagram and cause-and-effect diagram. Issue. A point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.

Iterative Life Cycle. A project life cycle where the project scope is generally determined early in the project life cycle, but time and cost estimates are routinely modified as the project team's understanding of the product increases. Iterations develop the product through a series of repeated cycles, while increments successively add to the functionality of the product.

Job Analysis. A technique used to identify job requirements and the competencies needed to perform effectively in a specific job.

Kanban. An adaptive life cycle in which project work items are pulled from a backlog and started when other project work items are completed. Kanban also establishes work-in-progress limits to constrain the number of work items that can be in-progress at any point in time.

Kanban Board. A tool used within the continuous improvement method of Kanban to visually depict workflow and capacity and assist team members in seeing the work that is planned, in process or completed. The Kanban board is a variation of the original Kanban cards.

Key Performance Indicator (KPI). Metrics usually defined by an organization's executives that are used to evaluate an organization's progress toward meeting its objectives or goals.

Key Stakeholders. A stakeholder who is identified as having a significant stake in the project or program and who holds key responsibilities such as approving requirements or approving changes to product scope.

Lessons Learned. The knowledge gained during a project, which shows how project events were addressed or should be addressed in the future for the purpose of improving future performance.

Low-Fidelity Prototype. A method of prototyping that provides fixed sketches, diagrams, and notes to provide a visual representation of what a screen will look like. Static prototypes do not demonstrate the operation of the system to the user.

Measure. The quantity of some element at a point in time or during a specific time duration, such as the number of work months spent on a project during a specific time period, the number of defects uncovered, or the number of customers responding to a survey stating that they were extremely satisfied.

Metric. A set of quantifiable measures used to evaluate a solution or business.

Model. A visual representation of information, both abstract and specific, which operates under a set of guidelines in order to efficiently arrange and convey a lot of information in an efficient manner.

Modeling Language. A set of models and their syntax. Examples include Requirements Modeling Language (RML), Unified Modeling Language (UML), Business Process Modeling Notation (BPMN), and System Modeling Language (SysML).

Monitoring. The process of collecting project performance data, producing performance measures, and reporting and disseminating performance information.

MoSCoW. A technique used for establishing requirement priorities. In this technique, the participants divide the requirements into four categories of must haves, should haves, could haves, and won't haves.

Multivoting Process. A technique used to facilitate decision making among a group of stakeholders. Participants are provided with a limited number of votes and are asked to apply those votes to a list of possible options. The option with the most votes is determined to be the most favorable option. Multivoting processes can be used to prioritize requirements, determine the most favorable solution, or to identify the most favorable response to a problem.

Narrative. A story. In business analysis, narratives are written when developing personas.

Needs Assessment. The domain of business analysis concerned with understanding business goals and objectives, issues, and opportunities, and recommending proposals to address them.

Negotiation. The process and activities used to resolve disputes through consultations between involved parties.

Net Present Value (NPV). The future value of expected project benefits expressed in the value those benefits have at the time of investment. NPV takes into account current and future costs and benefits, inflation, and the yield that could be obtained through investing in financial instruments as opposed to a project or program.

Nonfunctional Requirements. Requirements that express properties that the product is required to have, including interface, environment, and quality attribute properties.

Normal Flow. Within the context of use case analysis, the normal flow is the set of steps that are followed through the use case scenario when everything goes as planned or expected.

Objective. Something toward which work is to be directed, a strategic position to be attained, a purpose to be achieved, a result to be obtained, a product to be produced, or a service to be performed. In business analysis, objectives are quantifiable outcomes that are desired from a product, result, or service.

Observation. An elicitation technique that provides a direct way of obtaining information about how a process is performed or a product is used by viewing individuals in their own environment performing their jobs or tasks and carrying out processes.

Open-Ended Question. A question that allows the responder to answer in any way desired.

Operational Feasibility. The extent to which a proposed solution meets operational needs and requirements related to a specific situation. It also includes factors such as sustainability, maintainability, supportability, and reliability.

Opportunity. A risk that would have a positive effect on one or more project objectives.

Opportunity Analysis. A study of the major facets of a potential opportunity to determine the viability of successfully launching a new product or service.

Opportunity Cost. The loss of value that could be realized in other actions or alternatives, if the current action is pursued.

Organizational Modeling. A type of modeling that visually depicts the organizational structure and elements of an organization.

Organizational Chart. A model that depicts the reporting structure within an organization or within a part of an organization. In business analysis, organizational charts can be used to help identify stakeholders who are involved in a project and to understand the reporting structures that exist among those identified.

Organizational Goals. Broad-based translations of corporate goals into expressions that are actionable and measurable. Goals are typically longer in scope than objectives.

Organizational Objectives. Accomplishments that an organization wants to achieve to help enable goals. These are specific and tend to be of shorter duration than goals, often one year or less.

Pair-Matching. A step performed when constructing a weighted ranking matrix. It involves taking each option under analysis and comparing it one by one to all the other options listed.

Participant. One who participates in a group activity, such as focus groups or facilitated workshops.

Payback Period (PBP). The time needed to recover a project investment, usually in months or years.

Persona. An archetype user representing a set of similar end users described with their goals, motivations, and representative personal characteristics.

Policy. A structured pattern of actions adopted by an organization such that the organization's policy can be explained as a set of basic principles that govern the organization's conduct.

Predictive Life Cycle. A form of project life cycle in which the project scope, and the time and cost required to deliver that scope, are determined as early in the life cycle as possible.

Problem. An internal or external environment of an organization that is causing detriment to the organization, for example, lost revenue, dissatisfied customers, delays in launching new products, or noncompliance with government regulations.

Problem Domain. The area or context surrounding the problem that is currently under analysis.

Procedure. An established method of accomplishing a consistent performance or result. A procedure typically can be described as the sequence of steps that will be used to execute a process.

Process. A systematic series of activities directed towards causing an end result such that one or more inputs will be acted upon to create one or more outputs.

Process Flow. A business analysis model that visually shows the steps taken in a process by a human user as it interacts with an implementation. A set of steps taken by a system can be shown in a similar model, a system flow.

Process Worker. The stakeholder who physically works with or within the business process that is under analysis or the user who works specifically with a system that is part of the business process. Not all process workers are users.

Product. An artifact that is produced, is quantifiable, and can be either an end item in itself or a component item. Products are also referred to as materials or goods.

Product Scope. The features and functions that characterize a product, service, or result.

Product Stakeholder. A business stakeholder affected by a problem or opportunity, or impacted by or interested in the solution.

Program. A group of related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them individually.

Project. A temporary endeavor undertaken to create a unique product, service, or result.

Project Charter. A document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.

Project Life Cycle. The series of phases that a project passes through from its initiation to its closure.

Project Management Plan. The document that describes how the project will be executed, monitored, and controlled.

Project Manager. The person assigned by the performing organization to lead the team that is responsible for achieving the project objectives.

Project Phase. A collection of logically related project activities that culminates in the completion of one or more deliverables.

Project Schedule. An output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources.

Project Scope. The work performed to deliver a product, service, or result with the specified features and functions.

Project Stakeholder Management. Includes the processes required to identify all people or organizations impacted by a project, analyzing stakeholder expectations and impact on the project, and developing appropriate management strategies for effectively engaging stakeholders in project decisions and execution.

Project Team. A set of individuals who support the project manager in performing the work of the project to achieve its objectives.

Prototypes. A method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it.

Questionnaire and Survey. A written set of questions designed to quickly accumulate information from a large number of respondents.

RACI Model. A common type of responsibility assignment matrix that uses responsible, accountable, consult, and inform statuses to define the involvement of stakeholders in project activities.

Regulation. A requirement imposed by a governmental body. These requirements can establish product, process, or service characteristics, including applicable administrative provisions that have government-mandated compliance.

Report Table. A business analysis model that documents in a tabular format all of the requirements necessary to develop a single report.

Requirement. A condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.

Requirements Attribute. A property of a requirement used to store descriptive information about the requirement, such as last change date, author, source, etc.

Requirements Change Process. The process that defines how changes to requirements will be handled across the project.

Requirements Documentation. A description of how individual requirements meet the business need for the project.

Requirements Analysis. The process of examining, breaking down, and synthesizing information to further understand it, complete it, and improve it.

Requirements Elicitation. The activity of drawing out information from stakeholders and other sources for the purpose of further understanding the needs of the business, to address a problem or opportunity and the stakeholder's preferences and conditions for the solution that will address those needs.

Requirements Elicitation and Analysis. The domain of business analysis concerned with the iterative work to plan, prepare, and conduct the elicitation of information from stakeholders and to analyze, model, and document the results of that work with the objective of defining a set of requirements in sufficient detail to enable the purchase or build of the preferred solution or refinement of processes to achieve the business objective.

Requirements Life Cycle. The flow or life of a requirement throughout a project or program. The requirements life cycle is managed by assigning an attribute or qualifier onto the requirement to depict the requirement state at a specified point in time.

Requirements Management Plan. A component of the project or program management plan that describes how requirements will be analyzed, documented, and managed. See also business analysis plan.

Requirement State. An attribute of a requirement that identifies where the requirement falls within the requirements life cycle, for example, in-process, approved, deferred, or rejected.

Requirements Traceability Matrix. A grid that links product requirements from their origin to the deliverables that satisfy them. Also called Traceability Matrix.

Requirements Validation. The process of ensuring that the product satisfies its intended use and anticipated value, ensuring the correct product is delivered.

Requirements Verification. The process of reviewing requirements and models to ensure they meet quality standards. Verification is performed to ensure that requirements are constructed properly and that models conform to the proper use of modeling notation.

Responder. Any participant or person from whom information is gathered by means of elicitation.

Retrospective. A type of meeting in which participants explore their work and outcomes in order to improve both process and product. Retrospectives can occur on a regular basis (e.g., end of iteration or release), at the completion of a milestone, or after a special event (e.g., organizational change, accident).

Return on Investment (ROI). The percent return on an initial project or program investment, calculated by taking the projected average of all net benefits and dividing them by the initial cost.

Risk. An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.

Risk Analysis. The process of examining a program, project, or process for risk.

Risk Tolerance. The degree, amount, or volume of risk that an organization or individual will withstand.

Role. A defined function to be performed by a project team member, such as testing, filing, inspecting, or coding.

Rolling Wave Planning. An iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level.

Root Cause Analysis. An analytical technique used to determine the basic underlying reason that causes a variance or a defect or a risk. A root cause may underlie more than one variance or defect or risk.

Scenario. A case of usage of a solution often manifested as a concrete example of a use case or user story or several functional requirements specified in the sequence in which they occur.

Scope. The sum of the products, services, and results to be provided as a project. In business analysis, scope is defined as the boundary for the products, services, or results. See also project scope and product scope.

Scope Baseline. The approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed only through formal change control procedures and is used as a basis for comparison.

Scope Creep. The uncontrolled expansion to a product or project scope without adjustments to time, cost, and resources.

Scope Model. A type of model that identifies the boundaries of the project, program, product, and/or system under analysis. A context diagram is one example of a scope model.

Scrum. A type of adaptive life cycle where a product is built in small incremental portions and each cycle of development builds upon the last version of the product.

Situation. A condition which may be an internal problem or external opportunity that forms the basis of a business need and might result in a project or program to address the condition.

Situation Statement. An objective statement of a problem or opportunity that includes the statement itself, the situation's effect on the organization, and the ultimate impact.

SMART Goals. Goals that are well-written to meet the quality criteria of being specific, measurable, achievable, relevant, and time-bounded.

Software Requirements Specification. A type of requirements documentation that includes the functional and nonfunctional requirements of a software system.

Solution Evaluation. The domain of business analysis concerned with the activities to validate a solution that is about to be or that has already been implemented.

Solution Requirement. A requirement that describes the features, functions, and characteristics of a product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements.

Sponsor. A person or group who provides resources and support for the project, program, or portfolio and is accountable for enabling success.

Stakeholder. An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.

Stakeholder Analysis. A technique of systematically gathering and analyzing quantitative and qualitative information to determine whose interests should be taken into account throughout the project.

Stakeholder Characteristics. The qualities and attributes of a stakeholder, which together determine aspects of how the stakeholder behaves.

Stakeholder Identification. The process of determining the stakeholders impacted by a business problem or opportunity.

Stakeholder Groups. A collection of stakeholders who have similar likes, interests, and stakeholder characteristics. Stakeholder groups are used by project managers and business analysts to manage large groups of stakeholders.

Stakeholder Map. A technique used to visually analyze stakeholders and their relationship to each other and to the problem or opportunity under analysis.

Stakeholder Register. A project document including the identification, assessment, and classification of project stakeholders.

Stakeholder Requirement. A requirement that describes the need of a stakeholder or stakeholder group.

State Diagram. A business analysis model that visually shows how an object moves between different states. This model helps to show the life cycle of an object in a solution.

State Table. A business analysis model that shows all of the possible states of an object and all of the valid transitions. This model helps to enumerate all possible states and possible transitions.

Subject Matter Expert (SME). A person who is considered an expert in a particular subject area. In business analysis, SMEs are often involved in providing the requirements for their area of expertise.  

SWOT Analysis. Analysis of strengths, weaknesses, opportunities, and threats of an organization, project, or option.

Synchronous Interview. An interview conducted where the interviewer and interviewee are involved in the interview at the same time. Synchronous meetings can occur face to face, over the phone, or through web conferencing, etc.; the two parties are not required to be in person with one another, but both need to be active in the interview at the same time.

System Interface Table. A business analysis model that documents the requirements for the connections between each interfacing system involved in a project, including how they are connected and what information flows between them.

Technique. A defined systematic procedure employed by a human resource to perform an activity that produces a product or result or delivers a service, and that may employ one or more tools.

Technology Feasibility. An analysis to determine the extent to which a technology exists in an organization to support a potential solution and if not present, how feasible it would be to acquire and operate the needed technology. Also referred to as System Feasibility.

Templates. A partially completed document in a predefined format that provides a defined structure for collecting, organizing, and presenting information and data.

Threat. A risk that would have a negative effect on one or more project objectives.

Time Feasibility. An analysis to determine how well a proposed solution can be delivered to meet the organization's needed time frame.

To-Be Process. A proposed revision to an existing process that can provide an improvement for an organization over how activities are currently performed, or a revision to a new process when adding products or services.

Traceability. Traceability provides the ability to track product requirements from their origin to the deliverables that satisfy them.

Traceability and Monitoring. The domain of business analysis concerned with building and maintaining the traceability matrix to manage requirements and product scope, baselining the product requirements, assessing impacts of proposed requirement changes, and managing the required updates to the requirements and other business analysis deliverables once proposed changes are approved.

Transition Requirements. Requirements that are the temporary capabilities, such as data conversion and training requirements, needed to transition from the current as-is state to the future state.

Use Case. An analysis model that describes a flow of actor-system interactions and boundaries for those interactions, including trigger, initiating and participating actors, and preconditions and post conditions.

Use Case Diagram. A business analysis model that shows all of the in-scope use cases for a project and which actors have a part in those use cases.

User Class. A group of stakeholders who are users of a software system, product, or service and are grouped together due to the similarity in their requirements and use of the product.

User Experience Analyst. Also referred to as user interface analysts; individuals who are responsible for studying user behavior, preferences, and constraints in order to identify user interface and usability requirements for software applications and other products.

User Interface Flow. A business analysis model that shows the specific pages or screens of an application and how a user can navigate between them.

User Story. A one or two sentence description, written from the viewpoint of the actor, describing what function is needed. A user story usually takes the form of “as an , I want to , so that I can .”

Validation. The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification.

Verification. The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation.

Velocity. A measure of a team's productivity rate at which the deliverables are produced, validated, and accepted within a predefined interval. Velocity is a capacity planning approach frequently used to forecast future project work.

Version Control. The process of maintaining a history of changes on software or documentation.

Version Control System (VCS). A system that is used to track the history of revisions, often but not always related to software.

Weighted Criteria. A technique used to help support objective decision making. It uses a weighted ranking matrix to compare alternatives and their weighted scores in order to evaluate decision options. See also weighted ranking matrix.

Weighted Ranking Matrix. A table used in decision making that combines pair matching of all alternatives with weighted criteria to add objectivity when formulating a decision or recommendation. Each alternative is compared with every other alternative on the basis of weighted criteria, and the resulting scores are added together to determine the preferred choice.

Work Breakdown Structure (WBS). A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

Work Product. An output produced as a result of some completion of work that is required for a short-term purpose and not required to be monitored and maintained on an ongoing basis.