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

11. Maintain Requirements – Elements and Guidelines

Prioritized requirements, inputs and Elements after completing this topic, you should be able to recognize issues around the prioritization of requirements. The purpose of the Prioritized Requirements task is to run requirements based on their relative importance to stakeholders. This is an ongoing process that addresses which requirements should be implemented before and after. The requirements are also prioritized based on the sequence of implementation and ensures that those requirements that are dependent on one another have the same priority. Designs include diagrams and prototypes that illustrate business needs which are also prioritized.

The inputs are the requirements and designs that have been analyzed and created by the Business Analyst. The task is to work with stakeholders using various tools and techniques to prioritize the requirements. The outputs are both requirements that are prioritized and designed that are prioritized a benefit alliance to a business goal or objective which could include functionality and quality. Each stakeholder will perceive benefits based on their perspective and the context in which the requirement is conceived. What if the requirement is not implemented? Will there be a penalty based on lost functionality or not meeting regulatory standards? Penalties identified will trump any stakeholders request for a higher priority. Prioritized requirements over the inputs to the Prioritized requirements task are requirements and designs.

The task outputs are prioritized requirements and prioritized designs. Basis for Prioritization The basis for prioritization depends on various prioritization factors including benefit, penalty, cost, risk stability, time sensitivity, regulatory compliance and dependencies. Cost is used with other considerations to determine priority. Internal resources and vendor costs are reviewed by the Business analyst. He or she may use cost benefit analysis to inform stakeholders during the requirements prioritization process. Risk analysis identifies which requirements need a higher priority based on the potential issues. If the requirement is not met, the feasibility of a requirement is also assessed.

Proofs of concept can be used to establish if the requirement is feasible. Implementation subject matter experts are a key resource when assessing the feasibility. The Business analyst will determine if the requirements analyze. These activities have been carried out to a sufficient level to be prioritized. This is referred to as requirements Stability. These requirements tend to have a lower priority, giving the Business analyst time to fully describe the requirement, avoiding rework or waste this effort due to changes. Some requirements need to be implemented to meet market needs or to address competitive threats.

Requirements addressing compliance will have a due date that must be communicated to the implementation team through the prioritization effort. As mentioned earlier, external regulatory compliance and internal policies are always reviewed to ensure the requirements are prioritized accordingly. When one requirement cannot be addressed without another, this is referred to as dependency. The traceability matrix is a great tool which provides the needed information about these types of requirements to be able to prioritize them. Most stakeholders consider their requirements necessary and therefore should have a high priority.

The Business analyst focuses the stakeholder on the value that the requirement brings and when the value must be realized. Trade offs are facilitated by the business analysts using decision analysis, mediation, risk and financial analyzes to remove the emotion from the prioritization process. This addresses any conflict by identifying the value using evidence based decision analysis. Challenge of Prioritization different stakeholders may value different things, and necessary trade offs may be challenging to accept.

Stakeholders influence prioritization based on their position in the organization. However, it is incumbent on the business analyst to work with these stakeholders to understand the needs based on regulatory and implementation considerations. The prioritization approach outlined in the business analysis plan addresses requirements that may appear to conflict. This is where tradeoffs are negotiated with stakeholder’s priorities changes as the initiative moves ahead as other requirements are added, prompting the business analyst to review already prioritized requirements.

Requirements are prioritized at a high level as the requirements are further defined, prioritization may need to be revisited. Prioritization criteria evolves as requirements move closer to being realized. As a solution, the implementation team may implement low priority requirements because of the ease of implementation. Higher priority requirements may be delayed due to business or technical restraints or dependencies.

12. Maintain Requirements – Techniques and Stakeholders

Prioritize requirements. Guidelines and Techniques After completing this topic, you should be able to recognize tools and techniques used when prioritizing requirements. There are many guidelines and tools to be used when prioritizing requirements. Business constraints include regulations, obligations and policies. Requirements that meet regulatory constraints will likely be assigned a high priority to meet the timeline of the regulation and avoid the risk of penalties. The change strategy will outline the cost timelines and the value that needs to be realized by the requirements.

