Practice Exams:

IIBA ECBA – Business Analysis and Requirements Life Cycle Management Part 4

  1. Exercise – Maintain and Prioritize Requirements

Assess requirements, changes, guidelines and Techniques After completing this topic, you should be able to recognize guidelines and techniques used when assessing changes to requirements. The following guidelines and tools will be used by the Business Analyst to manage changes. The change strategy is a plan of activities needed to move from the current state to the future state. When changes are requested, the Business Analyst reviews the context and the alignment of the business objectives. Domain knowledge is needed by the Business Analyst to assess a proposed change. If the change is requested to add functionality that will allow customers to purchase alcohol using the search service station, the Business Analyst knowledge will include regulations related to age restrictions. The governance approach outlined the change control and decision process that will be used by the Business Analyst to manage requirements and design changes.

Legal and regulatory information are reviewed by the Business Analyst to ensure that any requested changes are compliant. He or she may work with a compliance expert to ensure that their analysis is correct. The Requirements architecture structures the requirements in a way to show the requirements and designs relate to each other. The structure is used by the Business Analyst to see how a change impacts the primary requirement and those that relate to it. Guidelines and Tools Guidelines and tools include change strategy, domain knowledge, governance approach, legal and regulatory information, and requirements architecture.

The Business Analyst reviews the solution scope ensures that the requested change falls within it. In the case of, for example, the Business Analyst will assess that the requested changes aligns to the goals of the business and if the change is also aligned to the scope of the self service station that we used for an example. If a change is requested to add the ability for a customer to select coupons, for example, to be printed for a later date, this will be assessed by the Business Analyst. The outcome could be that this is a great marketing strategy that doesn’t align to the business needs to have customers check out groceries.

There are various techniques for assessing changes. When a change is requested to a business rule, the Business Analyst will ensure that the rule or policy is written clearly and validated. He or she will also assess which requirements are impacted by the change. Business Rule financial analysis is used to assess the financial viability of the change. Estimation techniques will also be used to determine the financial impact. Risk analyzes and management is used to determine the level of risk the proposed changes poses. Decision analysis will be used to facilitate decisions regarding the change, and Interface Analyzes determines which interfaces will be impacted by the change or if there are new interfaces needed to enable the change. Guidelines and tools.

An additional guideline is Solution Scope Techniques for Assessing Changes. The techniques for assessing changes are placed in the categories Analyzes, group techniques, Tools and Document reviews. Analyzing techniques are Business Rules analyzes Financial analysis, risk analysis and management, decision analyzes and interface analysis. Group techniques are interviews and workshops. Tools include estimation and item tracking. Document review techniques are document analysis and business cases. There are two group techniques interviews where the business analyst will meet with one or more stakeholders to understand and validate the requested change. Workshops are used to understand the change and its impacts using a group settings and various techniques such as brainstorming to facilitate discussions on impacts, cost and risk. The business analyst will use various tools such as estimation techniques.

Estimation techniques will also be used to determine the time and financial impact. Item tracking will be used to track stakeholder concerns and issues with the proposed change. Documents will be reviewed by the business analysts to determine the impact of the change. This will include assessing the business case to ensure that the proposed change is aligned to the solution scope, business goals and objectives, and the business constraints.

  1. Assess Requirements Changes – Inputs and Elements

Assess requirements, changes, stakeholders and Outputs After completing this topic, you should be able to identify the outputs of the assess requirements. Changes Task a domain subject matter expert will provide input as to the impact of the proposed change and to the organization. Operational support will advise the Business Analyst if the request to change can be supported in the solution. The project manager will review the change to determine the impact of the project task and timelines. The project sponsor provides input on impact on a solution scope and may or may not approve the change, and the tester is consulted to determine the impact of the change to the solution and to the test plan.

The customer advises how the change will affect the value of the solution. For example, the Business Analyst could conduct interviews with customers asking if a change like adding voice commands to the user interface will assist them while they walk through the checkout process and ask if this is a value for them. Operational stakeholders. The operational stakeholders are the domain subject matter expert who provides input on the impact of the proposed change the operational support who provides input on the ability to support change in the solution the project manager who reviews assessment to determine impact on project work the sponsor who provides input on impact on the solutions cop and the tester who is consulted regarding the impact of the change. Other Stakeholders The other stakeholders are the customer, who provides input on how change will affect value, the end user, who provides input on how change will impact the solution and the regulator, who ensures legal and regulatory compliance.

The customer may say that it’s helpful or annoying, the end user will provide input on how the change will impact the solution on their day to day work, and the regulator ensures that the requested change aligns to regulatory and compliance needs. Once the Business Analyst has assessed the change impacts, he or she makes recommendations regarding proposed changes. These include whether to approve the change, modify the request, or reject the change. In the case of modifying a request, the Business Analyst may reduce the scope of the request. For example, if a request to add three languages Spanish, French and Mandarin, for example, to the user interface, the Business Analyst will conduct analysis on the impacts to the user interface.

