KBPA - DUN

Tasks: Requirements Life Cycle Management

"*Managing *requirements *traceability* *Maintaining *requirements for accuracy and *reuse* *Addressing *requirements *prioritization* *Determining* how requirements *should change* *Facilitating* requirements *approval*"

Tech: Focus Groups: Activities

2.1 Purpose 2.2 Location 2.3 Logistics 2.4 Participants 2.5 Budget 2.6 Timelines 2.7 Outcomes

9.4 Communication Skills

9.4.1 ****Verbal** Communication** 9.4.2 Non-Verbal Communication 9.4.3 Written Communication 9.4.4 **Listening**

Tasks: Business Analysis Planning and Monitoring

Defining the business analysis approach Planning for stakeholder engagement Setting up business analysis governance Outlining the business analysis information management process Identifying business analysis performance improvements ------ "*Planning* the business analysis *approach* for the project *Determining* how to *engage* stakeholders, including stakeholder identification, analysis, and categorization *Defining* the business analysis *governance* activities for decision making *Addressing* business analysis *information* management *needs* *Planning* the *requirements development* and management process *Managing* and *reporting *on the business analysis *effort*"

What are the three basic modeling elements of BPMN?

Event, Activity, and Gateway

Tech: Prototyping

Prototyping is used to *elicit and validate* stakeholder needs through an iterative process that creates a model or design of requirements. It is also used to optimize user experience, to evaluate design options, and as a basis for development of the final business solution.

Not identified in GA

Responsible to Implement What is Identified: - Who will approve change - How to change requests - Who can change requests

Tech: Financial Analysis: Return on Investment

Return on Investment = (Total Benefits - Cost of the Investment) / Cost of the Investment.

Tech: Stakeholder List, Map, or Personas

Stakeholder lists, maps, and personas assist the business analyst in analyzing stakeholders and their characteristics. *Common types of stakeholder characteristics* that are worth identifying and analyzing include: 1• level of authority within the domain of change and within the organization, 2• attitudes toward or interest in the change being undertaken, 3• attitudes toward the business analysis work and role, and 4• level of decision-making authority.

Tech: State Modelling: Elements

State modelling is used to describe and analyze the different possible states of an entity within a system, how that entity changes from one state to another, and what can happen to the entity when it is in each state. 1. State 2. State Transition 3. State Diagram 4. State Tables

Tech: Process Modelling: Elements

Types of Process Models and Notations 1. *Flowcharts * Non-Tech, swimlanes 2. *VSM* (Value Stream Mapping) 3. *UML* (Unified Modelling Language) Activity diagrams, elaborate on a single use case, business process modelling, swimlanes (responsibility), synchronization bars (parallell processing), multiple exit decision points 4. *BPMN* (Business Process model and Notation) Industry standard language, distinguish activities of different participants (pools/swimlanes -> responsibility passes) 5. *IDEF* (Integrated DEFinition) 6. *IGOE* (Input, Guide, Output, Enabler Diagrams) 7. *SIPOC* (Supplier, Input, Process, Output, Customer) 8. *VSA* (Value Stream Analysis) 9. *Data Flow Diagrams*

Methods used in Lean

VSM (Value Stream Mapping)

Logical data model:

is an abstraction of the conceptual data model that incorporates rules of normalization to formally manage the integrity of the data and relationships. It is associated with the design of a solution.

Tech: Review: Elements: Objecties

• to remove defects, • to ensure conformance to specifications or standards, • to ensure the work product is complete and correct, • to establish consensus on an approach or solution, • to answer a question, resolve an issue, or explore alternatives, • to educate reviewers about the work product, and • to measure work product quality.

Tech: Business Model Canvas: Elements

• Key Partnerships, • Key Activities (Value-Add/NonValue-Add/Business Non-value-add), • Key Resources (Physical/Fin/Intellectual/Human), • Value Proposition, • Customer Relationships, • Channels, • Customer Segments, --------- • Cost Structure, and • Revenue Streams (Licensing/Subscription/Trasaction/Fees/Sales/Lending/Renting/Leasing).

Tech: Decision Analysis: Tools

• pro versus con considerations, • force field analysis, • decision tables, • decision trees, • comparison analysis, • analytical hierarchy process (AHP), • totally-partially-not (TPN), • multi-criteria decision analysis (MCDA), and • computer-based simulations and algorithms.

RLCM: APPROVE REQ: Gain consensus.

"*Approval requires* a business analyst to *review requirements changes with accountable stakeholders and request that they agree* to and approve that change. Often, this process requires facilitation of the approval process, addressing questions and providing additional information as needed. *Approving a change confirms that stakeholders believe the change creates sufficient value* for the organization."

BAMP: PBAIM: Inputs

"*Business Analysis Approach* The information management *approach should align* with the business analysis approach for your initiative, as well as aligning with the other approaches defined in this knowledge area. *Governance Approach* The governance approach *identifies how to deal with changes, decisions, approvals, and priorities* for requirements and designs. *Stakeholder Engagement Approach* The defined stakeholder *collaboration and communication needs guide specific business analysis information needs*. Basically, you *must define what you need to know* and *who you need to get information* from. Then, go out and get that information."

BAPM: PBA: Output

"*Business Analysis Approach*: The business analysis approach *specifies how the business analysis team plans to perform* the business analysis *work on their project*. Essentially, this *approach is the business analysis methodology* for the project. If the approach is documented and saved as a business analysis process asset, it can be revised and reused on subsequent projects in the organization. Once the business analysis approach is complete, it is used as an input by other business analysis tasks They include planning for business analysis information management and preparing to engage your stakeholders. Both tasks are also part of the Business Analysis Planning and Monitoring knowledge area. * Recommended contents of Business Analysis Approach:* Business analysis *roles and responsibilities* Business analysis *activities* Business analysis *deliverables* Business analysis *techniques* *Timing and sequencing* of business analysis work"

BAMP: PBAG: Output

"*Business Analysis Governance Approach* According to the BABOK® Guide, the recommended content of a business analysis governance approach answers questions such as these: Who has responsibility and authority to make decisions about business analysis work? Who sets priorities for business analysis information? Who approves changes to business analysis information? Who defines the change management process for requirements and designs?"

SA: FSD: Output

"*Business Objectives* state the *desired direction required* for the business to achieve the future state *Future State Description* *defines* the new, removed, and modified *components of the enterprise* *Potential Value* potential value *expected* from the future state."

SE: ASL: Guidelines & Tools

"*Change Strategy * The change strategy is a *high-level plan of key activities and events relative to a proposed change*. Be sure to reference this information when creating the performance measures for your solution. *Risk Analysis Results * The risk analysis results *document the overall level of risk and individual risks for the solution* and solution components. *Solution Scope * Solution scope defines the *solution boundaries for what is in scope and what is out of scope*. These boundaries are used to measure and evaluate a solution."

Tasks: Solution Evaluation

"*Defining* solution performance *measures* *Collecting and analyzing* solution *performance data* *Assessing solution* limitations *Assessing enterprise* limitations *Recommending* actions to *increase solution value*"

RADD: DDO: Identify Improvement Opportunities

"*Improvement opportunities often occur when* you are defining design options. There *may* be an *opportunity to increase efficiency* by automating or simplifying the work that people perform. The solution may be able to provide better access to information. You might also find that your *design options identify capabilities beyond the required cap*abilities *found in your stakeholder or solution requirements*. You will need to decide whether these additional solution capabilities provide value to the organization, either now or in the future."

SA: CSD: Inputs

"*Needs * *Problems or opportunities must be understood* as part of analyzing the current state of the enterprise *relative to a potential change* in *how things are currently done*. *Elicitation Results (confirmed)* Elicitation results *help key stakeholders* to *define and understand the current state* of the enterprise *relative to the business need*. Elicitation information is *informally confirmed* to identify and resolve any problems with the information before it is used in some way. Confirmed elicitation results *should contain no errors, omissions, conflicts, or ambiguity relative to other information* that has been gathered or is known."

BAPM: PSE: Inputs

"*Needs* The focus of the Plan Stakeholder Engagement task is on the stakeholders who will be *affected by the business need* that is driving the project. Over time, you may discover and analyze new stakeholders that the business analysis team was *unaware of at the beginning of the project*. You also need to *beware of the stakeholders who change their position* as the project progresses. The *business need* for the project is *defined during Strategy Analysis*. *Business Analysis Approach* Successful business analysts make sure that the *business analysis approach and the stakeholder collaboration approach are in sync* with one another. Consistency across these two approaches ensures that the business analysis activities, stakeholder collaboration activities, and communication activities are all working together."

RLCM: ASSESS R CHANGES: Inputs

"*Proposed Change* A proposed change to requirements or designs *can occur at almost any time* and impact the business analysis work and deliverables completed to date. *Triggers* for proposed changes *include business strategy changes, stakeholders, legal requirements, or regulatory changes*. *Requirements * Business analysts *assess the requirements relative to a proposed change* in order to identify and quantify the impact of that change. *Designs * The more solution-focused designs are also *assessed relative to a proposed change* in order to identify and quantify the impact of that change and the modifications that will be made if the change takes place."

RADD: VERIFY: Guidelines & Tools

"*Requirements Life Cycle Management Tools* These software-based products are frequently *used to record, organize, store, and share requirements* and designs."

SE: ASL: Outputs

"*Solution Limitations* The solution limitation describes the current limitation of a solution or solution component, such as constraints and defects"

SE: MSP: Output

"*Solution Performance Measures* Measuring a solution or solution components *requires you define the performance measures that will be collected and analyzed*. The solution performance measures look at the solution performance relative to the value that the solution brings to the enterprise."

Validate vs Verified Requirements

"*Validated* requirements are stakeholder, solution, or transition *requirements* that are *aligned* with the *business goals and objectives* found in your project's business requirements or business case. *Verified* requirements are stakeholder, solution, or transition requirements that have been *reviewed and are correctly defined at an acceptable level of detail*. They are requirements of sufficient quality to allow further project work based on those requirements to be done."

"RLCM: PRIORITIZE: Defining the basis or criteria for prioritizing requirements"

"A number of prioritization schemes and approaches can be used The BABOK® Guide provides you with eight factors: *Benefit* Provide the *most business value* and meet business goals and objectives. *Penalty* *Minimize the negative* consequences of *not implementing* a specific requirement. *Cost* Force stakeholder awareness of the *implementation cost* of requirements. *Risk* *Spend time early on risky* or difficult components *to make sure the solution can be delivered*. *Dependencies* *Implement* requirements *that depend upon one another* at the same time. *Time Sensitivity* *Yield quick* or certain successes relative *to adding value* to the business. *Stability* *Avoid implementing unstable* requirements *until* they are *better defined and understood.* *Regulatory or Policy Compliance* Address regulatory or policy requirements."

SA: FSD: Techniques

"Acceptance and Evaluation Criteria *Identify what may make the future state acceptable* and how solutions options may be evaluated. Balanced Scorecard This strategic planning and management tool is used to set targets for *measuring the organizational performance in the future state*. Balanced scorecards are outcome focused and *provide a balanced view of the enterprise* by looking at *four dimensions: learning and growth, business process, customer, and financial*. Brainstorming Brainstorming is a creative way to *collaboratively come up with ideas* for what the future state might be. Participants generate new ideas and reduce those ideas into a smaller subset for subsequent analysis. Business Capability Analysis The business analyst *defines the future business capabilities* of the enterprise as part of the future state. Capability *performance gaps* are prioritized relative to value and risk. Business Cases A business case should *capture the desired outcomes* of the change initiative and clearly define the desired future state. Business Model Canvas This technique *maps out the needed infrastructure, target customer base, financial cost structure, and revenue streams* required *to fulfill the value proposition* to customers in the desired future state. Decision Analysis Decision analysis is a formal way to *examine and model the possible consequences of different decisions* being made in response to a problem. During future state definition, it is used to *compare the different future state options* and understand what the best choice might be. Decision Modelling This technique is used to *model complex decisions regarding future state options*. Decision models can use tables or trees to show how data and knowledge are combined to make a specific decision. Financial Analysis When defining the future state, financial analysis is used to *estimate potential financial returns to be delivered* by that proposed future state. Functional Decomposition Functional decomposition allows the business analyst to *break down the complex systems and relationships* that will make up the *desired future state into smaller*, easily understood pieces and parts. Interviews During future state definition, a business analyst *speaks with key stakeholders in order to understand their needs* and objectives relative to the future state. Lessons Learned Lessons learned can assist business analysts in determining which opportunities for improvement will be addressed as part of the future state and how to improve upon the current state. Metrics and Key Performance Indicators (KPIs) Metrics and KPIs are used to *assess the performance of the future state* of the enterprise. This technique can help business analysts determine when the organization has achieved the business objectives linked to the future state. Mind Mapping Mind mapping is a creative way to *develop future-state ideas* using a visual, nonlinear diagram that maps the relationships between ideas. Organizational Modelling Organizational models are used to *describe the roles, responsibilities, and reporting structure that could exist* in the future state organization. Process Modelling This graphical modelling technique *describes how work would occur* in the future state. Prototyping Prototypes *model requirements for one or more future state options* and help users and other stakeholders *determine the potential value and feasibility* of each option. Scope Modelling Scope models define the boundaries of the enterprise in the future state. Plan ahead and model the current state, too. Then it is an easy comparison between where the enterprise is now and where the enterprise wants to be relative to the business need. Survey or Questionnaire Surveys or questionnaires allow a business analyst to *understand stakeholder needs* and related business objectives that are part of the future state. This elicitation technique is effective with a *large, varied, or disparate group* of stakeholders over a relatively short period of time. Vendor Assessment This technique assesses the *potential value provided by vendor* solution options relative to the desired future state. Workshops Workshops help engage key stakeholders as they *collaboratively describe the future state* of the enterprise and their needs."

"Questions for: Business Requirements Stakeholder Requirements Solution Requirements Transition Requirements"

"Answers for: Why do I want it What are the needs What do I want What are the conditions"

SE: AEL: Techniques

"Benchmarking and Market Analysis Benchmarking can be used to *identify existing solutions* and enterprise interactions for a new solution. This identification is done relative to the potential value of that new solution defined in the future state description and the change strategy. Brainstorming This technique is used to *generate many ideas from a stakeholder group* in a short period of time. The resulting ideas can then be organized and prioritized to identify solution improvement opportunities and stakeholder concerns. Data Mining This technique is used to *collect and analyze the solution performance data*. Data mining is particularly useful when you are identifying factors that constrain the performance of the solution. Decision Analysis Decision analysis allows you to *examine and model the consequences of different decisions* before actually making or recommending a particular decision. This technique helps you to make decisions about functional, technical, or procedural gaps in the solution. Document Analysis *Reviewing existing documentation* is a way for the business analyst to understand the enterprise culture, operations, and structure. Interviews Interviews provide a forum for *identifying organizational gaps or stakeholder concerns* with the new solution and discussing possible solutions or workarounds. Item Tracking This technique is used to *record and manage stakeholder issues* related to solution limitations that impact value realization. Lessons Learned Lessons learned could be *used to look back at previous initiatives* and discover what happened along the way to limit the solution and its ability to deliver value to the enterprise. Observation Observation is used to *provide feedback on stakeholder or user perception* of a solution or to reconcile contradictory results. Sometimes it makes enterprise and solution interactions clear when you witness them and see what is going on. Organizational Modelling Organization models *offer a view of your stakeholder groups and stakeholders to use while assessing organizational readiness* and the need for organizational changes. Process Analysis *Process analysis assesses a process for efficiency and effectiveness*. This technique is used to identify opportunities to improve solution performance. Process Modelling Process models *identify activities that will change when the new solution is implemented* and tell you which stakeholders perform these activities. This allows you to focus on who is impacted by the change. Risk Analysis and Management This technique is used to consider the *risks of a new solution relative to the enterprise across several areas: technology, finance, and business*. It is essential that the required functionality and ability of the organization to change be considered and addressed. Roles and Permissions Matrix The *roles and permissions matrix helps* the business analyst *determine roles and permissions for stakeholders* and end users of a new solution. Root-Cause Analysis Root-cause analysis is used to determine the *underlying cause of a significant performance variance* within a solution. Sometimes this underlying cause is related to enterprise limitations. Survey or Questionnaire Surveys and questionnaires are techniques that give you a forum for identifying organizational gaps or stakeholder concerns with the new solution. SWOT Analysis The strengths, weaknesses, opportunities, and threats (SWOT) analysis technique *demonstrates how a change will help the organization by categorizing the strengths, weaknesses, opportunities, and threats associated with the new solution*. Workshops Workshops, or review meetings, are used to *identify organizational gaps* or stakeholder concerns about a new solution in a structured group setting."

SA: CSD: Techniques

"Benchmarking and Market Analysis Benchmarking is done to *compare organizational practices against the best-in-class practices* from competitors, the government, or industry associations. Market analysis researches customers to determine what those customers need or want. Both techniques allow you to identify opportunities for improvement in the current state. Business Capability Analysis This technique allows a business analyst to *define the current business capabilities* of the enterprise, *identify performance gaps*, and *prioritize those gaps* and capabilities *relative to the value and risk* of a business need. Business Model Canvas A business model canvas *describes how an enterprise creates, delivers, and captures value* to and from its customers. This technique provides an understanding of the value proposition between the enterprise and its customers as well as the *critical factors in delivering that value* and the resulting cost and revenue streams. Business Cases Many organizations use business cases to *justify a course of action* based upon the benefits of a proposed solution. When analyzing the current state, be sure to capture information regarding the business need and the opportunity that need presents to the enterprise. Concept Modelling Business analysts need to *capture and organize the key terms and concepts to build a ""business vocabulary"" or glossary* for people to use when discussing the current state and the proposed change. Data Mining Data mining looks for *useful patterns* and insights in enterprise data, such as information on the performance of the enterprise. This can *improve the decision-making process* relative to a business need. Financial Analysis Financial analysis is used to understand the *profitability of the current state* and to evaluate the enterprise's financial capability to deliver change. Focus Groups This group technique allows a business analyst to bring together a selected group of key stakeholders to *identify and discuss problems and opportunities* as part of analyzing the current state. Functional Decomposition Functional decomposition allows a business analyst to *break down the complex systems *and relationships that make up the current state into smaller, easily understood pieces and parts. Interviews It is essential that the business analysts *talk with stakeholders *to understand the current state and any stakeholder needs relative to that current state. Item Tracking This technique allows *issue tracking* and management relative to the description of the enterprise's current state. We often refer to this key technique as ""issue management"" on our projects. Lessons Learned Looking at *failures and opportunities from past change initiatives* can assist with facilitating a proposed change. Lessons learned may also highlight and drive a new business need for process improvement in one or more areas. Metrics and Key Performance Indicators (KPIs) Metrics and KPIs are used to assess the performance of the current state of the enterprise. Be sure to look for measurable ways to assess performance. Mind Mapping Mind mapping is a *creative way of note taking* that captures ideas and information in a visual and nonlinear way relative to the current state. This technique is used to *explore relevant aspects of the current state* and to understand the factors affecting the business need. Observation Observation allows a business analyst to *gain insight into needs by viewing* how things are done within the current state. Often, observation also helps business analysts discover new stakeholder and business needs based upon what they observe. Organizational Modelling Remember those hierarchical organization charts with the rectangles and the lines connecting each level of job title? When analyzing the current state, many business analysts *use this technique to describe the roles, responsibilities, and reporting structures* that currently exist within the organization. Process Analysis Process analysis *identifies opportunities to improve the current state* by looking at the efficiency and effectiveness of a particular process that is part of the current state. Process Modelling This graphical modelling technique *describes how work occurs* in the current state and the current solution. Risk Analysis and Management Risk analysis and management identifies areas of risk or uncertainty that *could negatively impact the current state*. This technique also analyzes and evaluates those uncertainties to develop responses to deal with the risks. Scope Modelling Ever been asked what is in scope and what is out of scope for your project? Scope models are used to *define the boundaries of the current state description*. Survey or Questionnaire This elicitation technique helps business analysts gain an understanding of the current state *from a large, varied, or disparate group* of stakeholders in a relatively short period of time. SWOT Analysis This tool evaluates the *strengths, weaknesses, opportunities, and threats* to the current state enterprise. Vendor Assessment This technique determines *whether vendors that are part of the current state are adequately* meeting their commitments or whether changes are needed. Workshops Workshops help *engage key stakeholders as they collaboratively describe the current state* and their current or future needs relative to that state."

BAMP: PBAG

"Business analysis governance is the road map for *what decisions* need to be made, *when the decisions* need to be made, and *who is responsible* for actually making those decisions. *The BABOK® Guide governance planning activities focus only on business analysis tasks and deliverables, such as decisions made about requirements and designs.*"

RLCM: BACCM

"Change *Manage and evaluate* proposed *changes to requirements* and designs across the life cycle. Needs Ensure the business *need is met by tracing, prioritizing, and maintaining the requirements*. Solution Make sure the *solution meets the business need by tracing requirements* and designs *to solution components*. Stakeholders Work with key stakeholders to *understand, agree upon, and approve requirements* and designs. Value Extend value beyond the current initiative by *maintaining requirements for reuse*. Context *Analyze the context* of the existing enterprise *to support tracing and prioritizing requirements* and designs."

Elements

"Elements are the *detailed concepts* that are necessary *to perform* a particular *task*. For some tasks, the elements are *categories of things* a business analyst *must consider*. For other tasks, the elements are *subtasks* a business analyst *performs*."

Describe: Elicitation and Collaboration

"Elicitation and Collaboration *defines how* business analysts work with stakeholders *to elicit requirements* and *understand* stakeholder *needs and concerns*. This knowledge area also addresses *ongoing collaboration and communication* during all business analysis activities. Different projects need different approaches to capture requirements. Sometimes, it may be a survey, sometimes an interview. This section documents best practices and identifies pros and cons with each approach. It is the job of the business analyst to *select the best technique* for each stakeholder on each project. It also deals with the *ongoing communication * with stakeholders after the requirements are elicited."

BAMP: PBAG: Stakeholders

"Key business analysis stakeholders may provide information or use the business analysis plans for their own planning efforts. Stakeholders involved with planning activities may include the following: Project manager Regulator The sponsor"

BAMP: PBAG: Plan for approvals

"Many *organizations have defined sets* of project deliverables, including deliverables that are traditionally created as a result of business analysis work. The business analysis team *needs to decide where* in the project life cycle the business analysis *deliverables are created, agreed upon, and updated*."

"RLCM: ASSESS R CHANGES: Determine the change assessment formality."

"Methods for assessing and deciding upon requirements changes range from the very informal to formal requests complete with committees to consider whether the requests are worthwhile. *Determining the level of formality depends upon the information available, the importance of the change, and the business analysis governance approach* defining change control for requirements and designs. *Predictive* approaches to projects often *use formal *methods to assess and determine the merits of requirement and design changes. Changes in projects using predictive approaches to planning can cause major rework of tasks and activities that were previously completed. In contrast, *adaptive *approaches to project planning often require *less change assessment formality* because of their iterative and incremental approach to getting work done."

RADD: S&M REQ: Represent Req and Attributes

"Most business analysts use the Requirements Classification Schema from the BABOK® Guide to classify their requirements: *business, stakeholder, solution, and transition. Solution requirements can be either functional or nonfunctional*. These categories are generic enough to fit any business need. Make sure you capture the requirements attributes associated with each of the requirements that you specify and model. The *attributes* that you need to capture for each type of requirement *are defined* for you in the requirements management plan that you produced *as part of the Business Analysis Planning and Monitoring* knowledge area. Exam Spotlight The BABOK® Guide makes an important distinction between requirements and designs for this task. When the focus of the specifying and modelling activities is on *understanding the business need, the resulting outputs are referred to as requirements*. When the focus of the specifying and modelling activities is on the *solution, the resulting outputs are referred to as designs*."

RLCM: APPROVE REQ

"Much of the work that you perform as part of the Requirements Life Cycle Management knowledge area gets your project requirements organized and structured appropriately. *After they are in good shape, you can share them with key stakeholders for their review, understanding, and approval.* This final task holds you responsible for communicating, obtaining agreement on, and getting approval of the requirements and designs. After receiving approval, business analysis work can proceed or actual solution construction can begin. Requirements communication tends to be iterative and ongoing in nature. It is usually done in parallel with most of the other business analysis tasks found in the BABOK® Guide. Requirements communication can be formal or informal in nature and includes conversations, notes, documents, presentations, and discussions with your stakeholders. *Approval of requirements and designs may also be formal or informal.* Predictive approaches usually perform approvals of requirements and designs at the end of project phases or during change control meetings. On the flip side, adaptive approaches approve requirements when construction and implementation of the solution meeting the requirements are ready to be done."

BAPM: PBA: Inputs

"Needs: The business analysis approach is impacted by the business need or need for change that is driving the project. This makes sense. Both the *project approach and the business analysis approach* will be *impacted* by the *problem or opportunity* it is addressing. The *needs for the project are defined during Strategy Analysis*."

Techniques: Nonfunctional Requirements Analysis

"Nonfunctional requirements *define the overall qualities or attributes of the resulting solution* or solution components. Basically, they *constrain how* the solution requirements are *to be met by the solution* itself. *Nonfunctional requirements state the qualities of behavior or quality attributes* that your stakeholders *want*. Nonfunctional requirements augment the description of solution functionality *by stating the solution's characteristics* in various dimensions that are important to the users or the developers. You should *consider using a checklist for eliciting and developing your nonfunctional req*uirements. It is *easiest to capture the functional and nonfunctional requirements at the same time*. Checklists can help you organize your nonfunctional requirements by category and make sure you are not missing anything. The BABOK® Guide recommends using a set of *15 categories as buckets for your nonfunctional requirements*. Table 6.6 summarizes each category for you. *Availability* Evaluates solution operability and accessibility when it is required for use *Certification* Defines constraints on the solution that are needed to meet standards or industry conventions *Compatibility* Most solutions today need to operate effectively and either coexist or interact with other solutions in the same environment. *Compliance* Regulatory, financial, or legal constraints on the solution *Extensibility* Evaluates the ability of a solution to incorporate new functionality *Functionality* Measures the extent to which your stakeholders can recognize whether or not a solution meets their needs *Localization* Defines requirements for local laws, languages, currencies, cultures, and spelling *Maintainability* Focuses on how easy it will be to change one solution component without affecting other components. You also need to consider component reuse, ease of diagnosing problems, and the ability to implement changes without causing unexpected failures. *Performance efficiency* Looks at the time it takes to perform activities and the resource utilization levels for the solution *Portability* You need to determine whether your solution can be migrated to, installed in, and uninstalled from different environments when needed. *Reliability* Focuses on the solution's availability when the stakeholders need it. You should also look at the solution's ability to recover from errors or failures. *Scalability* Looks at the degree with which a solution can grow or evolve to handle more work *Security* Looks at the solution's ability to store information and protect it from unauthorized use. Authentication of solution users and audit reporting is also considered. *Service level agreements* Formal agreements for solution performance between the user organization and the provider of the solution *Usability* Evaluates the ease of learning to use the new solution, its capabilities, and how usable the solution actually is *Once you have captured* your nonfunctional requirements, *you will need to document them*. Nonfunctional requirements are typically documented alongside the functional solution requirements that they constrain. That makes sense because the functional and nonfunctional requirements are both subsets of your solution requirements. It's a good idea to document the nonfunctional requirements that define your global constraints in their own section of your requirements document because they impact all of your solution requirements in some way."

"Technique: Estimation Analogous estimatio Parametric estimation Bottom-up estimation Rolling wave Three-point estimation (PERT) Historic analysis Expert judgment Delphi estimation Rough order of magnitude (ROM)"

"Recommended for BAPM: PBA (Planning Business Analysis) Effective business analysts *use estimates to promote better stakeholder decision making* and understanding of the project. Uses similar projects as the basis for top-down estimates Uses parameters and historical data Estimates smaller items first and aggregates upward Refines detailed estimates for increments of work over time Estimates optimistic, pessimistic, and most likely cases Uses history as the basis for bottom-up and top-down estimates Relies on those who performed similar work in the past Combines expert judgment and history Makes a high-level estimate based on limited information with a wide confidence interval"

RADD: S&M REQ: Analyze Requirements

"Requirements analysis requires you to *decompose the elicited business analysis information into components*. According to the BABOK® Guide, a *component is ""a uniquely identifiable element of a larger whole that fulfills a clear function.*"" Basically, you will break down what you know about the solution into organized pieces and parts and to the right level of detail. Be sure to look for things that are changing to meet the business need as well as things that need to stay the same. *Watch out for missing information and beware adding in components that are not needed to attain the solution scope.*"

RADD: VERIFY

"Requirements verification is a *quality check* of the *analyzed* requirements. This task involves *making sure* your *requirements are correct and complete* and that they *meet the quality standards* defined for them. Requirements verification can be thought of as an *internal check* by the business analysis team and the involved stakeholders to make sure the requirements are *ready to be seen out in public*. Out-in-public requirements are ready for formal review and approval so they can be used as the basis for subsequent project work, such as design and implementation. *Any type of requirement can be verified, including business, stakeholder, solution, or transition requirements*. *Because* verification is a *quality check of the analyzed* requirements, the requirements *cannot be the stated requirements or the business analysis information resulting from your elicitation efforts*. *They must have been analyzed, specified, and modelled.* Well-written requirements aren't a random event—they are planned and thoroughly reviewed and revised to meet most, if not all, of the characteristics listed in the BABOK® Guide. The elements you focus on during requirements *verification include a set of characteristics for well-written requirements and the work activities to make sure these characteristics are properly applied*."

Techniques: Use Cases & Scenarios

"Scenarios and use cases *offer you a way to model how your stakeholders interact with the solution capabilities* in order to get their jobs done. The *stakeholder roles are called actors*. Scenarios and use cases *show how actors interact with the solution to accomplish one or more of their goals* or in response to a particular event. They are *excellent ways to model the solution scope* and the behavior and goals of the actors interacting with that solution. *Models functionality* Scenarios and use cases are very much related. *Scenarios* are a *series of steps performed by a stakeholder in order to document one way* in which that *person could use a solution capability to achieve* a goal. *Use cases* consist of a *set of scenarios describing all ways* that stakeholder might achieve (or fail to achieve) a particular goal. *Elements* *Name* Unique name for each scenario or use case within the project, usually a ""verb-noun"" phrase such as Process Order *Goal* Brief description of a successful outcome of the use case from the perspective of the primary actor *Actor(s)* Unique name representing the role of each external person, system, or event that interacts with the solution through a use case *Preconditions* Any fact that the solution can assume to be true when the use case begins *Trigger* An event that initiates the flow of events for a use case *Flow of events* Description of what the actor and the solution do during the execution of the scenario, usually consisting of a primary flow and alternate flows *Post-conditions or guarantees* Any fact that must be true when the use case is complete"

Solution Requirements

"Solution requirements are the *most detailed type of requirements* that *describe the solution characteristics needed* to meet the higher-level business and stakeholder requirements. Typically, solution requirements are subdivided into two specific types: functional requirements and nonfunctional requirements. Solution requirements are developed and *defined as part of the tasks found in the Requirements Analysis and Design Definition* knowledge area."

SE: RAtoISV: Adjust solution performance measures

"Sometimes a *new solution does not quite fulfill the business goals and objectives* that triggered the project in the first place. *Issues, defects, problems, or discrepancies need to be recorded, prioritized, and resolved*. Another option is to change the solution performance measures based upon what is taking place. For a particular solution, more appropriate and achievable measures may be required."

BAPM: PSE: Elements: Perform stakeholder analysis.