The business analyst needs to have domain knowledge and expertise to effectively prioritize requirements. The Governance approach will provide information for prioritizing requirements. The approach for prioritizing requirements may be based on ranking or time boxing and based on the allocation of time and money. The requirements architecture describes the relationships with other requirements and work products. One requirement may be dependent on another requirement. A perfect example is the function to log into a system. This requires a password. The requirement to change a password is dependent on an existing password being present. The Requirement Management repository stores the information with regard to requirements prioritization and the attributes related to those requirements, and the solution scope provides the boundaries around which possible solutions could be realized. There are therefore several guidelines, and each contains different information that it used to support prioritization. Business constraints contain regulations, obligations and policies. The change strategy contains cost timelines and value realization. Domain Knowledge contains knowledge and expertise. Governance approach covers the approach for prioritizing requirements.

Requirements architecture deals with relationships with other requirements and work products. The Requirements Management repository contains requirements prioritization attributes. The final tool is Solution scope and covers boundaries around possible solutions. The following are some techniques for prioritizing requirements financial analysis, decision analysis and risk analysis. Risk analyzes examines the impact if a requirement is realized because of the priorities, it may be determined that there is a high likelihood that there will be a negative impact. If a requirement is not implemented within a desired time frame because of a regulation, then that requirement is assigned a high priority. There are various group techniques that can be used, including interviews and workshops. A business analyst could conduct a workshop with a group of varied stakeholders to determine the value of a particular requirement and assign a priority level.

The business analyst could use decision analyzes to determine if the value of the requirement is sufficient to warrant a high priority. Voting based on criteria and the weighted decision metrics is helpful. When prioritizing Requirements there are various tools to manage requirements. Prioritization backlog management is used in adaptive approaches. Item tracking is used to record any stakeholder concerns regarding the prioritization. Document reviews include business cases. A business case can provide information about the cost benefit of one feature over another. Techniques for prioritizing Requirements There are several techniques for prioritizing requirements across four categories analyzes, group techniques, tools and document reviews. Analyze techniques include financial analysis, decision analysis, and risk analysis and management group techniques are interviews and workshops tools are backlog management prioritization item tracking and estimation document reviews cover business cases.

13. Prioritise Requirements – Inputs and Elements

Prioritize requirements. Stakeholders and Outputs After completing this topic, you should be able to recognize the role of stakeholders with respect to prioritizing requirements and designs. The implementation subject matter expert provides input on technical dependencies. For example, this subject matter expert may point out that the solution must use the same operating system as the existing manned checkout stations. He or she may change prioritization based on those technical constraints. The project manager uses prioritization as input for the project plan, assigning resources and delivery dates for higher priority requirements. The sponsor will validate the prioritized requirements to ensure that the business goals and objectives are met. In this competitive business environment, the customer value must be delivered.

The customer can make the difference between an organization and its competitor. Customer value can be realized by the business analyst through his or her understanding of the customer needs. He or she may even meet with the customer to get input into the prioritization process. The end user is probably the most impacted stakeholder next to the customer. He or she provides insight into which requirements deliver the most value for them in their day to day operations. Operational Stakeholders The operational stakeholders are the implementation subject matter expert who provides input on technical dependencies and may change prioritization based on technical constraints, the project manager who uses prioritization as input for project plans, and the sponsor who validates prioritized requirements.

Other Stakeholders The other stakeholders are the customer who verifies prioritized requirements, the end user who validates prioritized requirements, and the regulator who ensures legal and regulatory adherence. Regulators ensure that the requirements not only meet compliance, but advise us on which requirements must be implemented to remove the risk of penalties for not meeting regulation. Requirements addressing customer needs are likely to be implemented first. For example, an easytouse customer tax form will be implemented before internal management results are reported. Prioritization may be dependent on a marketing initiative where advertising has been scheduled just in time for the tax season.

