Business Analysis Core Competency Model Definition (BACCM) PDF

Business Analysis Core Competency Model Definition Business Analysis Core Concept Model™ (BACCM™) is a conceptual framework for business analysis. It encompasses what (BACCM) business analysis is and what it means to those performing business analysis...

Business Analysis Core Competency Model Definition Business Analysis Core Concept Model™ (BACCM™) is a conceptual framework for business analysis. It encompasses what (BACCM) business analysis is and what it means to those performing business analysis tasks regardless of perspective, industry, methodology, or level in the organization Change The act of transformation in response to a need. Change works to improve the performance of an enterprise. These improvements are deliberate and controlled through business analysis activities. Context The circumstances that influence, are influenced by, and provide understanding of the change. Changes occur within a context. The context is everything relevant to the change that is within the environment. Context may include attitudes, behaviours, beliefs, competitors, culture, demographics, goals, governments, infrastructure, languages, losses, processes, products, projects, sales, seasons, terminology, technology, weather, and any other element meeting the definition. Solution A specific way of satisfying one or more needs in a context. A solution satisfies a need by resolving a problem faced by stakeholders or enabling stakeholders to take advantage of an opportunity. Stakeholder A group or individual with a relationship to the change, the need, or the solution. Stakeholders are often defined in terms 6 Core Concepts: (C2S2VN) of interest in, impact on, and influence over the change. Stakeholders are grouped based on their relationship to the needs, changes, and solutions. Value The worth, importance, or usefulness of something to a stakeholder within a context. Value can be seen as potential or realized returns, gains, and improvements. It is also possible to have a decrease in value in the form of losses, risks, and costs. Value can be tangible or intangible. Tangible value is directly measurable. Tangible value often has a significant monetary component. Intangible value is measured indirectly. Intangible value often has a significant motivational component, such as a company's reputation or employee morale. In some cases, value can be assessed in absolute terms, but in many cases is assessed in relative terms: one solution option is more valuable than another from the perspective of a given set of stakeholders. Need A problem or opportunity to be addressed. Needs can cause changes by motivating stakeholders to act. Changes can also cause needs by eroding or enhancing the value delivered by existing solutions Term Definition Term Definition Business Analysis BABOK defines business analysis as the practice of enabling change in an enterprise by defining needs and Requirement A requirement is a usable representation of a need. recommending solutions that deliver value to stakeholders. Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled Business Analysis Business analysis information refers to the broad and diverse sets of information that business analysts Business Requirement Statements of goals, objectives, and outcomes that describe why a change has Information analyze, transform, and report that is used as an input to, or is an output of, business analysis work. been initiated. E.g.- Examples of business analysis information include elicitation results, requirements, designs, solution They can apply to the whole of an enterprise, a business area, or a specific options, solution scope, and change strategy initiative. Design A design is a usable representation of a solution. Stakeholder describe the needs of stakeholders that must be met in order to achieve the Design focuses on understanding how value might be realized by a solution if it is built. requirements business requirements. They may serve as a bridge between business and solution requirements. Enterprise An enterprise is a system of one or more organizations and the solutions they use to pursue a shared set Solution requirements: describe the capabilities and qualities of a solution that meets the stakeholder of common goals. Solutions can be processes, tools or information. requirements. An enterprise may include any number of business, government, or any other type of organization They provide the appropriate level of detail to allow for the development and implementation of the solution. Organization An autonomous group of people under the management of a single individual or board, that works functional describe the capabilities that a solution must have in terms of the behaviour and towards common goals and objectives. requirements information that the solution will manage Organizations often have a clearly defined boundary and operate on a continuous basis, as opposed to an initiative or project team, which may be disbanded once its objectives are achieved. Requirement A requirement is a usable representation of a need. Non-functional do not relate directly to the behaviour of functionality of the solution, Requirements focus on understanding what kind of value could be delivered if a requirement is fulfilled requirements (or QoS) but rather describe conditions under which a solution must remain effective or qualities that a solution must have. Risk Risk is the effect of uncertainty on the value of a change, a solution, or the enterprise. Transition describe the capabilities that the solution must have and the conditions the BAs work with stakeholder to : mitigating the consequences, removing the source of the risk, avoiding the requirements solution must meet to facilitate transition from the current state to the future risk altogether by deciding not to start or continue with an activity that leads to the risk, sharing the risk state, but which are not needed once the change is complete. with other parties, or accepting or even increasing the risk to deal with an opportunity. They are differentiated from other requirements types because they are of a temporary nature. Transition requirements address topics such as data conversion, training, and business continuity Key Points: 1. The business analyst is inherently a stakeholder in all business analysis activities 2. A customer uses or may use products or services produced by the enterprise and may have contractual or moral rights that the enterprise is obliged to meet. 3. Sponsors are responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize the work to be performed, and control the budget and scope for the initiative. 4. Requirements are focused on the need; designs are focused on the solution. 5. Requirement leads to a design which in turn may drive the discovery and analysis of more requirements Knowledge Area Task Elements Input & Guidelines Output Key Point 1. Purpose is to define an appropriate method to conduct business analysis activities 2. Usually Standardized & Formalized in organisations but may be tailored Planning Approach 3. Predictive Approach: minimizing uncertainty and ensuring that the solution is defined before implementation begins in order to maximize control and minimize risk. Formality and Level of Detail of Business Analysis a. Used when the risk of an incorrect implementation is unacceptably high, or when engaging stakeholders presents significant challenges. Deliverables Inputs: Needs b. Require formal documentation and representations (Templates etc) c. Tasks are performed in specific phases. Guidelines: 4. Adaptive approaches: rapid delivery of business value in short iterations in return for acceptance of a higher degree of uncertainty regarding Business Analysis Activities Business delivery of the solution - Breakdown: Deliverables--> Tasks --> Activities - Business Analysis Analysis a. These approaches tend to be preferred when taking an exploratory approach to finding the best solution or for incremental improvement of an Performance Assessment Approach existing solution. Plan Business Analysis - Business Policies - who will perform b. Informal Documentation: defining requirements and designs through team interaction & feedback on a working solution. Formal - Expert Judgement - timing & documentation is often produced after the solution is implemented to facilitate knowledge transfer. Approach - Methodologies & Timing of Business Analysis Work sequencing, c. Tasks are performed iteratively - Availablility of resources, priority of initiative, Framework - deliverable 5. Other Factors: Complexity, regulated Industry, Contractual Obligation, Outsourcing, High staff turnover, SH location concurrent activities, regultory deadline/contracts - Stakeholder Engagement - Integrated 6. Risk & Complexity : No. of Stakeholder more --> Complexity of BA work more. Approach Approach Other Factor: Size of change, system affected, geographic/cultural considerations, tech. complexities BA Risk: Experience, domain knowledge, Stakeholder knowledge, time allocated by SH, existing framework, culture Complexity & Risk Acceptance 1. Analysis: Purpose is establishing and maintaining effective working relationships with the stakeholders 2. Degree of complexity increases as the number of stakeholders involved the BA activities increases Stakeholder 3. Analyzing their characteristics and data collected Inputs: 4. Who the SH are? What is their positive/negative influence? Impact of change on SH? Roles of Stakeholders; level of interest in the change Perform Stakeholder Analysis a. Needs Engagement 5. Company Organization Model & Business Process serve as source of internal Stakeholder.Sponsor identifies SH. b. Businss Analysis Approach 6. Understand Level of influence of a particular Stakeholder for buy-in/approvals. Develop risk plans if this is less. - List of Stakeholder Matrix : Influence v/s Interest; Approach Stakeholder Plan Stakeholder Engagement Stakeholder Onion Diagram - characteristics 7. Collaboration is different for both internal & external stakeholder Guidelines: - roles & 8. Consider for Collaboration: timing/frequency; location; available tools; delivery method; preferences of SH Define Stakeholder Collaboration - BA Performance Asses. responsibilities 9. Communication: What needs to be communicated; delivery method (verbal or oral); appropriate audience; time & Frequency of - Change Strategy - collaboration & communication; geographic location of SH; level of details; level of formality. communication - Current State Descrp. requirement Stakeholder Communication Needs 1. Purpose is to define how decisions are made about requirements and designs, including reviews, change control, approvals, and prioritization. 2. Defines: the decision makers; process; information required for decision making for requirements & designs 3. Decision Making: SH roles as a decision maker; SME; reviewer of information; approver of decisions; Escalation path 4. Change Control Process: Decision Making a. Request change process - steps for proposing change; when to propose changes; who & how can propose changes. Inputs: b. Element of CRs - cost & time estimate; Benefits; Risks; Priority; Course of action (multiple alternatives) Business Analysis a. Businss Analysis c. priortization of changes, documentation of changes, communication, impact analysis of changes & approval of changes Planning & Approach 5. Priortization Approach: Timelines, expected value, dependencies, resource constraints, adopted methodologies, and other factors influence Monitoring Governance how requirements and designs are prioritized. b. Stakeholder Approach 6. Consider for Priortization planning : formality & rigour of process; participants; process of priortization; criteria for priortization (cost, risk & Change Control Process Engagement Approach - Decision makers value) Plan Business Analysis Governance Approach - who is 7. Approval Process: Approval formalizes the agreement between all stakeholders that details are accurate, adequate, and contain sufficient detail Guidelines: responsible to to allow for continued progress to be made. a. BA performance Asses. priortize and a. timing and frequency of approvals are dependent on the size and complexity of the change & risk associated b. Business Policies approve changes b. When planning the appropriate approval process, business analysts consider the organizational culture and the type of information being approved Plan Prioritization Approach c. Current State d. Legal/Regulatory Info. Plan for Approval 1. Purpose is to develop an approach for how business analysis information will be stored and accessed 2. Information includes: all the information business analysts elicit, create, compile, and disseminate in the course of performing business analysis. Organization of Business Analysis Information 3. Organization of Info: info shouldn't b difficult to locate, conflicts with other information, or is needlessly duplicated Inputs: a. Relationship among information should be defined properly a. Business Analysis 4. Abstraction should be different for each stakeholder based on needs of SH, complexity of information, importance of change. High risk information is communicated in greater detail Level of Abstraction Approach 5. Traceability should be determined to add value without increasing overhead b. Stakeholder Information 6. Reusing requirements can save an organization time, effort, and cost. Engagement Approach Management 7. Candidate for reuse: regulatory req, contractual obligation, quality standard, SLAs, business rules & business processes, product descriptions Plan Business Analysis Plan Tracebility Approach c. Governance Approach Approach 8. business analysts plan ahead for requirements reuse by identifying how best to structure, store, and access requirements. For this, Information Management - how information requirements must be clearly named, defined, and stored in a repository that is available to other business analysts. Guidelines: stored, accessed, 9. Storage & Access : should be able to indicate status of any stored information and allow modification over time 10. Req. Attributes - Absolute Reference, Author, Complexity, Ownership, Priority, Risk, Source, Stability, Status, Urgency Plan for Requirement Reuse a. BA performance Asses. and utilized. b. Business Policies c. Info Mgmt Tool Storage & Access d. Legal/Regulatory Info. Requirements Attributes  1. Purpose is to establish the performance measures, conduct the performance analysis, report on the results of the analysis & identify any necessary preventive, corrective, or developmental actions. improvements are identified, they become guidelines for the next time a task is Performance Analysis Inputs: Business executed. a. Performance Objectives Analysis 2. Reports on business analysis performance can be informal and verbal, or they may include formal documentation (External) Performance 3. Performance Measures: deliverable due dates, frequency of the changes, review cycles required, task efficiency, qualitative feedback Identify Business Analysis Assessment Measure b. Business Analysis 4. Possible Measures: Accuracy and Completeness of work, Knowlege of BA, Effectiveness, Org Support, Significance to final solution, meeting Assessment Strategic objective, Timeliness Performance Improvements Approach - planned vs actual 5. Analysis of results may be done at Stakeholder or personnel manager or a Center of Excellence level. performance 6. Recommended actions: Preventive, Corrective, Improvement Analyze Results Guidelines: - root cause Org. Performance Std. -proposed appr. Recommend Actions for Improvement Knowledge Area Task Elements Input Output Key Point 1. Elicitation is the drawing forth or receiving of information from stakeholders or other sources 2. Elicitation & Collab is not a phase, it is on going & iterative as long as business analysis work is occuring 3. E&C can be planned (workshops, experiments) & unplanned (just in time interviews). Unplanned should be backed up by planned activities 4. Purpose is to understand the scope of the elicitation activity, select appropriate techniques, and plan for (or procure) appropriate Understand Scope of Elicitation supporting materials and resources & logistics 5. includes determining which work products will be produced, deciding which techniques are best suited to produce those results, establishing the req logistics, identifying any supporting materials needed & collab req Inputs: 6. Scope: Business Domain, corporate culture, SH Location, expected outputs, skills of BA, scope of sol, a. Understanding the scope of the elicitation activity allows BAs to keep activities on track & within scope. Selection Elicitation Technique a. Needs 7. Select Technique: depend on cost & time constraints; types of sources & their access; culture of org. & desired outcomes, needs & location b. Stakeholder Engagement Elicitation Activity of stakeholders. BA considers - a. techniques used in similar initiative ; b. technique suited to situation; c. tasks need to prepare execute, and complete each Approach Plan technique. Prepare for Elicitation - logistics, 8. Setup Logistics: includes activity goal, participants & their roles, scheduled resources (rooms etc), communication channel, techniques, Setup Logistics Guidelines: - scope of elicitation languages used by Stakeholder (oral & written), an agenda. - Business Analysis - selected techniques 9. Supporting material: Info about people people, systems, historical data, materials and documents. Documents could include existing Approach - supporting materials. system documents, relevant business rules, organizational polices, regulations, and contracts. - Business Objectives 10. Prepare Stakeholder: Brief Stakeholder in advance about the validity and relevance of the information elicited. Buy-in about the elicitation. Requesting that they review supporting materials to make elicitation effective. May provide agenda in advance. Secure Supporting Material - Existing BA Information - Potential Value Prepare Stakeholders 1. Three types of collaboration - Inputs: a. Collaborative - direct interaction with stakeholders, which relies on their experiences, expertise, and judgment. E.g Workshop Elicitation Activity Plan b. Research - discovering & studying information from materials/sources not known by stakeholders. E.g Doc Analysis for historical c. Experiments - identifying information that could not be known without some sort of controlled test. E.g - observational studies, Guidelines: PoCs &prototypes. Guide Elicitation Activity Elicitation Results 2. Guide Elicitation - ensure that the elicitation activities are focused on producing the intended info at the desired level of detail - Business Analysis a. Keep the elicitation within scope & on the track Conduct Elicitation (Unconfirmed) Approach b. Consider - Goals/Agenda, scope of change, form of output, representations of results, info. source, info. user, how info. is used - Stakeholder Eng. 3. Capture Elicitation Output : Elicitation can happen parallel or in sequence. Ensures that the information elicitated is recorded for later Approach reference and use. Can use a Scribe or record the session. Scribe can be different from moderator. - Existing BA Information - Supporting Materials Capture Elicitation Outputs 1. Purpose is to check the information gathered during an elicitation session for accuracy and consistency with other information Elicitation and 2. Identify problems in Information before committing resources to it. Discover errors, omissions, conflicts, and ambiguity. Collaboration Inputs: Elicitation Results 3. Commitment of resources should only be on confirmed elicited requirements. If not, additional elicitation may be required. Compare Elicitation Results against Elicitation Results Source Information (Confirmed) 4. Compare against source : May lead to follow-up meetings for corrections or can be done independently by Stakeholders alone. (Unconfirmed) - integrated output where 5. Compare against other source: Comparisons may also be made with historical data to confirm more recent elicitation results. Confirm Elicitation Guidelines: stakeholder & BA agree - Elicitation Activity Plan on correctness of Elicited - Existing BA information information Compare Elicitation Results against Other Elicitation Results 1. Purpose is to ensure that stakeholders have a shared understanding of business analysis information. Share information to stakeholders at the right time and in formats that meet their needs. Consider appropriate language, tone, and style. Bi-directional Inputs: 2. Business Analysis Package consider communication of req & designs, reviews/approvals, inputs to solution design, evaluation of alternatives, a. Business Analysis maintenance for reuse. Information 3. Format & Clarity is of top priority considering - who is the audience, what SH understand, SH preferred style, what info is communicated, Determine Objective & Format of b. Stakeholder Engagement any regulatory or contractual contraints are there? Business Analysis 4. Packages may be - Formal Documentation & informal documentation (text matrices, diagrams) and presentations. MOMs are not packages. Communicate Business Communication Approach Information 5. Stakeholder are given opportunity to review the documentation. It is shared in required details. Analysis Information (Communicated) 6. Appropriate Platform - Group Collaboration (All in once) , Individual Collaboration (one at a time; time consuming); Email or non-verbal Guidelines: methods (information is communicated as a package with little explaination) - BA Approach - Info Management Communicate Business Analysis Approach Package 1. Purpose is to encourage stakeholders to work towards a common goal. 2. Various stakeholders have different level of influence/authority & interest on work products. Ensure their participation overall. 3. This is an on-going activity. New stakeholders are identified at any point of time throughout the lifecycle. Inputs: 4. New SH should be analyzed as well. Each stakeholder's role, responsibility, influence, attitude, & authority may change overtime a. Stakeholder Engagement 5. Business analysts manage stakeholder collaboration to capitalize on positive reactions, and mitigate or avoid negative reactions. Gain Agreements on Commitments Approach 6. Commitments: BA and SH identify and agree upon commitments of engagement as early in the initiative as possible. b. Business Analysis 7. Stakeholder Engagement : a. participation of SH, SH attitude & interest are constant or improving, elicitation confirmation timely, agreements maintained. Performance Assessment b. Risks: SH diverted to other work, Elicitation activities not providing quality of BA info required, delayed approvals. Manage Stakeholder Stakeholder 8. Collaboration involves regular, frequent, and bi-directional communication. Collaboration Guidelines: Engagement a. Helps free flow of information, shared effort to resolves problem and achieve outcomes - BA Approach b. SH opinions should be heard, their opinions matter & contributions recognized. Monitor Stakeholder Engagement - Business Objectives - Future State Description - Risk Analysis & recommd. Actions Collaboration Knowledge Area Task Elements Input Output Key Point 1. Purpose is business, stakeholder, and solution requirements and designs are aligned to one another & the solution implements them. 2. Ensures BA information can be used in future as well. The management of requirements does not end once a solution is implemented. 3. The requirements life cycle: (Requirements may be in multiple states at one time.) a. begins with the representation of a business need as a requirement, b. continues through the development of a solution, and c. ends when a solution and the requirements that represent it are retired. 4. Trace Requirement: Purpose is to ensure that requirements and designs at different levels are aligned to one another, and to manage the effects of change to one level on related requirements. Level of Formality Inputs: 5. Requirement Tracebility - Origin of requirement, its forward & backward traceability and relationship to other requirements. a. Requirements a. Ensure solution conforms to requirements & assist in scope, change, risk, time, cost & communication management. a. Requirements(Traced) b. faster and simpler impact analysis, b. Designs b. Designs (Traced) c. more reliable discovery of inconsistencies and gaps in requirements, 1. Trace d. deeper insights into the scope and complexity of a change, and Requirements Guidelines: - relationships to other e. reliable assessment of which requirements have been addressed and which have not. - Domain Knowledge requirements, solution f. release planning of solution. - Info Mgmt Approach components, or releases, 6. The effort to trace requirements grows significantly when the number of requirements or level of formality increases. - Legal/Regulatory info phases, or iterations 7. Relationships between requirements : Derive - used when a requirement is derived from another requirement ; Depends- one req is dependent on other (Necessity & effort) ; Satisfy - implementation of one req satisfies other (func req.) Relationship - Req Mgmt Tools Validate: one req. validates other (req & its test case) 8. Requirements management tools can provide significant benefits for repository to maintain large number of requirements. E.g. VSTS, Sharepoint Tracebility Repository 1. Purpose is to retain requirement accuracy and consistency throughout and beyond the change during the entire requirements life cycle, and to support reuse of requirements in other solutions. Inputs: 2. Maintain Requirements: So that they remain correct and current after an approved change. Requirements must be clearly named and defined, and easily Maintain Requirements available to stakeholders. Also maintain relationship among requirements. Req mgmt tools assist in this. a. Requirements 3. Maintain Attributes: requirement’s source, priority, and complexity aid. An attribute may change even though the requirement does not. a. Requirements 2. Maintain b. Designs (Maintained) 4. Reuse Requirements : Req. that can be re-used or for long term use are identified, clearly named, defined, and stored for easy access for other BAs Requirements 5. Requirements can be reused: within the current initiative; within similar initiatives; within similar departments; throughout the organization. Maintain Attributes Guidelines: b. Designs (Maintained) 6. Requirements detailed in general manner without reference to a particular solution are candidate for reuse - Info Mgmt Approach 7. Stakeholders validate the proposed requirements for reuse before they can be accepted into a change since they describe current state. Reusing Requirements 1. Purpose is to rank requirements in the order of relative importance. It is an ongoing process and priority changes with time 2. Inter-dependencies between requirements are identified and may be used as the basis for prioritization Inputs: 3. Basis for Priortization: - Benefit (each SH group may percieve benefits differently); a. Requirements Penalty (result of not implementing a requirement - regultory or user experience);, Basis of Priortization b. Designs Cost (implementation cost may reduce the priority of a requirement after CBA); Requirements Dependencies (between the requirements); Time Senstivity (Best Before date of requirement after which it losses its value. E.g. Time to Market), Lifecycle Guidelines: a. Requirements Risk (chance that a req cannot deliver potential value or is not feasible. Such a req is given priority & can be tested as a POC so that remaining cost can be saved); Management 3. Prioritize - Business Constraints Stability (Likelihood of a req changing overtime, such are de-priortized), Regulatory or Policy Compliance (req to meet legal requirements) Requirements - Change Strategy (Priortized) 4. Challenges: Each Stakeholder may value something different and priortize differently. In such cases, SH need to make trade-offs b. Designs (Priortized) 5. Continual Priortization: Ongoing process as priorities changes over time. With more information comes more clarity. - Domain Knowledge a. The basis for priortization may be diffrent at different times. E,g. End user priortize based on benefits but Implementation team might repriortize based on ease Challenges of Priortization - Governance Approch of technical implementation. - Req. Architecture - Req. Mgmt Tool - Solution Scope Continual Priortization 1. Purpose is to evaluate the implications of proposed changes to requirements and designs. Not all changes to req & designs align to change startegy or solution scope. What actions should be taken and whether the changes increase the value of the solution or not. Inputs: 2. Assess - potential effect of the change to solution value & conflicts of changes to other requirements or increase risk level.(overall strategy) Ensure - Changes should be traced back to particular needs. Change can impact the time to deliver as well. Assessment Formality a. Requirements 3. BA determine assessment formality based on information available, apparent importance of the change, and governance process. b. Designs a. In Predictive Approach: Change may be disruptive, require substantial rework in completed activities. c. Proposed Changes b. In Adaptive Approach: Require less formality in assessment. reworking impact is less due to iterative & incremental approach. 4. Assess a. Requirements change 4. Impact Assesment : Traceability is important as changes to a req lead to change in related other requirements or solution components Guidelines: assessment a. Other considerations: Impact on Benefit, cost, Impact, schedule, urgency Requirement Impact Assessment b. Design change Changes - Requrmnt Architect. 5. Impact Resolution: various stakeholders (including BA) may be authorized to approve, deny, or defer the proposed change. All of this should be documented as - Tracebility. - Change Strategy assessment should be done in accordance with Goverance Approach. - Governance Approch - Legal/Reg. Info - Solution Scope - Domain Knowledge Impact Resolution  1. Purpose is to obtain agreement on and approval of requirements and designs for BA work to continue and/or solution construction to proceed. 2. Predictive Approach: end of the phase or during planned change control meetings; Understand Stakeholder Adaptive Approach: approve requirements only when construction and implementation of a solution meeting the requirement can begin. roles Inputs: 3. Stakeholder roles: who are the decision-makers; who possess authority for sign-off; which stakeholders should be consulted & informed. a. Requirements - Few can approve or deny the changes but many can influence these decisions 5. Approve (Verified) 4. SH groups can have different views & conflicting priorities. Conflicts may arise as a result of differing interpretations & values placed on them. a. Requirements - BA facilitates communication between stakeholders in areas of conflict so that each group has an improved appreciation for the needs of the others. Requirements Conflict and Issue b. Designs (Approved) 5. BAs are responsible for gaining approval from approving SHs indicating their agreement with solution or designs described. Management b. Designs (Approved) 6. BAs can use - BA governance approach & Communicate Business Analysis Information task to for this by addressing any queries. (Task 1 & 2) of KA Guidelines: - Approved Req & Design can 7. Any missing agreements can be marked as risks & managed accordingly. 5 Req Analysis is - Change Strategy be used for further Business 8. BAs records approval decisions, possibly in requirements maintenance and tracking tools for accurate records of current approval status. done before this. - Governance Approach Analysis work 9. Its important to maintain an audit history of changes to requirements: what was changed, who made the change, the reason for the change, and when it was Gain Consensus - Legal & Reg Info made. - Req. Mgmt Tool - Solution Scope Track and Communicate Approval Knowledge Area Task Elements Input Output Key Point 1. Strategy is the most effective way to apply the capabilities of an enterprise in order to reach a desired set of goals and objectives. Can be applied at level: enterprise, department, function & for a product, project or iteration. Business Needs 2. Strategy analysis focuses on defining the future and transition states needed to address the business need, and the work required is defined both by that - Top-Down, Bottom Up, Middle management, need and the scope of the solution space. External Drivers 3. Strategy analysis should be performed as a business need is identified to check whether to address that need or not. 4. Strategy Analysis focuses on - Need & Solution Scope 5. In case of Predictable Outcome: future state & possible transition states can be clearly defined & a clear strategy planned out. In case of unpredictable outcome: strategy may need to focus on mitigating risk, testing assumptions & changing course until a strategy that will succeed in reaching the business goals can be identified or until the initiative has ended. Organization Structure and Culture 6. Purpose of Analyze Current State is to understand why an enterprise needs to change some aspect of how it operates and what would be directly or indirectly affected by the change. 7. why the change is needed: triggered by problems or opportunities that cannot be addressed without altering the current state 8. BA & SH jointly define business needs that drive the desire to change. If not done, lead to conflicts later on. 9. Current State: stakeholders, processes, technology, and policies constitute the current state Capabilities and Processes 10. Current State can be defined at different levels: entire enterprise to small component of solution. Current State is not static. 11. Business Needs: Business needs are the problems, opportunities or issue faced of strategic importance faced by the enterprise. Inputs: a. Different levels: Top-Down (strategic goal), Bottom Up (process/function or system problem); Middle management (managerial efficiencies) or External a. Needs Drivers (Legal or regulatory changes or competition in market) b. Elicitation Results b. A solution must satisfy the business needs to be considered successful. Technology and Infrastructure (Confirmed) c. Business needs are always expressed from the perspective of the enterprise, and not that of any particular stakeholder. d. Business needs are often identified or expressed along with a presumed solution. BA should assess should question the assumptions and constraints. e. it isn’t necessary to fully detail all aspects of the current state before further developing the change strategy. Guidelines: a. Current State 12. Organization Culture - Relationship between people working in an organization. BA assses if cultural changes are required. Whether SH understand the 1. Analyze - BA Approach Description current state & value delivered by it & if SH feel any change is need in current state. Current State Policies - Enterprise Limitation b. Business 13. C&P are the activities, processes, knowledge, supported functions, products & services & methods used by enterprise. Measure by KPIs - Org. Startegy Requirements a. BA can asses capability-centric view where capabiilities are generally organized in a functional hierarchy therby easy to identify gaps - Solution Limitation b. BA can asses Process-centric view when looking for ways to improve the performance of current activities by having end-to-end view - Solution Performance 13. Technology & Infra: Includes - computer hardware, physical plants, and logistics, their operations and other tool used by customer/emp Goals 14. Policies define permitted behaviour, i.e., the scope of decision making at different levels of an enterprise (forcussed on routine operation & not strategic) - Solution Performance 15. Business Architecture: No part of the current state should be assessed in complete isolation from the rest. Business Architecture Measures a. existing business architecture typically meets an assortment of business and stakeholder needs. If not considered, may lead to loss. - Stakeholder Analysis 16. Industry Structure - imp if proposed change involves entering a new industry; competitors - entry of a new player & exisiting comes into this; Customers- the size and nature of existing and potential customer & any rising alternative to customer; Supplier - variety & diversity; Macroeconomic - trade, unemployment, or inflation factors; Technology - any new innovation; political or regulatory Internal Assets - tangible or intangible External Influencers - Industry Structure, Competitors, Customers, Suppliers, Political & Regulatory Environment, Technology, Macroeconomic 1. Purpose is State is to determine the set of necessary conditions to meet business need. Future state should include definition of success. 2. future state analysis is not intended to create a comprehensive description. Future state level of detail: Business Goals & Objectives a. define competing strategies to achieve the future state to be identified and assessed; b. clear definition of the outcomes that will satisfy the business needs, c. details the solution scope d. allows for value associated with the future state to be assessed, e. enables consensus to be achieved among key stakeholders. Descriptions may include visual models & texts. 3. In predictable outcomes & value & where there large no. of changes, future state analysis provide sufficient details that allows to make best possible Scope of Solution Space choices. In unpredictable outcomes, FSA aids in identification of appropriate performance measures & exploration of multiple solution options 4. Bus. Goals: Goals are longer term, ongoing, & qualitative statements of a state or condition that organization is seeking to establish & maintain. High level Constraints goals can be brokend down into general startegy for specific areas - increased cust. satisfaction, operational excellence, and/or business growth. Broken Down goals are objectively measurable. Objectives defined should be SMART (Specific, Measurable, Achievable, Relevant, Time-bounded) a. Business 5. Solution Space: defines which kinds of options will be considered when investigating possible solutions - org culture, capabilities, solutions, product & Objectives services, processes, technologies & infra or even strategic partnerships. Done by BA & implementation team jointly. Organization Structure and Culture Inputs: (- desired 6. Constraints: are the aspects of the current state, aspects of the planned future state that may not be changed by the solution, or mandatory elements of direction) the design. E.g - Budget, time, technology, infrastructure, policies, resources limits, SH skills, compliance, 7. Org Struc.: Change in reporting lines for alignment. components of future state provides insight into potential conflicts, impact, and limit a. Business Capabilities and Processes Requirements b. Future State 8. Capabilities: Identify new kinds of activities or changes in the way activities will be performed to realize the future state. 9. Tech. & Infra: If current tech. & infra. are insufficient to meet business need, indentify the changes necessary for future state. Existing tech. might impose Description restrictions on design of sol. Tech. constraints also include any IT architecture standards that must be followed. 2. Define (boundaries & 10. Policies: are a common source of constraints on a solution or on the solution space. A Change in policy might open solution option. Future State Policies potential value 11. Bus. Architecture: Elements of any future state must integrate & support one another and all contribute to meeting the business. Guidelines: from each 12. Internal Assests: BAs examine the resources needed to maintain the current state and implement the change strategy, and solution) determine what resources can be used as part of a desired future state. -Current State Desc. 13. Strategies are designed a set of assumptions which determine if strategy can succeed or not. Change strategies can be remodelled acc. Business Architecture - Metrics & KPIs c. Potential 14. Potential value must be evaluated to see if it is sufficient to justify a change. The P.V. of the future state is the net benefit of the solution after operating - Org. Startegy Value costs are accounted for. A change must result in greater value than current state. However, the value might decrease in certain cases due to new (expected value for regulations/legal req or rising competitions. Technology and Infrastructure each future state) BA perspective for PV: a. External Opportunities, Strength of Partner, New Technologies/Knowledge, Potential loss of competitor, madated adoption of a Strategy Analysis change component. 'Do Nothing' should be considered here as well Internal Assets Identify Assumptions Potential Value  1.Purpose is to understand the undesirable consequences of internal and external forces on the enterprise during a transition or the future state. 2. Assessing risks includes analyzing & managing them. Risk can be related to : current state, a desired future state, a change, change strategy 3. Risks are analyzed for: a. possible consequences if risk occurs; b. impact of conseq.; c. likelihood of riks; potential time frame when risk occur 4. Accept Risk: if effort required to modify the risk or the level of risk outweighs the probable loss.Otherwise risk is managed through mitigation. Unknowns Inputs: 5. Unkown: assess risks based on current understanding. It is possible to estimate impact of unknown or uncertain events or conditions occurring. a. Influences (Internal & - Consider lessons learned from past experience & expert judgements help in understanding impact & likelihood of risks for the current change. External) 6. Constraints, assumptions, and dependencies can be analyzed for risks & should be managed as risks themselves if it is related to the change. b. Elicitation Results 7. Risks have a negative impact to value.BAs express each risk and estimate its likelihood and impact to determine the level of risk. Potential impact of risk can (Confirmed) be quantified in financial terms, or in an amount of time, effort, or other measures. Constraints, Assumptions & Dependencies c. Designs (Priortized) Risk Analysis 8. Risk Tolerance: Level of uncertainty a stakeholder or an enterprise is willing to take on in exchange for potential value. d. Requirements Results Three ways: (Priortized) - understanding of Risk-aversion- unwillingness to accept much uncertainty leading to avoid a course of action which carries too high level of risk, or to invest more e. Business Objectives risk and mitigation Neutrality- some level of risk is acceptable, does not result in a loss even if the risks occur. 3.Assess Risk f. Potential Value Negative Impact to Value strategies to Risk Seeking - willingness to accept or even take on more risk in return for a higher potential value. (Opportunity) reduce the the highest level risks are dealt with no matter what the risk tolerance level. Low Tolerance: Transfer, Avoid or Mitigate ; High Tolerance: Accept Guidlelines: BA likelihood/impact 9. Recommendations: Course of action by BAs - Approach, Business of risk a. pursue the benefits of a change regardless of the risk ; b. pursue the benefits of a change while investing in reducing risk Policies, Change Strategy, c. seek out ways to increase the benefits of a change to outweigh the risk d. identify ways to manage and optimize opportunities Risk Tolerance Current State, Future e. do not pursue the benefits of a change. State, Identified Risks, Stakeholder Engagement Appraoch Recommendation 1. Purpose is to develop and assess alternative approaches to the change, and then select the recommended approach 2. the current state and the future state are already defined make it easy because they provide some context for the change 3. Change Strategy covers: a. context of the change ; b. alternative change strategies; c. justification of each strategy; d. investments or resources req. e. how enterprise will realize the value; f. key stakeholders; g. transition states along the way 4. The change strategy might be presented as part of a business case, Statement of Work (SOW), an enterprise’s strategic plan, or in other formats. 5. Defining a change strategy involves identifying several strategies and ultimately selecting the strategy that is most appropriate for the situation. 6. Describe each transition state with part of the solution completed and which are not. Solution Scope 7. Solution Scope: Defines the boundaries of the solution & is described in enough detail to enable stakeholders to understand which new capabilities the change will deliver. It also describes how the proposed solution enables future state's goals.Can include Out of scope sol component a. Describe solution scope in terms of - capabilities, technology, business rules, business decisions, data, processes, resources, knowledge & skills, models & descriptions of markets, functions, locations, networks, organizational structures, workflows, events, sequence, motivations, or business logic. Inputs: 8. Gap analysis identifies the difference between current state and future state capabilities. (both should be defined in advance & using same tech.) a. Stakeholder a. Change 9. The readiness assessment considers the enterprise’s capacity a. to make the change; b. use and sustain solution; c. realize value from solution. Strategy a. Considers both cultural readiness of stakeholders and operational readiness, timeline for making change & resources available to support change. Engagement 10. A change strategy is a high-level plan of key activities & events that will be used to transform enterprise from current state to future state. Approach (-the approach Gap Analysis that the Startegies may be -- a. singular initiative composed of smaller changes which might be structured as a set or sequence of projects, or b. Current State organization will b. Various continuous improvement efforts. Each element of change might not completely address the need, so multiple changes might be necessary Description follow to guide c. Various alternatives of strategies can be identified through brainstorming and consulting subject matter experts (SMEs). Sources of ideas - historical c. Future State change.) ideas, historical changes, other markets' strategies, and competitors' approaches., 4. Define d. Preferred Change strategy can be selected using org readiness, major cost and Investments, timeline for making change, alignment to business objectives, Change Description timelines for value realization, opportunity cost for change. d. Risk Analysis b. Solution Strategy Results Scope e. Opportunity cost refers to the benefits that could have been achieved by selecting an alternative change strategy. f. The net benefits of a future state may be very high, but if cost are also unbearable, entriprises may pass the opportunity & invest in something else. (-the solution g. Some changes decrease value in parts of an enterprise while increasing it in others. Enterprise Readiness Assessment scope that will be 11. Transition States & Release planning: is concerned with determining which requirements to include in each release, phase, or iteration of the change. Guideline: -BA Approach achieved through Business analysts help facilitate release planning for stakeholders to make decisions. execution of a. the future state will need to be achieved over time & therefore, the enterprise will have to operate in one or more transition states. - Design Options the change b. Consideration is to carry out the change without impact the current state. - Solution strategy.) Recommendations Change Strategy Transition States and Release Planning Knowledge Area Task Elements Input Output Key Point 1. BA analyze the potential value of both requirements & designs. 2. Purpose is to analyze, synthesize, and refine elicitation results into requirements and designs. Practices for analyzing elicitation results and creating representations of those results. Also, the specifying metadata about the requirements. 3. Needs are specified & modelled as Requirements; Solutions are specified and modelled as Designs. 4. Model is descriptive and visual way to convey information to a specific audience to support analysis, communication, a. Models may also be used to confirm knowledge, identify information gaps & identify duplicate information. 5. Types : a. Matrices - have a complex but uniform structure, which can be broken down into elements that apply to every entry in the Model Requirements - Matrices or Diagrams table. E.g. - data dictionaries, requirements, traceability, or for gap analysis. b. Diagrams: especially useful to depict complexity that would be difficult to do with words. E.g. - business domains, to categorize and create hierarchies of items, and to show components of objects such as data and their relationships. Inputs: 6. Modelling Categories - People and Roles (Org Modelling, Roles & Perm. Matrix, Personas), Rationale ('Why' - Decision/Scope Modelling, Elicitation Results (Any State) Business Model Canvas, RCA, Business Rule Analysis); Activity Flow (Process Modelling, Use cases, User Stories); Capability (Business Requirements Capability, Functional Decomposition, Prototyping), Data & infor (DFD, Interface analysis). Any combination of models can be used best Guidelines: suited to meet stakeholder needs in a context. (Specified & 7. Analyze Requirement: conduct to check if - anything must change; anything that should stay; missing components; unnecessary Specify & Model Analyze Requirements - Modelling Modeled) components; any constraints & assumptions. Level of detail according to SH's knowledge. Requirements Notations/Standards - in form of text, 8. Requirement Attributes: Identify req & their attributes as part of the elicitation results to show enough details. These attributes are - Modelling Tools diagram or decided during Information Mgmt Task. E.g. - Absolute Reference, Author, Complexity, Ownership, Priority, Risk, Source, Stability, Status, - Requirements Architecture matrices Urgency. Can also be classified under Req Schema (Business Req, Stakeholder Req. SOlution Req. - Functional/Non-functional, - Req Life Cycle Management Transition Req.) - Solution Scope 9. Abstraction based on the type of requirement & audience for the requirement. models. May also produce different viewpoints of requirements to represent the same need for different stakeholders. Represent Requirements & Attributes - Business Analysis Approach (Predictive or Adaptive) can also dictate level of abstraction & model used (prototypes) Implement the Appropriate level of Abstraction 1. Purpose is requirements & designs specifications & models meet quality standards & usable for the purpose served. 2. Ensures that the requirements and designs have been defined correctly. constitutes a check by the BA and key stakeholders to determine that the requirements and designs are ready for validation, & if further corrections required. 3. high-quality specification is - a. well written b. easily understood by its intended audience c. A high-quality model follows the formal Characteristics of Requirement & Designs or informal notation standards and effectively represents reality Quality 4. Most important is fitness for use. Quality is ultimately determined by stakeholders 5. Acceptable quality requirements characteristics - Atomic (self contained & understood independently of others); Complete (detailed Requirements enough for work to proceed); Concise (no unnecessary content); Consistent (aligned with Stakeholder's need & non conflicting with other Inputs: Verified Requirements (Specified & requirements); Feasible (reasonable & possible within agreed risk, cost, budget & schedule or can be investigated through prototypes or experiments); Unambiguous (Clearly Stated); Testable (able to be verified using a test), Priortized (ranked/grouped based on importance); Modeled) (- requirements or Understandable (represented using common terminology) Verify Requirements designs that is of 6. Verification Activities: a. compliance with organizational performance standards (tools & methods); b. use of correct modelling Verification Activities Guidelines: sufficient notation, templates, or forms; c. completeness within each model, d. comparing each model against other relevant models,(consistency) - Requirement Lifecycle quality to be used e. terminology used is understandable to stakeholders. f. Adding examples for clarification. Management Tool as a basis for 7. Checklists are used for quality control when verifying requirements and designs. Aim is to ensure that items determined to be further work.) important are included in final requirements deliverables, or steps req for verification process are followed. Checklists (quality control) 1. Purpose is requirements & designs align to the business requirements and support the delivery of needed value. 2. Ongoing process to ensure that SH, solution & transition requirements align to the business requirements & design satisfy requirements. Stakeholders have different, conflicting needs & expectations that may be exposed through validation.