The printed receipt and current infrastructure can address Spanish and French, but not mandatory because the technology doesn’t support the character set. Therefore, the Business Analyst may also determine that the customer base doesn’t have an need for Mandarin at this time. Change Assessments The recommendations regarding proposed changes can be to approve, modify or reject changes.

  1. Assess Requirements Changes – Guidelines and Techniques

Approve requirements, inputs and Elements after completing this topic, you should be able to recognize the business analyst responsibilities related to the approval of requirements. The business analyst facilitates approval of requirements and designs, allowing the development of a solution to proceed. The inputs are verified requirements. Verified requirements are reviewed by the implementation team to ensure that they are of the right quality in order to proceed. Designs are also verified by the implementation team and are inputs to approve requirements. The output is approved. Requirements and Approved Designs verified requirements are reviewed by the implementation team to ensure that they understand them and that the requirements are of a quality for the requirements to be used for further specification and development.

Designs are also reviewed to ensure that they accurately reflect the requirements and are ready for additional work and for the specifications. Other business analyzing information may be used, such as traceability metrics and an item tracking metrics. Approval signifies agreement to invest in a solution. The approval and consensus gaining processes are defined during the planned business analyzed governance task and are documented in the governance approach and information management approach. Approve Requirements Overview the approved requirements task has as inputs, verified requirements and designs.

The task outputs are approved requirements and approved designs. Inputs verified requirements are requirements to be used for further specification and development. Designs are ready for additional work and further specification. Gain Stakeholders Consensus approval signifies agreement to invest in solution. The business analyzes responsibility is to facilitate stakeholder consensus. This includes knowing who has decision making authority, consulting with influential stakeholders to make sure that they have the information they need to make an informed decision, obtain stakeholder approvals through presentations or requirements, work throughthes and get proper sign off. As it stated in the governance approach, the business analyst will inform stakeholders about the requirements and identify lack of agreement as a risk and work with the sponsor and project manager to resolve any conflict. If the business analyst continually communicates the progress of the requirements, the approval process should be seamless.

It is the business analyst responsibility to make issues managed and facilitate consensus among stakeholders. They may hold conflicting views of the value of a particular requirement and its priority. The business analyst facilitates communication during conflicts and will have stakeholders to understand the needs of others, explain the prioritization and approval process. Gain Stakeholders’consensus the business analyst responsibilities are knowing who has decision making authority, consulting influential stakeholders, making sure they have the information they need, obtaining stakeholder approval, getting proper sign off, informing stakeholders about requirements, and finally identifying lack of agreement as a risk. Conflict and issue management.

Stakeholders may hold conflicting views, as I said so the business analyst should facilitate communication during conflicts and help stakeholders understand the needs of others. He or she will track communication and manage the approval process. The business analyst records the approval decisions and will keep track of the approval status for a given requirement. He or she will maintain the audit history for each change. While the change was who requested a change, when the change was made and why it was made, and the approval around it, decisions for changes will be maintained in a requirements repository, and this is especially helpful during user acceptance testing. It’s quite common for someone reviewing the solution to ask why certain functionality exists or doesn’t exist. This is where a change approval record can be used to explain the circumstances of the change and why the decisions were made. Track and Communicate Approval It’s important to record approval decisions, keep track of statues, and maintain an audit history for each change, including what it was, who made it, when it was made, and why it was made.

  1. Assess Requirements Changes – Stakeholders and Outputs

Approve requirements. Guidelines and Techniques after completing this topic, you should be able to recognize how requirements are reviewed and approved. There are various guidelines and tools used by the Business Analyst to gain approval of requirements. Legal and regulatory information contains rules and regulations that must be followed, such as who has the sign of authority and the size of the expenditure and the signing authority associated with it. The change strategy outlines the context for the changes to the organization and the value realized by the solution. When approving requirements, it is important to highlight how the solution is meeting stakeholder needs. The Requirements Management Repository provides tools for recording and tracking of approvals. The governance approach details who gives approval, when and how they align with the organizational policies. The solution scope will help assess alignment and completeness of the requirements prior to approval.

There are various techniques for approving requirements. Decision analysis ensures the value and impacts of a solution are understood by stakeholders, pointing out the goals and objectives of the business and how the solution aligns to them. The Business Analyst elicits areas of uncertainty, providing information to ensure understanding and agreement. Acceptance and evaluation criteria outline the outcomes and conditions that the requirements must meet in order to approve the requirements. Guidelines and Tools There are several guidelines, as I said, and tools, and each has a different way of supporting the approval of requirements. Legal and regulatory information contains rules and regulations that must be followed.