Prioritized requirements and designs aligned and are available for implementation. This focuses the business analyzes’efforts to ensure that these requirements are communicated at the right level of abstraction and valid validated by stakeholders and verified by the implementation teams. Outputs the outputs are prioritized requirements and designs ready for additional work. The highest valued requirements and designs are available to be addressed first.

14. Prioritise Requirements – Guidelines and Techniques

Exercise maintain and Prioritize Requirements after completing this topic, you should be able to recognize what’s involved in maintaining and prioritizing requirements and designs. Therefore, in this exercise, you are required to recognize what’s involved in maintaining and prioritizing requirements and designs. You need to be familiar with the considerations, elements and guidelines that are part of the Maintain Requirements task. Which characteristics should requirements have in order to be reusable? Here we have the options clearly named or defined and easily retrievable collected during the elicitation phase defined thus lower level requirements to be more suitable for use and finally validated against the current state before being reused.

And here we have the answer. Option One this option is correct. Business analysts can maximize on reusability by ensuring the requirements are clearly named and defined in order to be easily retrievable. Option Two this option is incorrect. Although required attributes are collected during elicitation, this is not a characteristic of a requirement that makes it suitable for reusability. Option Three this option is incorrect. Lower level requirements are less suitable for reuse because they are allocated to very specific solution components. Option Four this option is correct. Requirements must be validated against the current state before being reused to maximize their reusability. There are several techniques business analysts can use to support the reusability of requirements match techniques to descriptions of how they are used to maintain requirements.

Here you have the options user stories, functional decomposition, process modeling, and Use cases and scenarios. And here we have the targets used by other departments with the same types of activities to facilitate change. Used to illustrate a business need and break it down into business. Stakeholder and functional requirements used to identify operational areas that may be candidates for reuse and finally, used to document requirements that may be suitable for reuse by other departments. User stories can be used by other departments with the same types of personas as the particular requirement. Functional decomposition is used to identify a business need and break it down into Business stakeholder and Functional requirements. Process modeling can help to identify operational areas that may be candidates to requirements for reuse. Use cases and scenarios are excellent ways in which to find candidates for reuse in other departments.

The purpose of the Prioritized Requirements task is to run requirements based on their relative importance to stakeholders. What do business analysts need to consider when prioritizing requirements? Here we have the options trade offs may be made if requirements conflict. Prioritization is an ongoing effort that evolves as more information becomes available. Trade offs between what is intended and what is achievable are not allowed. Stakeholders can potentially make prioritization difficult, but they need to agree on the criteria that will be used. And finally, all stakeholders are inclined to prioritize and value things the same. Here have the answer.

Option One this option is correct. The prioritization approach outlined in the Business Analysis Plan is used to address requirements that appear to be in conflict. Trade offs must then be negotiated with stakeholders. Option Two this option is correct. Priorities changes as initiatives moves ahead and as other requirements are added. As a business analyst, you need to realize that is an ongoing effort and you may need to review requirements that you had previously prioritized. Option Three this option is incorrect. Trade offs must be negotiated with stakeholders if there appears to be a conflict between two or more requirements. Option Four this option is correct. Stakeholders influence prioritization based on their position in the organization.

As a business analyst, you need to work with stakeholders to ensure that they understand the needs and criteria that will be used. Option Five this option is incorrect. Different stakeholders may value things differently. In addition, requirements are prioritized at a high level. As the requirements are further defined, prioritization may need to be revisited. When prioritizing requirements, there are several techniques and tools that business analysts can use. Match tools and techniques with descriptions of how they facilitate requirements prioritization. Here we have the options requirements architecture, business Constraint domain Knowledge Change Strategy and here we have the targets describe the relationship requirements have with each other and products. Includes regulations, obligations, and policies. Includes the expertise required to effectively prioritize requirements and finally, outlines the cost, timeline and value that need to be realized by the requirements.