"Stakeholder analysis consists of *identifying stakeholders, defining stakeholder characteristics, and analyzing the collected information* Business analysts should perform this task when a business need is identified and revisit and revise the results for as long as business analysis work continues on the project. Their involvement can, and often does, *change over the course of the project* life cycle. Identifying stakeholders late in the project is risky. This can lead to new requirements late in the project life cycle, revisions to existing requirements, solution rework, and possibly even new solution work that was not scoped out or planned. Many stakeholders who are not involved at the appropriate time in a project tend to be dissatisfied and often do not buy into the resulting solution. There are *four key areas for you to consider* as part of your stakeholder analysis activities: roles, attitudes, decision making, and power. Let's look at each area in greater detail. *1. Roles* Understanding *where and how* your stakeholders will *contribute* to the business analysis efforts is critical to the success of your project. The business analyst must discover and document which stakeholders are responsible for the work they are tasked to perform, which are *accountable* for making decisions, which must be *consulted prior to work* being done, and which are *to be informed after work* is complete. These roles may be relative to the entire business analysis effort, a particular business analysis task, or a specific business analysis deliverable, such as the business analysis approach you learned about earlier in this chapter. *2. Attitudes* Business analysts are responsible for *assessing the positive and negative attitudes* and behaviors. When doing this, they need to consider a number of factors. Stakeholder attitudes toward the project *must be assessed* and then *managed across the project life cycle*. At a minimum, *attitudes* need to be looked at *relative to the business goals, objectives, and solution approach* for the project. Additionally, attitudes must be assessed from a people perspective, considering things like the stakeholder's perception of the value of business analysis work, collaboration, and the sponsor and other key team members. *3. Decision-Making Authority* The business analysis team needs to know exactly which stakeholders *have authority * over the business analysis work and deliverables. This *includes reviewing and approving* deliverables (such as requirements), *requesting and approving* changes, and *vetoing proposed* requirements or solutions. *4. Level of Power or Influence* Understanding the nature of influence is essential when building effective stakeholder relationships and trust. The business analysis team should assess the influence of key stakeholders at the project and organization levels. The *amount of influence required* for a successful project should be *analyzed relative* to the amount of *influence possessed by the key stakeholders*. Informal stakeholder influence with the other stakeholders cannot be overlooked, as having informal project champions is a gift to the business analyst."

Techniques

"Techniques guide the business analyst in the *ways* a particular task *might be done*. The techniques in the BABOK® Guide are best practices that many business analysts use. However, business analysts can certainly use techniques that are not found in the BABOK® Guide."

RADD: VERIFY: Characteristics of Requirements and Designs Quality

"The BABOK® Guide provides you with the *nine characteristics of well-written, high-quality requirements*. Think of this as your well-written requirements quality checklist and make frequent use of it during your requirements development efforts. *Atomic* Atomic requirements are a set of requirements *organized as cohesive sets of information rather than random chunks* of information. They are *self-contained and can be understood independently* of other requirements or designs. *Complete* Your goal is to *produce a complete set of requirements defining what is needed for a solution* or a solution component. Your requirements should specify everything that is needed at the appropriate level of detail. While building your requirements document, ask yourself if you have missed anything. If you see unresolved issues or incomplete documentation, then fix it. *Concise* Concise requirements do not contain any extra information or content. There is *no ""gold plating,"" which is extra functionality that is not required* to achieve the solution scope or meet the business need. *Consistent* Consistent requirements *do not contradict or conflict* with one another. *If they do, they should be revised or removed*. Consistency should also be applied to the level of detail in your requirements document structure. All requirements at a specific numbering level in your document should be written at the same level of detail. Checking for consistency often requires a manual review and analysis of the complete set of requirements. *Feasible* Feasibility of requirements *relates to implementation*. The *existing* infrastructure, budget, timeline, and resources of the organization *should be adequate to implement your requirements* as defined. *If not*, your requirements will *need to be revised* to include any additional capabilities that are needed to implement them. *Prioritized* Verified requirements *should be ranked, grouped, or negotiated relative to their importance and value* versus *all other requirements*. Requirements prioritization involves the stakeholder as well as the business analysis team. *Testable* Can you *ensure that a requirement is met by your resulting solution*? If not, that requirement should be removed or revised because all requirements must be measurable and provable in some way. *Testing proves that what is needed is indeed present in the solution*. That means that *each requirement in your document must be provable as a single, standalone statement* or within a specific functional scenario. *Unambiguous* Can your requirements be interpreted in more than one way? If so, they are ambiguous. *Well-written requirements have only one meaning*. People should not be able to read your requirements and come up with multiple meanings. When terms have multiple meanings, consider defining those terms in your glossary. *Understandable* Requirements *need to be understood by the key stakeholders* as well as by the members of the project team. Requirements should be *written using common terms* that are understood by everyone. Numerous techniques exist for ensuring that requirements are met (Table 6.11). *Analysis* Performs analysis of the system characteristics to prove it works *Demonstration* Involves running the full system in the normal mode of operation *Execution* Uses another system or testing equipment to simulate your data *Inspection* Looks at (inspects) characteristics of the system or its output *Prior qualification* Recognizes that a component has already been tested and is being used unmodified"

BAMP: PBAIM: Decide the traceability approach.

"The business analyst wants to *show the relationships between* key pieces of business analysis *BA information* while not spending time tracing things that are not important. The information management approach is *where * the business analysis *team figures out how to trace* project requirements and designs. These decisions are based on project type and complexity. The BABOK® Guide recommends taking into account the following factors when planning traceability for your project requirements and designs: *Complexity of the domain Number of views of requirements that will be produced Requirements related risks, standards, and regulations Costs and benefits of traceability* *Creating and maintaining traceability adds* to the business analyst's *workload on a project*, so it should be reflected in the information management approach as well as in all subsequent planning activities."

What increases project complexity?

"The rule of thumb is that as these factors increase, so does the project complexity. The *size of the change* The *number of business areas or systems* affected The *amount and nature of risk* The *technological complexity* The *number of geographic and cultural* considerations"

Technique: Acceptance and Evaluation Criteria

"We think that defining and applying acceptance and evaluation criteria is a required technique in the fundamental knowledge base of an effective business analyst. *Both acceptance and evaluation criteria can be tied to contractual obligations*, which can introduce associated legal and political issues and risks into the project. *Acceptance criteria* define a *minimal set of requirements that must be met in order* for a solution or a solution component to be *considered acceptable* to its key stakeholders. These criteria should be defined early in the project life cycle and must be met in order to say that a solution is complete, correct, and worth implementing. *Test cases can and should be written that verify the solution against these defined and agreed-upon acceptance criteria*. *Evaluation criteria* are a *set of requirements used to choose between multiple solutions* to a particular problem. They are typically *built to allow scoring of the various solutions* under consideration. To evaluate potential solutions, this set of requirements is prioritized and ranked by order of importance. The solutions will then be scored against the ranked set of requirements using a preestablished evaluation scale. A must-have requirement that is not met by a proposed solution should remove that solution from consideration."

RADD: VALIDATE: Identify Assumptions

"Within a project's *business case*, you might have *documented assumptions about realizing the business benefits*. *Any assumptions* about a specific business benefit *should be documented and linked to the requirements that deliver those benefits.* This *might introduce additional risk* into the premises contained in the business case, since it is *possible that the assumptions might not be true* in the end."

BAPM: PSE: Elements: Assess stakeholder communication needs.

"You may also find yourself *building a stakeholder communication plan* to document your initiative's stakeholder communication approaches. Typically, these plans answer questions that address several aspects of stakeholder communication, such as the following: What needs to be communicated? Who is the audience? What is the delivery method? When should a communication occur? How often should a communication occur? Where are the stakeholders located? How much detail should the communication contain? How formal should the communication be? We recommend that you *combine your stakeholder collaboration and communication plans for the sake of efficiency and effectiveness*. Both plans will be more detailed components of your stakeholder engagement approach."

BAPM: PBA: Guidelines & Tools

*Business Analysis Performance Assessment* The business analysis performance assessment contains results from business analysis activities on *previous projects* for you to review and incorporate into your current approach to getting things done. *Business Policies* Business policies *define the limits within which business decisions* must be made and how work will be completed. These policies also frame and constrain the business analysis approach that you select. *Expert Judgment* Expert judgment is used to *evaluate and build the optimal business analysis approach* for your project. Your team will rely on individuals or groups with specialized knowledge or skills in business analysis and other aspects of the domain to assist in defining the approach. *Methodologies and Frameworks* Methodologies and frameworks *define and govern business analysis work* on a project. The business analysis approach may be defined by a particular methodology, an organizational framework, or a combination of the two. Don't forget to look at historical information from previous projects, such as risks, performance measures, schedules, and other data. When you discover a business analysis asset treasure trove at one of your clients, it *means you don't have to reinvent the wheel*. *Stakeholder Engagement Approach* Effective business analysts make sure that they understand their stakeholders. *Stakeholder concerns and interests can impact* the pieces and parts of your business analysis approach.

The overall business analysis process for performing work consists of the following:

*Deciding how and when* business analysis *tasks* will be *performed* *Agreeing* on the *techniques* to be used *Defining the deliverables* to be produced

"Requirements State: Maintained"

*Formatted and suitable for long-term* or future use by the organization; may be saved as organizational process *assets*

Stakeholder Map - What to Who

*Influence H / Impact L* Ensure stakeholder remains satisfied *Influence H / Impact H* Work closely with stakeholder to ensure in agreement and support *Influence L / Impact L* Monitor to ensure interest/influence do not change *Influence L / Impact H* Keep informed, stakeholder ver concerned about lack of control

What elicitation technique might best assist you in understanding the existing processes that are being used in an online order entry system?

*Observation* assesses the individual's work environment to document details about current processes.

Which technique organizes your requirements based on the solution components to which they are related?

*Scope modelling* organizes requirements based on the solution components to which they are related.

SE: AEL: Organizational Structure Changes

*Solutions can impact and change organizational structure*. Business analysts need to assess the organizational structure supporting a solution to *make sure that structure allows the solution to perform effectively*. In addition to the formal working relationships, knowledge of the informal stakeholder relationships within the organization can be very helpful to the business analyst in understanding the practical, day-to-day working structure.

SA: CSD: Technology and infrastructure

*Technology is composed of information systems* that support people as they do their work, communicate with others, and make decisions. Infrastructure is part of the enterprise environment, consisting of physical components and capabilities, such as computer hardware or operating a manufacturing plant.

"Requirements State: Specified"

*Well-formed* requirements* documented using text, matrices, and models*

List Underlying competencies of BA

- analytical thinking and problem solving skills, - behavioral characteristics such as trustworthiness, - business knowledge, - software knowledge, - interaction skills, and - communication skills.

Needed for a request of change requirements

- cost and time estimates of the requested change, its associated - benefits and risks, and the - recommended course of action for the change.

Tech: Non-Functional Requirements Analysis: Categories of Non-Function Req

.1 Categories of Non-Functional Requirements Common categories of non-functional requirements include: 1. *Availability*: degree to which the solution is operable and accessible when required for use, often expressed in terms of percent of time the solution is available. 2. *Compatibility*: degree to which the solution operates effectively with other components in its environment, such as one process with another. 3. *Functionality*: degree to which the solution functions meet user needs, including aspects of suitability, accuracy, and interoperability. 4. *Maintainability*: ease with which a solution or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. 5. *Performance Efficiency*: degree to which a solution or component performs its designated functions with* minimum consumption of resources. Can be defined based on the context or period, such as high-peak, mid- peak or off-peak usage. 6. *Portability*: ease with which a solution or component can be transferred from one environment to another. 7. *Reliability*: ability of a solution or component to perform its required functions under stated conditions for a specified period of time, such as mean time to failure of a device. 8. *Scalability*: degree with which a solution is able to grow or evolve to handle increased amounts of work. 9. *Security*: aspects of a solution that protect solution content or solution components from accidental or malicious access, use, modification, destruction, or disclosure. 10. *Usability*: ease with which a user can learn to use the solution. 11. *Certification*: constraints on the solution that are necessary to meet certain standards or industry conventions. 12. *Compliance*: regulatory, financial, or legal constraints which can vary based on the context or jurisdiction. 13. *Localization*: requirements dealing with local languages, laws, currencies, cultures, spellings, and other characteristics of users, which requires attention to the context. 14. *Service Level Agreements*: constraints of the organization being served by the solution that are formally agreed to by both the provider and the user of the solution. 15. *Extensibility*: the ability of a solution to incorporate new functionality.

Tech: Interviews: Elements

.1 Interview Goal .2 Potential Interviewees .3 Interview Questions 4. Interview Logistics 5. Interview Flow 6. Interview Follow up

Tech: Financial Analysis: Elements

1. *Cost of the Change* The cost of a change includes the expected cost of building or acquiring the solution components and the expected costs of transitioning the enterprise from the current state to the future state 2. *Total Cost of Ownership* The total cost of ownership (TCO) is the cost to acquire a solution, the cost of using the solution, and the cost of supporting the solution for the foreseeable future, combined to help understand the potential value of a solution. 3. *Value Realization* Value is typically realized over time. 4. *Cost-Benefit Analysis* Cost-benefit analysis is a prediction of the expected total benefits minus the expected total costs, resulting in an expected net benefit (the planned business value). 5. *Financial Calculations*

Tech: Business Rules: Elements

1. *Definitional Rules* Definitional rules shape concepts, or produce knowledge or information 2. *Behavioural Rules* Behavioural rules are people rules-even if the behaviour is automated. *Levels of Enforcement* 2.1 Allow no violations (strictly enforced). • 2.2 Override by authorized actor. 2.3 Override with explanation. 2.4 No active enforcement.

Tech: Process Analysis: Elements

1. *Identify Gaps & Areas to Improve* (what is in scope) 2. *Identify Root Causes* 3. *Generate and Evaluate Options* 4. *Common Methods* (SIPOC, VSM) Value stream mapping (VSM) is a process analysis method used in Lean methodologies. SIPOC is a process analysis method that originates in the Six Sigma methodology and has been more commonly adopted as a process analysis method outside of Six Sigma.

Software Req Traceability

1. Business Need 2. Business Requirement 3. Stakeholder Requirement 4. Solution Requirement (Design, Code, Test)

business goal

A state or condition that an organization is seeking to establish

root cause analysis

A structured examination of an identified problem to understand the underlying causes.

enterprise readiness assessment

An assessment that describes the enterprise is prepared to accept the change associated with a solution and is able to use it effectively.

organization

An autonomous group of people under the management of a single individual or board, that works towards common goals and objectives.

temporal event

An event based on time that can trigger the initiation of a process, evaluation of business rules, or some other response.

Which BA work product does not affect several RCLM tasks

BAA

SE: SPA: Stakeholders

Domain SME Project manager Sponsor

SDLC (Systems Development Life Cycle)

Phase 1: Requirement collection and analysis Phase 2: Feasibility study Phase 3: Design Phase 4: Coding Phase 5: Testing Phase 6: Installation/Deployment Phase 7: Maintenance

Core Business Need?

Revenue

requirements architecture

The requirements of an initiative and the interrelationships between these requirements.

RLCM: APPROVE REQ: Elements

Understand stakeholder roles. Address conflict and issue management. Gain consensus. Track and communicate approval.

SA: AR: Elements

Unknowns Constraints, assumptions, and dependencies Negative impact to value Risk tolerance Recommendation

Tech: Use Cases & Scenarios

Use cases and scenarios describe how a person or system interacts with the solution being modelled to achieve a goal. ---- Use Case Diagram 1. Relationship (Extend - Insertion / Include - Make use of) 2. Name 3. Goal (Successful outcome) 4. Actors (Person/system external to solution) 5. Preconditions (must be true before) 6. Trigger (Initiates) 7. Flow of events (set steps) 8. Post-conditions / Guarantees (fact that must be true after)

What are the 7 dimensions of the product that may help in discovery of requirements and provide a comprehensive understanding of the product requirements?

User, Interface, Data, Control, Usability, Quality, Environments

Which of the following is not a valid threat?

Variety of insurance products is not a valid threat. This may be a strength of the company.

Recommended Statistical Sampling Techniques

Volume or sample size Frequency and timing Currency

SE: APM

"*Analyzing performance measures* typically *begins* once your constructed *solution is deployed* and in operational use. Business analysts need to understand the potential value of the solution and the enterprise context where that solution is being implemented. *You will find yourself looking at goals, objectives, KPIs, risks, and other factors as part of this analysis work.* You may find yourself *investigating how the solution is being used and assessing the positive and negative impacts* it has on the organization and its stakeholders. Some folks analyze performance measures in a post-implementation assessment performed shortly after their project is complete"

RADD: REQ ARCH: Relate and Verify Requirements Relationships

"*Applying traceability techniques* as part of the Trace Requirements task *shows the relationships between requirements*. When *defining or using the requirements architecture*, business analysts also *need to examine the traced req*uirements to make *sure the relationships meet certain quality criteria*. *Defined* A relationship exists between the requirements, and the type of relationship is described. *Necessary* The relationship is necessary for understanding the requirements. *Correct* The elements have the relationship described. *Unambiguous* There are no relationships linking elements in different or conflicting ways. *Consistent* Relationships are described in the same way with the same set of standard descriptions in the viewpoints."

RADD: REQ ARCH: Guidelines & Tools

"*Architecture Management Software * Many business analysts use modelling software to build and manage the requirements architecture. The *focus is on the volume, complexity, and version control for the information in the architecture and the relationships it contains*. *Legal/Regulatory Information * Oftentimes, there are *rules, regulations, contracts, or standards*-based constraints that *must be incorporated into the requirements arch*itecture and followed. *Methodologies and Framework * Many *org*anizations have a *predetermined set of models and relationships between those models* that are to be used in the requirements architecture."

RADD: VALIDATE: Evaluate Business Case Alignment

"*Beware of requirements that are beloved by your stakeholders yet add little or no business value to the organization*. The best rule to follow is that *requirements that do not align with the solution scope result* in either a revised business case or their *removal from the solution scope*. Watch out for the opportunity cost of implementing such requirements. *Sometimes it is best to remove requirements that don't align with the solution scope versus investing the time and money to make them work*. Your time and money might be better spent elsewhere. Every opportunity (or requirement) has an associated cost."

BAPM: BAPI: Inputs

"*Business Analysis Approach* Business analysis performance is traditionally measured in the same way you look at project performance. The *business analysis approach is used to measure actual* progress *against the planned deliverables, activities, tasks, and estimates*. *Performance Objectives (external)* Many *organizations define the high-level performance outcomes* that they *want to achieve* as a result of the projects or initiatives. These external performance *outcomes need to be factored in* to the business analysis performance improvements."

BAMP: PBAG: Inputs

"*Business Analysis Approach* The business analysis approach governs planning activities, as it *defines * the *planning process and the development life cycle*. It is *essential* that you keep your business analysis *governance process consistent with the overall business analysis approach* for your efforts. *Stakeholder Engagement Approach * *Understanding* the *preferences* of key business analysis *stakeholders* will *shape* the resulting business analysis *governance process* to some degree. *Stakeholder roles and levels* of involvement *need to be understood* and incorporated into your business analysis governance process."

SA: AR: Guidelines & Tools

"*Business Analysis Approach* The business analysis approach provides the framework for all business analysis activities. It contains the *guidelines for how business analysts will perform risks analysis* on their project. *Business Policies* The *limits and boundaries for decision making* within the organization live here. These policies may have an impact on the risk management activities taking place. *Change Strategy* The change strategy tells us *how we plan to transition from the current state to the future state*. Risks associated with this change and the steps of the change need to be considered when analyzing risks. *Current State Description* How things are currently working *provides the context* within which the new work needs to be completed. Current state risks may come into play on your project, and you should watch for them. *Future State Description* Along with the change strategy and the business requirements, this description provides business analysts with a *baseline for determining the risks associated with achieving the future state*. *Identified Risks* Identified risks come from the *risk analysis results* and can be *used as a starting point* for additional risk identification and analysis activities relative to the current and future states. *Stakeholder Engagement Approach* Stakeholders are an important source of risks for your project. Be aware of your stakeholders and get them involved with the risk assessment efforts across the project life cycle."

SA: CSD: Guidelines & Tools

"*Business Analysis Approach* The business analyst's approach to analyzing the current state of the enterprise is defined and guided by the business analysis approach. Every time a business analyst *tackles a task, they need to think about how they will go about getting that work done*. Using your organization's business analysis approach to performing this work can be helpful and keep you on track. The approach can be as simple as a *series of steps* to produce a deliverable *or as complex as a detailed plan* for gathering information and creating a project deliverable. *Enterprise Limitation* Challenges, such as the *lack of resources or knowledge/skill gaps*, can exist within the enterprise relative to the business need and the potential change. These limitations can impact the resulting requirements and solution and must be identified and addressed. *Organizational Strategy* Organizations usually have a set of business goals and business objectives. Some of them are found in the *statements of mission, vision, and values*, outlining *what the organization wants to achieve and how they see themselves doing it*. A determination of how and why addressing the problem or opportunity furthers these goals and objectives can be critical to success. *Solution Limitation* Understanding the current state means being aware of the *limits* and challenges that may be *present in an existing solution*. Changes to the existing solution may impact or be impacted by the existing solution, its capabilities, and its infrastructure. *Solution Performance Goals* Most organizations measure the current performance of the enterprise and its solutions, particularly IT solutions. These *measures of existing solution performance are the baseline* for setting the desired future state goals and improvements. These goals reflect enterprise/solution and *baselining*. *Solution Performance Measures* While solution performance goals are more focused on establishing a baseline for enterprise/solution performance, solution performance measures describe the *actual performance of existing solutions* in the enterprise. Analysts can then *compare the actual to the baseline* to assess change. The measures only focus on the actual state of solutions. *Stakeholder Analysis Results* Identifying the *business need is the first step* in defining a project's business requirements. As part of their identification efforts, business analysts *must elicit information from key stakeholders* about their high-level needs and *knowledge of the current state*."

BAPM: BAIMA: Output

"*Business Analysis Information Management Approach* The information management approach *describes how* business analysis information *will be stored, accessed, and used* *during and after* your project. The BABOK® Guide recommends that the information management approach define the following aspects of the business analysis information on your projects: *Organizing* the business analysis information *Capturing information* at the *correct level of detail* *Tracing the relationships* between the information *Using or reusing * the information across the enterprise *Accessing and storing* information *Maintaining characteristics* about the information The *business analyst has the primary responsibility for creating or tailoring* the *information management approach* for their project. The project manager also participates in this effort as they have responsibility for managing changes to the project scope and are accountable for delivering the resulting solution. Ideally, the change management approach for the project should also govern any requirements or design changes."

BAPM: BAPI: Outputs

"*Business Analysis Performance Assessment* The business analysis performance assessment *helps* the business analysis *team compare planned versus actual performance* of business analysis work activities. *If there are significant variances* from the plan or approach, this *assessment addresses the root cause of these variances* and *suggests approaches for resolving issues*. The business analysis performance assessment *provides ongoing performance information to assist the team* in planning future business analysis work based on what has happened to date. As a result of assessing business analysis performance, the business analysis team *may need to revise the business analysis processes, results, and templates* that are being used. The revisions could be adding in new approaches that increase efficiency, or they could be correcting things that are not working well. In either case, these results should be treated as lessons learned and incorporated into the process assets and business analysis information of the organization. The *business analyst has the primary responsibility for creating the business analysis performance assessment* for their project and updating any business analysis information. The project manager also participates in these efforts as they have responsibility for monitoring performance and updating process assets for the project. Ideally, the monitoring, evaluation, and reporting approach for business analysis work should align with the project approach to handling this data. Several business analysis stakeholders are interested in the contents of the business analysis performance. They include domain SMEs, the project manager, and the sponsor."

BAMP: PBAIM: Guidelines & Tools

"*Business Analysis Performance Assessment* Be sure to review and incorporate results of *previous business analysis efforts* into your business analysis information management approach. *Business Policies* Business policies define the *limits within which business decisions must be made* and how work will be completed. These policies *also frame and constrain* the information management approach that you select. *Information Management Tools* Take a *look at the tools your organization currently* uses to store, retrieve, and share business analysis information. These may be the tools your organization requires you to use on your initiative. *Legal/Regulatory Information* Sometimes legislative rules or regulations *have an impact on your business analysis information*. If that is the case, you need to address these additional *constraints, such as* information* security or privacy*, in your information management approach."

BAPM: PSE: Guidelines & Tools

"*Business Analysis Performance Assessment* The business analysis performance assessment contains results from business analysis activities on *previous projects* for you to review and incorporate into your current approach to working with your stakeholders. *Change Strategy* Checking the organization's or the project's *change strategy* allows for *improved assessment of stakeholder impact* and development of more effective stakeholder engagement strategies. *Current State Description * *How things are working right now* provides context for the work being done. Being familiar with the current state can lead to *more effective stakeholder analysis* and understanding relative to the impacts the planned change will have on your stakeholders."

BAMP: PBAG: Guidelines & Tools

"*Business Analysis Performance Assessment* There is nothing like *looking at the past* to help effective business analysts do better at planning for the future. You can use previous business analysis work performance *data on an earlier phase in this project* or on *previous efforts* as part of the current business analysis planning activities. *Business Policies* Every organization has *limits on what decisions can be made*. Business analysts must be aware of these limits and plan for business analysis governance accordingly. Decision making is often bounded by contractual, legal, or regulatory constraints. *Current State Description* The *current state* of the business area you are planning to change *provides *the business analysis team with *context for the decisions* that will need to be made moving forward. *Legal/Regulatory Information* The business analyst should remember to seek out and *use any existing policies, procedures, methods, and templates* as part of planning business analysis activities."

RLCM: PRIORITIZE: Guidelines & Tools

"*Business Constraints * Requirements *priorities should align with the regulatory statutes, contractual obligations, and business policies* of the enterprise. These constraints may drive the priority of one or more requirements. *Change Strategy * The change strategy *documents costs, timelines, and value realization goals *that can factor into prioritizing requirements to meet these planned goals and measures. *Domain Knowledge * Stakeholders with specific *domain knowledge contribute a lot of value to requirements prioritization* activities. Their knowledge and experience are indispensable. *Governance Approach * The governance approach, built during Business Analysis Planning and Monitoring, *defines the approach* for the business analyst to take on the project *when prioritizing requirements*. *Requirements Architecture * The requirements architecture *defines the relationship of requirements to other requirement and work products*. *Requirements Management Tools/Repository * Many requirements management *tools include a data field for specifying requirements priorities*. This field prompts the business analyst to prioritize the requirement and assists in sorting and searching the requirements for the project by priority. *Solution Scope * The solution scope *should be kept front and center when prioritizing requirements in order to deliver the full solution in the end.*"

SE: MSP: Inputs

"*Business Objectives * Business analysts use the defined business objectives to *make sure that the solution will deliver measurable results* to the enterprise. *Implemented Solution (External)* A solution or solution component is *required in order to measure performance*. The solution *may be an implemented solution, a prototype, or a beta* solution."

RADD: APotVal: Guidelines & Tools

"*Business Objectives * Business objectives *are measurable results used to indicate a business goal has been achieved*. They can also be *used to calculate the expected benefits* of a design option or solution approach. *Current State Description * Defined in Strategy Analysis, the current state *describes the existing context within which the work will be completed*. The current state provides a baseline to identify and quantify the value delivered by the solution. *Future State Description * The future state description *describes the desired future state* of the enterprise. The design options being defined are part of this future state and should be *evaluated relative to where the enterprise wants to be* when the solution is implemented and operational. *Risk Analysis Results * Assessing risks is a necessary step in *analyzing the potential value of design options*. There is a *level of risk associated with each option that needs to be explored and assessed* before decisions are made. *Solution Scope * Solution scope provides the *boundaries for the design options* by telling the business analyst what is in and out of scope for the solution."

SA: AR: Inputs

"*Business Objectives * Business objectives *describe and point to the desired direction needed to achieve the future state*. They are also used to identify and discuss potential risks along the way as part of the risk analysis efforts. *Designs (Prioritized)* Prioritized designs *link to and influence the risks along the way to solution* realization. Keep an eye on the designs priorities as you perform risk analysis activities as they directly influence how you prioritize and address the identified risks. *Elicitation Results (Confirmed)* Effective business analysts make sure that the elicitation information *contains an understanding of what the stakeholders perceive as risks* in achieving the desired future state. *Influences (Internal and External)* Influences are factors from inside and outside the enterprise that can impact achieving the future state. They can be as simple as organizational *attitudes toward a proposed change* in how things are done or tangible influences such as *existing or proposed infrastructure and technology*. *Potential Value* Potential value is the *value to be realized when a proposed future state* is implemented. This definition of business value *provides a benchmark against which risks can be assessed* across the project life cycle. *Requirements (Prioritized)* Prioritized requirements *link to and influence the risks along the way to solution* realization. Keep an eye on the requirements priorities as you perform risk analysis activities as they directly influence how you prioritize and address the identified risks."

SE: RAtoISV: Guidelines & Tools

"*Business Objectives * Business objectives are *measurable results indicating a business goal has been met*. Be sure to consider these objectives when evaluating, measuring, and determining solution performance. *Current State Description * The current state description *provides the context of the existing enterprise* where the work needs to be done. It can be used to assess alternatives and understand ways to increase solution value. *Solution Scope * Solution scope *defines the solution boundaries for what is in scope and what is out of scope*. These solution boundaries are used to define what needs to be measured and evaluated."

SE: AEL: Guidelines & Tools

"*Business Objectives * Business objectives are *measurable results indicating a business goal has been met*. Be sure to consider these objectives when measuring solution performance. *Change Strategy * The change strategy is a *high-level plan of key activities and events relative to a proposed change*. Be sure to reference this information when implementing a solution and when creating performance measures for that solution. *Future State Description * The future state description *provides a definition of the boundaries for the solution scope* and all of the solution components. It also links back to the potential value expected from the future state. *Risk Analysis Results * Risk analysis results contain the *overall level of risk for the solution as well as the individual risks for the solution* components. *Solution Scope * Solution scope *defines the solution boundaries for what is in scope and what is out of scope*. These solution boundaries are used to define what needs to be measured and evaluated."

RADD: VALIDATE: Guidelines & Tools

"*Business Objectives* Business analysts use the defined business objectives to *make sure that the requirements are validated and actually will deliver the business benefits*. *Future State Description * Validation is *incomplete unless* the business analyst *can prove that the requirements will achieve the desired future state* as part of the defined solution scope. *Potential Value * The potential value is used as a *benchmark for assessing the value* that will be delivered to the business by the requirements *after they are implemented*. *Solution Scope * Experienced business analysts *make certain* that the *requirements providing benefits to the business are within the boundaries* of the solution scope."

Differences between Business Requirement / Need / Goal / Objective

"*Business Requirements * The *defined problem, opportunity, or need* based upon the current state of the business *Business Need * *A problem or opportunity* that an organization is facing *within the framework of the organization's business goals and objectives* *Business Goal* *A future state* that an organization is seeking to establish and maintain *Business Objective* An *objective and measurable result* that *indicates a business goal has been achieved*"

SA: FSD: Inputs

"*Business Requirements* The business requirements are the basis for defining the future state. Business requirements *define the problems, opportunities, or constraints* that *need to be addressed by the solution scope*. The business analyst is focused on *what it will take to deliver the business requirements*, either by using existing capabilities or by creating new capabilities."

SE: APM: Guidelines & Tools

"*Change Strategy * The change strategy is a *high-level plan of key activities and events relative to a proposed change*. Be sure to reference this information when analyzing solution performance using the defined performance measures. *Future State Description * The future state description provides a definition of the *boundaries for the solution scope* and all of the solution components. It also links back to the potential value expected from this future state. *Risk Analysis Results * The risk analysis results from Strategy Analysis provide a look at both the *overall level of solution risk and the more specific individual risks* inherent to the solution and its components. *Solution Scope * Solution scope defines the *solution boundaries for what is in scope and what is out of scope. These boundaries are used to analyze solution performance."

RLCM: APPROVE REQ: Guidelines & Tools

"*Change Strategy * The strategy provides information that *helps manage stakeholder consensus *regarding stakeholder needs. *Governance Approach * A governance approach *identifies stakeholders who have the authority and responsibility to approve* business analysis information, the approval process, and their alignment to organizational policies. *Legal/Regulatory Information * This information describes the *legislative rules or regulations that must be followed* and may impact the approval process. *Requirements Management Tools/Repository * A *tool such as this documents requirements approvals*. *Solution Scope * Business analysts *assess scope when approving requirements to accurately assess alignment and completeness*."

RLCM: ASSESS R CHANGES: Guidelines & Tools

"*Change Strategy* The change strategy describes the *purpose of changes and establishes a context and direction* for the changes on a project or initiative. It also identifies the critical components for change. *Domain Knowledge * Stakeholders with *specific domain knowledge contribute* a lot of value to assessing proposed requirements changes. *Governance Approach * The governance approach, built during Business Analysis Planning and Monitoring, *defines the approach* for the business analyst to take on the project when making decisions and dealing with change control. *Legal/Regulatory Information * Legislative rules or regulations may also *impact a proposed change* on a project. They must be considered when assessing requested changes to requirements. *Requirements Architecture * The requirements architecture defines the *relationship of requirements to other requirement and work products*. This architecture should be used when assessing the impacts of proposed changes to the requirements. *Solution Scope * The solution scope should be considered when assessing proposed changes to requirements *in order to fully understand the impacts of a proposed change*."

SE: MSP: Guidelines & Tools