The change strategy holds information regarding stakeholder needs. The Requirements Management repository provides tools for recording and tracking approvals. Governance approach details who gives approval, when and how they align with organizational policy solutionscope helps assess the alignment and complexness of requirements. Techniques for Approving Requirements The techniques include decision analysis and acceptance and evaluation criteria. Item tracking is used to document and manage issues and conflicts that will keep the requirements from being approved.

These have to be managed closely by the Business Analyst. Reviews facilitate the evaluation of the requirements by the stakeholders to ensure that they meet their needs. This is also referred to as validation implementation.

Subject matter experts review the requirements and designs to assess that they are of sufficient quality for work to begin. Workshops are used to gain consensus from a group of stakeholders. The domain subject matter experts reviews the respective requirements to approve them. The Business Analyst role is to walk them through it to ensure that they understand the requirements and the respective value. Operational support ensures the requirements can be supported once they are implemented and may make suggestions on which requirements care or cannot be supported. The project manager manages project risk associated with a solution and may manage the approval process. The sponsor reviews and approves the requirements, and the tester verifies that the requirements are testable. Techniques for approving requirements.

Other techniques are item tracking, reviews and workshops. Operational Stakeholders The operational stakeholders are the domain subject matter expert who reviews and approves requirements operational support who ensures requirements and designs are supported, the project manager, who identifies and manages risk, the sponsor who reviews and approves requirements, and the tester who ensures that quality assurance quality standards are feasible. The customer or customer advocate, such as marketing, ensures value is realized and the customer needs are met. The end user will review the requirements to ensure that they meet their daily needs. The regulator ensures requirements are compliant legally and meet internal business policies.

The output is approved. Requirements and designs that are agreed to by stakeholders and ready to use. Approved designs used in solution development efforts are also reviewed and approved. Approved requirements may need an ink signature. However, requirements management tools will indicate the statues of particular requirements or the entire solution as approved. Any memos or notes related to approval or any issues related to approval should be stored and managed by the business analysts. Other Stakeholders The other stakeholders are the customer who reviews and approves requirements to ensure needs are met, the end user, who reviews and validates requirements and the regulator, who provides input on relationships and ensures compliance with regulations. Outputs the output is approved requirements and designs which are agreed to by stakeholders and are ready for use. Approved designs are used in solution development efforts. You.

  1. Approve Requirements – Inputs and Elements

Exercise assess and approve requirements. After completing this topic, you should be able to recognize what’s involved in assessing and approving requirements. Therefore, in this exercise, you are required to recognize what’s involved in assessing and approving requirements, nothing more, nothing less. The impact of any potential changes to requirements need to be analyzed. What the business analysts need to consider during the Assessed Requirements Changes task. Here you have the options whether an impact analysis needs to be performed if the project approach is adaptive.

The need to conduct an impact analysis if the project approach is predictive whether a proposed change impacts any aspect of a business or its deliverables at any time the cost impact of a proposed change based on the phase of the traceability and lastly, the level of formality that’s required for a change assessment. Here we have the answer. Option One this option is incorrect regardless of whether the project approach happens to be predictive or adaptive, and impact analysis is conducted to determine which requirements and designs are affected by requested change. Option Two this option is incorrect and impact analysis helps to determine which requirements and designs are affected by requested change. This analysis is done regardless of whether a project is predictive and adaptive. Option Three this option is incorrect. Consideration needs to be given to the fact that a proposed change may impact any part of business analyzes or deliverables at any time. Option Four this option is correct. You can refer to the traceability metrics to determine if primary independent requirements are impacted and to discern the trade state the requirement is in. This helps define the cost impact. Option Five and the last One this option is correct. Business analysts need to consider the level of formality that’s required for a particular change assessment.

This may be outlined in the Information Management approach. Applicable guidelines should be adhered to as part of the Assessed Requirements Change task. Which guidelines and tools help assess proposed requirements change? Here we have the options Project Plan, SWOT Analysis, Solution Scope, Requirements Architecture, Domain Knowledge, and Change Strategy. And here we have the answer. Option One this option is incorrect. The project manager, rather than the business analyst, tries to determine how requirement may impact the project by referring to the plan. Option Two this option is incorrect as what analyzes is used to analyze strengths, weaknesses, opportunities and threats. This tool is not used during the Assessed Requirements Changes task.

Option Three this option is correct. You can review the solution scope to ensure a request requirements change falls within it. Option Four this option is correct. You can refer to the requirements architecture to establish how a change impacts the primary requirement and those that relate to it. Option Five this option is correct. You can apply domain knowledge, which includes expertise, to assess a proposed change. Option Six this option is correct. You can refer to the Change strategy, which lists the activities needed to move from the current state to the future state. Business analysts should evaluate the impact of proposed changes to requirements and designs.

