IIBA-ECBA Study Guide "Understands" - Chapter 4,5,7
Model Categories
1. People and Roles 2. Rationale 3. Activity Flow 4. Capability 5. Data and Information
Model Requirements
A model is a descriptive and visual way to convey information to a specific audience in order to support analysis, communication, and understanding. Models may also be used to confirm knowledge, identify information gaps that the business analyst may have, and identify duplicate information. Modeling formats: -matrices -diagrams
Completeness
An architecture helps ensure that a set of requirements is complete. The entire set of requirements should be able to be understood by the audience in way that it can be determined that the set is cohesive and tells a full story. No requirements should be missing from the set, inconsistent with others, or contradictory to one another. The requirements architecture should take into account any dependencies between requirements that could keep the objectives from being achieved. Structuring requirements according to different viewpoints helps ensure this completeness. Iterations of elicitation, specification, and analysis activities can help identify gaps.
Analyze Requirements
Business analysis information is decomposed into components to further examine for: • anything that must change to meet the business need, • anything that should stay the same to meet the business need, • missing components, • unnecessary components, and • any constraints or assumptions that impact the components. The level of decomposition required, and the level of detail to be specified, varies depending on the knowledge and understanding of the stakeholders, the potential for misunderstanding or miscommunication, organizational standards, and contractual or regulatory obligations, among other factors. Analysis provides a basis for discussion to reach a conclusion about solution options.
Determine Objectives and Format of Communication
Business analysis information packages may be prepared for a number of reasons including—but not limited to—the following: • communication of requirements and designs to stakeholders, • early assessment of quality and planning, • evaluation of possible alternatives, • formal reviews and approvals, • inputs to solution design, • conformance to contractual and regulatory obligations, and • maintenance for reuse. The primary goal of developing a package is to convey information clearly and in usable format for continuing change activities. Possible forms for packages may include: • Formal Documentation: is usually based on a template used by the organization and may include text, matrices, or diagrams. It provides a stable, easy to use, long-term record of the information. • Informal Documentation: may include text, diagrams, or matrices that are used during a change but are not part of a formal organizational process. • Presentations: deliver a high-level overview appropriate for understanding goals of a change, functions of a solution, or information to support decision making. Consideration is given to the best way to combine and present the materials to convey a cohesive and effective message to one or more stakeholder groups. Packages can be stored in different online or offline repositories, including documents or tools.
Gain Consensus
Business analysts are responsible for ensuring that the stakeholders with approval authority understand and accept the requirements. Approval may confirm that stakeholders believe that sufficient value will be created for the organization to justify investment in a solution. Business analysts obtain approval by reviewing the requirements or changes to requirements with the accountable individuals or groups and requesting that they approve, indicating their agreement with the solution or designs described. Using the methods and means established in the tasks Plan Business Analysis Governance and Communicate Business Analysis Information business analysts present the requirements to stakeholders for approval. Business analysts facilitate this approval process by addressing any questions or providing additional information when requested. Complete agreement may not be necessary for a successful change, but if there is a lack of agreement, the associated risks are to be identified and managed accordingly.
Compare Elicitation Results Against Other Elicitation Results
Business analysts compare results collected through multiple elicitation activities to confirm that the information is consistent and accurately represented. As comparisons are drawn, business analysts identify variations in results and resolve them in collaboration with stakeholders. Comparisons may also be made with historical data to confirm more recent elicitation results. Inconsistencies in elicitation results are often uncovered when business analysts develop specifications and models. These models may be developed during an elicitation activity to improve collaboration.
Represent Requirements and Attributes
Business analysts identify information for requirements and their attributes as part of the elicitation results. Requirements should be explicitly represented and should include enough detail such that they exhibit the characteristics of requirements and designs quality. Various attributes can be specified for each requirement or set of requirements. These attributes are selected when planning for information management (see Plan Business Analysis Information Management. As part of specifying requirements, they can also be categorized according to the schema described in task Requirements Classification Schema (p. 16). Typically elicitation results contain information of different types, so it is natural to expect that different types of requirements might be specified at the same time. Categorizing requirements can help ensure the requirements are fully understood, a set of any type is complete, and that there is appropriate traceability between the types.
Secure Supporting Material
Business analysts identify sources of information that are needed to conduct the elicitation activity. There might be a great deal of information needed to conduct elicitation including people, systems, historical data, materials and documents. Documents could include existing system documents, relevant business rules, organizational polices, regulations, and contracts. Supporting materials might also take the form of outputs of analysis work, such as draft versions of analysis models.
Prepare Stakeholders
Business analysts may need to educate stakeholders on how an elicitation technique works or what information is needed. It may be helpful to explain an elicitation technique to stakeholders not involved in the activity to help them understand the validity and relevance of the information elicited. Stakeholders may be unresponsive or challenging during an elicitation activity if they feel that it is not aligned to their individual objectives, don't understand the purpose, or are confused about the process. In preparing for elicitation, the business analyst should ensure that there is buy-in from all necessary stakeholders. Business analysts may also prepare stakeholders by requesting that they review supporting materials prior to the elicitation activity in order to make it as effective as possible. An agenda might be provided in advance to support stakeholders in coming prepared to the activity with the necessary frame of mind and information. Eliciting through research or exploration may be a solo activity for the business analyst and not require preparing other stakeholders.
Monitor Stakeholder Engagement
Business analysts monitor the participation and performance of stakeholders to ensure that: • the right subject matter experts (SMEs) and other stakeholders are participating effectively, • stakeholder attitudes and interest are staying constant or improving, • elicitation results are confirmed in a timely manner, and • agreements and commitments are maintained. Business analysts continually monitor for such risks as: • stakeholders being diverted to other work, • elicitation activities not providing the quality of business analysis information required, and • delayed approvals.
Assessment Formality
Business analysts will determine the formality of the assessment process based on the information available, the apparent importance of the change, and the governance process. Many proposed changes may be withdrawn from consideration or declined before any formal approval is required. A predictive approach may indicate a more formal assessment of proposed changes. In predictive approaches, the impact of each change can be disruptive; the change can potentially generate a substantial reworking of tasks and activities completed in previous activities. An adaptive approach may require less formality in the assessment of proposed changes. While there may be reworking needed as a result of each change, adaptive approaches try to minimize the impact of changes by utilizing iterative and incremental implementation techniques. This idea of continuous evolution may reduce the need for formal impact assessment.
Describe Design Options
Design options are investigated and developed while considering the desired future state, and in order to ensure the design option is valid. Solution performance measures are defined for each design option. A design option usually consists of many design components, each described by a design element. Design elements may describe: • business policies and business rules, • business processes to be performed and managed, • people who operate and maintain the solution, including their job functions and responsibilities, • operational business decisions to be made, • software applications and application components used in the solution, and • organizational structures, including interactions between the organization, its customers, and its suppliers.
Expected Benefits
Expected benefits describe the positive value that a solution is intended to deliver to stakeholders. Value can include benefits, reduced risk, compliance with business policies and regulations, an improved user experience, or any other positive outcome. Benefits are determined based on the analysis of the benefit that stakeholders desire and the benefit that is possible to attain. Expected benefits can be calculated at the level of a requirement or set of requirements by considering how much of an overall business objective the set of requirements contribute to if fulfilled. The total expected benefit is the net benefit of all the requirements a particular design option addresses. Benefits are often realized over a period of time.
Expected Costs
Expected costs include any potential negative value associated with a solution, including the cost to acquire the solution, any negative effects it may have on stakeholders, and the cost to maintain it over time. Include: timeline, • effort, • operating costs, • purchase and/or implementation costs, • maintenance costs, • physical resources, • information resources, and • human resources. Expected costs for a design option consider the cumulative costs of the design components. Business analysts also consider opportunity cost when estimating the expected cost of a change. Opportunity costs are alternative results that might have been achieved if the resources, time, and funds devoted to one design option had been allocated to another design option. The opportunity cost of any design option is equal to the value of the best alternative not selected.
Requirements Allocation
Requirements allocation is the process of assigning requirements to solution components and releases to best achieve the objectives. Allocation is supported by assessing the trade-offs between alternatives in order to maximize benefits and minimize costs. The value of a solution might vary depending on how requirements are implemented and when the solution becomes available to stakeholders. The objective of allocation is to maximize that value. Requirements may be allocated between organizational units, job functions, solution components, or releases of a solution. Requirements allocation typically begins when a solution approach has been determined, and continues until all valid requirements are allocated. Allocation typically continues through design and implementation of a solution.
Relate and Verify Requirements Relationships
Requirements may be related to each other in several ways when defining the requirements architecture. Business analysts examine and analyze the requirements to define the relationships between them. The representation of these relationships is provided by tracing requirements Business analysts examine each relationship to ensure that the relationships satisfy the following quality criteria: • Defined: there is a relationship and the type of the relationship is described. • Necessary: the relationship is necessary for understanding the requirements holistically. • Correct: the elements do have the relationship described. • Unambiguous: there are no relationships that link elements in two different and conflicting ways. • Consistent: relationships are described in the same way, using the same set of standard descriptions as defined in the viewpoints.
Collaboration
Stakeholders are more likely to support change if business analysts collaborate with them and encourage the free flow of information, ideas, and innovations. Genuine stakeholder engagement requires that all stakeholders involved feel that they are heard, their opinions matter, and their contributions are recognized. Collaboration involves regular, frequent, and bi-directional communication. Collaborative relationships help maintain the free flow of information when obstacles and setbacks occur, and promote a shared effort to resolve problems and achieve desired outcomes.
Gain Agreement on Commitments
Stakeholders participate in business analysis activities that may require time and resource commitments. The business analyst and stakeholders identify and agree upon these commitments as early in the initiative as possible. The specific details of the commitments can be communicated formally or informally, as long as there is explicit understanding of the expectations and desired outcomes of the commitment. There may be dialogue and negotiation regarding the terms and conditions of the commitments. Effective negotiation, communication, and conflict resolution skills are important to effective stakeholder management
Compare Elicitation Results Against Source Information
Task Conduct Elicitation describes sources from which elicitation results may be derived, including documents and stakeholder knowledge. The business analyst may lead follow-up meetings where stakeholders correct the elicitation results. Stakeholders may also confirm the elicitation results independently.
Select Elicitation Techniques
The techniques used depend on cost and time constraints, the types of business analysis information sources and their access, the culture of the organization, and the desired outcomes. The business analyst may also factor in the needs of the stakeholders, their availability, and their location (co-located or dispersed). Choosing the right techniques and ensuring each technique is performed correctly is extremely important to the success of the elicitation activity. BA consider: • techniques commonly used in similar initiatives, • techniques specifically suited to the situation, and • the tasks needed to prepare, execute, and complete each technique.
Understand Stakeholder Roles
The approval process is defined by the task Plan Business Analysis Governance. Part of defining the approval process is understanding stakeholder roles and authority levels. Business analysts are responsible for obtaining stakeholder approvals and are required to understand who holds decision-making responsibility and who possesses authority for sign-off across the initiative. Business analysts also consider any influential stakeholders who should be consulted or informed about the requirements. Few stakeholders may have the authority to approve or deny changes, but many stakeholders may be able to influence these decisions.
Basis for Prioritization
The basis on which requirements are prioritized is agreed upon by relevant stakeholders as defined in the Business Analysis Planning and Monitoring knowledge area. Benefit Penalty Cost Risk Dependencies Time-Sensivity Stability Regulatory or Policy Compliance
Implement the Appropriate Levels of Abstraction
The level of abstraction of a requirement varies based on the type of requirement and audience for the requirement. Not all stakeholders require or find value in the complete set of requirements and models. It may be appropriate to produce different viewpoints of requirements to represent the same need for different stakeholders. Business analysts take special care to maintain the meaning and intent of the requirements over all representations. The business analysis approach may also influence the level of abstraction and choice of models used when defining requirements.
Communicate Business Analysis Package
The purpose of communicating the business analysis package is to provide stakeholders with the appropriate level of detail about the change so they can understand the information it contains. Stakeholders are given the opportunity to review the package, ask questions about the information, and raise any concerns they may have. • Group collaboration: used to communicate the package to a group of relevant stakeholders at the same time. It allows immediate discussion about the information and related issues. • Individual collaboration: used to communicate the package to a single stakeholder at a time. It can be used to gain individual understanding of the information when a group setting is not feasible, most productive, or going to yield the best results. • E-mail or other non-verbal methods: used to communicate the package when there is a high maturity level
Define Solution Approaches
The solution approach describes whether solution components will be created or purchased, or some combination of both. Business analysts assess the merits of the solution approaches for each design option. Include: 1. Create 2. Purchase 3. Combination of both
Business Analysis Information Architecture
The structure of the business analysis information is also an information architecture. This type of architecture is defined as part of the task Plan Business Analysis Information Management. The information architecture is a component of the requirements architecture because it describes how all of the business analysis information for a change relates. It defines relationships for types of information such as requirements, designs, types of models, and elicitation results. Understanding this type of information structure helps to ensure that the full set of requirements is complete by verifying the relationships are complete. It is useful to start defining this architecture before setting up infrastructure such as requirements life cycle management tools, architecture management software, or document repositories.
Understand the Scope of Elicitation
To determine the scope of elicitation BA consider: • business domain, • overall corporate culture and environment, • stakeholder locations, • stakeholders who are involved and their group dynamics, • expected outputs the elicitation activities will feed, • skills of the business analysis practitioner, • other elicitation activities planned to complement this one, • strategy or solution approach, • scope of future solution, and • possible sources of the business analysis information that might feed into the specific elicitation activity. Understanding the scope of the elicitation activity allows business analysts to respond if the activity strays from the intended scope. It also allows them to recognize if people and materials are not available in time, and when the activity is complete.
Conflict and Issue Management
To maintain stakeholder support for the solution, consensus among stakeholders is usually sought prior to requesting approval of requirements. The approach for determining how to secure decisions and resolve conflicts across an initiative is planned for in the task Plan Business Analysis Governance. Stakeholder groups frequently have varying points of view and conflicting priorities. A conflict may arise among stakeholders as a result of different interpretations of requirements or designs and conflicting values placed on them. The business analyst facilitates communication between stakeholders in areas of conflict so that each group has an improved appreciation for the needs of the others. Conflict resolution and issue management may occur quite often, as the business analyst is reviewing requirements and designs, and aiming to secure sign-off.
Guide Elicitation Activity
Understanding the proposed representations of business analysis information, which were defined in planning, helps ensure that the elicitation activities are focused on producing the intended information at the desired level of detail. This applies to each instance of an elicitation activity throughout a change and may vary based on the activity. BA consider: • the elicitation activity goals and agenda, • scope of the change, • what forms of output the activity will generate, • what other representations the activity results will support, • how the output integrates into what is already known, • who provides the information, • who will use the information, and • how the information will be used. While most of these are considered when planning for the elicitation activity, they are also all important while performing the elicitation activity in order to keep it on track and achieve its goal. For example, stakeholders might have discussions that are out of scope for the activity or change, and the business analyst needs to recognize that in the moment to determine the next step; either acknowledge it and continue, or guide the conversation differently.
Identify Improvement Opportunities
When proposing design options, a number of opportunities to improve the operation of the business may occur and are compared. Examples: 1. Increase Efficiencies 2. Improve access to information 3. Identify Additional Capabilities
Level of Formality
When tracing requirements, business analysts consider the value that each link is supposed to deliver, as well as the nature and use of the specific relationships that are being created. The effort to trace requirements grows significantly when the number of requirements or level of formality increases.
Characteristics of Requirements and Designs Quality
While quality is ultimately determined by the needs of the stakeholders who will use the requirements or the designs, acceptable quality requirements exhibit many of the following characteristics: 1. Atomic 2. Complete 3. Consistent 4. Concise 5. Feasible 6. Unambiguous 7. Testable 8. Prioritized 9. Understandable
Diagrams
a diagram is a visual, often pictorial, representation of a requirement or set of requirements. A diagram is especially useful to depict complexity in a way that would be difficult to do with words. Diagrams can also be used to define boundaries for business domains, to categorize and create hierarchies of items, and to show components of objects such as data and their relationships.
Matrices
a matrix is used when the business analyst is modelling a requirement or set of requirements that have a complex but uniform structure, which can be broken down into elements that apply to every entry in the table. Matrices may be used for data dictionaries, requirements traceability, or for gap analysis. Matrices are also used for prioritizing requirements and recording other requirements attributes and metadata
Testable
able to verify that the requirement or design has been fulfilled. Acceptable levels of verifying fulfillment depend on the level of abstraction of the requirement or design.
Consistent
aligned with the identified needs of the stakeholders and not conflicting with other requirements.
Increase Efficiencies
automate or simplify the work people perform by reengineering or sharing processes, changing responsibilities, or outsourcing. Automation may also increase consistency of behaviour, reducing the likelihood of different stakeholders performing the same function in distinctly different fashions.
Verification Activities
checking for compliance with organizational performance standards for business analysis, such as using the right tools and methods, • checking for correct use of modelling notation, templates, or forms, • checking for completeness within each model, • comparing each model against other relevant models, checking for elements that are mentioned in one model but are missing in other models, and verifying that the elements are referenced consistently, • ensuring the terminology used in expressing the requirement is understandable to stakeholders and consistent with the use of those terms within the organization, and - adding examples where appropriate for clarification.
Concise
contains no extraneous and unnecessary content
Complete
enough to guide further work and at the appropriate level of detail for work to continue. The level of completeness required differs based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented.
Identify Additional Capabilities
highlight capabilities that have the potential to provide future value and can be supported by the solution. These capabilities may not necessarily be of immediate value to the organization (for example, a software application with features the organization anticipates using in the future).
Capability
models focus on features or functions of an enterprise or a solution. Techniques used to represent capabilities include Business Capability Analysis, Functional Decomposition, and Prototyping.
Activity Flow
models represent a sequence of actions, events, or a course that may be taken. Techniques used to represent activity flows include Process Modelling, Use Cases and Scenarios, and User Stories.
People and Roles
models represent organizations, groups of people, roles, and their relationships within an enterprise and to a solution. Techniques used to represent people and their roles include Organizational Modelling, Roles and Permissions Matrix and Stakeholder List, Map, or Personas.
Rationale
models represent the 'why' of a change. Techniques used to represent the rationale include Decision Modelling, Scope Modelling, Business Model Canvas, Root Cause Analysis, and Business Rules Analysis.
Data and Information
models represent the characteristics and the exchange of information within an enterprise or a solution. Techniques used to represent data and information include Data Dictionary, Data Flow Diagrams, Data Modelling, Glossary, State Modelling, and Interface Analysis.
Combination of both
not all design options will fall strictly into one of the categories above. Design options may include a combination of both creation and purchase of components.
Improve Access to Information
provide greater amounts of information to staff who interface directly or indirectly with customers, thereby reducing the need for specialists.
Prioritized
ranked, grouped, or negotiated in terms of importance and value against all other requirements.
Feasible
reasonable and possible within the agreed-upon risk, schedule, and budget, or considered feasible enough to investigate further through experiments or prototypes.
Dependencies
relationships between requirements where one requirement cannot be fulfilled unless the other requirement is fulfilled. In some situations, it may be possible to achieve efficiencies by implementing related requirements at the same time. Dependencies may also be external to the initiative, including but not limited to other teams' decisions, funding commitments, and resource availability. Dependencies are identified as part of the task Trace Requirements
Understandable
represented using common terminology of the audience.
Regulatory or Policy Compliance
requirements that must be implemented in order to meet regulatory or policy demands imposed on the organization, which may take precedence over other stakeholder interests.
Atomic
self-contained and capable of being understood independently of other requirements or designs.
Create
solution components are assembled, constructed, or developed by experts as a direct response to a set of requirements. The requirements and the design options have enough detail to make a decision about which solution to construct. This option includes modifying an existing solution.
Purchase
solution components are selected from a set of offerings that fulfill the requirements. The requirements and design options have enough detail to make a recommendation about which solution to purchase. These offerings are usually products or services owned and maintained by third parties.
Time Sensitivity
the 'best before' date of the requirement, after which the implementation of the requirement loses significant value. This includes time-to-market scenarios, in which the benefit derived will be exponentially greater if the functionality is delivered ahead of the competition. It can also refer to seasonal functionality that only has value at a specific time of year.
Benefit
the advantage that accrues to stakeholders as a result of requirement implementation, as measured against the goals and objectives for the change. The benefit provided can refer to a specific functionality, desired quality, or strategic goal or business objective. If there are multiple stakeholders, each group may perceive benefits differently. Conflict resolution and negotiation may be employed to come to consensus on overall benefit.
Risk
the chance that the requirement cannot deliver the potential value, or cannot be met at all. This may include many factors such as the difficulty of implementing a requirement, or the chance that stakeholders will not accept a solution component. If there is a risk that the solution is not technically feasible, the requirement that is most difficult to implement may be prioritized to the top of the list in order to minimize the resources that are spent before learning that a proposed solution cannot be delivered. A proof of concept may be developed to establish that high risk options are possible.
Penalty
the consequences that result from not implementing a given requirement. This includes prioritizing requirements in order to meet regulatory or policy demands imposed on the organization, which may take precedence over other stakeholder interests. Penalty may also refer to the negative consequence of not implementing a requirement that improves the experience of a customer.
Cost
the effort and resources needed to implement the requirement. Information about cost typically comes from the implementation team or the vendor. Customers may change the priority of a requirement after learning the cost. Cost is often used in conjunction with other criteria, such as cost-benefit analysis.
Stability
the likelihood that the requirement will change, either because it requires further analysis or because stakeholders have not reached a consensus about it. If a requirement is not stable, it may have a lower priority in order to minimize unanticipated rework and wasted effort.
Unambiguous
the requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need.
Relationships
• Derive: relationship between two requirements, used when a requirement is derived from another requirement. This type of relationship is appropriate to link the requirements on different levels of abstraction. For example, a solution requirement derived from a business or a stakeholder requirement. • Depends: relationship between two requirements, used when a requirement depends on another requirement. Types of dependency relationships include: • Necessity: when it only makes sense to implement a particular requirement if a related requirement is also implemented. • Effort: when a requirement is easier to implement if a related requirement is also implemented. • Satisfy: relationship between an implementation element and the requirements it is satisfying. For example, the relationship between a functional requirement and a solution component that is implementing it. • Validate: relationship between a requirement and a test case or other element that can determine whether a solution fulfills the requirement.