"*Change Strategy* The change strategy is a *high-level plan of key activities* and events relative to a proposed change. *Be sure to reference this information when creating performance measures* for your solution. *Future State Description* The future state description *provides a definition of the boundaries for the solution scope* and all of the solution components. It also *links back to the potential value expected* from this future state. *Requirements (validated)* Validated requirements *have been analyzed and appraised to determine their potential value*. *Solution Scope * Solution scope *defines* the solution boundaries for *what is in scope and what is out of scope*. These boundaries are used to measure and evaluate a solution."

RADD: DDO: Inputs

"*Change Strategy* The change strategy, defined during Strategy Analysis, *describes* the *approach* that *will be taken to achieve* the *desired future state*. This impacts the design options for tactically getting from the current state to this future state. *Requirements (Validated, Prioritized)* Prioritized and validated stakeholder and solution requirements *allow you to define design options and solution components* relative to the most important requirements on your project. *Requirements Architecture * The requirements architecture *defines the full set of requirements and their relationships*. This information is required when defining design options to make sure you don't miss anything."

SE: BACCM

"*Change* *Recommend a change to the solution* or the enterprise in order to realize a solution's potential value. *Need* *Evaluate how a solution* or solution component *is fulfilling a business need*. *Solution* *Assess solution performance* to see *if it is delivering the potential value*. *Stakeholders* *Elicit information from stakeholders* about solution performance and value delivery. *Value* *Determine if a solution is delivering potential value* and examine why a value may not be being realized. *Context* *Determine solution performance measures and limitations within the context* of the project and the enterprise."

RADD: BACCM

"*Change* *Transform the elicitation results into requirements* and designs defining the proposed change. *Need* *Analyze needs and recommend a solution * that meets those needs. *Solution* D*efine solution options and recommend the option* addressing the need that has the most value to the business. *Stakeholder* *Tailor requirements * and designs so the stakeholders *can both understand and use them*. *Value* *Analyze the potential value of the solution options * in order to confirm and communicate that value. *Context* Model and describe the *context for the proposed change* in an understandable and usable format."

SA: FSD: Guidelines & Tools

"*Constraints* Constraints may exist within the enterprise that *limit or change your solution options* as part of the future state definition. *Current State Description* The current state description *defines the current capabilities* of an organization *relative to a business need*. The description may look at the organization's business processes, software, hardware, people, operations, and current projects. This is the first place you look to understand the organization's current capabilities relative to the business need being addressed and the desired future state to be defined. *Metrics and KPIs* When defining the future state, key performance indicators and metrics must be considered. This *allows you to determine whether the future state has been achieved* when the solution is implemented. *Organizational Strategy* This strategy *defines the path, method, or approach* the organization will take *to achieve the desired future state*. This strategy may impact the solution that is chosen for implementation."

RADD: S&M REQ: Output

"*Create the Specified and Modelled Requirements* Specified and modelled requirements are *used as an input to several solution-related tasks*. Remember the definition for analyzed requirements: the modelled and specified stakeholder and solution requirements for your project."

SA: CSD: Output

"*Current State Description* & *Business Requirements* The *current state description provides the context* for the enterprise's existing scope, capabilities, resources, performance, culture dependencies, infrastructure, external influences, and significant relationships between these elements. The *business requirements define the problem, opportunity, or constraint* defined based upon understanding the definition and inner workings of the current state. The business requirements include the business need, describing the problem or opportunity that an organization is facing. The business requirements and the current state description drive the start of your project."

Techniques: Data Flow Diagrams

"*Data flow diagrams (DFDs) model how information flows within a system*. DFDs *portray* the *transformation of data* by looking at the following: *External* entities that are *sources or destinations* for data Data *processes* that *transform the data* in some way Data *stores* that *collect the data* for some period of time Data *flows* moving *data between external entities, processes, and data stores* *DFDs help you understand the range of data found within a solution* or solution component. They are *created after a context diagram has been built* that shows you the high-level view of the solution and its associated data flow. However, *DFDs do not show you who performs the work* nor do they show you any alternative paths through the process. 2 Data Flow Diagram Notations: *Yourdon* : Data process as Circle / Data Store between parallel lines *Gane-Sarson* : Data process as Rectangle with curved corners/ Data Store as Rectangle with right side open/square"

Techniques: Data Modelling

"*Data models visually represent the people, places, things, and concepts* that are important to the business. The *two most common types* of data models are the *ERD and the class diagram*. *ERDs are often used* for projects where a *relational database is part of the solution*, while *class diagrams are a better fit for object-oriented software development efforts*. *Logical data models look at the concepts, attributes, and relationships for the information relevant* to the organization in detail or at a high level. *Physical data models describe how data is stored and managed* by a software application that is part of the solution scope. *Conceptual data models represent how the business perceives its information*—both the words used to describe the information and the relationships within the information. *In data models, concepts are something significant to the organization* about which the organization needs data. *Attributes are used to define specific pieces of information* associated with a concept, such as its name, acceptable values, and a description. *Relationships are significant business associations between concepts*."

BAMP: PBAIM: Define the levels of abstraction.

"*Deciding the breadth and depth* of business analysis *information* can be challenging. Business analysis information typically ranges *from very high-level, conceptual* data to *very detailed data* about a particular capability. *Three perspectives are essential* as part of this definition: *stakeholder information needs*, the *complexity of what is being explained*, and the *importance of the change*."

Tasks: Strategy Analysis

"*Defining *and *understanding *the business *problem or opportunity* *Assessing* capability* gaps *in the organization by analyzing the current and future states *Assessing risks* relative to the proposed *solution* *Defining* the change *strategy* for the initiative *Determining* the *most feasible* business *solution* approach" Tasks from the Strategy Analysis knowledge area *focus* on *defining the business requirements* and justifying delivery of the *solution scope* for the project. Business analysis performance *metrics for the tasks and deliverables* are *also defined and tracked.* *determine* whether it is a *viable and worthwhile project * for the business.

RADD: DDO: Output

"*Design Options* Design options *describe ways to satisfy one or more needs*, such as: the solution approach, potential improvement opportunities that are part of the design option, and the components defining the design option. Each of these ways requires the business analyst to *assess the value that each design option delivers to the business*. Your project's validated and prioritized requirements are used as an input for defining design options. Remember that the design options should be based on the prioritized and validated requirements for your project."

RADD: DDO: Describe Design Options

"*Design options* are often *developed in parallel with defining the desired future state* as part of Strategy Analysis. It is *essential* that the *design options* for each design component *be valid for the future state*. Design options *can describe many things*, such as the following: Business *policies and rules* Business *processes* *People* operating and maintaining the solution Operational business *decisions* *Software applications* and application components used in the solution *Organizational structures *and internal/external *interactions*"

RLCM: TRACE: Guidelines & Tools

"*Domain Knowledge* Tracing requirements *leverages* business *knowledge and expertise from* stakeholders in the *business domain* being addressed. This knowledge enables business analysts to put together the pieces of the traceability puzzle correctly. *Information Management Approach * The business analysis team's traceability *decisions should be based on the information management approach*. This approach *addresses and defines requirements traceability* before any actual requirements development has begun. *Legal/Regulatory Information* Sometimes the business analyst *must incorporate legislative or regulatory rules* into their project's traceability approach. *Requirements Management Tools/Repository* The tools and storage for requirements and requirement traceability *must be in place prior to commencing* requirements development. Based upon the complexity of the project and the degree of traceability formality, these tools can range from simple spreadsheets to complex requirements management tools."

RADD: APotVal: Assess Design Options and Recommending Solutions

"*Each design option is assessed based on its potential value*. Understanding the cost and effort required for each solution component is an essential step in evaluating and recommending what should be done. *The BABOK® Guide recommends taking three factors* into account during this process: *available resources*, Allocated resources can *impact or limit getting work done* to implement the requirements. Sometimes, a *business case* must be *used to justify additional resources* to get things done. *solution constraints*, and Regulatory requirements *may impact how requirements are implemented* in the solution. They *can also drive requirements prioritization* *requirements dependencies*. *Some capabilities support other high-value requirements* in the solution yet provide limited capabilities to the organization"

RADD: S&M REQ: Input

"*Elicitation Results (Any State)* Modelling begins when there are elicitation results available. The *elicitation results* that are used *can be either confirmed or unconfirmed*. Modelling and elicitation *can be sequential, iterative, or concurrent* activities. *Modelling often leads to the need for additional elicitation results* to clarify or expand upon what is known at a particular point in time."

SE: RAtoISV: Inputs

"*Enterprise Limitation* Enterprise limitations *look at how solution performance impacts the enterprise relative to any limitations* that enterprise might have. *Solution Limitation * Solution limitations *focus on the limits, constraints, and defects of the solution itself* and how those limitations might impact value realization."

SE: AEL: Outputs

"*Enterprise Limitations* Your *enterprise limitation assessment describes* the *current enterprise limitations* of a *solution*. Be sure to look at how solution performance impacts the enterprise. You always need to keep in mind that a solution isn't a success if people are unable to use it effectively."

RADD: DDO: Guidelines & Tools

"*Existing Solutions * On many projects, existing products or services are components of one or more design options. This includes third-party products and services that were built external to the organization. *Future State Description * The future state description, defined in Strategy Analysis, describes the desired future state of the enterprise. The *design options* being defined are part of this future state and *should be evaluated relative to where the enterprise wants to be* when the solution is implemented and operational. *Requirements (Traced)* Traced requirements *should be used when defining design options to make sure all known requirements are fulfilled by the solution*. *Solution Scope* Solution scope provides the boundaries for the design options by telling the business analyst what is in and out of scope for the solution."

SE: ASL: Inputs

"*Implemented Solution (External)* Implemented solutions *are those that exist and can be evaluated*. They may or may not be in operational use, such as a prototype solution. *Solution Performance Analysis * The solution performance analysis *contains the results of collected and analyzed solution performance measurements*. It also contains recommendations to solve any performance gaps or take advantage of any opportunities that could improve the solution's value."

SE: AEL: Inputs

"*Implemented or Constructed Solution (External) * The implemented or constructed *solution must actually exist*. It may be in operational use or a prototype. In either case, the solution must be in use so its performance can be measured and analyzed. *Current State Description * The current state description *describes the environmental, cultural, and internal factors of the solution* being measured and analyzed. *Solution Performance Analysis * This deliverable describes how the solution performs relative to the business goals and objectives that led to its creation and implementation. It *contains the results of analyzing the solution performance measurements* that were collected and the business analyst's recommendations relative to the results of the measurements."

RCLM: MAINTAIN: Guidelines & Tools

"*Information Management Approach * The business analyst's approach for managing requirements *reuse is defined as part of the information management approach* during Business Analysis Planning and Monitoring activities."

RLCM: TRACE: Selecting the relationships to be traced

"*Key dependencies and relationships* between requirements *should be recorded* so they *can be traced* across the project life cycle. Creating and maintaining this information *assists the BA* (business analyst) in sequencing project work activities *to design and deploy the capabilities* found in the requirements. It also assists the business analyst in *correctly allocating requirements to solution components*. The following are types of relationships to consider: *Derive*. Derivation is the *backward traceability* of a requirement *to its higher-level parent*. An example of derivation is when a solution requirement is derived from a business or stakeholder requirement. *Depends*. A dependency relationship exists between two requirements when the *requirements depend upon one another* in some way. There are two *types of dependency*: necessity and effort. *Necessity* is when it *makes sense to implement one requirement only when* another requirement is also implemented. *Effort* is when a *requirement is easier to implement when* a related requirement is also implemented. *Satisfy*. The satisfy relationship *exists between a requirement and a solution component*. Essentially, the solution component satisfies the associated requirement. *Validate*. This relationship *exists between a requirement and the test case* or other method *that validates or proves the solution fulfills the requirement*."

BAPM: PBA: Elements: Gain Stakeholder Acceptance of the Approach

"*Key stakeholders must review and agree* to the approach the business analyst creates. In general, the more your key stakeholders are involved with creating and thinking through the business analysis approach, the easier acceptance will be. Some projects require a formal sign-off on the approach from key stakeholders. Other projects may consider the approach accepted with an email saying that a key stakeholder agrees that all business analysis activities are identified, the estimates are realistic, and the proposed roles and responsibilities are correct. Be sure to plan for handling stakeholder acceptance of changes to the business analysis approach over time as work progresses and conditions change."

RLCM: APPROVE REQ: Address conflict and issue management.

"*Maintaining stakeholder support* for a change to requirements or designs *can be challenging*. The *BABOK® Guide recommends seeking consensus* for the change among stakeholders *prior to requesting that they approve and sign-off* on the change. The business analysis governance approach built during Business Analysis Planning and Monitoring *BAPM defines how to make decisions about changes and resolve any conflicts that arise*."

RADD: S&M REQ: Guidelines & Tools

"*Modelling Notations/Standards * Many business analysts use *standard templates* and syntax to precisely and consistently specify requirements. *Modelling Tools * There are many modelling tools available to draw and store matrices and diagrams that represent requirements. *These tools may or may not be part of a requirements life cycle management tool*. *Requirements Architecture * The business analyst *uses the requirements and their interrelationships* to make sure the requirements and designs *are complete and consistent*. *Requirements Life Cycle Management Tools * These software-based products are frequently *used to record, organize, store, and share requirements and designs*. *Solution Scope * Solution scope is the *set of capabilities a solution must deliver* to meet the business need. The *boundaries of the solution scope are also the boundaries for the resulting requirements and designs* that are being specified and modelled."

RADD: S&M REQ: Model Requirements

"*Models are a simplified representation or diagram* of something real. They *can be textual, graphical,* or a combination of both. *The phrase ""a picture is worth a thousand words"" is certainly true when it comes to analyzing and documenting your requirements*. Many analysts find using models—formal or informal—to be helpful during their requirements elicitation efforts, as well as during requirements analysis. The *most common matrix type of model* seen in requirements is a *two-dimensional table or spreadsheet*. Requirements attributes and data dictionaries lend themselves to being developed in a table format. A table can be *much more effective* than a bunch of sentences when you are *trying to show simple relationships between pieces* of your requirements information, such as requirements priorities or traceability relationships."

BAPM: BAPI: Guidelines & Tools

"*Organizational Performance Standards* Many organizations have *mandated performance standards or expectations* for business analysis work and for their overall organization or enterprise as well. If this is the case, the business analysis team *must factor these into the business analysis performance metrics* for their project."

What are the 5 categories of Models

"*People and Roles* *Rationale* *Activity flow* *Capability* *Data and information*"

What are the 5 categories of Models (details)

"*People and Roles* - Represent organizations, people, and their relationships to the enterprise and the solution == Organizational modelling == Scope modelling == Roles and permissions matrix == Stakeholder list, map, or personas *Rationale* - Represent the rationale or the ""why"" of a change == Decision modelling == Scope modelling == Business model canvas == Root-cause analysis == Business rules analysis *Activity flow* - Represent a sequence of actions, or events as an activity flow == Process modelling == Use cases and scenarios == User stories *Capability* - Represent capabilities, features, or functions of the solution == Business capability analysis == Functional decomposition == Prototyping *Data and information* Represent the exchange of information within a solution and the characteristics of that information == Data dictionary == Data flow diagram == Data modelling == Glossary == State modelling == Interface analysis"

SE: ASL: Performing an Impact Assessment

"*Performing an impact assessment on one or more identified solution problems determines the severity of the problem, the probability of the problem occurring again, the impact on the business operations, and the capacity of the business to absorb that impact*. Problems can be resolved, mitigated, or accepted. Risks are also assessed as part of an impact analysis."

SE: APM: Input

"*Potential Value * Potential value *describes the value that might be realized* from the operational solution. This *estimate is often used as a benchmark* when analyzing the actual solution performance. *Solution Performance Measures* Solution performance metrics *define the criteria that are used to measure and assess solution performance*. They may be quantitative or qualitative in nature. Examples of quantitative metrics include numerical measures of time, revenue, or transaction volume. Qualitative metrics are softer measures, such as customer satisfaction or recommendations."

RADD: APotVal: Input

"*Potential Value * Potential value is *often described in financial terms*. It *can be used as a benchmark* against the value a particular design option may deliver to the enterprise. *Design Options * Design options *describe ways to satisfy one or more needs*, such as the solution approach, potential improvement opportunities that are part of the design option, and the components defining the design option. *Design options are evaluated and compared to one another* in order *to select and recommend one* option for the solution."

Tasks: Elicitation and Collaboration

"*Preparing* for *elicitation* activities Meeting with stakeholders to *conduct the elicitation activity* *Confirming, documenting, and recording* the elicitation *results* *Communicating and confirming* elicitation *results * with key stakeholders"

Techniques: Process Modelling

"*Process models organize your requirements using a hierarchy of processes and subprocesses*, and they address those processes *from start to finish*. Use them to *document the steps your stakeholders take to get their work done*. Process models are easy to understand and to work with. Think of graphically depicting a series of steps to place an online order on a whiteboard with arrows between them to show the sequence of events. That flowchart is a simple process map. According to the BABOK® Guide, *process models are visual representations of the sequential flow and control logic of a set of related activities*. Process models may consist of manual steps performed by the stakeholders, automated steps taken by a software system, or some combination of the two. Process models may be developed at a high level to get a general understanding of what is going on, or they may be very detailed steps that your stakeholders take to perform their work. The *two most common notations are flowcharts and activity diagrams* *Process Model Notation Elements* *Activity* Individual steps or pieces of work being performed to execute a business process *Decision point* Forks where workflow takes different directions or merges back together based on a decision being made *Directional flow* Indicates direction of the sequence of activities, typically drawn as top to bottom or left to right *Events* External factors such as actions taken or messages received that create, interrupt, or terminate a process *Link* A connection to other process maps *Role* Represents a type of person or a group found in the organization"

SE: RAtoISV: Recommendations

"*Recommendations describe ways to increase solution performance*. There are several common recommendations that might be made based upon the situation. *Do nothing.* Remain in the current state when the value of a change is low and the cost/risks of making the change are high. *Organizational change* Make *changes to organizational structure or personnel*, such as automating work, simplifying work, or improving access to information. *Reduce interface complexity.* Make it *easier to share and understand work or data between systems* or people. *Eliminate redundancy.* Meet the *common needs of different stakeholder groups with a single solution* to reduce implementation costs. *Avoid waste.* Remove activities *that do not add value and minimize activities* that do not directly contribute to the final product. *Identify additional capabilities.* Be aware of *capabilities in the solution that exceed requirements* and make sure they will provide future value. *Retire the solution.* Replace a solution or component *because of old technology, insourcing, outsourcing, or a solution not fulfilling its goals*. Necessity Many solutions and their *components have a limited life span* and *must be replaced at a certain point in time*. Don't forget the sunk costs, which are the money and effort already committed to a solution. Many folks hold on to a bad solution versus replacing, eliminating, or redirecting the solution because of the sunk costs that cannot be recovered."

SE: RAtoISV

"*Recommended Actions* The recommended actions *provide a summary of what should be done to improve the value of a solution within the enterprise*. This output is picked up by the Manage Stakeholder Collaboration task in the Elicitation and Collaboration knowledge area. *Stakeholders participate in the recommendation review and the decision making regarding what is to be done, if anything*. Remember that the more significant the impact of a change, the more attention is directed to managing stakeholder collaboration as part of the business analysis activities."

Technique: Metrics & Key Performance Indicators

"*Recommended for Business Analysis Performance Improvement* Metrics and key performance indicators (KPIs) are the *basis for the monitoring, evaluation, and reporting system* that addresses business analysis work, the overall project, and the resulting solution. *KPI* *KPIs are indicators that allow* the business analyst or business analysis team *to measure performance or progress* of solutions and solution components *toward strategic goals* or objectives. KPIs are indicators that allow the business analyst or business analysis team to measure performance or progress of solutions and solution components toward strategic goals or objectives. *Metric* *Metrics facilitate the more basic monitoring and evaluation* of business analysis work activities and deliverables *in your quest to meet the overall solution goals*. Metric is a *standard of measurement* that is *defined relative* to business analysis *performance defining a quantifiable level of an indicator that the business analysis team wants to accomplish* *Indicator* Indicators identify specific numeric measurements indicating progress toward achieving something, such as an activity or deliverable. Metrics and KPIs are essential for the ongoing monitoring and evaluation of business analysis activities on any project. *Effective monitoring, evaluation, and reporting must address several elements: indicators, metrics, structure, and reporting*. To measure a particular aspect of a project or solution, you must have at least one indicator. The business analyst needs to know the source of each defined indicator, how to collect the measurement, the person or system doing the collecting, and how often it will be done. *Good indicators meet five quality characteristics*: they are *clear, relevant, economical, adequate, and quantifiable*. If indicators can't be quantified and measured when we need them, they are not of much use. Exam Spotlight *Metrics can be a specific point, a threshold, or a range of values* based on what is being measured. They *allow* the business analysis team or the project manager *to track, assess, and report on the quality of business analysis work* that is being done."

Technique: Root-Cause Analysis

"*Recommended for CSD* Business analysts perform root-case analysis to *determine the underlying source of a problem*. This structured technique is used to examine a situation in order to establish the *root causes and resulting effects* of a particular problem. The BABOK® Guide recommends two common methods for root-cause analysis: the fishbone diagram and the five whys. *Fishbone Diagram * A fishbone diagram allows the business analyst to *show the causes of a problem* or an effect. Fishbone diagrams are also called *Ishikawa or cause-and-effect diagrams*. This diagram allows the business analyst to see all possible causes of a result in a structured way and to make sure that everyone understands the problem or cause that is being addressed. The business analyst and key stakeholders will brainstorm the categories and the possible causes in each category. *Typical categories* include things like *people, methods, machines, materials, measurements, and environment*. After the diagram is built, the business analyst will analyze the results and (hopefully) determine the actual cause of what is taking place. This fishbone example looks at the possible causes for a specific effect: decreased wine sales revenue. The possible causes are diagrammed and broken down across four areas: people and skills, systems, distributors, and surroundings. A fishbone diagram, like the one shown in Figure 3.2, offers the team the opportunity to analyze and discuss what they think is leading to this decrease in revenue. *Five Whys* The five whys is a questioning technique that asks, ""Why?"" repeatedly in order to get to the root cause of a problem. This technique can be used alone or used with the fishbone diagram technique. This is a simple and effective facilitation tool. Many business analysts customize their use of this tool by asking, ""How?"" instead of ""Why?"" or by alternating between the two terms. Often the root cause is identified before the five questions are asked."

Technique: Document Analysis

"*Recommended for CSD* Document analysis *allows * a business analyst to *elicit, confirm, or crosscheck project requirements* information by studying *existing documentation* and other relevant information. These secondary sources of information allow the business analyst to *gather details for existing solutions (the ""as is"" situation*) to see whether they have components that can be used or should be changed for the *new solution that is being proposed (the ""to be"" situation*). Document analysis *assumes *that the existing documentation is *easily available and up-to-date*. If the information is not up-to-date and valid, it will be of little help to a business analyst in eliciting or confirming the requirements. The ""existing stuff"" is information prepared for another project or purpose but relevant to your requirements development efforts. This type of secondary data can be quite helpful during requirements elicitation. To *conduct document analysis*, the business analyst steps through three stages: preparation, the actual document review, and wrap-up. *Preparation involves locating and evaluating* the relevant system and business documentation. During *document review, you study the material, identify the relevant details* (technical and business), and document them along with any questions you might have to follow up on with the subject matter experts (SMEs). *Wrap-up is the ""get answers, review, and confirm""* step."

Techniques: Vendor Assessment

"*Recommended for Define Design Options* *Vendor assessments allow you to assess an external vendor's ability to provide all or part of your solution*. You *look at* their *technical ability, financial stability, staff skills, and reputation in their workspace*. External vendors are often involved in the design, construction, implementation, and maintenance activities on our projects. Here is a *quick list of things you may want to consider*: Knowledge and expertise Experience, reputation, and stability Licensing and pricing models Product reputation and market position Contractual terms and conditions Vendor assessments are used to ensure that your vendors are reliable and that they will be able to meet your expectations"

Techniques: Benchmarking and Market Analysis

"*Recommended for FSD* Benchmarking and market analysis studies target using new and different methods, ideas, and tools to improve organizational performance. When conducting such a study, the business analyst *compares their organization's strategies, operations, and processes against the best-in-class strategies, operations, and processes of their competitors and peers*. After determining *how other companies achieve superior performance*, the organization can *then propose projects to reproduce solutions* that work elsewhere."

Techniques: SWOT Analysis

"*Recommended for FSD* Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis lets you look at the organization's current capabilities relative to meeting a new business need. There are two dimensions to this analysis: the *internal strengths and weaknesses* of the organization and the *external opportunities and negative threats* that are in play. SWOT analysis is done using a matrix or a grid. Stakeholders brainstorm and complete each quadrant of the grid and then analyze the resulting data to make sure that the business need and its environment are well understood. Solutions for meeting the business need may then be proposed and considered."

Technique: Prioritization

"*Recommended for RCLM: Prioritization* The prioritization technique is a catchall for several approaches to prioritizing requirements. The *priorities may be based on risk, value, implementation difficulty, or other criteria*. The *four approaches are grouping, ranking, time boxing/budgeting, and negotiation*. The selection of approach is up to the business analyst team and may change to fit the current situation and the needs of the stakeholders. Business analysts may find themselves using one or more approaches to prioritize their project requirements. Let's step through each approach in more detail. *Grouping * This common prioritization approach classifies requirements or business analysis information according to predefined categories, such as *high, medium, and low*, or the *Must, Should, Could, and Won't* categories of MoSCoW analysis. Grouping helps you to reach a common understanding with your stakeholders on the importance they place on the delivery of each requirement. Requirements might move between prioritization groups as you iteratively apply the technique and discuss your options with key stakeholders. *Ranking * Ranking orders the requirements or business analysis information from what is *most important to what is least important*. Ranking can be explicitly sequenced *to create a product backlog* of requirements in an ordered list. One recommendation is to rank your requirements so that 25 percent of those requirements are Must, 25 percent of the requirements are Should, 25 percent are Could, and the remaining 25 percent are Won't. If these percentages don't work for you, you can select numbers that fit your project and your set of requirements to prioritize. *Time Boxing/Budgeting * Time boxing/budgeting prioritizes requirements for implementation *based on the allocation of a fixed resource*, usually *either time (time boxing) or money (budgeting)*. This technique is most effective when it is framed by the defined solution scope for the project. *Negotiation * This approach requires *establishing consensus * among the involved stakeholders regarding the prioritized requirements. Conflict management and negotiation skills can be used to encourage the group to reach consensus."

Techniques: Functional Decomposition

"*Recommended for Requirement Architecture* *Functional decomposition breaks down or decomposes the solution scope into its component parts* based on a group of related functionalities. You *can then create a model of what needs to be done to deliver all or part of the solution*. Functional decomposition is an excellent way to break things into manageable pieces and to understand the relationships between those pieces. Functional decomposition is typically used during requirements analysis to break an organizational unit or the solution scope into its component parts. *Each resulting part may have its own set of requirements*. This is similar to building a work breakdown structure (WBS) for a project where you break down or decompose the project scope into phases, work packages, and deliverables. The BABOK® Guide recommends breaking things down until the parts found at the lowest level cannot be broken down further. You should then analyze each part independently."

Techniques: Organizational Modelling

"*Recommended for Requirement Architecture* *Organizational modelling is used during requirements analysis to describe the organizational units, the stakeholders, and the relationships between them*. This allows you the *opportunity to structure* your project *requirements based upon the needs of each stakeholder group*. Most of us have seen an organization chart showing the hierarchy of an organization. This is an example of an organizational model. *The model defines the purpose and structure of an organization* or an organizational unit. When this technique is used for business analysis, an organization chart that shows the organizational units, lines of reporting, the roles, and the people in those roles is basically built."

Techniques: Business Rule Analysis

"*Recommended for S&M Req + Designs* Business rules analysis *allows you to define the business policies and rules that govern business decisions and operations* in your organization. *Business policies are directives that support business goals*. *Business rules, by contrast, are actionable and testable directives that support the business policies*. Complex business rules are often represented using a decision tree or table. Business rules require you to create or to use a defined glossary of terms and an understanding of the relationships between them. There are two types of business rules: *Definitional business rules * *Behavioral business rules * *Behavioral business rules guide the actions of people who work in your organization* and are typically enforced by organizational policies. *Definitional business rules structure and categorize the knowledge and information found in your organization*. When analyzing, stating, and managing business rules, you should do the following: State the business rules using the appropriate terminology. Keep the business rules independent of their implementation. Document business rules separately from how they are enforced. State business rules at the atomic level using a declarative format. Separate business rules from the processes that the rules support or constrain. Maintain the business rules in a way that allows for changes as business policies change. *To effectively perform business rules analysis, you need to have a data dictionary and glossary for your specific project or your organization.*"

RADD: REQ ARCH: Input

"*Requirements (Any State)* The focus of requirements analysis and design *takes the requirements provided during elicitation and derives the real requirements* for your project. The *requirements are analyzed, documented, and modelled based on the requirements architecture* you create with this task. *Information Management Approach * Created during Business Analysis Planning and Monitoring, the information management approach *defines how business analysis information will be stored and accessed*. *Solution Scope * The selected *requirements architecture must describe the solution scope fully and from all stakeholder perspectives*. *Think of the solution scope as the frame for the more detailed picture you are painting with your project requirements*."

RLCM: APPROVE REQ: Output

"*Requirements (Approved)* *Designs (Approved)* Remember that proposed changes to requirements and designs are not just communicated from the business analyst to the stakeholders. They *must be received, understood, and acknowledged* by those stakeholders *in order for effective requirements communication* to have taken place."

RLCM: MAINTAIN: Output

"*Requirements (Maintained)* *Designs (Maintained)* Maintained and reusable requirements and designs often become part of the organizational process assets (OPAs) and the enterprise architecture of an organization."

RLCM: PRIORITIZE: Outputs

"*Requirements (Prioritized)* *Designs (Prioritized)* Prioritized requirements and prioritized designs are requirements that have been *assigned a priority attribute* indicating their relative importance to the stakeholders and to the organization. Sometimes you will find yourself assigning a priority value to a group of related requirements as opposed to a single, standalone requirement. Once you have prioritized your requirements, it is time to assess the risks inherent to those requirements."

RADD: VALIDATE: Input

"*Requirements (Specified and Modelled)* Specified and modelled requirements and/or designs are produced in the form of text, matrices, and/or diagrams. They *take the business analysis information from the stakeholders and make sense of what was said*. Validation activities may be done on any type of requirements or designs. *Sometimes, validation activities begin before verification activities are complete.*"

RCLM: TRACE: Output

"*Requirements (Traced)* *Designs (Traced)* Clearly defined relationships to the other requirements and designs within the solution scope. Used in Define Design Options"

RLCM: APPROVE REQ: Inputs

"*Requirements (Verified)* Verified requirements provide a *set of requirements that are of sufficient quality* to be *used as a reliable body of work* for further specification and development. *Designs* This set of designs is ready to be used for further specification and development."

RLCM: TRACE: Inputs

"*Requirements * All requirements can be traced to other requirements on a project. According to the BABOK® Guide, ""*other requirements"" include goals, objectives, business requirements, stakeholder requirements, solution requirements, and transition requirements*. All solution and stakeholder requirements must be traceable to a business requirement. *Requirements may also have traceability relationships with solution components, business rules*, and other work products. *Designs* Designs are usable representations of solutions. They can be *traced to all types of requirements, to solution components*, and to other work products."

RADD: DDO: Allocate Requirements

"*Requirements allocation assigns requirements to solution components and releases*. *One goal* of requirements allocation *is to maximize benefits and reduce costs for implementing the solution*. Requirements are typically allocated between organizational units, job functions, solution components, or solution releases. This *activity is ongoing, beginning when the solution approach is determined and ending after design and implementation of the solution*."

RLCM: ASSESS R CHANGES: Outputs

"*Requirements change Assessment* *Designs change Assessment* A Requirements or Designs Change Assessment is the output of this task. This assessment contains a recommendation to approve, modify, or deny a proposed change to either area based upon the results of the impact analysis."

RCLM: MAINTAIN: Inputs

"*Requirements* Requirements that are *maintained for reuse typically describe the current state* of an organization and the systems and solutions that are being used to address a business need. *Designs* Designs that are maintained for reuse also *describe the current systems and solutions that are being used*. They can be maintained across their life cycle."

RLCM: PRIORITIZE: Inputs

"*Requirements* To prioritize requirements defining stakeholder needs and capabilities, a business analyst needs to have those requirements available. Requirements ready for prioritization can be in the form of text, matrices, or diagrams. *Designs * To prioritize any designs associated with the solution, business analysts need to have those designs on hand in the form of text, prototypes, or diagrams."