What is the output of the assessed requirements? Changes task? Here we have the options a recommendation on whether the proposed change should align with a solution, a recommendation on whether to conduct an impact analysis, or a recommendation on whether the proposed change should be accepted or rejected. And here we have the answers. Option One this option is incorrect. This is not an output of the assessed Requirements Changes Task. Requirements must always be in alignment with a solution. No recommendations are needed.

Option Two this option is incorrect. Impact analysis are conducted to determine which requirements and designs are affected by a requested change. This is not an output of the Assess Requirements Changes task. Option Three this is the correct option. The assess requirements changes task outputs are a requirements. Change Assessment and Design change Assessment this is typically presented as a recommendation to modify, accept or reject a proposed change. Business analysts facilitate approval of requirements and designs during the Approved Requirements Task, which signals the development of the solution to proceed.

What can you do as part of your responsibilities in the Approve Requirements Task? Here you have the options destroy the audit history for each change after it has been proposed. Consult influential stakeholders and inform them about requirements. Determine who gives approval, when and how. Remove bias by preventing information in the Requirements repository from being accessed during user acceptance testing. Identify lack of agreement as a risk and obtain stakeholder approval and get proper sign off. And here we have the answer. Option One this option is incorrect. A business analyst needs to maintain the audit history for each change. This includes knowing details of a requested requirement and who requested it. Option Two this option is correct. It is the business analyst responsibility to consult with influential stakeholders and ensure that they have the information they need to make an informed decision and inform them about the requirements. Option Three this option is correct. As a business analyst, you are responsible for facilitating stakeholder consensus. This includes knowing who has decision making authority. Option Four this option is incorrect. Decisions regarding requests for requirement changes will be maintained in a requirements repository. This information is useful during user acceptance testing.

Option Five this option is correct. Business analysts need to identify a lack of agreement among stakeholders as a risk can work with a sponsor and project manager to resolve any conflicts. Option Six this option is correct. It is your responsibility to obtain stakeholder approvals through presentations or requirements walkthrough and get proper sign off. As it states in the governance approach, business analysts can use various guidelines and tools to help facilitate requirements approval. Which techniques can be used in the approval requirements task. Here we have the Options workshops, traceability metrics, decision analyzes, data modeling, acceptance and evaluation criteria.

And here we have the answer. Option One this option is correct. Workshops can be used to gain consensus among a group of stakeholders regarding the respective requirements that need to be approved. The business analyst role is to walk stakeholders through the proposed requirements to ensure that they are understood. Option Two this option is incorrect. The traceability matrix is used by a project manager to trace requirements. This is not a technique that’s used during the approved requirements task. Option Three this option is correct.

Decision analysis is a technique that can be used to ensure the value and impact of a solution are understood by the stakeholders. This is done by pointing out the goals and objectives of the business and how the solution applies to them. Option Four this option is incorrect. Data modeling is a technique that is used during the assess requirements changes task, not during the approved requirements task. Option Five and the last one. This option is correct. You can use acceptance and the evaluation criteria to outline the outcomes and conditions that requirements must meet in order to be approved by stakeholders.

  1. Approve Requirements – Guidelines and Techniques

Congratulations. You finished the business? Analyzes and requirements lifecycle management course. In this course, we started looking at the Business Analyzes knowledge Area Requirements lifecycle Management Requirements are the foundation of all your Business Analyzes activities. If the objective of a project is to deliver solutions that best meet requirements, then you best keep a close eye on those requirements and the designs that address them. So in this course, we looked at your role in tracing and maintaining requirements and designs.

The first part of the course called An Introduction to Requirements lifecycle deals with requirements lifecycle Management requirements Management. And it’s finished with an exercise on understanding requirements management. The second part of the course, called Trace Requirements, has the following structure requirements and Traceability trace Requirements, inputs and elements, trace Requirements Guidelines and techniques, trace Requirements Stakeholders and outputs, and an Exercise on Trace Requirements. This is just to remind you the broad structure. The third part of the course called maintain and prioritize requirements. Includes maintain requirements, elements and guidelines. You will see that this is pretty standard maintain Requirements, techniques and stakeholders, prioritize Requirements, Inputs and elements, prioritize Requirements Guidelines and techniques, prioritize Requirements Stakeholders and outputs, and an exercise on maintaining and prioritizing Requirements. The fourth and the last part of this course is called Assess Changes and Approve Requirements and has this structure assess Requirements, Changes, Inputs and elements, assess Requirements changes, Guidelines and techniques, assess Requirements changes, Stakeholders and outputs, approve Requirements, Inputs and elements, approved Requirements, Guidelines and Techniques and finally, an exercise on assessing and approving requirements. Don’t forget, this is course four out of 14 of the Business Analyzes Certification program. Thank you for watching and see you on the next course.