And here I have the answer. The requirement architecture describes the relationships of requirements in terms of each other and other products. Business constraints include the regulations, policies and obligations for requirements. Prioritization domain knowledge is the knowledge, skills or expertise required by subject matter experts to prioritize a requirement effectively. The Change strategy provides an outline of the value that needs to be realized by the requirements as well as the timeline and cost involved in doing so. The Priority Requirements task involves several stakeholders match each stakeholder with a description of their role in requirements. Prioritization descriptions may have more than one match sponsor, end user, customer regulator, project manager, and implementation subject matter expert.

And here we have the targets validates prioritized requirements ensures legal and regulatory compliance, provides input on technical dependencies, and modifies prioritizations. Uses requirements prioritizations as input for project plan. This is the answer sponsors, end users and customers validate prioritized requirements. Regulators ensure legal and regulatory compliance during the prioritization process. The implementation subject matter expert provides input on technical dependencies and is allowed to modify prioritizations. The project manager uses prioritizations as inputs when compiling the project plan. You.

15. Prioritise Requirements – Stakeholders and Outputs

Assess requirements, changes, inputs and elements. After completing this topic, you should be able to recognize considerations a Business Analyst must make when assessing changes to requirements. The implications of changes to requirements are addressed in the Assess Requirements Changes task. As needs change, so do the requirements. The Business Analyst must ensure that requirements are approved, traced and prioritized. This includes both requirements and designs. The inputs include the proposed change, the requirements and the designs. The task itself is to assess if those requirements changes align to the business need and provide value.

The outputs is a requirements change that has been assessed by the Business Analyst and that the designs have also been assessed to ensure the change impact is appropriate. The proposed change may impact any part of business analysis or deliverables at any time. For example, a stakeholder may identify that the customer record now has to include other incentive membership numbers. For example, a department store is now recognizing an airline’s miles promotion program. The Business Analyst will analyze the request and evaluate the data model, data dictionary and prototype to ensure that the change is reflected there.

Changes Overview The task assess requirements changes, has as inputs the proposed change requirements and designs. The outputs of the task are Requirements, change assessment and designs. Change Assessment Inputs proposed change may impact any part of business analysis or deliverables at any time and includes changes to strategy, stakeholders and regulations. Requirements and designs requires understanding on how they may be impacted by the change. Impact analysis is conducted to determine which requirements and designs are affected by a requested change, no matter if the project is predictive or adaptive. The following is considered by a Business Analyst based on the nature of the change.

The Business Analyst will determine if the change will reap a benefit to the organization. Benefits may include a competitive advantage, regulatory compliance, or a positive experience for the customer. Costs associated with rework are also considered if the cost to implement the change foregoes other requirements. The Business Analyst may also consider cost associated with rework to implement the change and the cost of foregoing other requirements to accommodate the change. Regulatory security and other implications will dictate how urgent the change is.

The change request will be analyzed to determine how the change impacts the schedule and existing delivery commitments will be examined by the Business Analyst. Impact Analyzes A spider diagram with five branches illustrates the impact of change. This is a depiction of this process. The center of the diagram is Impact of Change. The five branches are benefit, cost, urgency, schedule and impact. The impact itself include what is changed or added to the requirements and designs, and they should be reviewed. The traceability matrix will help to identify if primary and dependent requirements are impacted, as well as the trace state that requirement is in.

This will help to define cost impacts based on the phase of the traceability. Predictive approaches require authorization for any changes. In some organizations, a change control committee would review and approve or review changes. Impacts and resolutions are documented and communicated to all stakeholders. The business analyst will find guidance from the information management approach and from requirements, governance, impact resolution, authorization for change may be required. Impacts and resolutions are communicated to stakeholders and guidance is found in information management approach.