BAMP: PBAIM: Select requirements attributes.

"*Selecting requirements attributes for a project is an important step*. Attributes are intended to be of *assistance in the ongoing management of requirements* across the project life cycle. Experienced business analysts know how to select the requirements attributes that add value to the requirements information for their project. Attributes allow the team to associate information and add context to individual requirements or groups of requirements. The BABOK® Guide recommends that the business analysis team consider using one or more of the common requirements attributes: Absolute reference Unique numeric or text identifier for each requirement Author Name of the person who wrote the requirement if you have any questions later Complexity Difficulty in implementing the requirement Ownership Individual or group that needs the requirement Priority Indicates the relative importance of requirements so you can decide which requirements should be implemented first Risks Associated with meeting or not meeting the requirements Source Origin of the requirement if you need more information later Stability Indicates requirements maturity and if you can start work on it Status Proposed, accepted, verified, postponed, cancelled, or implemented Urgency How soon the requirement is needed"

Techniques: Sequence Diagrams

"*Sequence diagrams* can be thought of as if they were *tracking the information flow between two people having a conversation*. They *show how the information gets passed back and forth between the two people*. Sequence diagrams are *commonly used during object-oriented analysis* to *show how classes and objects interact during a scenario.* You can also use them to show *how the user interface components* or software components *interact in your solution*. In a nutshell, sequence diagrams *shows stimuli flowing between objects*. The *stimulus is a message*, and the *arrival of the stimulus* at the object is *called an event*. Each *object name is in a rectangle* with a single vertical *line* drawn beneath it *called a lifeline*. *Messages* are depicted *starting at the top of the lifeline and moving down that lifeline over time*. There are *two ways to send messages* between objects: asynchronous and synchronous. *Synchronous* flow *transfers* a message to the receiving object *and waits for a response* or return message *before it can do anything else*. *Asynchronous* flow *allows the sender to continue* with its own processing after sending the message to the receiver."

SE: APM: Output

"*Solution Performance Analysis* The solution performance analysis *describes how the solution is performing relative to the business goals and objectives* that led to its creation and implementation. It *contains the results of analyzing the solution performance measurements that were collected*. The deliverable also contains the business analyst's recommendations relative to the results of the measurements. The *focus is on recommendations to solve any performance gaps* as well as leveraging opportunities to create more value."

RADD: APotVal: Output

"*Solution Recommendation* The solution recommendation *identifies the most appropriate solution based upon evaluating all defined design options*. The recommended solution targets *maximizing the value provided to the enterprise*."

"SE: MSP: Validating solution performance measures"

"*Solution performance measures should be validated with key stakeholders* to *ensure* the *measures are useful and relevant*. More detailed performance *measures should align with the higher-level performance measures* for the solution or for the enterprise."

BAMP: PBAIM: Plan for requirements reuse.

"*Some requirements* developed for a particular project might also be candidates for *long-term use or reuse* by the organization. The requirements that you choose to maintain might relate to infrastructure, hardware, software, or operational capabilities that the organization must meet on an ongoing basis versus just for your particular project. *Common features or services used across multiple* systems or process are also *good candidates for reuse*. *Reusable requirements are structured, stored, and accessed* by other business analysts in the organization. This ""ease of reuse"" requires advance planning and a common requirements storage repository. The BABOK® Guide lists several types of requirements that can be reused across projects within an organization. Regulatory requirements Contractual obligations Quality standards Service level agreements (SLAs) Business rules or processes Product requirements"

RADD: VERIFY: Inputs

"*Specified and Modelled Requirements* Specified and modelled requirements and/or designs are *produced in the form of text, matrices, and/or diagrams*. They take the business analysis information from the stakeholders and make sense of what was said."

Tasks: Requirements Analysis and Design Definition

"*Specifying and modeling* requirements and designs *Verifying* requirements and designs *Validating* requirements and designs *Defining* the *architecture and structure* of requirements *Defining* *solution options* *Analyzing value* and *recommending a solution*"

BAPM: PSE: Output

"*Stakeholder Engagement Approach* According to the BABOK® Guide, the following information about your business analysis stakeholders should be included in the stakeholder engagement approach: Names Titles Characteristics Location Special needs Authority levels Number of individuals in each role Description of stakeholder influence and interest Collaboration approach Communication plan A number of stakeholders are involved with conducting stakeholder analysis for the business analysis activities of a project. Remember that the business analyst *shares responsibility* for analyzing business analysis stakeholders *with the project manager*. This means that any stakeholder analysis results *should align with the project stakeholder analysis* results in both structure and content. Key business analysis stakeholders may be able to recommend other stakeholders to include in the stakeholder analysis results. This includes the customers, domain SMEs, end users, the project manager, sponsors, the regulator, and suppliers."

Techniques: State Modelling

"*State modelling shows a sequence of states* that an *object, entity, or concept goes through during its lifetime*. These models also *define the events that cause a transition* between these states. The functionality and behavior of a particular object will be different based on its current state. For example, a mainframe computer system in batch-processing mode may be unable to process real-time queries from a user during the time it is in that state. *State models are also called state machine diagrams*. A state represents a unique condition that an object can be in or a status that the object may have. All states for an object are mutually exclusive, which means that an *object can be in only one state at a time*. All state machines have an initial state and any number of intermediate or end states. Transitions define the behaviors that move an object from one state to another state. *They are often triggered by completed activities or events.* Here is a simple state machine for requirements development activities using the BABOK® Guide. The transitions for the requirements that are under development are the knowledge area tasks that change the state of those requirements as you work on them. For example during requirements analysis, the analyzed solution requirements (those that have been specified and modelled) go through a quality check using the verify requirements task. When the requirements emerge from this task, they have changed to a new state and become the verified solution requirements; are omitted or deferred to a later release; were determined to be out of scope, unnecessary, or unworkable; or marked as failed as a solution requirement for some other reason."

SE: MSP: Collecting solution performance measures

"*Statistical sampling techniques are often used* to collect solution performance measures. Be sure to *consider the volume or sample size* for the initiative so you collect enough data and achieve accurate results. The *frequency and timing of measurements are also critical*. *Watch the currency of your data* as well. Measurements that are *more current tend to be more representative* of solution performance than older data. Additionally, *effective business analysts often use qualitative measures* to estimate the value delivered by a solution with stakeholders."

RLCM: TRACE: Documenting and maintaining the traced requirements

"*Traceability is usually achieved* by *putting* the requirements *in a table, spreadsheet, or tool to manage the tracing activities*. Although traceability can be done manually using a spreadsheet, complex projects often require a more streamlined approach. Many business analysts prefer to use a requirements management tool or a configuration management system to trace large numbers of requirements. Implementing traceability for project requirements demands work from the business analysis team, but it's worth the effort. Traceability is used for many things on a project. For example, *traceability allows the business analyst to thoroughly evaluate the impacts of a change request to both the requirements and the solution components*. In another example, tracing requirements back to the business needs *shows the BA how those objectives will be accomplished*. This also allows the business analyst to *confirm that all the business needs are included in the solution scope and the solution components*. In one last example, traceability *allows the BA to trace the subset of requirements that are allocated to each of the solution components*."

Techniques: User Stories

"*User stories* are commonly *used for change-driven requirements development*. They *briefly describe the functionality your solution provides to its users*. You *should define acceptance and evaluation criteria for each user story* so you *can prove that its functionality has been met by the solution*. Business analysts write *user stories from the user's point of view*. User stories contain the following: The *actor* or stakeholder benefiting from the user story A high-level description of the *functionality* in the story The *business benefits* that the story delivers User stories create customer ownership of requirements by having actual users write stories about what the solution needs to accomplish for them. You can use these stories to support your iterative, incremental development environments. They *allow you to define key features of the solution that can be implemented* by the project team in one to three weeks. (Remember, *user stories for Agile* projects are for *small bites of projects, typically time bound, and short in duration*.)"

RADD: VALIDATE: Output

"*Validated requirements * *are stakeholder, solution, or transition requirements that are aligned with the business goals and objectives* found in your project's business requirements or business case. These requirements benefit the organization and will provide value when they are implemented by the resulting solution. Remember that *validated requirements fall within the framework of your defined solution scope*. Validated requirements are *used as an input* to two business analysis tasks, including *define design options & measuring solution performance* as part of the Solution Evaluation knowledge area."

RADD: VERIFY: Output

"*Verified requirements* *are well-written requirements* that can be *used in other project work, such as technical design*. Verified requirements must be of reasonable quality so that the team *can use them and not worry about having to redo things later*. Verified requirements are *used as input* to several business analysis tasks, including *validating requirements and communicating verified requirements with your stakeholders* for their review or approval."

RADD: REQ ARCH: Requirements Viewpoints and Views

"*Viewpoints are templates for specific stakeholders* groups, *defining how requirements will be represented, organized, and related for each* group. *Viewpoints typically address the types of models and model notations to be used, attributes to be included, and relationships to be identified and maintained*. Requirements documents using a set of viewpoints from different perspectives make a stronger set of requirements for your project. The *actual set of requirements* and designs for a solution *from a particular viewpoint are referred* to as a *view*. *A collection of views makes up the requirements architecture* for a solution. *Viewpoints tell* you *what information to provide for each stakeholder group* while *views describe the actual requirements and designs that are produced*."

RLCM

"*managing and sharing the project requirements and designs with the project stakeholders* *begin as soon as requirements development work begins* for a project. They accompany the work being done in any knowledge area that develops requirements, including Strategy Analysis, Requirements Analysis, Design Definition, and Solution Evaluation. The requirements life cycle in this knowledge area works like this: *Begins* with the *representation* of a business need as a *requirement* *Continues through* the *development of a solution* *Ends* when the requirements and the resulting solution *are retired*"

RADD: REQ ARCH: Output

"*requirements architecture* defines an *organized structure* for *stakeholder and solution requirements* and the *documented relationships between them*. The *requirements structure* defines *the scope of each specific model or set of requirements*, and *provides a location where each specific requirement can be found*. The *requirements structure is not the same as traceability*. *Traceability links related requirements*. The *requirements structure tells you where the specific requirements for a project can be found*."

RADD: DDO

"A *design is a usable representation of a solution*. *For example, a text description, a screen mockup, or prototype that represents a solution*. A *design option is the possible form a solution might take*. There are often multiple design options or alternatives that can satisfy a set of requirements, *which a business analyst might represent as three different prototypes*. Remember that *design options are tactical in nature versus the more strategic change strategy (solution) they will be implementing*. Over time, *trade-off decision making* is required in order *to choose the best design option* to get the job done and achieve the desired future state. Is It a Design or a Solution? As you become more deeply involved in a project, it's easy to become lost in the details. Remember, the BABOK® Guide defines terms to help you maintain clarity. *Design* A usable representation of a solution *Solution* A specific way of satisfying a need"

SE: APM: Risks

"A *lack of performance measures* for a solution is considered a solution *performance risk*. *Performance measures may uncover new risks* to the solution or the enterprise. The new risks are identified and managed just like any other risk."

Solution vs Solution Components vs Release

"A *solution is a set of changes to an organization's current state enabling the organization to meet a business need*, solve a problem, or take advantage of an opportunity. *Solutions are made up of solution components*, the parts of a solution that span the enterprise architecture of the organization, such as new business processes, new software applications, or new hardware. *Each solution component implements a subset of the solution requirements*. *Solutions are typically implemented in releases*. A *release is the distribution of all or part of a scheduled operational solution*, such as a release consisting of software application code, related documents, and support materials."

RADD: S&M REQ: Other Techniques

"Acceptance and Evaluation Criteria Acceptance criteria *define the requirements that must be met for a solution to be acceptable* to stakeholders. Evaluation criteria are the measures used to assess those requirements. Business Capability Analysis This technique is used to *describe* what an enterprise or part of an *enterprise is able to do*. These business capabilities *represent features or functions* of the enterprise. Business Model Canvas This diagnostic planning tool can be used to *describe the rationale for requirements relative to* the current state of the business. Concept Modelling Concept models are used to *define terms and relationships* that are relevant to proposed change and the enterprise where the change is taking place. Data Dictionary Data dictionaries are technical in nature and are used to *define data elements, their meanings, and their allowable values*. Building a data dictionary for your project might be a necessary step in your requirements specification and modelling activities. Decision Modelling Decision models *represent decisions and the elements of decision making* that are required in a particular model. Functional Decomposition *Functional decomposition allows* you to systematically *break down the solution scope components into smaller pieces* and more detailed requirements based on similar or related functionalities or features. Glossary *Glossaries allow you to document key business terms along with their definitions*. Much of the information that goes into the glossary will be a result of your business, stakeholder, solution, and transition requirements development efforts. Interface Analysis *Interface analysis* establishes a basis for interoperability by *recognizing inputs, outputs, and key data elements* that *enable your solution and its components to interact with everything else* that is already out there. Organizational Modelling Most of us have seen an *organization chart* showing the hierarchy. This is an example of an organizational model. The model defines the purpose and structure of an organization or an organizational unit. Prototyping Prototyping is a *great way to add additional details to your solution interface requirements* and *integrate* those requirements *with the other requirements* defining the new solution. Essentially a *prototype is an initial or preliminary version of a solution* or system. Roles and Permissions Matrix This *matrix separates and models the user duties* and external interfaces associated with a specific solution. Root Cause Analysis This technique is used to *model the root causes of a problem* or need as part of the rationale for a change or a new solution. Scope Modelling Scope models *visually show stakeholders the boundary of the solution scope*. During requirements analysis, the business analyst can place capabilities either inside or outside of this scope. *Stakeholder List, Map, or Personas* Identifying stakeholders and their roles is a *key part of analyzing and specifying requirements*. Use the stakeholder list, map, or personas technique to help you do a thorough job with identifying your stakeholders and their characteristics."

RADD: VALIDATE: Techniques

"Acceptance and Evaluation Criteria Acceptance criteria are the *quality metrics that must be met by a requirement*, a solution component, or the solution itself *in order to be accepted* by the project stakeholders. Evaluation criteria are used to measure how successful a deployed or operational solution is in providing business benefits. Document Analysis Document analysis is used during requirements validation activities to *identify previously documented business needs*. Financial Analysis This technique allows the business analyst to *define and confirm the expected financial benefits* associated with the validated requirements. Item Tracking Item tracking makes sure that *any problems or issues related to validation are managed and resolved* as part of the issue management process. Metrics and Key Performance Indicators (KPIs) Metrics and KPIs are used to *select and define performance measures* for your requirements, solution components, or solutions. Reviews This technique is used frequently by business analysts *seeking agreement from their stakeholders* that the requirements meet their needs and can be considered validated. Risk Analysis and Management *Risks are generated when you make assumptions about your requirements*, such as achieving the potential business benefits or building a solution that adds value to the organization. Risk analysis might result from the need to evaluate those assumptions and the associated potential risks."

RADD: VERIFY: Techniques

"Acceptance and Evaluation Criteria As part of requirements verification, you must *determine the quality criteria against which you will evaluate your requirements*. This gives the folks verifying your requirements the metrics to use in their evaluation of them. Item Tracking Item tracking is one *component of issue management*. This technique allows a business analyst to maintain focus on business-analysis-related problems and issues across the project life cycle. Any problems identified during requirements verification may be tracked using this technique. Metrics and Key Performance Indicators (KPIs) Metrics are quantifiable indicators used to measure progress. KPIs are specific numerical measurements that represent the degree of progress toward something. Both are used to *identify and evaluate the quality of requirements* and/or designs. Reviews Reviews are frequently used to *inspect requirements documentation and identify requirements that are not of acceptable quality*. A review is a meeting with a tour guide. Your destination is the verified requirements, and your meeting agenda will walk you through the possibilities in order for the group to evaluate and revise the requirements."

RADD: APotVal: Techniques

"Acceptance and Evaluation Criteria One best practice is *defining measurable acceptance criteria for each of your project releases*. The criteria define the set of requirements that must be met in order for your release and its accompanying capabilities *to be considered acceptable* to its key stakeholders. *Test cases will be written to verify the release* using this defined acceptance criteria. Backlog Management The backlog records, *tracks, and prioritizes remaining work*. Managed backlogs put work items at the top of the list with the highest business value, making these items the next things to be worked on. Brainstorming Brainstorming allows a business analyst to *identify potential business benefits of the requirements* in a collaborative fashion with stakeholders. Business Cases Be sure to *compare the design options, their potential value to the enterprise, and the resulting recommendations against the business goals* and initiatives contained in the business case. Business Model Canvas This planning and monitoring tool is *used to understand strategy and initiatives relative to the current state* of the business. Decision Analysis Decision analysis allows you to *examine and model the costs and benefits* of different requirements allocation schemes *before making or recommending a particular decision*. Estimation Estimating techniques are used to forecast the cost and effort of meeting requirements and to *provide financial information with which to rank the design options* and select the option to recommend. Financial Analysis There are many financial techniques business analysts can use to *evaluate the financial return of different design options* and choose the best possible return on investment (ROI). Focus Groups Focus groups allow you to get stakeholder *input on which design options best meet the requirements* and to understand the stakeholder's value expectations relative to the solution. Interviews Interviews are a face-to-face way to get stakeholder* input on which design options best meet the requirements* and to understand the stakeholder's value expectations of the solution. Metrics and Key Performance Indicators (KPIs) As part of *analyzing the potential value of design options*, business analysts create and evaluate the measurements used to determine value. Risk Analysis and Management This technique *identifies and manages risks* that could affect the potential value of the requirements, the design options, and the resulting solution. Survey or Questionnaire Surveys and questionnaires allow for stakeholder *input on which design options best meet the requirements* and understand the stakeholder's value expectations. SWOT Analysis Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis is another technique that can be used to i*dentify areas of strength and weakness that impact the solution value*. Workshops Workshops or *structured reviews are an excellent way to get stakeholder input on which design options best meet requirements* and understand the stakeholder's value expectations."

RLCM: APPROVE REQ: Techniques

"Acceptance and Evaluation Criteria Stakeholders and decision-makers *define acceptance and evaluation criteria in order to make decisions* regarding proposed requirements and designs changes. Decision Analysis Decision analysis allows you to *examine and model the consequences of different decisions before making* a well-informed decision. When resolving issues and evaluating proposed changes, business analysts *use decision analysis to resolve issues and gain agreement*. Item Tracking Item tracking allows *tracking of any issues* raised by stakeholders during the agreement and approval activities. Reviews Reviews are used to *evaluate requirements* and designs *relative to a proposed change*. Workshops Requirements workshops are structured meetings where a selected group of *stakeholders works together to define or refine a set of project requirements*. During a requirements workshop, specific requirements may be presented to *make everyone familiar with the existing solution scope and the current requirements*."

SE: ASL: Techniques

"Acceptance and Evaluation Criteria These *criteria define the acceptable solution performance*. The degree of variance in the collected data is used in analyzing the solution performance and assessing solution limitations. Benchmarking and Market Analysis Benchmarking can be used to *observe the results of other organizations using similar solutions*. This includes looking at risks, trends, and variances relative to the solution being analyzed. Business Rules Analysis This technique *shows the current business rules and the changes to those rules that are required to achieve the potential value* of the change. Business rules may limit or constrain solution performance or impact value realization. Data Mining This technique is used to *identify factors that may constrain or limit solution performance*. The collected data being analyzed and reviewed typically includes performance measures, trends, issues, and variances. Decision Analysis Decision analysis allows you to *examine and model the costs and benefits of different requirements allocation schemes* before making or recommending a particular decision. Interviews This technique is used with individuals or small groups. The business analyst is speaking with them to *determine the problems or limitations of a solution* as well as how the solution's performance is perceived. Item Tracking This technique is used to *record and manage stakeholder issues related to solution limitations* that are impacting value realization. Lessons Learned Lessons learned could be *used to look back and discover what happened along the way to limit the solution* and its ability to deliver value. Risk Analysis and Management *Risks are identified and managed on an ongoing basis* during solution performance analysis. Activities include risk identification, analysis, response planning, and management. Root Cause Analysis Root cause analysis is *used to determine the underlying cause* of a significant performance variance within a solution. Survey or Questionnaire Surveys and questionnaires provide you with a vehicle to *gather quantitative and qualitative information from large numbers of stakeholders* during your problem analysis efforts."

SE: APM: Techniques

"Acceptance and Evaluation Criteria These criteria *define the acceptable solution performance*. The degree of variance in the collected data is used in analyzing the solution performance. Benchmarking and Market Analysis Benchmarking can be *used to observe the results of other organizations* using similar solutions. This includes looking at risks, trends, and variances relative to the solution being analyzed. Data Mining This technique is used to collect and analyze the solution performance data. The *collected data typically includes performance measures, trends, issues, and variances*. Interviews This technique is used with individuals or small groups. The business analyst is speaking with them *to determine the expected value of a solution as well as how the solution's performance is perceived*. Metrics and Key Performance Indicators (KPIs) Metrics and KPIs are *defined and used to measure and analyze solution performance*. The measures are used to judge how well the solution contributes to achieving business goals. Observation Observation allows you to observe the solution in action. This technique may reveal problems or issues that have not been noticed or reported. *It may also reveal issues that are not obvious in the collected data.* Risk Analysis and Management Risks are identified and managed on an ongoing basis during solution performance analysis. *Activities include risk identification, analysis, response planning, and management.* Root-Cause Analysis Root-cause analysis is *used to determine the underlying cause* of a significant performance variance within a solution. Survey or Questionnaire Surveys and questionnaires *provide you with a vehicle to gather quantitative and qualitative information* from large numbers of stakeholders about how they perceive a solution performs."

adaptive approaches

"Adaptive planning approaches are used on projects where *many small iterations are defined and developed* en route to the final result. Adaptive business analysis approaches target *rapid delivery* of business value. To achieve that goal, they *accept greater uncertainty (risk)* relative to the overall solution delivery. This is an *exploratory approach* to finding the best solution, using *short iterations to incrementally develop* components of the solution. Adaptive approaches that you may be familiar with include *agile *development methods and many *continuous process improvement projects* being done in organizations. One key feature of adaptive approaches is that they *use flexibility to control project risk.*"

BAPM: BAPI: Elements: Recommend actions for improvement

"After business analysts have the business analysis performance measures in hand for a particular period of time, they can *assess those measures and determine whether any problems or improvement opportunities exist*. Experienced business analysts know they *must engage key stakeholders to assist* the business analysis team in *identifying any corrective actions or preventive actions* that might be required. *Corrective actions occur after the fact* and are ways to *reduce the negative impact* of an event. In contrast, *preventive actions focus on reducing the probability of a negative event happening in the first place*. There is also a positive side of the coin: *improvement actions*. These actions *occur when you want to increase the probability or impact* of events with *positive* impacts on business analysis work and deliverables. Exam Spotlight Corrective and preventive actions are not the same thing. *Corrective actions are steps taken to remove the causes* of existing nonconformities or errors *after they occur*. *Preventive actions try to stop events from happening* in the first place."

SA: FSD

"After the business analyst analyzes and understands the current state of the enterprise relative to the business need, the next step is to define the new capabilities required to address that business need. You must determine whether the organization's existing capabilities can meet the business need or whether additional capabilities and conditions are necessary. Typically, *projects begin when organizations have to add new capabilities* to the mix *in order to meet a business need*. Defining the future state allows the stakeholders to *understand the potential value* of a range of solution options. This *leads to making an informed decision* and *selecting the best possible solution* as part of the change strategy. We will look at the change strategy in more detail later in this chapter. According to the BABOK® Guide, the future state is defined to a level of detail that: Allows for *competing strategies to be identified and assessed* Provides *clear definition of outcomes* satisfying the business need Details the *scope of the solution space* Allows for *value* associated with the *future state to be assessed* *Enables consensus* to be achieved among key stakeholders"

BAPM: PBA: Elements: Decide Formality and Level of Detail

"All expected business analysis *deliverables across the project life cycle* should be *defined in the BAA* (business analysis approach). If you forget a particular deliverable that is due later in the life cycle or change your mind about one that has already been defined, you can always revisit the business analysis approach and make the necessary changes. Predictive approaches are usually quite formal and produce very detailed document sets requiring formal approval. Adaptive approaches can be quite informal, often limiting the documentation to a bare minimum. Project work and business analysis *deliverables are approved informally through team interaction and feedback*. *Remember that adaptive business analysis approaches must have well-prioritized requirements because a prioritized requirements list may well be the only required project documentation.*"

BAMP: PBAG: Plan the prioritization approach

"All requirements and designs are not created equal, nor do they deliver equal value to the business and the stakeholders. *Business analysts are responsible* for *establishing the requirements*, the *design prioritization* process technique, and the *level of formality* for their projects. They are also responsible for *defining the prioritization scheme* and process as early in the project as possible. This enables the project *stakeholders to understand and buy into the way* the business analysis team will prioritize the project requirements and designs at all levels of detail and focus, including the business, stakeholder, solution, and transition requirements found in the BABOK® Guide."

SE: AEL

"Another interesting task in the Solution Evaluation knowledge area is assessing the enterprise limitations of a solution. As a business analyst, you are an agent of change; you shepherd new solutions from conception to completion. The trick is proving that the operational solution delivers its potential value to the enterprise. Assessing enterprise limitations identifies the root causes of specific factors and describes how those factors can limit a solution's value realization potential. Exam Spotlight Be sure you recognize what an enterprise limitation for a solution or solution component might be on your exam. *Enterprise limitations include* the following factors: *Culture Operations Technical components Stakeholder interests Reporting structures* Many factors external to a solution may impact its ability to deliver business value. Frequently, solutions operate across organizational boundaries within the enterprise with many interactions and interdependencies. Solutions may depend upon external factors, such as outsourcing your solution's servers to a third-party vendor. Enterprise limitations can be assessed at any time during the solution life cycle, from component development to full solution implementation. Existing, operational solutions can also be assessed if the need arises."

BAMP: PBAIM

"BA information is *formally documented* in the business analysis *information management approach*. Once the business analysis team *establishes* the information management approach for a project, the approach is *not expected to change significantly* across the project life cycle. However, it should be revisited at each phase of the project to ensure that it is being followed and that no changes are required for the work that will be started or based on business analysis performance to date. To plan for information management, the business analyst must understand the organizational process needs and objectives that apply to the project. These *needs and objectives may include compatibility with other organizational processes, constraints on time-to-market, regulatory and governance framework compliance, a desire to evaluate new approaches to solution development, or other business objectives.* In some organizations, an information management process or approach is already in place. If that is the case, the business analysis team needs to review the existing process and tailor it to fit their current project and environment. Remember that the business analysis team needs to develop project requirements and designs before managing them across the project life cycle. Note One *important aspect of business analysis information management* is *communicating requirements and design information* across the project life cycle. It is essential to elicit the right information from key stakeholders about the capabilities of the desired solution and to validate that the analyzed requirements and design information is correct and complete."

RLCM: PRIORITIZE: Techniques

"Backlog Management Ranked requirements are often stored in a product backlog consisting of *prioritized requirements in an ordered list*. This backlog can be used to *compare requirements* to be prioritized. Business Cases The business goals and objectives found in the *business case are used to *determne the importance of requirements* during the prioritization process. Decision Analysis You can use this *technique to examine and model the consequences of different decisions* before actually making a well-informed decision. When prioritizing project requirements, business analysts can use decision analysis to identify and assess high-value requirements. Estimation *Cost estimates are often used as the basis* for requirements prioritization. This can occur early in the prioritization process or later when solution implementation specifics are being considered. Financial Analysis These techniques can be used to assess the *financial value of a set of requirements* and to look at how implementation timing can impact that value. Interviews Business analysts use interviews to understand *how individual stakeholders* or small stakeholder groups *want to prioritize requirements*. Item Tracking Item tracking allows for *tracking of any issues* raised by stakeholders during prioritization activities. Risk Analysis and Management *Risky requirements* often need to be *investigated further to determine what should be done* with them. Some organizations prefer to implement risky requirements early on to minimize the costs of failure, while others prefer to defer risky requirements until later in the life cycle in order to decide what to do with them. Workshops Business analysts use workshops to *understand the basis for how larger stakeholder groups want to prioritize* requirements."

SE: MSP: Techniques

"Benchmarking and Market Analysis Benchmarking can be used to *define acceptable measures* for a solution relative to the potential value defined in the future state description and the change strategy. Business Cases *Business objectives are defined in the business case for the project. Performance measures* for the resulting solution *can also be found here*. Data Mining This technique is used to *collect and analyze the solution performance data*. Data mining is particularly useful when there is a lot of data to analyze relative to a particular solution. Decision Analysis Decision analysis allows you to *examine and model the consequences of different decisions* before actually making or recommending a particular decision. Effective decision analysis requires you to effectively structure the decision problem and process, keeping in mind any relevant values, goals, and objectives. Focus Groups Focus groups are often used to *give assessment, insight, and impressions* of a solution's performance. The results of using this technique are subjective in nature. Metrics and Key Performance Indicators (KPIs) Metrics and KPIs are defined and *used to measure solution performance*. These measures are aligned with enterprise measures, goals, and objectives. Nonfunctional Requirements Analysis Nonfunctional requirements *define the expected characteristics of a solution*. Be sure to use this technique and its results when defining solution performance measures. Observation Observation is used to *provide feedback on stakeholder or user perception of a solution* or to reconcile contradictory results. Sometimes it makes things clear when you watch them personally and see what is going on. Prototyping Prototyping is commonly *used to simulate a new solution prior to constructing that solution*. Performance measures can be defined, collected, and analyzed using the prototype as a baseline. Survey or Questionnaire Surveys and questionnaires are often *used to collect information from stakeholders about solution performance*. They are particularly useful when you are seeking input from a large number of stakeholders. Use Cases and Scenarios Use cases and scenarios *define the expected outcomes of a solution* or a solution component. Performance measures can be defined, collected, and analyzed using the use case or scenario as a baseline. Vendor Assessment Vendor assessments allow you to *assess an external vendor's ability to provide all or part of your solution*. As part of the assessment, be sure to look at their performance measures for the solution."

RADD: DDO: Techniques

"Benchmarking and Market Analysis Benchmarking studies are a source of business analysis information, comparing an aspect of the system with an external baseline. Market analysis is a mechanism for determining what external customers want and what your competition provides. Both can be used to identify and analyze existing solutions and market trends. Brainstorming This technique is used during analysis to generate many ideas from a stakeholder group in a short period of time. The resulting ideas can then be organized and prioritized to identify improvement opportunities and design options. Document Analysis Business analysts use document analysis to confirm analysis results against existing documents, source information, and other elicitation results. This technique provides information to describe existing solutions, design options, and design elements. Interviews Interviews involve asking questions of stakeholders to uncover needs, identify problems, or discover opportunities during the requirements analysis process. This technique is used to identify improvement opportunities and design options. Lessons Learned Lessons learned provide a *great way to identify improvement opportunities* during requirements analysis activities based upon what others have experienced with previous products and services. Mind Mapping Mind mapping is a *visual, nonlinear, collaborative way of generating, organizing, and prioritizing many ideas* from a group of stakeholders. This technique *can be used to identify and explore possible design options* during requirements analysis. Root-Cause Analysis This technique helps the business analysts and the key stakeholders *understand the underlying cause of problems being addressed by a change* and to propose design options to address those problems. Survey or Questionnaire Surveys and questionnaires allow the business analyst to *discover business analysis information* about customers, products, work practices, and attitudes in a structured way from a group of stakeholders. During analysis, they can be used to identify improvement opportunities and design options. Workshops Workshops are a *collaborative and facilitated way to identify improvement opportunities and design options* with a group of stakeholders."

BAPM: BAPI: Techniques

"Brainstorming Brainstorming is a good way for a group of stakeholders to generate ideas for business analysis improvement opportunities. Interviews Another source of business analysis performance data is to interview key business analysis stakeholders and ask them for their assessment of the business analysis work on the project. Item Tracking Issue management activities take into account tracking business analysis work performance issues that occur so those issues can be addressed and resolved later. Lessons Learned A lesson learned process allows the business analyst to compile and document successes, failures, and recommendations for improving performance of business analysis activities on future projects. Observation This technique allows you to witness business analysis performance in person and see for yourself how things are being done. Process Analysis Process analysis is a technique to analyze existing business analysis processes and suggest ways to improve them, either as a group or as an individual. Process Modelling Business analysis processes can be modelled and improved using this technique. The business analysis team may find it helpful to graphically depict the flow of business analysis work in order to improve performance. Reviews Sitting down in a review meeting can help the team identify changes to business analysis processes and deliverables that can be incorporated into future work activities. Risk Analysis and Management One facet of this technique should focus on identifying and managing potential risks that may impact business analysis work activities and deliverables. Root Cause Analysis Asking ""why?"" five times can help the business analysis team identify the actual cause of problems encountered when performing business analysis work. Survey or Questionnaire If you can't speak directly with your key stakeholders, consider sending them a survey or questionnaire to ask them for their assessment of the business analysis work performance on the project. Workshops Workshops are used to assess business analysis performance and generate ideas of improvement opportunities in a group setting."

PBAM: PSE: Techniques

"Brainstorming Brainstorming is an excellent technique to use when the business analysis team is generating a list of all possible stakeholders for the business analysis effort. Generating ideas about who the business analysis stakeholders are could reveal hidden stakeholders that should be involved with your efforts. Business Rules Analysis We think of business rules as things that define or constrain some aspect of how a business actually does business. They may define the business structure or perhaps control how the business behaves day to day. Business rules analysis allows you to identify those stakeholders who are the source of the business rules and those who abide by the rules when performing their jobs. Document Analysis Document analysis is used to review existing organizational assets that might assist in planning your stakeholder engagement approach. Interviews When interviewing business analysis stakeholders, the business analyst should always ask the interviewees to identify additional stakeholders. Lessons Learned Don't forget to look in the past for successes and challenges your organization has faced when it comes to engaging and collaborating with project stakeholders. Mind Mapping This is used to identify potential stakeholders and understand the relationships between those stakeholders. Process Modelling Anyone involved with the business processes that are affected by the proposed solution should be identified as a stakeholder. Process models can assist the business analyst with that identification, as they show the related processes and systems. Risk Analysis and Management The results of stakeholder analysis may contribute to the risks for the business analysis effort and to the project. The people involved with your efforts can be the source of possible risks, and they can also help the team identify additional risks that may be important downstream. Scope Modelling Scope models can show the business analysis team the set of stakeholders external to the solution scope that interact with the solution in some way. Survey or Questionnaire Business analysts may use this technique to identify shared characteristics of a particular business analysis stakeholder group. Workshops When conducting requirements workshops on any project topic, the business analyst should always ask the group of participants about any additional stakeholders."

SA: CSD: Business Needs

"Business *needs consist of problems and opportunities*, such as customer complaints or the emergence of a new market. They are *identified at every level* of the enterprise and drive the enterprise to *define and pursue a solution to satisfy that need*. Remember to express business needs from the enterprise's point of view versus being too stakeholder specific to eliminate bias. A business analyst *must investigate the business problem or opportunity* to ensure that there is a *good reason to move forward* and address the problem or opportunity. You are *looking for a way to improve* the business and *add value*. Consider several factors when performing this work: *Quantify any adverse* impacts. *Define any expected benefits* from the proposed solution. *Estimate a timeframe* for addressing the problem or opportunity. Look at the *""do nothing"" option* as an alternative approach. Identify the *underlying cause * of the problem."

RLCM: ASSESS R CHANGES: Techniques

"Business Cases A business case is often used to *justify a proposed change*. Business cases are particularly relevant when looking at the benefits to be gained by accepting the proposed change to requirements or designs. Business Rules Analysis This technique is used during impact analysis to *trace business rules to the requirements* that the business rules support. The technique also works in a different direction and can be *used to trace the business rules that support requirements*. Decision Analysis Decision analysis facilitates the change assessment process by *examining and modelling the possible consequences of different actions*. This helps the business analyst decide *whether to approve, deny, or defer* a proposed change to requirements or designs. Document Analysis Use document analysis to *analyze existing documents* to help you *understand the possible impacts of a proposed change* to the requirements or designs. Estimation *Estimating the cost and effort* to *implement* a proposed change is a necessary step in impact analysis. Estimation is an iterative process where the act of review and revision takes place as more information is known over time. Financial Analysis This technique estimates the *financial consequences of a proposed change* to requirements or designs. Consequences include financial viability, stability, and benefit realization. Interface Analysis Interface analysis *identifies interfaces that can be affected by a proposed change* to requirements or designs. This technique looks at where, what, why, when, how, and for whom *information is exchanged between solution components* or across solution boundaries. Interviews Business analysts use interviews to talk with individuals and small groups of stakeholders in order *to understand the impact of the change* on the organization or its assets. Item Tracking Item tracking or issue management *tracks any issues or conflicts * that were discovered during impact analysis activities. Risk Analysis and Management Risk analysis and management techniques *determine the level of risk associated with a proposed change* as part of impact analysis activities. Workshops Workshops allow groups of stakeholders to *collectively discuss and understand the impacts of a proposed change* or *decide what to do* about one or more proposed changes."

Requirements (BABOK classification scheme)

"Business Requirements Stakeholder Requirements Solution Requirements Functional Req NonFunctional Req Transition Requirements"

RCLM: MAINTAIN: Techniques

"Business Rules Analysis Business *rules that are similar* across the enterprise may be *helpful in identifying requirements* that are candidates *for reuse* on other projects and initiatives. Data Flow Diagram Look for information flow that is similar across the enterprise. This *consistent data may indicate requirements that are candidates to be maintained and reused*. Data Modelling Just like *data flow, data structures* that are similar or *consistent across the enterprise* may be pointing to requirements that are *candidates for reuse*. Document Analysis Playing detective and analyzing existing documentation at the enterprise level may assist you in *discovering requirements that may be maintained and reused* on other projects and initiatives. Functional Decomposition *When performing *functional decomposition to break something down into more detailed pieces and parts, be sure to *look for requirements associated with lower-level components of the solution that can be reused*. Process Modelling Process modelling gives a window into the *requirements associated with the processes* that might be *candidates for reuse*. Use Cases and Scenarios Use cases and scenarios can help* identify solution components that can be reused *by more than one solution. User Stories User stories can be used to *identify requirements associated with the story* being told that *may be available for reuse as part of another solution*."

RLCM: TRACE: Techniques

"Business Rules Analysis This technique can be *used to trace business rules to the requirements* that the business rules support. The technique also works in a different direction, *tracing business rules that support requirements*. Functional Decomposition *Break down solution scope into smaller components for requirements allocation*. Requirements allocation assigns requirements to be implemented by a specific solution component or components. Functional decomposition is also *used to trace high-level components to lower-level components*. Process Modelling Process models *visually show the future state process*. These models allow the business analyst to *trace requirements to that future state process*. Scope Modelling Scope models *visually depict the scope* and allow the business analyst to *trace requirements to the area of the scope that the requirement supports*"

RLCM: ASSESS R CHANGES: Provide impact resolution for the proposed change

"Business analysts *follow* the methods defined in the *governance approach *when making decisions about proposed changes on their projects. Based upon the approach, key stakeholders may be authorized *to approve, deny, or defer a proposed change*. Typically, the *results * of the impact analysis are *documented and communicated to all stakeholders.* Note When considering the total costs of approving and implementing a proposed change, be sure to look at the cost to make the change, the cost of any associated rework resulting from the change, and any opportunity costs such as other features that might be sacrificed or deferred if the change is approved."

BAPM: BAPI: Elements: Analyze results

"Business analysts *look at the performance of* the business analysis *deliverables*, the *resources* performing the work, and the *overall* business analysis *process relative to the defined measures*. Business analysis performance can be measured and evaluated from more than one point of view, such as the stakeholders, the business analysis team, a personnel manager, or an organization's Center of Excellence."

BAPM: BAPI: Elements: Performance analysis

"Business analysts don't always find it easy to define the level of performance required for effective business analysis work. It is *necessary to determine the appropriate performance measures* for effective business analysis work on a specific project. There are the traditional measures to report on, such as meeting schedule dates for activities and deliverables that can be applied. There are also more requirements-focused metrics, such as the frequency of requirements changes or the number of review cycles needed. Note According to the BABOK® Guide, performance *metrics will encourage certain behaviors and discourage others. Poorly chosen metrics may drive behavior that is detrimental to the enterprise as a whole*. Performance measures may be quantitative or qualitative in nature. Quantitative data tends to be numeric and can be measured. Qualitative data is subjective and can be observed but not actually measured. *Potential business analysis performance measures:* Accuracy and Completeness Determine whether business analysis work products are correct and relevant when delivered or if revisions are required to gain stakeholder acceptance. Knowledge Assess whether the business analyst has skills and/or experience to perform the task. Effectiveness Assess if business analysis work products are easy to use as standalone deliverables or if they require extensive explanation in order to be understood. Organizational Support Assess if adequate resources are available to complete business analysis activities. Significance Consider the benefit obtained from work products and assess if cost, time, and resource investments expended to produce the work products were justified for the value delivered. Strategic Look to see whether business objectives were met, problems were solved, and improvements were achieved. Timeliness Evaluate whether the business analyst delivered work on time per stakeholder expectations and schedule."

BAMP: PBAG: Decision making

"Business analysts must *define which stakeholders are responsible* for making key decisions as part of the business analysis efforts. The decision-making process in the business analysis governance approach defines who is involved in making what decisions and to what degree. This is *similar to defining the roles and responsibilities in a RACI matrix*, as we discussed earlier relative to stakeholder engagement. Stakeholders may have many roles in decision making, such as the following: Participating in decision-making discussions Providing subject-matter expertise as part of decision-making Reviewing information Approving decisions that are made Business analysts also need to *think about how to handle decisions when the team cannot reach agreement or consensus*. Setting forth *escalation paths* and defining the *stakeholders with the authority to make a final decision* is a key component of business analysis governance."

Business Requirements

"Business requirements are *defined early* in the project, representing the *high-level* goals, objectives, and outcomes for the project. Business requirements *justify the reasons* for making a *change* in the enterprise and define *how success will be measured* once that change has been implemented. Typically, these high-level, ""big-picture"" requirements are *defined by tasks found in the Strategy Analysis* knowledge area."

Business Requirements

"Business requirements are the *highest level of requirements* and are developed *during Strategy Analysis* activities. They *define* the *high-level goals, objectives, and needs* of the organization. They also *describe and justify* the high-level business *functionality that is needed* in the resulting *solution*. To *define a solution*, business analysts will *progressively elaborate and decompose business requirements* to the next level of detail, * => the stakeholder requirements.* In the BABOK® Guide, business requirements are not contained within a single, standalone document. They are *contained in a set of Strategy Analysis task deliverables*, including the *business need, the required capabilities, the solution scope, and the business case*. (We will look at these deliverables in more detail later when we dig into this knowledge area in Chapter 2, ""Controlled Start: Strategy Analysis."")"

"RLCM: PRIORITIZE: Considering challenges of prioritization"

"Challenging: *Facilitating a session to prioritize* requirements can be quite challenging. There is a tendency for stakeholders to *issue nonnegotiable demands* relative to the importance of their requirements, such as ranking all of their requirements as the most important requirements of the bunch (whether they really are or not). The problems aren't confined to the stakeholders, though. It is *not unusual to find the solution development team trying to influence the prioritization results*, perhaps because they have some interesting technology *they would like to implement*. The facilitator must recognize and focus on the need for trade-off decision making and compromise in a session that takes on these characteristics."

SA: BACCM

"Change *Define the future state* and *develop a change strategy* to achieve that future state. Needs *Identify and prioritize needs* within the *current state* of the business to *determine the desired future state*. Solution *Define the solution scope* as part of the *change strategy*. Stakeholders *Collaborate with stakeholders* to understand the business needs and *develop a change strategy and future state* to meet those needs. Value Examine the *potential value of the solution* to see whether the change is *justified*. Context Consider the *change strategy in the context* of the existing enterprise: stakeholders, processes, technology, and policies."

BAPM: BACCM

"Change *Determine how changes* to business analysis *results are requested and authorized*. Needs *Choose* a business analysis *approach* providing adequate analysis for the change. Solution *Evaluate* if business analysis *performance contributed* to successful solution *implementation*. Stakeholders *Perform* stakeholder *analysis* to ensure Business Analysis Planning and Monitoring *activities reflect stakeholder needs and characteristics*. Value *Conduct performance analysis* to ensure business analysis *activities produce sufficient value* to stakeholders. Context *Ensure complete understanding* of the context being analyzed *in order to develop an efficient BAA* (business analysis approach)"

Requirement

"Condition or Capability needed by a stakeholder to solve a problem / achieve an objective Representation of a need / problem / objective"

SE: RAtoISV: Techniques

"Data Mining This technique is used to *generate predictive estimates of solution performance*. Data mining is particularly useful when there is a lot of data to analyze relative to a particular solution. Decision Analysis Decision analysis allows you to *examine and model the consequences of different decisions before actually making or recommending a particular decision*. Effective decision analysis helps you determine the impact of acting upon solution issues. Financial Analysis There are *numerous financial analysis techniques available to assess the potential costs and benefits* of a proposed change. Focus Groups Focus groups are often *used to give assessment, insight, and impressions of a solution's performance* and the associated performance measures. Organizational Modelling Organization models *offer a view of your stakeholder groups and stakeholders to use while assessing organizational readiness* and the need for organizational changes. Prioritization Many business analysts use *prioritization techniques to identify the relative value* of different actions that might be taken to improve solution performance. Process Analysis Process analysis *assesses a process for efficiency and effectiveness*. This technique is used to identify opportunities to improve solution performance. Risk Analysis and Management This technique is used to *evaluate different solution outcomes and their associated risks* under specific conditions. Survey or Questionnaire Surveys and questionnaires are often used to *collect information from stakeholders about solution performance*. They can help you get feedback on value realization based upon the performance measures and analysis that has been done."

RADD: REQ ARCH: Techniques

"Data Modelling *Data models organize requirements by describing the concepts* and *relationships between the concepts* that are *relevant to the defined solution scope*. Business analysts *use this technique to describe the data components* of the requirements architecture. Interviews Interviews are a way for the business analyst *to speak directly to key stakeholders* to define the requirements architecture and structure in a collaborative fashion. Scope Modelling *Scope models organize requirements based on the solution components* to which they are related. *Solution components are parts of a solution spanning the enterprise architecture* of the organization, including business processes, software applications, or hardware. Workshops Workshops are a way for the business analyst to work with *groups of key stakeholders to define the requirements architecture and structure in a collaborative fashion*."

SA: AR

"During Strategy Analysis, the business analyst analyzes and manages the risks relative to the current state, the future state, and the change strategy. According to the BABOK® Guide, the risks are analyzed in a basic way with which most of us are familiar. The business analyst *looks at: the possible consequences if the negative risk occurs, the impact of the consequences, the actual likelihood of the risk occurring, and the potential timeframe when the risk might occur*. Exam Spotlight In the BABOK® Guide, risks are uncertain events that can produce negative outcomes. The focus is on the negative (threat) aspect of risks versus the positive (opportunity) view of risk found in many methods. On your exam, opportunities or positive risks are captured as needs and managed accordingly. Effective business analysts understand the consequences of internal and external forces on the enterprise when working toward a desired future state. *Assessing and being aware of risks *allows the business analyst to *recommend courses of actions* as well as select a change strategy that fits the situation at hand. Business analysts manage risks on their projects at any stage of the life cycle *to minimize the impact of those risks on the value* of the implemented solution or change."

SA: FSD: Business goals and objectives

"Early in a project or before a project even begins, business analysts are asked to analyze the organization's business goals and objectives as part of defining a particular business need and the desired future state. This strategic information is usually located in the organization's strategic plan, starting with the organization's mission, vision, and values. Many people mistake the vision statement for the mission statement. *Vision * The vision describes a *future identity*. *Mission* The mission describes *why *that future identity *will be achieved*. *Values* Values provide *boundaries* for how an organization *defines its mission in order to achieve its vision*."

SE: RAtoISV

"Estimating the potential value of a solution can be quite different from realizing the actual value once that solution is operational. *One key task *performed by business analysts is *trying to align the potential value and the actual value of a solution* as much as possible. The previous four tasks in the Solution Evaluation knowledge area collect solution performance data, measure the solution performance, and assess solution and enterprise limitations that may impact the actual value. *This task uses the results from the other tasks to understand the big picture of a solution's value* and *recommend ways to improve solution performance* and value realization. Solution-focused *recommendations look at how solutions should be replaced, retired, or enhanced*. These recommendations have a long-term perspective over the life of the solution within the enterprise. The solution or the organization may require adjustment in order to use the solution more effectively and realize additional value from its use."

Defect vs Issue

"Exam Spotlight Make sure you know the difference between a defect and an issue. *Defects are deficiencies in your solution, reducing the quality* of that solution. *Issues are points or matters in dispute or in question*."

RADD: APotVal: Expected Benefits

"Expected benefits are the *positive values that a solution delivers* to stakeholders and the enterprise. A solution's value can consist of: benefits, reduced risk, compliance, improved usability, or any other positive outcome. *Benefits can be calculated for individual requirements, for groups of requirements, or for the overall initiative*. Benefits are typically realized over time, often after the solution is implemented and operational."

RADD: APotVal: Expected Costs

"Expected costs are the ""flip side"" of expected benefits. They are the *negative value associated with a solution*, such as the cost to acquire, build, or maintain that solution. Expected, or negative, costs include many things, such as resources, operating costs, purchase costs, and maintenance costs. Exam Spotlight Business analysts should also remember to look at the opportunity costs when estimating the expected cost of a change. Opportunity costs are alternative results that might have been achieved if resources, time, and funds were allocated to a design option that was not selected. The opportunity cost of any deign option equals the value of the best alternative design option that was not selected."

"RLCM: APPROVE REQ: Track and communicate approval."

"Formal requirements *communication follows* the contents of the business analysis *governance approach* when it comes to dealing with proposed changes. *Informal communication takes place whenever it is needed*. *Business analysts record the change approval decisions, often using requirements management tools.* *Stakeholders should be able to see what requirements and design changes are approved and in the queue for implementation*. Many projects require an audit history of changes to requirements. Be sure to document what was changed, the business analyst who made the change, the reason for the change, and when the change was made. Exam Spotlight According to the BABOK® Guide, *conflict resolution and issue management* occurs frequently *during the change approval process*. This *occurs when the business analyst reviews requirements and designs and aims to secure a sign-off on proposed changes*"

Guidelines and Tools

"Guidelines and tools list *resources* a business analyst *uses to transform a task input* into the resulting task *output*. Guidelines *provide instructions *to the business analyst *for executing *a task. Tools *provide things *the business analyst can *use to perform the task*."

Requirements (classified by focus)

"High-level business requirements User requirements System requirements Software requirements"

List: Defining the Requirements Management Process

"How the team will deal with requirements *traceability* The explicit *process for developing* requirements How requirements will be *prioritized* What requirements *attributes will be collected* How *changing requirements will be handled* both during requirements development and after the requirements are agreed upon and baselined *Who will review and approve* requirements and any requested changes"

"RLCM: ASSESS R CHANGES: Perform an impact analysis."

"Impact analysis is done *to assess or evaluate the impacts of a proposed change* to requirements or designs. *Traceability allows the business analyst to look at the impact* of the change *relative to related requirements* and solution components. The impacts of changing existing requirements should be assessed across the five areas: *Benefit* Benefits to be *gained by accepting* the change *Cost* Total *costs to implement* the change *Impact* *Number* of customers or business processes *affected* *Schedule* Impact to *existing delivery commitments* *Urgency* Level of *importance* of the change"

Describe: Business Analysis Planning and Monitoring

"In the Business Analysis Planning and Monitoring knowledge area, a business analyst *plans* how to *approach* the business analysis *BA effort*. The *approach* is a set of *processes, templates, and activities* used to *perform business analysis *in a specific context. The *tasks organize and coordinate* the *performance of all* other business analysis* tasks*. d These planning and monitoring activities take place *throughout the project life cycle*. The *results* of this knowledge area *guide the tasks* found *in the remaining five knowledge areas* and set the performance *metrics to be used to evaluate* all business analysis work. This deals with the *planning of the requirements-gathering activities*, *analyzing stakeholders*, and *getting buy-in* to the requirements-*gathering efforts*. It also outlines how *change control and traceability* of requirements *will be dealt with*."

BAPM: PBA: Elements: Determine Timing of Business Analysis Work

"It is *critical* that you *determine when* the business analysis work *will take place* throughout the project. This includes identifying not only the *tasks* to be performed but also the business analysis *resources* that will perform each task. Requirements development time is a traditionally heavy period of work for the business analysis team. You need to know whether these efforts will align with specific project phases early in the project (predictive) or whether the work will be done iteratively throughout the project (adaptive)."

BAMP: PBAIM: Look at information storage and access.

"It is *essential* that the business analysis *team create an information repository for storing requirements and designs*. Use of the repository should be linked to the process defined in the information management approach and in the higher-level business analysis approach. Documents created during the project life cycle should be saved in a secured area."

RCLM: MAINTAIN: Maintain Attributes

"It is not enough to just keep the requirements for your project up-to-date and available. The requirements attributes that were elicited along with those requirements also need to be maintained. Typical *attributes collected* during requirements elicitation *include the requirements source, priority, and complexity*. Remember that requirements *attributes may change over time while the requirement itself stays the same*."

RCLM: MAINTAIN: Reusing Requirements

"Maintained and retrievable requirements can be reused across multiple projects or initiatives. *Reusable requirements* are those that the *organization must meet on a continuous basis*, such as contractual obligations, quality standards, business processes, or service level agreements (SLAs). The organization may have to prove that the ongoing, operational requirements are met by the deployed solution."

Nonfunctional Requirements (conditions & constraints)

"Nonfunctional requirements *describe* *quality attributes, design and implementation constraints*, and *external interfaces* that the product must have. They are a subset of the solution requirements that the business analyst develops for the project, and they are typically paired up with the functional requirements that they constrain in some way. They would *add characteristics to the functional requirements*"

RADD: VALIDATE: Define Measurable Evaluation Criteria

"One item of interest found in your business case is the business benefit that the project will provide to the organization once the project is complete and the solution is up-and-running. *Business benefits can be measured only if you define the measurement criteria and how you will evaluate whether you have achieved them*. *If you are lucky, they were defined in the business case. If not, you will need to define them now during requirements validation.*"

RLCM: ASSESS R CHANGES

"One thing is certain when it comes to developing requirements—*at some point in time, those requirements are going to change*. Ideally, the changes are handled in a consistent, formal fashion by using a change request to initiate the process of assessing and decision making. This *task is performed when a proposed change identifies new needs or possible solutions to those needs*. The proposed change must be assessed before action is taken to approve, deny, or modify the request. *Business analysts view proposed requirements and design changes relative to the solution value, the current set of requirements, and the level of risk.* Experienced business analysts should ask the following questions when assessing a proposed change. Does the proposed change: Align with the overall strategy? Affect the value delivered to the business or the stakeholders? Impact the timeline or resources required to deliver the value? Alter any risks, opportunities, or constraints? The answers to these questions drive the outcome of assessing the proposed change. *When assessing a proposed change, remember to use the decision-making and change control* approaches *defined in the governance approach* that was created by the task Plan Business Analysis Governance as part of Business Analysis Planning and Monitoring."

BAMP: PBAIM: Organize business analysis information.

"Organizing business analysis information is a *challenging task on a complex project*. Information must be structured for efficient access and ease of use. *Duplication* of requirements and *conflicting requirements* should be *avoided*. Business analysts decide how to do this early in their projects. *Planning how you will organize* your business analysis information requires consideration of the following factors: The *type and amount* of information *to be collected* Stakeholder *access and usage* needs *Size and complexity* of the *change* *Relationships between* the types of *information*"

predictive approaches

"Predictive planning approaches focus on ensuring that the *solution is fully defined before* its implementation begins Predictive business analysis *tries to minimize your up-front uncertainty* (or risk) and *maximize your control* over the business analysis activities on your project. This is a more *traditional style* of development, such as the waterfall model of software development or what you find in straightforward business process reengineering initiatives. The *biggest issue* with predictive approaches is whether or not the *solution requirements can actually be well defined prior to commencing* the overall solution delivery efforts. In effect, *predictive approaches use structure to control project risk.*"

BAPM: PBA: Elements: Consider Project Complexity and Risk

"Project complexity impacts the business analyst in a number of ways. In general, the *more complex the project* is, the *more complex the business analysis effort* is as part of the project work. *Complex projects may result* in a *greater number of formal deliverables* and stakeholder *review points*. Complex projects can also be *riskier for everyone*—the business, the project team, as well as the business analysis team and its business analysts. Situations with a *complex solution* should be *addressed* with *more up-front modelling and planning work*. Examples of complex projects include building an airline reservation system or creating a telecommunications circuit ordering and provisioning application."

RADD: REQ ARCH

"Project requirements should *not be a jumble of information*. Your *requirements need to be structured and organized into a cohesive set of information that is complete, comprehensive, consistent, and understandable to your stakeholders*. You are responsible for deciding how to structure your individual requirements, group those requirements, and show the relationships between them. A *good requirements arch*itecture *targets consistency, repeatability, and a high level of requirements quality*. The *requirements should collectively support each other* and *produce a useful outcome* for the stakeholders. *The Requirements Architecture Answers the Following Questions for the Business Analyst* Which models are appropriate for the business analyst to use? How are the requirements structures relevant to different stakeholders? In what ways do the models and requirements interact with and relate to one another? How do the parts of the requirements document fit into a cohesive whole? How do the requirements work together to achieve the overall objectives? How can trade-off decisions about requirements within this framework be made? Remember that *requirements architecture and requirements traceability are not the same thing*. While *traceability may represent and manage the relationships* between requirements, *it does not prove the solution is a cohesive whole that will actually work*."

Technique: Organizational Modelling

"Recommended for Plan Stakeholder Engagement Most of us have seen an organization *chart showing the hierarchy*. This is an example of an organizational model. The model defines the purpose and structure of an organization or an organizational unit. When you use this technique for business analysis, you basically build an organization chart that *shows the organizational units, lines of reporting, the roles*, and the people in those roles. When you are working with a new client, one of the first things you should ask for is a current organization chart. This will allow you to evaluate who sits where in the food chain and to decide who you might initially involve in your business analysis efforts. *This is an excellent way to identify business analysis stakeholders.*"

Technique: Stakeholder List, Map, or Personas

"Recommended for Plan Stakeholder Engagement Personas are sometimes built to *represent groups of users and how they interact* with a product, kind of like building a fictional character and thinking about how they do things at work. Stakeholder maps are a *graphical technique* often used as part of stakeholder analysis. Stakeholder map looks at how these stakeholders will be involved with the resulting solution. This takes the concept of an organizational model one step further by visually relating the identified business analysis stakeholders to the solution, as well as to one another. There are two basic types of stakeholder maps: a stakeholder matrix - stakeholder matrix provides a two-dimensional look at stakeholder influence versus their level of interest in your efforts onion diagram - depicts stakeholder involvement with the resulting solution RACI matrix - matrix defines business analysis stakeholder roles across four designations: *Responsible (do the work), Accountable (makes the decision - only 1 per task/deliverable), Consulted (prior to work), and Informed (after the fact)*"

Describe: Requirements Analysis and Design Definition

"Requirements Analysis and Design Definition *describes how *the business analyst progressively elaborates to *define, refine, prioritize, and organize requirements*. In essence, the business analyst *takes the elicited information* and makes sense of it to *derive the real requirements* for the project. This knowledge area also *focuses on* graphically *modeling* the requirements and resulting designs as well as *documenting *them. When performing these tasks, the business analyst should *ensure the feasibility of the requirements* while *defining, describing, and refining the characteristics of* an acceptable *solution*. After requirements have been elicited, they must be organized, analyzed, and documented. This *may be in text format* or in *models*, or in a combination of both.* Conflicting requirements should be identified*, and the set of requirements should be evaluated for *priority and completeness*. It is also here that *alternative solution options are identified*."

Describe: Requirements Life Cycle Management

"Requirements Life Cycle Management *defines* how the business analyst *approaches managing and maintaining requirements*. *Tasks and techniques for managing* changes, conflicts, and issues related to requirements *are also described*. Business analysts perform requirement management tasks as *part of requirements development* work by doing the following"

RADD

"Requirements analysis *takes elicited information and makes sense of it*. The *tasks* found in the Requirements Analysis and Design Definition knowledge area *focus on analyzing the* business analysis *info*rmation *from your elicitation efforts* and *building the real stakeholder or solution requirements for your project*. The real requirements define the derived needs of your stakeholders after your structured and collaborative requirements analysis and design efforts are complete. Deriving and refining requirements for a project is repetitive and systematic in nature. *Experienced business analysts find themselves moving between requirements elicitation, requirements analysis, and requirements documentation* or specification activities many times throughout their projects. There can be a significant difference between the business analysis information elicited from stakeholders and the real requirements that define the resulting solution. The Requirements Analysis and Design Definition knowledge area * (RADD) focuses on analyzing what your stakeholders have told you and defining which capabilities need to be part of the resulting solution*. According to the BABOK® Guide, the Requirements Analysis and Design Definition *knowledge area is where you develop your stakeholder and solution requirements* for your project. Business requirements are developed by tasks in the Strategy Analysis knowledge area, and transition requirements are built by the Solution Evaluation tasks. Exam Spotlight Stakeholder requirements describe the capabilities of the solution that will meet the stakeholder needs. *Solution requirements are more detailed requirements, describing the behavior of the solution components* so that those components *can actually be created later in the project life cycle*. Be sure you know the difference. The tasks in this knowledge area *take the elicited business analysis information and make sense of it*. The information reflects what the stakeholders have told you about what they need. The business analysis information becomes analyzed requirements after it is acted upon by the tasks in this knowledge area. *Analyzed requirements are defined as requirements that have been specified and modelled.* These tasks focus on *making sure* that the *stakeholder and solution requirements* for your projects are *thoroughly analyzed and documented* for you, your team, and your stakeholders. The *goal is to use the capabilities defined in these requirements as the basis for designing and constructing the solution*."

RCLM: MAINTAIN

"Requirements can and will change on your projects, even while the requirements are being developed. *Maintaining requirements focuses on the current requirements* for your project, *as well as possibly reusing* some of those *requirements on other projects and initiatives downstream*. Requirements are *maintained so they stay current* and correct across the project life cycle, particularly after an approved change. Some requirements developed for a particular project might also be candidates for long-term use or reuse by the organization. The requirements that you choose to maintain might relate to infrastructure, hardware, software, or operational capabilities that the organization must meet on an ongoing basis versus just for your particular project. Requirements that can be reused on other projects must be named, defined, and easily available to other business analysts in the organization. These requirements are stored and managed in a requirements repository. Some organizations save and maintain all ongoing, operational requirements *to assist support and maintenance teams in evaluating possible impacts of changes to the deployed solutions and systems.*"

RLCM: PRIORITIZE: Address continual prioritization

"Requirements priorities can be a moving target *over time as more information becomes available*. As the requirements are *defined in greater detail, initial assigned priorities* may need to be *revisited and revised*. The *basis for prioritization also changes over time*. Initial *priorities based upon business benefits* may be *reprioritized based upon technical constraints* and the order of implementation or the cost of the requirements."

RLCM: PRIORITIZE

"Requirements prioritization *determines the relative importance* of requirements in order to gain maximum value to each other and to implement the overall solution scope. Ranking the requirements by their importance to stakeholders is the way most business analysts perform this task. There are many ways to prioritize requirements. The requirements *prioritization scheme needs to be planned* and defined for the business analysis team *prior to eliciting* requirements information at any level of detail. The priority of a specific requirement or group of requirements may alter over time as the context and level of detailed knowledge changes."

RLCM: TRACE

"Requirements traceability *provides * the business analyst with the *ability to identify and document the lineage of each requirement* and design. A *requirement's lineage includes its relationship* to *other* project: *requirements, to work products, and to the solution components*. When business analysts say that they can trace a requirement or design, they are telling you that they can look at that specific requirement or design and *all other requirements and designs to which it is related*. Requirements traceability begins with each project's business needs. The business needs are used to determine the business requirements. In turn, the *business requirements are decomposed into the more detailed stakeholder requirements* level. *Stakeholder requirements get broken down once more into the detailed solution requirements* that *transition the project team from requirements definition to solution design and development*. *All of the requirements* that make up a project's solution scope *should trace back to one or more business needs* for that project."

Experienced business analysts make sure that their business objectives are

"SMART (Specific, Measurable, Achievable, Relevant, and Time-Bound). Specific A business objective is specific if it has an *observable outcome*. Specific objectives allow an organization to ascertain that particular business objectives have actually been met. Measurable Quantifiable business objectives have measures that are used to *track and measure* their observable outcomes. Remember, if you can't measure something, it can't be verified. Achievable Business objectives must also be *feasible*. This is true relative to their cost, complexity, implementation, and ongoing support. Relevant All business goals and objectives must *align to the organization's mission, vision, and values*. Otherwise, there is no need to pursue them. Time-Bound Each business objective should have a *defined timeframe for achieving* that objective. Business analysts should ensure that the timeframe is consistent with the business need."

Describe: Solution Evaluation

"Solution Evaluation *focuses on assessing and validating* proposed, in progress, and implemented *solutions* before, during, and after the project life cycle. A business analyst's *attention* is *on the value* that the *solution will deliver* to the enterprise, including the *constraints* that may impact value. While many tasks in this knowledge area take place later in the project life cycle, some solution-focused activities *may occur quite early*. The business analyst must *trace the requirements through the product cycle* and *ensure* that the *product being designed* and developed *matches the requirements given* by the stakeholders. This includes *verifying that the customer is satisfied* with the product *after implementation*."

SE

"Solution Evaluation *provides care and feeding for your selected solution* across the project life cycle. The *tasks* found in this knowledge area *focus on assessing solution performance* and the *value delivered* by the solution to the enterprise. The *transition requirements are also developed* as part of this knowledge area. Transition requirements define how the solution will be implemented after the project work is complete. Care and feeding of a solution has many facets. One important aspect is the benefits realization aspect of a solution once that solution is being used. During a solution's operational life, you will want to *measure its performance* and *quantify the business value* it delivers. Keep in mind that there are *many ways to implement a solution* once it has been selected. *Experienced business analysts always make sure that the solution is defined, designed, and implemented well.* The *Solution Evaluation knowledge area focuses on ensuring that the solution can be successfully implemented* within the organization in order *to meet the business need* driving your project. You *must have knowledge of your business environment* and be able to assess *how each of your project's proposed solutions would affect that environment*. Communicating solution requirements and implementation-specific information to your stakeholders is also your responsibility. According to the BABOK® Guide, this knowledge area is where you will *develop your project's transition requirements*. Transition requirements describe the solution capabilities required to transition from the current organizational state to the future state. Transition requirements are no longer needed once the transition to the new solution is complete. Remember that the business requirements are developed by tasks in the Strategy Analysis knowledge area, and your stakeholder and solution requirements are built by tasks found in the Requirements Analysis and Design Definition knowledge area. Exam Spotlight An important *distinction* between Solution Evaluation and other knowledge areas is the *existence of an actual solution*. Solution Evaluation tasks can be performed on solution components in varying stages of development, including the following: Prototypes or proofs of concept Pilot release or Beta release Operational releases"

Solution Requirements

"Solution requirements are the most detailed type of requirements found in the BABOK® Guide. They *describe* the *solution characteristics* that *meet the higher-level business and stakeholder requirements*. Typically, a business analyst divides solution requirements into two specific types: functional requirements and nonfunctional requirements. A business analyst develops and defines solution requirements as *part of* the tasks found in the *Requirements Analysis knowledge area*. solution requirements *include* the * business need, the required capabilities, the solution scope (define capabilities that a solution must possess), and the business case* (all produced by SA knowledge area)"

Stakeholder Requirements

"Stakeholder requirements are the *bridge between* the *business requirements* and the more detailed *solution requirements* to *define the needs of stakeholders and how they will interact with a solution. * They are *developed* and defined as *part of the Requirements Analysis and Design Definition* knowledge area. Like the business requirements that preceded them, the stakeholder requirements *will be progressively elaborated into the more detailed solution requirements*."

Describe: Strategy Analysis

"Strategy Analysis focuses on how the business analyst *identifies the business needs* driving a project by performing problem definition and analysis. In addition to defining and refining these strategic or tactical needs, the business analyst is responsible for *defining a feasible solution scope* that can be implemented by the business. This work may also include *developing a business case or feasibility study* for a proposed project. Typically, the tasks in this knowledge area *occur prior to or early* in the project life cycle The business analyst's task list for this knowledge area includes *translating business strategy into proposed new business or enterprise solutions* Business analysts must understand the business and organizational environment in which they are working and recognize that a *project does not operate in a vacuum*, but rather is *interacting with the rest of the enterprise*. For the business analyst to successfully document *requirements, the business, its goals, visions, business rules, and mission* must be *documented as well*. This knowledge area also deals with *feasibility studies and evaluation of business cases* for different projects"

RLCM: APPROVE REQ: Understand stakeholder roles

"The *approval process* for proposed changes to requirements or designs is *defined in the business analysis governance approach*. *Stakeholder roles and authority levels* in this process must be defined and understood. It is *essential to know who has the decision-making and sign-off authority*. Look for influential stakeholders that should be consulted or informed about the changes, as well. These influencers can help with communicating and gaining consensus about the changes that are proposed."

"SE: MSP: Defining solution performance measures"

"The *first step* in defining solution performance measures is to *take a look at any existing performance measures* and methods. Make sure the existing measures are both *accurate and relevant to the new solution*. *Common sources for performance measures include business goals, objectives, and processes as well as any legal or regulatory constraints* on the solution. Exam Spotlight Solution performance measures *may be quantitative, qualitative or both*, depending on the value being measured. Quantitative measures are numerical, countable, or finite, such as measuring amounts, quantities, or times. Qualitative measures are more subjective in nature, such as attitudes and perceptions of a solution and its operations. Be sure you can distinguish between these two types of measures for your exam."

RADD: APotVal: Determine Value

"The *potential value* of a solution *equals* the *sum of the expected benefits and the associated costs* of those benefits. A positive value means that the benefits exceed the costs, while a negative value means that the costs exceed the benefits. *The value should be determined at the enterprise level versus for a single group of stakeholders*. This potential value is uncertain because of the tangible and intangible costs that are part of the estimating process."

RADD: DDO: Define Solution Approaches

"The *solution approach describes how* you will go about *building and implementing the solution* itself. *Solution components may be created or purchased*, or perhaps some combination of ""build and buy"" will be used."

BAMP: PBAG: Change control process

"The business analysis *team must decide how to handle changing requirements* and designs across the project life cycle. The change control process should address not just baselined requirements but also changes to requirements that the business analyst develops. If the organization has a robust change management process, the business analyst can apply it to the requirements work on the project. If not, the business analysis governance approach needs to address how changing requirements are to be handled. This *includes* determining the process for: *requesting requirements or design changes, authorizing requirements or design changes, performing impact analysis for significant change requests, and determining how change requests are worded*. *Exam Spotlight* The BABOK® Guide recommends that the requirements management process spell out the components found in a request for change. At a minimum, a *change request should include cost and time estimates*, an *assessment of benefits and risks associated* with the change, a *priority for the requested change*, and a *recommended course of action*."

BAPM: BAPI: Elements: Performance analysis

"The business analysis *team must decide on the methods* to be used for *reporting tracking and archiving* business analysis *performance data*. These reports can range from formal, written documents and presentations to informal conversations by the water cooler. If the reports are to be archived, then they must be in writing. Again, many of these requirements may be set at the project level by the project manager, so keep the lines of communication open with that individual on your projects."

SA: CSD

"The business analysis team and key stakeholders must understand and be able to articulate *why a change is needed*. According to the BABOK® Guide, the business need ""defines a problem or opportunity of strategic or tactical importance to be addressed."" The *business need driving the change must be documented and agreed upon*. A business analyst *must understand the current state* of the enterprise today relative to this proposed change *in order to have a context for the change*. Remember, not every project gets started because an organization is having a problem. Organizations often consider adding new or changing existing capabilities based on new market opportunities, customer feedback, newly available technologies, or changing legal and regulatory requirements. Understanding the current state of the business starts the team and its key stakeholders down the path of fully understanding a business problem or opportunity. *Organizations need to stay targeted on the business needs versus reacting too quickly to problems, issues, or perceived inefficiencies*. The *current state definition sets the stage* for what comes next in the early part of a project, including deciding on the following: The *range of solution options* to consider The *set of stakeholders* to involve The *appropriate solution approaches to evaluate* After the business need and the current state of the business relative to that need are *articulated* for a project or initiative, they are *not expected to change significantly* through that project's life cycle. If the business need for a project does *change during* that project's life cycle, the business analyst will have to *go back to validate all* of the high-level planning and definition work to make sure everything is still okay."

BAPM: PBA: Elements: Plan and Integrate Business Analysis Activities

"The business analyst must *decide on the process* to follow for *planning* a project's business analysis *activities*. This *requires coordination and communication* with the *project manager*, because this business analysis work plan is typically integrated into the higher-level project plan. *If there are planning standards* to follow for the project, the business analyst should *use those standards* when planning the business analysis work. These standards could include guidelines for estimating or specific planning and scheduling tools to be used. If the business analysis work plan is not consistent with the project plan, it will be difficult to integrate into the overall effort."

RLCM: TRACE: Deciding the level of formality

"The challenge for business analysts and project teams is *deciding what *requirements and designs need to be *traced* and *or* what can be *skipped*. Traceability can be built and maintained at many levels within a given set of project requirements. Traceability usually *begins* with tracing the *current requirements* under development *to the higher-level requirements* from which they are being derived. For example, when business analysts build the solution requirements for a project, the first aspect of traceability that they address is derivation from the stakeholder requirements that preceded the solution requirements. The business analyst needs to decide the project's approach to traceability before the requirements development work actually begins. It is important to decide the level of traceability and the types of relationships to be traced ahead of time. That allows the business analysis team to do this work concurrently with developing the requirements. Factors to Consider when Planning for Traceability: *Number of Requirements * Complex projects have more requirements, the more relationships there tend to be. Toward a more sophisticated requirements management tool that uses a database to relate the requirements to one another. *Estimated System Lifetime * The longer a system or solution, greater the need for traceability . *Level of Organizational Maturity * Acquiring a new requirements management tool at the beginning of a major requirements development effort is bad timing. It will be difficult for the business analysis team to learn to use the new tool and to do their requirements development work simultaneously. Use what they have"

SE: AEL: Enterprise Culture Assessment

"The cultural part of your assessment focuses on the *willingness of your key stakeholders to change and accept the solution*. You need to put your marketing hat on and sell this solution as part of your business analysis activities. This involves understanding each key stakeholder's willingness to change and getting them on board with the changes that are coming with the new solution. Your stakeholders need to understand and buy into the rationale for the new solution and the benefits it provides."

RADD: APotVal

"The final task in the Requirements Analysis and Design definition knowledge area is *estimating and modelling the potential value of each design option* and figuring out *which option is the most appropriate option* for the enterprise. *Potential value is typically analyzed many times over the course of a change*. *Remember the ""do nothing"" option may also be the best recommendation* based upon what you know. The business *value* of design options and solution approaches *changes depending on how requirements are implemented*. Some solution implementation approaches cost more money but take less time to perform, such as purchasing a proven commercial product versus developing your own software application. On the flip side, some solution implementation approaches are low cost but may eliminate capabilities in the initial deployment. These low-cost alternatives fail to provide end users with the complete functionality needed to do their jobs."

RADD: S&M REQ

"The first task in the Requirements Analysis and Design Definition knowledge area is specifying and modelling the stakeholder and solution requirements for your project. The business analyst *BA analyzes the elicitation results and creates representations of those results*. For most projects, this work is not done all at once. The *higher-level stakeholder requirements are typically defined and decomposed into the more detailed solution requirements*. Your *requirements architecture drives how you accomplish this *by defining the combination of text, charts, diagrams, and models that you will use. Formal textual or graphical models must follow the rules for their model type. Typically, modelling rules are set either by your organization, by your selected modelling tool vendor, or by a set of standards and guidelines for the particular type of modelling technique that you have selected. That means you are expected to consistently use the correct notation and meaning for every element in your model. *Formal models* are powerful tools as long as your stakeholder audience understands the language they are speaking. *Informal models have no formal definition, connecting elements in ways that have meaning for you* and for your stakeholder audience."

SE: MSP

"The first task in the Solution Evaluation knowledge area is *defining performance measures for collecting solution performance data* and measuring the performance of a newly deployed or an existing solution. *Performance is typically measured using key performance indicators (KPIs), project goals and objectives, process performance targets, or software application testing*."

New business needs can be identified at many levels of the enterprise.

"The four typical sources are: *Top down*: To achieve a strategic goal *Bottom up*: To address a current process, function, or system *Middle management*: To make better decisions or perform additional functions to meet business objectives *External drivers*: To meet customer demand or business/market competition"

BAPM: PSE: Elements: Define stakeholder collaboration.

"There are many approaches used to collaborate with stakeholders across the business analysis life cycle. It can be *challenging to keep your stakeholders involved, interested, and engaged* across the life cycle of your initiative. Stakeholder *collaboration can be planned and formal*. It can also take place in a *spontaneous and informal fashion*. Many business analysts document their stakeholder collaboration approach in a stakeholder collaboration plan by looking at the *timing, location, and methods* to be used *for regularly scheduled stakeholder collaboration*."

BAPM: BAPI

"There is *no reason to do business analysis planning* if the *team isn't going to use those plans* and approaches to measure and control business analysis performance. The *primary reason* for building the previous four business approaches in the Business Analysis Planning and Monitoring knowledge area *is to be able to perform, monitor, and report on the business analysis work* that is being done. This occurs at two levels: for the overall project and for each project phase. *Monitoring and measuring* business analysis *performance against* the business analysis *approaches* and the project plan *ensures* that the project's business analysis *effort produces the desired outcomes * and that the business analysis work is performed efficiently. *Exam Spotlight* *Capturing * business analysis *performance metrics* is *done throughout the project life cycle*. Once potential performance improvements are *identified, they become guidelines for the next time* a task is executed. *Business analysis team is responsible for determining the metrics used to measure business analysis work on the project*"

SA: FSD: Potential Value

"There is no reason to transition to a future state if no value is added to the enterprise as a result of the change. For the purpose of comparison, the value should be compared to the ""do nothing"" option. The BABOK® Guide defines the potential value of the future state as ""the net benefit of the solution after operating costs are accounted for."" Potential value is a key component of the business case justifying the proposed change. There are a number of techniques that you can use when assessing your organization's current capabilities relative to a new business need. You can almost always use benchmarking and market analysis or SWOT analysis to help you define the future state of things. Let's take a look at those recommended techniques now"

Stakeholder Requirements

"These requirements *define the needs of stakeholders* and *how* they will *interact with a solution*. Stakeholder requirements *bridge* between the business requirements and the more detailed solution requirements. Many folks refer to stakeholder requirements as high-level user requirements. They *identify* what is *needed * from the *user's perspective and define ""big picture"" capabilities* that the resulting solution must possess. Business analysts develop and define stakeholder requirements as *part of the tasks found in the Requirements Analysis and Design Definition* knowledge area. Like with the business requirements, the business analyst will progressively elaborate stakeholder requirements into the more detailed solution requirements."

SE: AEL: Operational Assessment

"This part of your assessment *focuses on the capabilities that the new solution will provide and how the stakeholders will use those capabilities*. You *might need to create new policies and procedures* governing use of the solution. *Training might be needed* so folks know how to use the solution correctly. Systems support and maintenance also need to be planned and put in place prior to solution implementation. Exam Spotlight When conducting an operational assessment for a solution, business analysts should consider the following six areas:* Policies and procedures Capabilities and processes Skill and training needs Human resources practices Risk tolerance and management approaches Tools and technology required for supporting the solution*"

RADD: Deliverables

"This requirements development-focused knowledge area generates several key business analysis deliverables. They include the following: *Specified and modelled stakeholder and solution requirements* *Verified* stakeholder and solution requirements *Validated* stakeholder and solution requirements *Requirements architecture * *Design options* *Solution recommendation*"

SE: APM: Solution Performance vs. Desired Value

"To analyze performance measures, you *need to collect the metrics that describe solution performance*. Some software applications might provide these metrics to you automatically. Other types of solutions will require manual collection of quantitative and qualitative solution metrics for evaluation. If you have a solution that is *over-or under-performing and not meeting one or more of the business goals and objectives*, it may be that your solution metrics associated with those goals and objectives are flawed. The solution metrics should also be validated and defined more appropriately."

Transition Requirements

"Transition requirements *define* the *solution capabilities required* to *transition from the current state to the future state* and are *no longer needed once the transition is complete*. Typically, the business analyst creates transition requirements *later in the project life cycle after defining both the current and new solutions*. Business analysts develop and define transition requirements as *part of* the tasks found in the *Solution Evaluation* knowledge area."

RADD: VALIDATE

"Validating requirements *ensures that your requirements align to the business requirements and the business objectives* for your project. By definition, valid requirements *contribute directly or indirectly to the project's business case*. Requirements validation is *ongoing* across the project life cycle; it *ensures* that each level of *detail you add to your requirements aligns with the big picture*."

SA: CSD: Capabilities and processes

"When defining the current state, be sure to *look at the activities the enterprise performs*. Core capabilities or processes describe the essential functions of the enterprise that differentiate it from other enterprises. The current state description *should define the current capabilities and processes* of an organization *relative to a business need*. This description looks at the organization's business processes, software, hardware, people, operations, and current projects. Activities and processes are measured by performance indicators that will help business analysts assess the benefits associated with a proposed change. Business analysts can take a *capability-centric view* of the enterprise in their current state description. This perspective *looks at innovative ways to combine existing capabilities and produce new outcomes*. The capabilities being assessed are *organized in functional hierarchies that relate them to other capabilities*. On the flip side, business analysts may choose to take a *process-centric view* of the enterprise, *looking for ways to improve the performance of existing activities*. Processes are typically organized in a different way than capabilities, flowing in an end-to-end fashion across the enterprise."

RADD: VERIFY: Verification Activities

"You will find yourself verifying requirements many times during the project life cycle. When you are *doing this task, remember to look at all of the specified requirements and designs, including text, tables, and graphical models*. Verification activities include checking for the following: *Compliance* with organizational standards Correct use of *modelling notations* *Completeness* within each model *Inconsistencies* between models Understandable *terminology* and correct use of terms"

BAPM: PBA: Elements: Select Planning Approach

"Your *planning approach* for business analysis activities *should fit the size and type of project* you are working on. It should *also fit within the org*anization where you work. We have already discussed the spectrum of planning approaches available to the business analyst, ranging from predictive to adaptive. Successful business analysts tailor their planning approach *to ensure that value is delivered* to the enterprise."

SE: AEL: Stakeholder Impact Analysis

"Your assessment *must address how the changes from your new solution will affect your stakeholders*. There are a number of things to consider. *Functions* Your impact analysis should *look at the solution capabilities that each stakeholder group uses* and address the significant work changes. *Consider new or modified processes*, as well as specific applications that the stakeholders will now be using as part of their jobs. *Locations* Stakeholder location also comes into play when assessing the impacts of change. If your stakeholders are all *located in one place, it will be easier to train and support* their use of the new solution. If your stakeholders are found in multiple locations, you will have to address how they learn to use the new solution and get assistance when they have questions in a virtual environment. *Concerns* Stakeholder *concerns and issues should also be addressed in your analysis*. There are several areas to consider, such as solution usability, work demands, potential job loss, or changes in work satisfaction."

SE: ASL

"Your next task in the Solution Evaluation knowledge area is *assessing solution limitations*. This task *identifies the root causes of underperforming and ineffective solutions* and solution components. This task is closely linked to another task in the Solution Evaluation knowledge area—assessing the enterprise limitations. We will discuss this task later in the chapter. The tasks are often done concurrently at any point during the solution life cycle. Solution Components Let's make sure you remember the definition of *solution components*. They are the pieces and parts of a solution that span the enterprise architecture of the organization including things like the following: *Business processes, policies, and rules People along with their job functions and responsibilities Software applications and application components Organizational structure and its internal/external interactions*"

A business analyst is estimating business analysis activities. Which formula is used to compute estimate as a weighted average?

(O+4M+P)/ 6 is used to compute estimate as a weighted average, where O = Optimistic, M = Most Likely, and P = Pessimistic

Tech: Acceptance vs Evaluation Criteria

*Acceptance criteria* are used to *define the requirements, outcomes, or conditions that must be met* in order for a solution to be considered *acceptable* to key stakeholders. - *Evaluation criteria* are the *measures used to assess a set of requirements* in order to *choose between multiple solutions*.

"Requirements State: Approved"

*Agreed to by stakeholders* and *ready for use* in subsequent business analysis or implementation efforts

SA: Tasks

*Analyzing the current state* of the business *Defining the desired future state* of the business Determining the *change strategy* and *solution scope* *Assessing the risks* of the selected change strategy

Which of the following *may not be a specific requirement* when a third party is involved in design, construction, implementation, or maintenance of the solution or solution component or when the solution is outsourced?

*Business analyst experience working with third party* may not be a specific requirement when a third party is involved in design, construction, implementation, or maintenance of the solution or solution component or when the solution is outsourced.

SA: FSD: Business architecture

*Business architecture is the design, structure, and behavior* of every aspect of the enterprise. The future state of an enterprise does not exist in a vacuum; all these elements work together to meet (or obstruct) business goals and objectives. This view of how things will work together in the future *helps business analysts align strategic objectives with tactical demands* and possible changes downstream.

"Requirements State: Validated"

*Demonstrated to deliver value* to stakeholders; are *within the solution scope* and are *aligned with business goals/objectives*

Difference: Enterprise vs Business Architecture

*Enterprise Architecture* - A *description of the business processes, information technology, people, operations, information, and projects* of an enterprise and the relationships between them. *Business architecture*: - The *design, structure, and behaviour of the current and future states* of an enterprise to provide a common understanding of the organization. It is *used to align the enterprise's strategic objectives and tactical demands*.

SE: APM: Performance Variance

*Variance is the difference between the expected and the actual solution performance*. Business analysts watch the variance and *attempt to minimize or eliminate that variance* to deliver solution value.

View vs Viewpoints vs Design Options vs Solution Components vs Solution Approach

*Viewpoints* Stakeholder-focused templates, standards, and guidelines that *define how requirements will be represented, organized, and related to one another* *Views*: Name given to the *actual requirements and designs for a particular solution* from *a chosen stakeholder viewpoint*. A *collection of views makes up the requirements architecture* for a specific solution. *Design Options*: *Possible ways to satisfy one or more needs* in a solution *Solution Components*: *Subparts of a solution*, such as people, infrastructure, hardware, or software *Solution Approach*: *How to go about building and implementing the solution*, such as whether solution components will be created, purchased, or some combination of both

"Requirements State: Modelled"

*Well-structured and represented* using correct *modeling notations*

Tech: Scope Modelling: Elements

1. *Objective* (• span of control, • relevance of elements, and • where effort will be applied.) 2. *Scope of Change and Context* (business processes, functions, new capabilities, events, technologies , stakeholders and organizational roles impacted by the change) 3. *Level of Detail* 4. *Relationships* (Parent-Child / Function-Responsibility / Supplier-Customer / Cuase-Effect / Emergent) 5. Assumptions 6. Scope Modelling Results

Tech: Root Cause Analysis: Elements

1. *The Fishbone Diagram* A fishbone diagram (also known as an Ishikawa or cause-and-effect diagram) is used to identify and organize the possible causes of a problem. 2. *The Five Whys* The five whys is a question asking process to explore the nature and cause of a problem.

Various levels of enforcement may be specified for a behavioural rule. For example

1. Allow no violations (strictly enforced). 2• Override by authorized actor. 3• Override with explanation. 4• No active enforcement.

Tech: Review: Elements: Participants

1. Author - Answers Q, listens to suggestions (All tech) 2. Peer - Examines and review objectives. (All tech) 3. Facilitator - Neutral, keep everyone focused (Inspection/Formal walkthrough/Single Issue) 4. Scribe - Neutral, document (inspection/formal&informal walkthrough)

Tech: Business Capability Analysis: Elements

1. Capabilities 2. Using Capabilities 3. Performance Expectations 4. Risk Model (Business risk/Tech risk/Org risk/Market risk) 5. Strategic Planning 6. Capability Maps (Out to in: Business Value, Customer Value, Risk, Explicit Performance Gaps - An Outcome)

Indicators must be...

1. Clear / 2. Relevant / 3. Economical / 4. Adequate / 5. Quantifiable / 6. Trustworthy&Credible) CREATQ

Tech: Decision Analysis: Elements

1. Components of Decision Analysis (a. Decision to be made, b. Decision Maker, c. Alternative, d. Decision Criteria) 2. Decision Matrices (Simple Decision Matrix / Weighted Decision Matrix) 3. Decision Trees (Decision Nodes/Chance Nodes/ Terminator(End Node)) 4. Trade-offs (Elimination of dominated alternatives / Ranking objectives on similar scale)

Tech: Decision Modelling: Types of Models and Notations

1. Decision Tables/ 2. Decision Trees/ 3. Decision Requirements Diagrams 3.1 Decisions (Rectangles) 3.2 Input Data (Ovals) 3.3 Business Knowledge Models - Business rules & other decision models(Rectangles with ends off) 3.4 Knowledge Sources (Document icon/ Square with wave)

Tech: Func Decomposition: Elements

1. Decomposition Objectives 2. Subjects of Decomposition 3. Level of Decomposition 4. Representation of Decomposition Results

Tech: Func Decomposition: Elements (Detailed)

1. Decomposition Objectives (Measuring & Mng / Designing / Analyzing / Estimating & Forecasting / Reusing / Optimization / Substitution / Encapsulation) 2. Subjects of Decomposition (Business Outcomes / Work to be Done (WBS) / Business Process / Function / Business Unit / Solution Component / Activity / Products & Services / Decisions) 3. Level of Decomposition 4. Representation of Decomposition Results (Tree Diagrams / Nested Diagrams / Use Case Diagrams / Flow Diagrams / State Transition diagrams / Cause-Effect Diagrams / Decision Trees / Mind Maps / Component diagram / Decision Model & Notation)

Tech: Decision Analysis: Approach Activities

1. Define Problem Statement 2. Define Alternative 3. Evaluate Alternatives 4. Choose Alternative to Implement 5. Implement Choice

Types of Analytics

1. Descriptive analytics: uses historical data to understand and analyze past business performance. 2. Predictive analytics: applies statistical analysis methods to historical data to identify patterns, and then uses that understanding of relationships and trends to make predictions about future events. 3. Prescriptive analytics: expands on predictive analytics to identify decisions to be made and to initiate appropriate action to improve business performance.

Types of Data Mining

1. Descriptive: such as clustering make it easier to see the patterns in a set of data, such as similarities between customers. 2. Diagnostic: such as decision trees or segmentation can show why a pattern exists, such as the characteristics of an organization's most profitable customers. 3. Predictive: such as regression or neural networks can show how likely something is to be true in the future, such as predicting the probability that a particular claim is fraudulent.

Tech: Focus Group: Elements

1. Focus Group Objectives 2. Focus Group Plan (Activities:) 2.1 Purpose 2.2 Location 2.3 Logistics 2.4 Participants 2.5 Budget 2.6 Timelines 2.7 Outcomes 3. Participants (6-12 & Paid) 4. Discussion Guide 5. Assign a Moderator and Recorder 6. Conduct Focus Group 7. After the Focus Group

Tech: Backlog Mng: Elements

1. Items in the backlog 2. Prioritization 3. Estimation 4. Mng Changes to the Backlog 5.

Tech: Mind Mapping: Elements

1. Main Topic 2. Topics 3. Sub Topics 4. Branches 5. Keywords 6. Colour 7. Images

Tech: Estimation: Elements

1. Methods (Top-Down/Bottom-up/Parametric/Rough Order of Magnitude (ROM)/Rolling Wave/Delphi/PERT 2. Accuracy of Estimate 3. Sources of Info (Analogous Situation/Org History/Expert Judgement) 4. Precision & Reliability of Estimates 5. Contributors to Estimates

Tech: Business Cases: Elements

1. Need Assessment 2. Desired Outcomes 3. Assess Alternatives 3.1 Scope 3.2 Feasibility 3.3 Assumptions, Risks, Constraints 3.4 Financial Analysis/Value Assessment 4. Rocommended Solution

Tech: Review: Elements

1. Objectives 2. Techniques 3. Participants

Tech: Observation: Elements

1. Observation Objectives (Understand activity(tasks,tools,events) / identify opportunities for improv / establish perf metrics / assess solution / validate assumptions) 2. Prepare for Observation 3. Conduct the Observation Session 4. Confirm and Present Observation Results

Tech: Collaborative Games: Steps

1. Opening Step (Learn rules) 2. Exploration (Engage) 3. Closing Step (Assess ideas)

Tech: Document Analysis: Elements

1. Preparation 2. Doc Review & Analysis 3. Record Findings

Tech: Brainstorming: Steps

1. Preparation 2. Session 3. Wrap-up

Tech: Workshop: Elements

1. Prepare for workshop 2. Roles (Sponsor, Facilitator, Scribe, Timekeeper, Participants) 3. Conduct Workshop 4. Post Workshop wrap-up

Tech: Collaborative Games: Types

1. Product Box (Used to help identify features - construct a box and try to sell) 2. Affinity Map (Used to help identify related features - sticky notes) 3. Fishbowl (Used to identify hidden assumptions/perspectives - 2 groups, 1 speaks, other listens)

Tech: Prototyping: Elements

1. Prototyping Approach a) Throw-away b) Evolutionary/Functional 2. Prototyping Examples a) Proof of Principle/Concept (validate, without appearance) b) Form Study Prototype (explore appearance, without functionality) c) Usability Prototype (test how user interacts without appearance) d) Visual Prototype (visual, without functionality) e) Functional Prototype (test software func) 3. Prototyping Methods a) Storyboarding (visual/text sequence of activities different user interactions) b) Paper Prototyping c) Workflow Modelling d) Simulation (test various)

RACI

1. Responsible 2. Accountable 3. Consulted 4. Informed

Onion Diagram - Levels?

1. Solution Delivery (Project team, direct) 2. Affected Org Unit (End users, help desk, affected by) 3. Org / Enterprise (Sponsor, executive, SME, interact with) 4. Affected External Stakeholder (Customer/Supplier/Regulations, etc)

Tech: Stakeholder List, Map, or Personas: Elements

1. Stakeholder Lists 2. Stakeholder Map (Stakeholder Matrix/Onion Diagram)

Process Traceability

1. Value Chain 2. Business Process 3. Sub-Process 4. Activity 5. Task

Datamining Techniques

1. classification and regression trees (CART), C5 and other decision tree analysis techniques, 2. linear and logistic regression, 3. neural networks, 4. support sector machines, and 5. predictive (additive) scorecards.

A Business Analyst is performing financial analysis for the proposed solution, as shown in the image. What is the interest rate considered?

10%. The discount rate also refers to the interest rate used in discounted cash flow (DCF) analysis to determine the present value of future cash flows. *Discounted factor / rate in PV formula* is *1/ (1+i)n. * First Year discounted factor is 0.91, so interest rate = 10%

Tech: Risk Analysis & Mng: Treatment

1• *Avoid*: either the source of the risk is removed, or plans are adjusted to ensure that the risk does not occur. 2• *Transfer*: the liability for dealing with the risk is moved to, or shared with, a third party. 3• *Mitigate*: reduce the probability of the risk occurring or the possible negative consequences if the risk does occur. 4• *Accept*: decide not to do anything about the risk. If the risk does occur, a workaround will be developed at that time. 5• *Increase*: decide to take on more risk to pursue an opportunity.

9.1 Analytical Thinking and Problem Solving

9.1.1 Creative Thinking 9.1.2 Decision Making 9.1.3 Learning 9.1.4 **Problem Solving** 9.1.5 Systems Thinking 9.1.6 **Conceptual Thinking** 9.1.7 Visual Thinking

9.2 Behavioural Characteristics

9.2.1 Ethics 9.2.2 Personal Accountability 9.2.3 **Trustworthiness** 9.2.4 Organization and Time Management 9.2.5 **Adaptability**

9.3 Business Knowledge

9.3.1 **Business Acumen** 9.3.2 Industry Knowledge 9.3.3 Organization Knowledge 9.3.4 **Solution Knowledge** 9.3.5 **Methodology Knowledge**

9.5 Interaction Skills

9.5.1 Facilitation 9.5.2 **Leadership** and Influencing 9.5.3 Teamwork 9.5.4 **Negotiation and Conflict Resolution** 9.5.5 **Teaching**

9.6 Tools and Technology

9.6.1 Office Productivity Tools and Technology 9.6.2 Business Analysis Tools and Technology 9.6.3 Communication Tools and Technology

RADD: REQ ARCH: Completeness

A *complete set of requirements should specify everything that is needed* at the appropriate level of detail. The requirements architecture should help you assess if you have missed anything while building your requirements document. Structuring requirements using different viewpoints also helps with completeness and identifying potential gaps.

methodology

A body of methods, techniques, procedures, working concepts, and rules used to solve a problem

product vision statement

A brief statement or paragraph that describes the goals of the solution and how it supports the strategy of the organization or enterprise.

requirements artifact

A business analysis artifact containing information about requirements such as a diagram, matrix, document or model.

online analytical processing (OLAP)

A business intelligence approach that allows users to analyze large amounts of data from different points of view.

solution requirement

A capability or quality of a solution that meets the stakeholder requirements. Solution requirements can be divided into two sub-categories

functional requirement

A capability that a solution must have in terms of the behaviour and information the solution will manage.

stakeholder list

A catalogue of the stakeholders affected by a change, business need, or proposed solution, and a description of their attributes and characteristics related to their involvement in the initiative.

requirements attribute

A characteristic or property of a requirement used to assist with requirements management.

BA is using two types of indicators for the four dimensions of the balanced scorecard. What are the two types of indicators used?

A combination of Leading and Lagging Indicators are used in balanced score card. Kaplan and Norton call these Performance Drivers" and "Outcome Measures."

gap analysis

A comparison of the current state and desired future state of an enterprise in order to identify differences that need to be addressed.

value stream mapping

A complete, fact-based, time-series representation of the stream of activities required to deliver a product or service.

change team

A cross-functional group of individuals who are mandated to implement a change. This group may be comprised of product owners, business analysts, developers, project managers, implementation subject matter experts (SMEs), or any other individual with the relevant set of skills and competencies required to implement the change.

business decision

A decision that can be made based on strategy, executive judgment, consensus, and business rules, and that is generally made in response to events or at defined points in a business process.

defect

A deficiency in a product or service that reduces its quality or varies from a desired attribute, state, or functionality.

work breakdown structure (WBS)

A deliverable-oriented hierarchical decomposition of the work to be executed to accomplish objectives and create the required deliverables. It organizes and defines the total scope of the project.

metadata

A description of data to help understand how to use that data, either in terms of the structure and specification of the data, or the description of a specific instance of an object.

enterprise architecture

A description of the business processes, information technology, people, operations, information, and projects of an enterprise and the relationships between them.

strategy

A description of the chosen approach to apply the capabilities of an enterprise in order to reach a desired set of goals or objectives.

stakeholder requirement

A description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements.

use case

A description of the observable interaction between an actor (or actors) and a solution that occurs when the actor uses the system to accomplish a specific goal.

business analysis plan

A description of the planned activities the business analyst will execute in order to perform the business analysis work involved in a specific initiative. See also requirements management plan.

business analysis communication plan

A description of the types of communication the business analyst will perform during business analysis, the recipients of those communications, and the form and frequency of those communications.

plan

A detailed scheme for doing or achieving something usually comprising a set of events, dependencies, expected sequence, schedule, results or outcomes, materials and resources needed, and how stakeholders need to be involved.

fishbone diagram

A diagramming technique used in root cause analysis to identify underlying causes of an observed problem, and the relationships that exist between those causes. Also known as an Ishikawa or cause-and- effect diagram.

task (business analysis)

A discrete piece of work that may be performed formally or informally as part of business analysis.

feature

A distinguishing characteristic of a solution that implements a cohesive set of requirements and which delivers value for a set of stakeholders.

work product (business analysis)

A document or collection of notes or diagrams used by the business analyst during the requirements development process.

business analysis package

A document, presentation, or other collection of text, matrices, diagrams and models, representing business analysis information.

Workshop

A facilitated and focused event attended by key stakeholders for the purpose of achieving a defined goal.

mission statement

A formal declaration of values and goals that expresses the core purpose of the enterprise.

request for information (RFI)

A formal elicitation method intended to collect information regarding a vendor's capabilities or any other information relevant to a potential upcoming procurement.

peer review

A formal or informal review of a work product to identify errors or opportunities for improvement. See also inspection.

inspection

A formal review of a work product by qualified individuals that follows a predefined process, and uses predefined criteria, for defect identification and removal.

organizational capability

A function inside the enterprise, made up of components such as processes, technologies, and information and used by organizations to achieve their goals.

force field analysis

A graphical method for depicting the forces that support and oppose a change. Involves identifying the forces, depicting them on opposite sides of a line (supporting and opposing forces) and then estimating the strength of each set of forces.

entity-relationship diagram

A graphical representation of the entities relevant to a chosen problem domain and the relationships between them.

focus group

A group formed to to elicit ideas and attitudes about a specific product, service, or opportunity in an interactive group environment. The participants share their impressions, preferences, and needs, guided by a moderator.

stakeholder

A group or individual with a relationship to the change, the need, or the solution.

swimlane

A horizontal or vertical section of a process diagram that shows which activities are performed by a particular actor or role.

actor (business analysis)

A human, device, or system that plays some specified role in interacting with a solution.

business case

A justification for a course of action based on the benefits to be realized by using the proposed solution, as compared to the cost, effort, and other considerations to acquire and live with that solution.

business process management (BPM)

A management discipline that determines how manual and automated processes are created, modified, cancelled, and governed.

technique

A manner, method, or style for conducting a business analysis task or for shaping its output.

return on investment (ROI) (business analysis)

A measure of the profitability of a

proof of concept

A model created to validate the design of a solution without modelling the appearance, materials used in the creation of work, or processes and workflows ultimately used by the stakeholders.

scope model

A model that defines the boundaries of a business domain or solution.

business policy

A non-practicable directive that controls and influences the actions of an enterprise.

prototype

A partial or simulated approximation of the solution for the purpose of eliciting or verifying requirements with stakeholders.

Personas

A persona is defined as a fictional character or archetype that exemplifies the way a typical user interacts with a product. Personas are helpful when there is a desire to understand the needs held by a group or class of user

change strategy

A plan to move from the current state to the future state to achieve the desired business objectives.

commercial off-the-shelf (COTS)

A prepackaged solution available in the marketplace which address all or most of the common needs of a large group of buyers of those solutions. A commercial off-the-shelf solution may require some configuration to meet the specific needs of the enterprise.

requirements defect

A problem or error in a requirement. Defects may occur because a requirement is poor quality (see requirements verification) or because it does not describe a need that, if met, would provide value to stakeholders (see requirements validation).

business need

A problem or opportunity of strategic or tactical importance to be addressed.

need

A problem or opportunity to be addressed.

governance process (change)

A process by which appropriate decision makers use relevant information to make decisions regarding a change or solution, including the means for obtaining approvals and priorities.

lessons learned process

A process improvement technique used to learn about and improve on a process or project. A lessons learned session involves a special meeting in which the team explores what worked, what didn't work, what could be learned from the just-completed iteration, and how to adapt processes and techniques before continuing or starting anew.

A process that has inputs but no outputs is considered to be a

A process that has inputs but no outputs is considered to be a Black hole process.

request for quote (RFQ)

A procurement method of soliciting price and solution options from vendors.

dynamic systems development method (DSDM)

A project delivery framework which focuses on fixing cost, quality, and time at the beginning while contingency is managed by varying the features to be delivered.

evolutionary prototype

A prototype that is continuously modified and updated in response to feedback from stakeholders.

vertical prototype

A prototype that is used to drill down into a proposed solution to uncover requirement and design considerations through multiple layers of a solution that are not easily understood or that are not discernible on the surface. It may include interaction between several solution components.

horizontal prototype

A prototype that is used to explore requirements and designs at one level of a proposed solution, such as the customer-facing view or the interface to another organization.

throw-away prototype

A prototype used to quickly uncover and clarify requirements or designs using simple tools, sometimes just paper and pencil. It is intended to be discarded when the final system has been developed.

metric

A quantifiable level of an indicator measured at a specified point in time.

estimate

A quantitative assessment of a planned outcome, resource requirements, and schedule where uncertainties and unknowns are systematically factored into the assessment.

repository

A real or virtual facility where all information on a specific topic is stored and is available for retrieval.

A business analyst is working in the e-commerce industry. Solution construction for a set of requirements is in progress. At the end of the iteration, completed work is reviewed in order to provide feedback. Which of the estimation techniques is most likely to be used by the team?

A relative estimation technique is most likely to be used by the team.

model

A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication, and understanding.

business requirement

A representation of goals, objectives and outcomes that describe why a change has been initiated and how success will be assessed.

stated requirement

A requirement articulated by a stakeholder that has not been analyzed, verified, or validated. Stated requirements frequently reflect the desires of a stakeholder rather than the actual need.

transition requirement

A requirement that describes the capabilities the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature.

verified requirement

A requirement that has been reviewed and is determined to be defined correctly, adheres to standards or guidelines, and is at an acceptable level of detail.

validated requirement

A requirement that has been reviewed and is determined to support the delivery of the expected benefits, and is within the solution scope.

request for proposal (RFP)

A requirements document issued when an organization is seeking a formal proposal from vendors. An RFP typically requires that the proposals be submitted following a specific process and using sealed bids which will be evaluated against a formal evaluation methodology.

walkthrough

A review in which participants step through an artifact or set of artifacts with the intention of validating the requirements or designs, and to identify requirements or design errors, inconsistencies, omissions, inaccuracies, or conflicts.

Roles & Permission Matrix

A roles and permissions matrix is used to ensure coverage of activities by denoting responsibility, to identify roles, to discover missing roles, and to communicate results of a planned change. 1. Identify Role 2. Identify Activities 3. Identify Authorities 4. Refinement (Delegation/Inheritance)

definitional business rule

A rule that indicates something is necessarily true (or untrue); a rule that is intended as a definitional criterion for concepts, knowledge, or information. Also known as a structural rule.

life cycle

A series of changes an item or object undergoes from inception to retirement

process

A set of activities designed to accomplish a specific objective by taking one or more defined inputs and turning them into defined outputs.

quality assurance

A set of activities performed to ensure that a process will deliver products that meet an appropriate level of quality.

viewpoint

A set of conventions that define how requirements will be represented, how these representations will be organized, and how they will be related.

questionnaire

A set of defined questions, with a choice of answers, used to collect information from respondents.

process model

A set of diagrams and supporting information about a process and factors that could influence the process. Some process models are used to simulate the performance of the process.

quality attributes

A set of measures used to judge the overall quality of a system. See also non-functional requirements.

product backlog

A set of user stories, requirements, or features that have been identified as candidates for potential implementation, prioritized, and estimated.

interface

A shared boundary between any two persons and/or systems through which information is communicated.

iteration (business analysis)

A single instance of progressive cycles of analysis,

user story

A small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.

What is a solution (set of)

A solution is a set of changes to the current state of an organization made in order to enable the organization to meet a business need, solve a problem, or take advantage of an opportunity. It is the basis for the project scope that implements the solution and its components.

product (business analysis)

A solution or component of a solution that is the result of an initiative.

requirements package

A specialized form of a business analysis package primarily concerned with requirements. A requirements package may represent a baseline of a collection of requirements.

indicator

A specific numerical measurement that indicates progress toward achieving an impact, output, activity, or input. See also metric.

initiative

A specific project, program, or action taken to solve some business problem(s) or achieve some specific change objective(s).

solution

A specific way of satisfying one or more needs in a context.

business rule

A specific, practicable, testable directive that is under the control of the business and that serves as a criterion for guiding behaviour, shaping judgments, or making decisions.

supplier

A stakeholder outside the boundary of a given organization or organizational unit who provides products or services to the organization and may have contractual or moral rights and obligations that must be considered.

end user

A stakeholder who directly interacts with the solution.

implementation subject matter expert

A stakeholder who has specialized knowledge regarding the implementation of one or more solution components.

sponsor

A stakeholder who is responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize the work to be performed and control the budget and scope for the initiative.

project manager

A stakeholder who is responsible for managing the work required to deliver a solution that meets a business need, and for ensuring that the project's objectives are met while balancing the project constraints,

operational support

A stakeholder who is responsible for the day-to-day management and maintenance of a system or product.

customer

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

domain subject matter expert

A stakeholder with in-depth knowledge of a topic relevant to the business need or solution scope.

checklist (business analysis)

A standard set of quality elements that reviewers use for requirements verification.

competitive analysis

A structured assessment which captures the key characteristics of an industry to predict the long-term profitability prospects and to determine the practices of the most significant competitors.

requirements workshop

A structured meeting in which a carefully selected group of stakeholders collaborate to define and/or refine requirements under the guidance of a skilled neutral facilitator.

solution component

A sub-part of a solution that can be people, infrastructure, hardware, software, equipment, facilities, and process assets or any combination of these sub-parts.

requirements management plan

A subset of the business analysis plan for a specific change initiative, describing specific tools, activities, and roles and responsibilities that will be used on the initiative to manage the requirements. See business analysis plan.

Tech: Survey / Questionnaire

A survey or questionnaire is used to elicit business analysis information—including information about customers, products, work practices, and attitudes—from a group of people in a structured way and in a relatively short period of time. *Closed-Ended* or *Open-ended* ----- Elements: 1. Prepare (Define Objective, target group, type, sample, distribution channel, timeliness, test) 2. Distribute (urgency, security, geographic) 3. Document Results (collect, summarize, evaluate, formulate, breakdown to measurable increments)

enterprise

A system of one or more organizations and the solutions they use to pursue a shared set of common goals.

decomposition

A technique that subdivides a problem into its component parts in order to facilitate analysis and understanding of those components.

project

A temporary endeavour undertaken to create a unique product, service, or result.

Tech: Glossary: Elements

A term is included in the glossary when: • the term is unique to a domain, • there are multiple definitions for the term, • the definition implied is outside of the term's common use, or • there is a reasonable chance of misunderstanding.

matrix

A textual form of modelling used to represent information that can be categorized, cross-referenced, and represented in a table format.

suppliers, inputs, process, outputs, and customers (SIPOC)

A tool used to describe relevant high-level elements of a process. May be used in conjunction with process mapping and 'in/out of scope' tools, to provide additional detail.

responsible, accountable, consulted, and informed matrix (RACI matrix)

A tool used to identify the responsibilities of roles or team members and the activities or deliverables in which they will participate, by being responsible (doing the work), accountable (approving the results), consulted (providing input) or informed of the completed item after it has been completed.

create, read, update, and delete matrix (CRUD matrix)

A two-dimensional matrix showing which user roles have permission to access specific information entities, and to create new records in those entities, view the data in existing records, update or modify the data in existing records, or delete existing records. The same type of matrix can be used to show which processes, instead of users, have the create, read, update and delete rights.

use case diagram

A type of diagram defined by UML® that captures all actors and use cases involved with a system or product.

sequence diagram

A type of diagram that shows objects participating in interactions and the messages exchanged between them.

non-functional requirement

A type of requirement that describes the performance or quality attributes a solution must meet. Non-functional requirements are usually measurable and act as constraints on the design of a solution as a whole.

component

A uniquely identifiable element of a larger whole that fulfills a clear function.

requirement

A usable representation of a need.

design

A usable representation of a solution. For more information see Key Terms (p. 14) and Requirements and Designs (p. 19).

Tech: User Stories

A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder. Used for: Capture need, estimating, user acceptance test, metric, tracing, additional analysis, reporting -- Elements: 1. Title 2. Statement of value (Who, What, Why) 3. Conversation 4. Acceptance Criteria

Tech: Vendor Assessment

A vendor assessment assesses the ability of a vendor to meet commitments regarding the delivery and the consistent provision of a product or service. Elements: 1. Knowledge and Expertise 2. Licensing / Pricing Models 3. Vendor Market Position 4. Terms and Conditions 5. Vendor Experience, Repution, Stability

statement of work (SOW)

A written description of the services or tasks that are required to be performed.

interoperability

Ability of systems to communicate by exchanging data or services.

Which of the following is not a valid evaluation criteria?

Ability to provide high quality dataset is one of the acceptance criteria to be considered before you decide if the solution is worth implementing. The others are evaluation criteria.

Which of the following sets of techniques is best to define future state in the case study?

According to Case study: Process modeling, Vendor assessment, Interviews, Workshops, etc. are most likely to be used to define the future state. Vendor assessment is important; it is used to assess potential value provided by vendor solution option.

Stakeholders

All tasks come with a generic list of stakeholders who *may be involved in performing that task* or who *might be affected* by the task and its outcome. Interestingly enough, the business analyst is a stakeholder for every business analysis activity found in the BABOK® Guide. This makes perfect sense—the business analyst is responsible and accountable for making sure that these tasks are done and done well. Remember that earlier in this chapter we took a look at the key generic stakeholder roles that typically interact with business analysts on their projects.

requirements model

An abstract (usually graphical) representation of some aspect of the current or future state.

secondary actor

An actor external to the system under design that supports the execution of a use case.

time-box

An agreed-upon period of time in which an activity is conducted or a defined deliverable is intended to be produced.

state diagram

An analysis model showing the life cycle of a data entity or class.

concept model

An analysis model that develops the meaning of core concepts for a problem domain, defines their collective structure, and specifies the appropriate vocabulary needed to communicate about it consistently.

strengths, weaknesses, opportunities, and threats analysis (SWOT)

An analysis model used to understand influencing factors and how they may affect an initiative. Also known as SWOT analysis.

cost-benefit analysis

An analysis which compares and quantifies the financial and non-financial costs of making a change or implementing a solution compared to the benefits gained.

decision analysis

An approach to decision making that examines and models the possible consequences of different decisions, and assists in making an optimal decision under conditions of uncertainty.

predictive approach

An approach where planning and baselines are established early in the life cycle of the initiative in order to maximize control and minimize risk.

adaptive approach

An approach where the solution evolves based on a cycle of learning and discovery, with feedback loops which encourage making decisions as late as possible.

knowledge area (business analysis)

An area of expertise that includes several specific business analysis tasks.

impact analysis

An assessment of the effects a proposed change will have on a stakeholder or stakeholder group, project, or system.

business process

An end-to-end set of activities which collectively responds to an event, and transforms information, materials, and other resources into outputs that deliver value directly to the customers of the process. It may be internal to an organization, or it may span several organizations.

feasibility study

An evaluation of proposed alternatives to determine if they are technically, organizationally, and economically possible within the constraints of the enterprise, and whether they will deliver the desired benefits to the enterprise.

document analysis (business analysis)

An examination of the documentation of an existing system in order to elicit requirements.

tester

An individual responsible for determining how to verify that the solution meets the requirements defined by the business analyst, and conducting the verification process.

constraint (business analysis)

An influencing factor that cannot be changed, and that places a limit or restriction on a possible solution or solution option.

assumption

An influencing factor that is believed to be true but has not been confirmed to be accurate, or that could be true now but may not be in the future.

guideline (business analysis)

An instruction or description on why or how to undertake a task.

external interface

An interaction that is outside the proposed solution. It can be another hardware system, software system, or a human interaction with which the proposed solution will interact.

Tech: Interviews

An interview is a systematic approach designed to elicit business analysis information from a person or group • Structured Interview: in which the interviewer has a predefined set of questions. • Unstructured Interview: in which the interviewer does not have a predetermined format or order of questions. Questions may vary based on interviewee responses and interactions.

business problem

An issue of strategic or tactical importance preventing an enterprise or organization from achieving its goals.

business objective

An objective, measurable result to indicate that a business goal has been achieved.

event (business analysis)

An occurrence or incident to which an organizational unit, system, or process must respond.

request for tender (RFT)

An open invitation to vendors to submit a proposal for goods or services.

Which element has scope of decision making at various levels

Analyzing the current state and its capabilities has eight elements: business needs, organizational structure and culture, capabilities and processes, technology and infrastructure, policies, business architecture, internal assets, and external influences. *The scope of decision making at different levels in the organization is part of the policies element.*

business analysis information

Any kind of information at any level of detail that is used as an input to business analysis work, or as an output of business analysis work.

business analyst

Any person who performs business analysis, no matter their job title or organizational role. For more information, see Who is a Business Analyst? (p. 2).

organizational unit

Any recognized association of people within an organization or enterprise.

artifact (business analysis)

Any solution-relevant object that is created as part of business analysis efforts.

deliverable

Any unique and verifiable work product or service that a party has agreed to deliver.

user acceptance test (UAT)

Assessing whether the delivered solution meets the needs of the stakeholder group that will be using the solution. The assessment is validated against identified acceptance criteria.

SA: FSD: Internal Assets

Assets are tangible and intangible parts of the future state description. The future state *may require new assets* or more capabilities from existing assets.

SA: CSD: Internal assets

Assets are the tangible and intangible parts of the current state description. They include *financial resources, patents, reputation, and brand names*.

9 Characteristics of Well-Written Requirements

Atomic Complete Consistent Concise Feasible Unambiguous Testable Prioritized Understandable C3ATPUUF

Guideline / Input into all BAPM tasks

BAPA

SE: APM: Trends

Be sure to consider the time period over which performance measurement data is being collected. A *large time period and a good sample size of data yields a more accurate view* of a solution's performance.

5 Areas for Assessing the impact of proposed change to Requirement

Benefit Cost Impact Schedule Urgency

Factors that influence Prioritization

Benefit Penalty Cost Risk Dependencies Time sensitivity Stability Regulatory or policy compliance

Which of the following criteria are considered in the ranking approach of prioritization which was suggested by Karl E. Wiegers, an American software engineer?

Benefit, Penalty, Cost, Risk

BAMP: PBAG: Techniques

Brainstorming As part of business analysis planning, decomposing and understanding the business analysis tasks and deliverables sufficiently enables effective planning. Document Analysis Be sure to review existing governance processes or templates used for business analysis activities or for the overall project. The existing processes may have an impact on how to define and perform governance as part of your project. Interviews The business analysis team may use interviews as a method to identify and select individuals who are responsible for business analysis decision-making, change control, prioritization, or approval activities. Item Tracking For many business analysts, item tracking is synonymous with issue management. Be sure to keep track of your issues while planning your governance approach. Lessons Learned There is no need to reinvent the wheel or to make the same mistakes when defining business analysis governance. Effective business analysts use lessons learned on previous projects to keep them on track with their own planning efforts. Organizational Modelling Organizational models show the relationships between stakeholders and the roles and responsibilities the stakeholders have within the organization. Process Modelling Many business analysts use process models to document the process or flow of business analysis decision making. Reviews Don't forget to review your governance approach with your key stakeholders and get their buy-in and approval on how decisions will be made and how change control will be used. Survey or Questionnaire The business analysis team may use surveys or questionnaires as ways to identify and select individuals who are responsible for business analysis decision-making, change control, prioritization, or approval activities. Workshops Workshops are excellent ways to work with a group and identify and select individuals who are responsible for business analysis decision-making, change control, prioritization, or approval activities.

BAPM: PBA: Techniques

Brainstorming Brainstorming is an excellent way for the business analysis team to generate a list of all possible business analysis activities, techniques, or risks for the business analysis approach. Business Cases Experienced business analysts look to the project's business case for timesensitive, high-value aspects of the problem or opportunity that is being addressed. Document Analysis This technique is used to review existing organizational assets that might assist in planning the business analysis approach. Financial Analysis Financial analysis allows you to assess how different approaches and delivery options affect the value being delivered to the enterprise. Functional Decomposition Functional decomposition is pretty much what it sounds like it would be, breaking down complex business analysis activities into smaller and easily understood pieces. It is a critical part of business analysis planning; understanding the business analysis tasks and deliverables sufficiently enables effective estimating. Interviews When interviewing key stakeholders, the business analyst should always ask the interviewees to identify additional information that might fit as part of the business analysis approach. Item Tracking This technique is used to track issues or risk-related items encountered while planning the business analysis approach. Items may be opened for the project that relate to business analysis activities. These items should be addressed and resolved by the business analysis team. Lessons Learned Effective business analysts compile and document successes, failures, and recommendations for improving the performance of business analysis activities on their projects. Be sure to use your previous experiences (both good and bad) when building your business analysis approach. Process Modelling Process models document the steps of the business analysis approach or process for a project. Think of graphically depicting a series of business analysis process steps on a whiteboard with arrows between them to show the sequence of events. That is a simple process map that can be used to build and decide on a business analysis approach. Reviews Experienced business analysts use reviews to validate the business analysis approach with key stakeholders and team members. This is a meeting with a tour guide. Your destination is the business analysis approach, and your meeting agenda will walk you through the possibilities in order for the group to decide on the approach that is right for their project. Risk Analysis and Management Remember that the results of planning the business analysis approach may contribute to the risks for the business analysis effort and to the project. The people involved with your efforts can be the source of possible risks, and they can also help the team identify additional risks that may be important downstream. Scope Modelling Scope models help you determine the boundaries of the solution and its scope as an input to the planning and estimating activities. Survey or Questionnaire Business analysts may use this technique to identify possible business analysis activities, techniques, and risks to help build the contents of the business analysis approach. Workshops Conducting workshops allows you to build the business analysis approach in a team setting. The business analyst should always ask the participants about any additional activities, techniques, or risks that should be considered for inclusion in the approach.

BAPM: BAIMA: Techniques

Brainstorming Brainstorming with stakeholders helps them uncover and share ideas about what their business analysis information management needs might be. Interviews The business analysis team uses interviews with stakeholders as a way to identify and define their business analysis information management needs. Item Tracking This technique allows for managing and tracking of issues discovered relative to information management needs on your project or initiative. Lessons Learned Be sure to review existing information management tools, processes, and techniques used in your organization. The existing methods may have an impact on how to define and perform information management as part of your project. Mind Mapping Mind mapping allows the business analysis team to identify and categorize business analysis information that needs to be managed. Process Modelling Process models graphically depict the process used to manage business analysis information. These models can help your stakeholders understand how to manage requirements, designs, and other data on your projects. Survey or Questionnaire Many business analysts use this technique to remotely request stakeholder input about their business analysis information management needs. Workshops Workshops allow you to discover business analysis information needs from groups of stakeholders versus asking people one by one.

Which set of techniques can be used together in one session?

Brainstorming, Affinity Grouping, and Multi-voting are approaches for generating, categorizing, and choosing among ideas from a group of people.

BSC - How well is the business performing dimension

Business Process Dimension

BAPM: Deliverables

Business analysis approach Stakeholder engagement approach Governance approach Information management approach Business analysis performance assessment

SE: ASL: Investigating Solution Problems

Business analysts often *use problem analysis techniques* to investigate solution performance problems. It is *essential to identify the source of the problem* so the problem *can be addressed* and corrected. Problems may be indicated by an inability to meet a goal or objective or by a failure to realize a benefit. Solution outputs may not be of sufficient quality, or potential value may not be realized.

SE: APM: Accuracy

Business analysts test and analyze solution performance data to make sure the data is accurate and reliable. The *results of accurate and reliable performance measures can be reproduced and repeated*.

SA: FSD: Elements

Business goals and objectives Scope of solution space Constraints Organizational structure and culture Capabilities and processes Technology and infrastructure Policies Business architecture Internal assets Assumptions Potential value

SA: CSD: Elements

Business needs Organizational structure and culture Capabilities and processes Technology and infrastructure Policies Business architecture Internal assets External influencers

What is another name for an organized peer-level review of a requirements document?

Business rules analysis Structured walkthroughs are organized peer-level or team reviews of project deliverables, such as requirements. Attendees are looking for errors or omissions in the requirements.

Categories of Non Functional Requirements

C*2*REAMCUP*2*S*3* FL Availability: degree to which the solution is operable and accessible when required for use, often expressed in terms of percent of time the solution is available. • Compatibility: degree to which the solution operates effectively with other components in its environment, such as one process with another. • Functionality: degree to which the solution functions meet user needs, including aspects of suitability, accuracy, and interoperability. • Maintainability: ease with which a solution or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment. • Performance Efficiency: degree to which a solution or component performs its designated functions with minimum consumption of resources. Can be defined based on the context or period, such as high-peak, mid- peak or off-peak usage. • Portability: ease with which a solution or component can be transferred from one environment to another. • Reliability: ability of a solution or component to perform its required functions under stated conditions for a specified period of time, such as mean time to failure of a device. • Scalability: degree with which a solution is able to grow or evolve to handle increased amounts of work. • Security: aspects of a solution that protect solution content or solution components from accidental or malicious access, use, modification, destruction, or disclosure. • Usability: ease with which a user can learn to use the solution. • Certification: constraints on the solution that are necessary to meet certain standards or industry conventions. • Compliance: regulatory, financial, or legal constraints which can vary based on the context or jurisdiction. • Localization: requirements dealing with local languages, laws, currencies, cultures, spellings, and other characteristics of users, which requires attention to the context. • Service Level Agreements: constraints of the organization being served by the solution that are formally agreed to by both the provider and the user of the solution. • Extensibility: the ability of a solution to incorporate new functionality.

Despite this, there are a few stakeholders who are resistant to change and are not supporting business analysis activities. What could be the most probable reason?

Change in stakeholder impact and interest .. The most probable reason is a change in stakeholder impact and interest level. Stakeholder management is iterative. During execution, there may be changes in stakeholder impact and interest level; hence, stakeholder engagement strategy has to change so that stakeholders remain engaged and supportive of the business analysis activities

RCLM is affected by which deliverables?

Change strategy Governance approach Information management approach

RADD: VERIFY: Checklists

Checklists are an *excellent quality control technique* to apply to your requirements documentation. *Checklists ensure that important items are included in the final requirements deliverables* for your project, such as the nine characteristics of well-written requirements previously discussed. Checklists may also contain process steps to guide you through the requirements verification activities that should be done on your project.

survey

Collecting and measuring the opinions or experiences of a group of people through a series of questions.

monitoring

Collecting data on a continuous basis from a solution in order to determine how well a solution is implemented compared to expected results. See also metric; indicator.

Which data model is not concerned with table and columns?

Conceptual and Logical models are not concerned with table and columns. Physical Models are concerned with table and columns.

SA: FSD: Constraints

Constraints limit the current state as well as the planned future state. Constraints may not change as part of the solution. Constraints come in many flavors, such as *budget, time, technology, infrastructure, policy, resources, team member skills, and regulations*.

The healthcare industry is heavily regulated. Which technique is most useful in developing a clear understanding of a solution scope?

Context Diagram The context diagram provides a very structured approach to asking questions that helps stakeholders determine the boundaries of their request. The context diagram shows the solution or product as a circle in the center of the diagram. It does not show any details inside the solution. It shows the outside forces that will be important for the solution, resting on the idea that if you understand everything that is outside the scope but has an impact on the scope, you, by definition, have defined the scope.

change control

Controlling changes to requirements and designs so that the impact of requested changes is understood and agreed-to before the changes are made.

acceptance criteria

Criteria associated with requirements, products, or the delivery cycle that must be met in order to achieve stakeholder acceptance.

Requirements that are intended for reuse reflect what view of the organization?

Current state Requirements that are intended for reuse reflect the current state of the organization.

SE: RAtoISV: Stakeholders

Customer Domain SME End user Regulator Sponsor

SE: ASL : Stakeholders

Customer Domain SME Regulator Sponsor Tester

SA: CSD: Stakeholder

Customer Domain SMEs and end users Implementation SME Operational support Project manager Regulator Supplier Tester

RLCM: APPROVE REQ: Stakeholders

Customers Domain SMEs End users Operational support Regulators Sponsor Testers

RCLM: TRACE: Stakeholders

Customers Domain subject matter experts (SMEs) End users Implementation SMEs Operational support Sponsor Suppliers Testers

SA:FSD: Stakeholders

Customers and Suppliers Domain SME End user Implementation SME Operational support Project manager Regulator Tester

According to the case study, which of the following business analysis techniques is not used when configuring a proposed cloud-based solution with minimum customization?

Data models may not be considered when configuring a proposed cloud-based solution. Consider full state of business rule to create decision table and decision model. Change the existing processes so that they are aligned with the new solution. This will minimize customization, out-of-the-box capabilities, and trade-off between customization and process changes. Map existing roles and responsibilities with roles and permissions available in the new solution.

SA: CSD: Policies

Day-to-day *decision making in an enterprise is defined by policies* at different organizational levels. Any policies that may have an impact on the change being proposed need to be identified and understood.

SA: FSD: Policies

Day-to-day decision making in an enterprise is defined by policies at different organizational levels. These *policies might need to change as part of the desired future state. Policies also have a bad habit of constraining the solution space for the future state*, so stay alert for these possible issues and roadblocks.

RLCM: TRACE: Elements

Deciding the level of formality Selecting the relationships to be traced Documenting and maintaining the traced requirements

BAMP: PBAG: Elements

Decision making Change control process Plan the prioritization approach Plan for approvals

What is required before the implementation team or solution delivery team starts constructing or developing a solution?

Define Solution Approach. Requirements are allocated between organizational units, job functions, and solution components to maximize solution value. Requirements allocation typically begins when a solution approach has been determined and lasts until all valid requirements are allocated. Allocation typically continues through design and implementation of a solution.

Bottom up

Defining a business need from the bottom up occurs when you are *looking at the current state* of an existing system and *trying to figure out how to improve* the efficiency of that system.

RADD: DDO: Elements

Defining solution approaches Identifying improvement opportunities Allocating requirements Describing design options

SE: MSP: Elements

Defining solution performance measures Validating solution performance measures Collecting solution performance measures

RLCM: PRIORITIZE: Elements

Defining the basis or criteria for prioritizing requirements Considering challenges of prioritization Address continual prioritization

5 Common Traceability Relationships between Requirements

Derive Depends/Necessity Depends/Effort Satisfy Validate

RADD: APotVal: Elements

Describing expected benefits Defining expected costs Determining value Assessing design options and recommending a solution

One of the domain subject matter experts has performed informal review of the work product and has provided feedback. Which of the following review techniques is used?

Desk Check is a technique in which the reviewer performs review of the work product and provides formal or informal feedback.

RLCM: ASSESS R CHANGES: Elements

Determine the change assessment *formality*. Perform an *impact analysis*. Provide *impact resolution* for the proposed change.

prioritization

Determining the relative importance of a set of items in order to determine the order in which they will be addressed.

A business analyst working in the e-commerce industry periodically evaluates the performance of the deployed solution and feedback from end users to identify a set of requirements to be addressed in the next release. The list of solution enhancements has been analyzed further to ensure that enhancements are aligned with the organization strategy and may increase value of the implemented solution. What should the BA do next?

Develop release plan. The business analyst will develop overall strategy. One of the important elements is developing transition state and release planning.

Which of the following is not correct with regard to the root cause analysis shown in the diagram?

Does not Help: Root cause analysis doesn't help in understanding the relationship between causes, i.e., how one cause affects another cause. .. .. Helps: Root cause analysis helps in identifying causes contributing to the problem 5 Why technique is used while identifying causes Further analysis is required on the causes

SE: AEL: Stakeholders

Domain SMEs End Users Customer Regulator Sponsor

RLCM: MAINTAIN: Stakeholders

Domain SMEs Implementation SMEs Support Regulators Testers

BAPM: BAIMA: Stakeholders

Domain SMEs Regulators The sponsor

BAPM: PBA: Stakeholders

Domain subject-matter expert (SME) Project manager Regulator Sponsor

When/Why to Plan Stakeholder Engagement

Done as long as business analysis work *continues* NOT Conducted *during* the project phase to which it applies (*but PRIOR to*) Performed *as soon as the business need is identified* Determines stakeholder *influence and levels of authority*

Purpose .

Each task starts off with a short description of its purpose: *why that task is needed* and what *value performing the task* creates.

experiment

Elicitation performed in a controlled manner to make a discovery, test a hypothesis, or demonstrate a known fact.

interview

Eliciting information from a person or group of people in an informal or formal setting by asking relevant questions and recording the responses.

RADD: APotVal: Stakeholders

End-Users Project Managers Customer Domain SME Implementation SME Regulator Sponsor

SE: AEL: Elements

Enterprise culture assessment Stakeholder impact analysis Organizational structure changes Operational assessment

He or she would like a way to quickly and fairly determine which solution is the best choice for the organization. Which of the following is the best approach that would allow you to determine the most viable solution?

Establish criteria for evaluating solution and determine rank based on the *score*. Best practice is to establish 3 to 9 criteria. You may assign different weightage to each criterion, and total weight should be 1 or 100%.

SA: CSD: External influencers

External influences add constraints, dependencies, or drivers to the description and understanding of the current state of things. There are many sources of external influences on an enterprise, including *industry structure, competitors, customers, suppliers, the political and regulatory environment, technology, and macroeconomic factors such as unemployment or inflation*.

Functional Requirements (capabilities)

Functional requirements *define* the *capabilities that a product or solution must provide* to its users. They are a subset of the solution requirements that the business analyst develops for the project.

According to the case study, which one of the following is a high-priority solution requirement?

Functionality via web service so that it's easier to integrate with other system is a high-priority solution requirement.

3 Aspects of Stakeholder Impact Analysis

Functions Locations Concerns

"Requirements State: Prioritized"

Having an *attribute* describing its *relative importance* or assigned priority to stakeholders and the organization

"Requirements State: Traced"

Having* clearly defined and identified relationships* to other requirements or designs *within the solution scope*

stakeholder analysis

Identifying and analyzing the stakeholders who may be impacted by the change and assess their impact, participation, and needs throughout the business analysis activities.

RADD: VALIDATE: Elements

Identifying any assumptions Defining measurable evaluation criteria Evaluating your alignment with the solution scope

SE: ASL: Elements

Identifying internal solution component dependencies Investigating solution problems Performing an impact assessment

risk assessment

Identifying, analyzing and evaluating risks.

Which of the following is a review role in which the participant should be neutral?

In a review meeting, a neutral participant plays the roles of facilitator and scribe.

When defining your approach to requirements traceability on your project, what levels will you choose from when deciding how to trace the requirements?

Individual, model, or feature Requirements tracing may be done at the individual requirement level, at the model level, at the package level, or at the feature level.

input (business analysis)

Information consumed or transformed to produce an output. An input is the information necessary for a task to begin.

Inputs

Inputs consist of the information and *preconditions* tasks require so that *task can begin*. These inputs must be usable by the task that needs them. Single or multiple business analysis tasks produce inputs externally.

Tech: Interface Analysis: Elements

Interface analysis is used to identify where, what, why, when, how, and for whom information is exchanged between solution components or across solution boundaries. .1 Preparing for Identification .2 Conduct Interface Identification .3 Define Interfaces

Tech: Item Tracking: Elements

Item tracking is used to capture and assign responsibility for issues and stakeholder concerns that pose an impact to the solution. 1. Item Record (Item identifier / Summary / Category / Type / Date Identified / Identified by / Impact / Priority / Resolution Date / Owner / Resolver / Agreed Strat / Status / Resolution Updates / Escalation Matrix) 2. Item Management 3. Metrics

elicitation

Iterative derivation and extraction of information from stakeholders or other sources.

Which of the following techniques can a business analyst use to understand which feature will drive customer satisfaction?

Kano analysis technique is used to understand which feature will drive customer satisfaction.

Which of the following is the best strategy when stakeholder impact on business analysis activity is high and influence of stakeholders is low?

Keep the stakeholders informed when stakeholder impact on business analysis activity is high and influence of stakeholder is low

Level 0 Data Flow Diagram. This is also known as:

Level 0 Data Flow Diagram is also known as Context Diagram.

Which of the following parties may be combined in Level 0 Data Flow Diagram (Figure 1)?

Level 0 Data Flow Diagram or Context Diagram is a scope model. At this level, lab technicians and reception staff are employees. Each specific role can be in Level 1, 2, and 3 diagrams as appropriate.

RCLM: MAINTAIN: Tasks

Maintain requirements. Maintain attributes. Reusing requirements

RCLM: MAINTAIN: Maintain Requirements

Maintained requirements and designs are *correct, up-to-date and available across the business analysis life cycle* as well as the project life cycle. The business analysis team is *responsible for keeping requirements current and correct* while they are being developed and when a change is requested and approved.

RADD: REQ ARCH: Template Architectures

Many business analysts *use predefined, template architectures* as the starting point for building a custom requirements architecture. These architectural frameworks are typically a collection of standard viewpoints across the organization

SE: Tasks

Measure solution performance. Analyze performance measures. Assess solution limitations. Assess enterprise limitations. Recommend actions to increase solution value.

Tech: Metrics & KPI

Metrics and key performance indicators measure the performance of solutions, solution components, and other matters of interest to stakeholders. 1. Indicators (Results...) (CREATQ) (Clear / Relevant / Economical / Adequate / Quantifiable / Trustworthy&Credible) 2. Metrics (Objective to reach...) 3. Structure (data collection/analysis...) 4. Reporting (Compare baseline, metrics, target...)

What is a model

Model is a descriptive and visual way to convey information

RADD: S&M REQ: Elements

Model requirements. Analyze requirements. Represent requirements and attributes. Implement appropriate levels of abstraction.

During Business Analysis Planning and Monitoring, business analysts choose a business analysis approach that provides adequate analysis for the change. This relates to which core concept of the Business Analysis Core Concept Model (BACCM)

Need A problem or opportunity to be addressed. During Business Analysis Planning and Monitoring, business analysts choose a business analysis approach that provides adequate analysis for the change.

A Business Analyst is performing financial analysis for the proposed solution, as shown in the image. What is Net Present Value (NPV)?

Net Present Value (NPV) = Sum of PV of all years

Tech: Financial Analysis: Internal Rate of Return

Net Present Value = (-1 x Original Investment) + Sum of (net benefit for that period / (1 + IRR) for all periods) = 0. The internal rate of return (IRR) is the interest rate at which an investment breaks even, and is usually used to determine if the change, solution or solution approach is worth investing in. T

Tech: Financial Analysis: Net Present Value

Net Present Value = Present Value - Cost of Investment

Which of the following is not a scope modeling type for exploring relationship?

Non-Functional-Responsibility is not a scope modeling type for exploring relationship.

Tech: Non-Functional Requirements Analysis

Non-functional requirements analysis examines the requirements for a solution that define how well the functional requirements must perform .1 Categories of Non-Functional Requirements (AC3-FMP2-RS3ULE) .2 Measurement of Non-Functional Requirements .3 Context of Non-Functional Requirements

A business analyst needs to define service-level expectation from a third party. Which of the following may be used to define service level expected from a third party?

Non-functional requirements may be used to define service level expected from a third party.

Which of the following key concepts is not needed to plan stakeholder engagement?

Not Needed: Stakeholder Requirements Needed: Stakeholder Analysis. Stakeholder Collaboration. Stakeholder Communication needs

Paul is helping the business analyst to understand what capability is. Which one of the following is not true with regard to capability?

Not True: A capability is a process or value stream True: Capabilities are purely business views of the business Capabilities are unique, based on the information they require and use Capabilities can be framed by the roles and resources that have those capabilities .. A process or value stream stands out because it veers into "how" something is being done. It's not about "what" is being done. A business capability defines "what" a business does at its core. This differs from "how" things are done or where they are done.

Explain Object Diagrams

Object diagrams can be used to illustrate particular instances of entities from a data model. They can include actual sample values for the attributes, making object diagrams more concrete and more easily understood.

Tech: Observation: Approaches

Observation is used to elicit information by viewing and understanding activities and their context ----- There are two basic approaches for observation: 1• *Active/Noticeable*: while observing an activity the observer asks any questions as they arise. Despite this interruption to the work flow, the observer can more quickly understand the rationale and hidden processes underlying the activity, such as decision making. A variation of this method may involve even stronger intervention into actors' activities by stimulating them to perform specific tasks. This kind of facilitated observation allows focus on the observer's objectives in order to shorten observation time or elicit specific information. 2• *Passive/Unnoticeable*: during the activity the observer does not interrupt the work. Any concerns are raised once the observation is over. This allows observation of a natural flow of events without intervention by the observer, as well as measurement of the time and quality of work. A variation of this method is video recording the activity and then reviewing it with the person being observed so they may provide further clarification.

Which of the following is not true about observation technique?

Observation technique is not a substitute for business sponsor engagement. Business sponsor engagement is necessary to connect knowledge gained from end-users to higher-level company strategy.

SA: FSD: Capabilities and processes

Once you have a handle on the current capabilities, it's time to *consider the new capabilities* that may be needed to meet the business need. The business analyst is responsible for modelling and describing these new capabilities. One common way to do this is called *gap analysis: defining what it will take to eliminate or minimize the gap between the current capabilities and the desired future state.*

core concept (business analysis)

One of six ideas that are fundamental to the practice of business analysis

solution option

One possible way to satisfy one or more needs in a context.

Which of the following strategies for solution replacement may have more business risk than any other strategy?

One time cutover strategy for solution replacement may have more business risk than any other strategy.

Which of the following is not a kind of actor?

Onstage actor is not a kind of actor in the use case diagram.Primary actor fulfils user goals using services of the System under Discussion (SuD). Supporting actor provides a service to the SuD. Offstage actor has an interest in the behavior of the use case, but is not the primary or supporting actor.

Tech: Org Modelling: Elements

Organizational modelling is used to describe the roles, responsibilities, and reporting structures that exist within an organization and to align those structures with the organization's goals. 1. Types of Org Models 1.1 Functionally-orientated (based on shared skills/expertise) 1.2 Market-oriented 1.3 Matrix Model 2. Roles 3. Interfaces 4. Org Charts 5. Influencers

BAMP: PBAIM: Elements

Organize business analysis information. Define the levels of abstraction. Decide the traceability approach. Plan for requirements reuse. Look at information storage and access. Select requirements attributes.

Outputs

Outputs are the *results* that *successfully completed tasks deliver*. One task can have a single or many outputs.

Who is responsible for BAA aligning with project approach

PM

SA: CSD: Organizational structure and culture

Part of assessing the current state is performing a cultural assessment of the organization. The BABOK® Guide defines organizational culture as "the *beliefs, values, and norms shared by the members* of an organization. These *beliefs drive the actions* taken by [that] organization." Communications channels and working relationships are influenced by the organization's structure and culture and should be accounted for as part of analyzing the current state.

5 Categories of Models

People and Roles Rationale Activity Flow Capability Data and Information

BAPM: PSE: Elements

Perform stakeholder *analysis*. Define stakeholder *collaboration*. *Assess* stakeholder *communication needs*.

BAPM: BAPI: Elements:

Performance analysis Assessment measures Analyze results Recommend actions for improvement

change management

Planned activities, tools, and techniques to address the human side of change during a change initiative, primarily addressing the needs of the people who will be most affected by the change.

BAPM: PBA: Elements

Planning the overall business analysis approach Deciding degree of formality and level of detail for business analysis deliverables Integrating the execution of business analysis activities with the overall project plan Determining timing of business analysis work Considering complexity and risk Gaining acceptance of the business analysis approach from key stakeholders

requirements management

Planning, executing, monitoring, and controlling any or all of the work associated with requirements elicitation and collaboration, requirements analysis and design, and requirements life cycle management.

Tech: Financial Analysis: Present Value

Present Value = Sum of (Net Benefits in that period / (1 + Discount Rate for that period)) for all periods in the cost-benefit analysis.

Tech: Prioritization: Elements

Prioritization provides a framework for business analysts to facilitate stakeholder decisions and to understand the relative importance of business analysis information. For the purpose of this technique, prioritization is classified into one of four approaches: 1• Grouping (high/med/low) 2• Ranking (most/least), 3• Time boxing/Budgeting (allocation based on amount work/budget) 4• Negotiation (consensus).

Tech: Process Analysis

Process analysis assesses a process for its efficiency and effectiveness, as well as its ability to identify opportunities for change. Process analysis is used for various purposes including: 1• recommending a more efficient or effective process, 2• determining the gaps between the current and future state of a process, 3• understanding factors to be included in a contract negotiation, 4• understanding how data and technology are used in a process, and 5• analyzing the impact of a pending change to a process. *When analyzing BA look for how value is created, aligns to strat, importance and how future state will affect*

Tech: Process Modelling

Process modelling is a standardized graphical model used to show how work is carried out and is a foundation for process analysis. Process models describe the sequential flow of work or activities. Process models can be used to: 1• describe the context of the solution or part of the solution, 2• describe what actually happens, or is desired to happen, during a process, 3• provide an understandable description of a sequence of activities to an external observer, 4• provide a visual to accompany a text description, and 5• provide a basis for process analysis.

RLCM: ASSESS R CHANGES: Stakeholder

Project Manager Customer Domain SME End user Operational support Regulator Sponsor Tester

SE: MSP: Stakeholders

Project Manager Customer Domain SME End user Sponsor Regulator

RADD: REQ ARCH: Stakeholder

Project ManagerDomain SME Implementation SME Project manager Sponsor Tester

RLCM: PRIORITIZE: Stakeholders

Project manager Customer Domain SME End user Implementation SME Regulator Sponsor

RADD: DDO: Stakeholder

Project manager Domain SME Implementation SME Operational support Suppliers

Which of the following is not a valid statement? Prototyping

Prototyping technique is not used to assess whether the problem is worth solving in the first place. Without this, it is a potential waste of resources to develop a prototype.

"Requirements State: Verified"

Requirements have been *checked* and are of *sufficient quality* to allow *further work * to be performed

RADD: REQ ARCH: Elements

Requirements viewpoints and views Template architectures Completeness Relate and verify requirements relationships Business analysis information architecture

business process re-engineering

Rethinking and redesigning business processes to generate improvements in performance measures.

Tech: Review: Purpose

Reviews are used to evaluate the content of a work product. ------- Each is tailored to the needs of the organization and business analyst, and uses these *dimensions*: 1• *Objectives*: defining the purpose of the review. 2• *Techniques: identifying either a formal or informal way to perform the review. 3• *Participants*: identifying who should take part in the review activity.

Tech: Risk Analysis & Mng

Risk analysis and management identifies areas of uncertainty that could negatively affect value, analyzes and evaluates those uncertainties, and develops and manages ways of dealing with the risks. 1. Risk Identificaiton 2. Analysis 3. Evauation 4. Treatment (avoid/transfer/mitigate/accept/increase)

Tech: Root Cause Analysis Used for? Activities?

Root cause analysis is used to *identify and evaluate the underlying causes* of a problem. Root cause analysis helps organize the information in a framework, which allows for deeper analysis if needed. Root cause analysis *can be used for*: 1• *Reactive Analysis*: identifying the root cause(s) of an occurring problem for corrective action, or 2• *Proactive Analysis*: identifying potential problem areas for preventive action. --- Root cause analysis *uses four main activities*: 1• *Problem Statement Definition*: describes the issue to be addressed. 2• *Data Collection*: gathers information about the nature, magnitude, location, and timing of the effect. 3• *Cause Identification*: investigates the patterns of effects to discover the specific actions that contribute to the problem. 4• *Action Identification*: defines the corrective action that will prevent or minimize recurrence.

A business analyst is estimating at a high level based on limited information. Which of the following estimation techniques is the BA using?

Rough Order of Magnitude (ROM) is estimated at a high level based on limited information, and this may have very wide confidence interval. (-75% to +25%)

Tech: SWOT

SWOT analysis is a simple yet effective tool used to evaluate an organization's strengths, weaknesses, opportunities, and threats to both internal and external conditions. --- A SWOT analysis can be used to: 1• evaluate an organization's current environment, 2• share information learned with stakeholders, 3• identify the best possible options to meet an organization's needs, 4• identify potential barriers to success and create action plans to overcome barriers, 5• adjust and redefine plans throughout a project as new needs arise, 6• identify areas of strength that will assist an organization in implementing new strategies, 7• develop criteria for evaluating project success based on a given set of requirements, 8• identify areas of weakness that could undermine project goals, and 9• develop strategies to address outstanding threats.

Tom, a business analyst, may NOT have used SWOT analysis technique to _______.

SWOT analysis is not used while assessing solution limitations.

Tech: Scope Modelling

Scope models define the nature of one or more limits or boundaries and place elements inside or outside those boundaries. ---- These *models may show elements that include*: 1• *In-scope*: the model identifies a boundary as seen from inside, as well as the elements contained by that boundary (for example, functional decomposition). 2• *Out-of-scope:* the model identifies a boundary as seen from outside, as well as the elements that are not contained by that boundary (for example, context diagram). 3• *Both: *the model identifies a boundary as seen from both sides, as well as elements on both sides of the boundary (for example, venn diagram or use case model). ------ Scope models *provide the basis for understanding the boundaries* of: 1• *Scope of Control*: what is being analyzed, roles and responsibilities, and what is internal and external to the organization. 2• *Scope of Need*: stakeholder needs, value to be delivered, functional areas, and organizational units to be explored. 3• *Scope of Solution*: requirements met, value delivered, and impact of change. 4• *Scope of Change*: actions to be taken, stakeholders affected or involved, and events to cause or prevent.

operative rule

See behavioural business rule.

goal

See business goal.

objective

See business objective.

policy

See business policy.

organizational change management

See change management. organization modelling

COTS

See commercial off-the-shelf.

CRUD matrix

See create, read, update, and delete matrix.

structural rule

See definitional business rule.

software engineer

See developer.

subject matter expert (SME)

See domain subject matter expert; implementation

business domain

See domain.

DSDM

See dynamic systems development method.

user

See end user.

Ishikawa diagram

See fishbone diagram.

cause-and-effect diagram

See fishbone diagram. change

retrospective

See lessons learned process.

OLAP

See online analytical processing.

RFI

See request for information.

RFP

See request for proposal.

RFQ

See request for quote.

allocation

See requirements allocation.

requirements document

See requirements package.

RACI matrix

See responsible, accountable, consulted, and informed matrix. regulator

ROI

See return on investment.

product scope

See solution scope.

user requirement

See stakeholder requirement.

SOW

See statement of work.

SWOT analysis

See strengths, weaknesses, opportunities and threats analysis. system

SME

See subject matter expert.

UAT

See user acceptance test. ®

VSM

See value stream mapping.

WBS

See work breakdown structure.

RFT

Seerequestfortender.

UML

Seeunifiedmodellinglanguage.

When requirements are captured in use cases, which technique is most appropriate for design?

Sequence diagram is used to specify a specific sequence of actions and interactions between actors and the system.

Tech: Sequence Diagrams:

Sequence diagrams are used to model the *logic* of *usage scenarios* by showing the information passed between objects in the system through the execution of the scenario. Elements 1. Lifeline (lifespan of object) 2. Activation Box (period of execution) 3. Message (Synchronous Call - send & wait / Asynchronous Call - Send & Continue) ---- Used for chronological order

Which of the following business analysis work products must be traceable to a business requirement?

Solution and stakeholder requirements The solution and stakeholder requirements on a project must be traceable to a business requirement.

SE: ASL: Identifying Internal Solution Component Dependencies

Solution performance can be limited by internal dependencies. It is *important to identify internal solution dependencies between components* and see if there *is anything* about the components *that limits performance or value realization*. The performance of an entire solution can be impacted by and limited to the performance of the least effective solution component.

SE: APM: Elements

Solution performance versus desired value Risks Trends Accuracy Performance variances

requirements management tool

Special-purpose software that provides support for any combination of the following capabilities

RADD: Tasks

Specify and model requirements and designs. Verify requirements. Validate requirements. Define requirements architecture. Define design options. Analyze potential value and recommend solution.

Which technique provides a visual and physical view of the sequence of activities to be supported by a solution?

Story Mapping provides a visual and physical view of the sequence of activities to be supported by a solution.

observation (business analysis)

Studying and analyzing one or more stakeholders

RADD: REQ ARCH: Business Analysis Information Architecture

The *business analysis architecture is one type of information architecture*. Interestingly enough, the information architecture that is defined by the Information Management Approach is a component of the requirements architecture. It defines relationships for different types of information, such as requirements and designs. *The optimal approach is to define this architecture before setting up* information technology and infrastructure, such as *requirements life cycle management tools, architecture software, or document repositories*.

At the end of a controlled start (BAPM & SA):

The *solution scope* is finalized. The *business case* and justification are in place. The *high-level business analysis approach* has been built. Business analysis *governance is defined* and in place. Business analysis *information management* is ready to go. Business analysis *stakeholders are identified and engaged*. Business analysis *performance measures are agreed on*. The business analysis *team* should be *ready to get to work*.

requirements traceability

The ability for tracking the relationships between sets of requirements and designs from the original stakeholder need to the actual implemented solution. Traceability supports change control by ensuring that the source of a requirement or design can be identified and other related requirements and designs potentially affected by a change are known.

collaboration

The act of two or more people working together towards a common goal.

facilitation

The art of leading and encouraging people through systematic efforts toward agreed-upon objectives in a manner that enhances involvement, collaboration, productivity, and synergy.

scope

The boundaries of control, change, a solution, or a need.

BAPM: BA role

The business analyst is responsible for *developing, defining, and managing the roles and tasks* associated with this work.

SA: FSD: Scope of solution space

The business analyst must also describe the *range of solutions* and the options that will be considered to achieve the desired future state. The *target is reaching a desired outcome that delivers the most value* and can be implemented to address the business need. Do not confuse the desired outcome with a solution; they are not the same thing. Solution options to achieve the future state will be evaluated relative to the desired outcome to make sure they can deliver the business benefits that are expected.

root cause

The cause of a problem having no deeper cause, usually one of several possible causes.

context

The circumstances that influence, are influenced by, and provide understanding of the change.

SA: CSD: Business architecture

The current state of an enterprise relative to a *business need does not exist in a vacuum*. Be sure to consider the business architecture when thinking about making a change. *Business architecture is the design, structure, and behavior of every aspect of the enterprise*. This view of how things are currently working *helps the business analyst align strategic objectives* with tactical demands and possible changes downstream.

quality

The degree to which a set of inherent characteristics fulfills needs.

architecture

The design, structure, and behaviour of the current and future states of a structure in terms of its components, and the interaction between those components. See also business architecture, enterprise architecture, and requirements architecture.

business architecture

The design, structure, and behaviour of the current and future states of an enterprise to provide a common understanding of the organization. It is used to align the enterprise's strategic objectives and tactical demands.

Tech: Financial Analysis: Discount Rate

The discount rate is the assumed interest rate used in present value calculations.

risk (business analysis)

The effect of uncertainty on the value of a change, a solution, or the enterprise. See also residual risk.

Which of the following techniques can be applied when tracing requirements?

The four techniques that may be used when tracing requirements include business rules analysis, functional decomposition, process modelling, or scope modelling.

Which one of the following may be a reason for sponsor rejecting these techniques?

The most likely reason is that these techniques are time consuming and expensive. The organization may not have the expertise to conduct the analysis and interpret useful information.

Tech: Fincial Analysis: Payback Period

The payback period provides a projection on the time period required to generate enough benefits to recover the cost of the change, irrespective of the discount rate.

service (business analysis)

The performance of any duties or work for a stakeholder, from the perspective of the stakeholder.

business analysis

The practice of enabling change in the context of an enterprise by defining needs and recommending solutions that deliver value to stakeholders.

requirements allocation

The process of assigning requirements to be implemented by specific solution components.

validation (business analysis)

The process of checking that a deliverable is suitable for its intended use. See also requirements validation.

verification (business analysis)

The process of determining that a deliverable or artifact meets an acceptable standard of quality. See also requirements verification.

Tech: Lessons Learned

The purpose of the lessons learned process is to compile and document successes, opportunities for improvement, failures, and recommendations for improving the performance of future projects or project phases. Sessions can include a review of: 1• business analysis activities or deliverables, 2• the final solution, service, or product, 3• automation or technology that was introduced or eliminated, 4• impact to organizational processes, 5• performance expectations and results, 6• positive or negative variances, 7• root causes impacting performance results, and 8• recommendations for behavioural approaches.

SA: FSD: Technology and infrastructure

The question you must answer is, "*Does the organization have the current business and technology capabilities to meet the business need?*" You will look at specific parts of the current technology and infrastructure that relate to the business need. Existing technology may impose technological constraints on solution design. If you miss something, your view of the organization's current technical capabilities may be incorrect and incomplete. That will require you to spend extra time doing the research to discover what you need to know.

residual risk

The risk remaining after action has been taken or plans have been put in place to deal with the original risk.

stakeholder proxy (business analyst)

The role a business analyst takes when representing the needs of a stakeholder or stakeholder group.

business analysis effort

The scope of activities a business analyst is engaged in during the life cycle of an initiative.

capability

The set of activities the enterprise performs, the knowledge it has, the products and services it provides, the functions it supports, and the methods it uses to make decisions.

solution scope

The set of capabilities a solution must deliver in order to meet the business need.

business analysis approach

The set of processes, rules, guidelines, heuristics, and activities that are used to perform business analysis in a specific context.

According to the case study, who is likely to implement turnkey solution for data acquisition, transfer, and reporting?

The solution provider can implement turnkey solution to devices, software, infrastructure, configuration, and training.

domain

The sphere of knowledge that defines a set of common requirements, terminology, and functionality for any program or initiative solving a problem.

requirements life cycle

The stages through which a requirement progresses from inception to retirement.

solution life cycle

The stages through which a solution progresses from inception to retirement.

evaluation

The systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over time, and to identify ways to improve the solution to better meet objectives. See also indicator; metric, monitoring.

Description

The task description explains a task to the business analyst in greater detail, including *what* the task actually is, *why* the task is *performed*, and *what* the task should *accomplish*

project scope

The work that must be performed to deliver a product, service, or result with the specified features and functions.

value (business analysis)

The worth, importance, or usefulness of something to a stakeholder in a context.

According to the case study, which of the following is the most appropriate source of a business need?

This question may be tricky. Answer can be either C or D. *C* From external drive, customer demand or business competition in the market place. *D* ; A Strategic goal that needs to be achieved. What is driving this initiative? Is it customer or business completion? There is no clue in the case study. However, *achieving company strategic goals may be the driving factor*, going by the statement LRS is operationally successful for the current need; however

Which of the following are common use case format

Three common use case formats are Brief, Casual, and Fully Dressed.

Top Down

To achieve a strategic goal (need)

Bottom Up

To address a current process, function, or system

Middle Management

To make better decisions or perform additional functions to meet business objectives

External Drivers

To meet customer demand or business/market competition

RLCM: Tasks

Tracing requirements and designs Maintaining requirements for reuse Prioritizing requirements Assessing requirements changes Approving requirements

SA: FSD: Organizational structure and culture

When assessing the future state, remember to do a cultural assessment of the organization relative to the changes in formal and informal working relationships that may occur. *Communications channels and working relationships are influenced* by the organization's structure and culture and should be accounted for as part of analyzing both the current and future states of the enterprise during strategy analysis.

What does decision analysis compare?

When building a change strategy, decision analysis can be used to compare the costs of implementing a proposed solution against the benefits to be gained.

RADD: S&M REQ: Implement appropriate levels of abstraction

When the different types of requirements found in the BABOK® Guide (business, stakeholder, solution, and transition) are discussed, the names are provided for the different levels of abstraction or detail found in those requirements. For example, business requirements are high level and focus on the big picture of what an organization requires in order to address a business need. Solution requirements are far more detailed, providing a basis to design and develop the capabilities needed in a new solution and its components. *It is important for you to understand the levels of abstraction in your project requirements and factor them into your requirements elicitation and analysis activities* across the project life cycle.

requirements verification

Work done to evaluate requirements to ensure they are defined correctly and are at an acceptable level of quality. It ensures the requirements are sufficiently defined and structured so that the solution

requirements validation

Work done to evaluate requirements to ensure they support the delivery of the expected benefits and are within the solution scope.

Tech: Workshops

Workshops bring stakeholders together in order to collaborate on achieving a predefined goal. Workshops generally include: 1• a representative group of stakeholders, 2• a defined goal, 3• interactive and collaborative work, 4• a defined work product, and 5• a facilitator.

Can Unapproved or unimplemented requirements might also be maintained for later use on future projects or initiatives.

Yes

SA: FSD: Assumptions

You will have to *make assumptions to define new capabilities* for the future state. Assumptions are things that are believed to be true regarding meeting the business need. Make sure that you clearly understand any assumptions associated with the new capabilities. *Identify and document each assumption, just in case you discover later that one or more of them are actually false*

What is the mission statement?

a statement of the organization's purpose - what it wants to accomplish in the larger environment

Conceptual data model:

is independent of any solution or technology and can be used to represent how the business perceives its information. It can be used to help establish a consistent vocabulary describing business information and the relationships within that information.

Physical data model

is used by implementation subject matter experts to describe how a database is physically organized. It addresses concerns like performance, concurrency, and security.

Tech: Review: Elements: Techniques

• *Inspection*: a formal technique that includes an overview of the work product, individual review, logging the defects, team consolidation of defects, and follow-up to ensure changes were made. The focus is to remove defects and create a high quality work product. While usually performed by peers, it can also be used for stakeholder reviews. • *Formal Walkthrough* (also known as Team Review): a formal technique that uses the individual review and team consolidation activities often seen in inspection. Walkthroughs are used for peer reviews and for stakeholder reviews. • *Single Issue Review* (also known as Technical Review): a formal technique focused on either one issue or a standard in which reviewers perform a careful examination of the work product prior to a joint review session held to resolve the matter in focus. • *Informal Walkthrough*: an informal technique in which the business analyst runs through the work product in its draft state and solicits feedback. Reviewers may do minimal preparation before the joint review session. • *Desk Check*: an informal technique in which a reviewer who has not been involved in the creation of the work product provides verbal or written feedback. • *Pass Around*: an informal technique in which multiple reviewers provide verbal or written feedback. The work product may be reviewed in a common copy of the work product or passed from one person to the next. • *Ad hoc*: an informal technique in which the business analyst seeks informal review or assistance from a peer.

The balanced scorecard is composed of four dimensions:

• Learning and Growth, • Business Process, • Customer, and • Financial.