IIBA CBAP – Tasks of Requirements Life Cycle Management

1. Trace Requirements

Requirements. Lifecycle Management Knowledge area describes the tasks that the business owners perform in order to manage and maintain requirements and design from inception to retirement. In this session, you will learn about tasks to trace requirements. Using this task, we can analyze and make maintain the relationships between requirements, designs, solution components, etc. For impact analysis, coverage and allocation. The purpose provides a short description of the reason to perform the task and the benefits from performing the task. The purpose of trace requirements is to ensure that requirements and design are aligned to one another and to manage the effects of change. Requirements traceability identifies the lineage or roots of each requirement, which includes backward as well as forward traceability and relationship of a requirement to other requirements. Requirement traceability is used to detect any missing functionality or to identify if there is any implemented functionality that is not supported by any requirement.

Traceability supports impact analysis, discovery of inconsistencies, and gaps in requirements. Traceability has to manage scope and requirement changes and to identify requirements that are not addressed. Traceability also supports requirement allocation and release planning. There are two inputs to this task. First, input is all type of requirements and second input is design elements describe the key concepts that are needed to understand how to perform the task. Please note that all elements are not mandatory as part of performing a task and their usage might depend on the business analyst approach. To perform this task, we need to determine level of formality needed to trace requirements.

Depending on the number of requirements to trace, the effort to trace requirements grows significantly when the number of requirements or level of formality increases. So we need to identify nature and use of each traceability link and justify efforts against the benefit from identifying, documenting and maintaining that traceability. We also need to establish relationship between requirements. When a requirement is derived from another requirement, the relationship is derived relationship. When a requirement depends on another requirement, the relationship is depends relationship. We can have two further types of depend relationships when it only makes sense to implement a particular requirement.

 If a related requirement is also implemented, the relationship is a necessity. Relationship. When a requirement is easier to implement if a related requirement is also implemented, the relationship is an effort relationship. When there is a relationship between a requirement and satisfying solution component, the relationship is a satisfying relationship. When there is a relationship between a requirement and a test case, the relationship is a validate relationship. This is used to check if the solution fulfills the requirement.

We may also document and maintain requirement traceability in a repository. Traceability can be maintained using a simple text document or as a traceability metrics using a spreadsheet. Requirements management tool can be used to trace a large number of requirements that would otherwise be unmanageable with simple textual document or spreadsheet. Guidelines and tools list resources that are required to transform the input into an output. A guideline provides instructions or descriptions on why or how to undertake a task. A tool is something that is used to undertake a task. Guidelines and tools can include outputs of other tasks, domain knowledge and legal or regulatory information. Helps to identify relationship between requirements and support traceability information management approach provide guidance or directions on how to trace requirements and designs requirements management tools or repository can be used to store and manage relationship between requirements. There are two outputs from this task.

First output is Trace Requirements, which define relationship of requirement with other requirements, solution components, releases, phases, iterations, et cetera. Second output is Trace Design, which defines relationship of design with other requirements, solution components, releases, phases, iterations, et cetera. To recap requirement. Lifecycle Management Knowledge area describes the task that business owners perform in order to manage and maintain requirements and design from inception to retirement. In this session, we have learned about tasks to trace requirements. Using this task, we can analyze, analyze and maintain the relationship between requirements, design, solution components, etc. For impact analysis, coverage and allocation. In the next session, we will learn about tasks to maintain requirements.

2. Maintain Requirements

Requirement. Lifecycle Management Knowledge Area describes the tasks that the businesses perform in order to manage and maintain requirements and design from inception to retirement. In this session, you will learn about tasks to maintain requirements. Using this task, we can ensure that requirements and designs are accurate and current throughout the lifecycle and facilitated reuse where appropriate. The purpose of maintain requirement is to retain accuracy and consistency of requirements during the entire requirement life cycle that is throughout and beyond change and to support reuse of requirements in other solutions.

A requirement that represents an ongoing need must be maintained to ensure that it remains valid over a period of time. To maintain and reuse requirements, the requirement should be consistent. The requirement should be reviewed and approved for maintenance. The requirement should be verified for quality and stored with proper access right. The requirement should also be easily accessible and understandable. There are two inputs to this task. First, input is all types of requirements and second, input is designed. To perform this task, we need to maintain or regularly update requirements so that they remain relevant or applicable for the current state.

The requirements must be clearly named and defined and must be easily available to stakeholders. We need to maintain relationships among requirements to ensure the context and original intent of the requirement is preserved. We also need to maintain or regularly update requirements attributes such as requirements, source, priority and complexity as they will aid in managing each requirement throughout the lifecycle. Please note that requirement attribute may change even though requirement does not. Requirements that are generalized and are at high levels of abstraction with limited reference to specific solutions can be reused within the current or similar initiatives, within the similar departments, and throughout the entire organization.

Requirements intended for reuse should be written in a general manner without direct ties to particular tool organizational structure. As requirements are expressed in more detail, they become more tightly associated with specific solutions or solution options. Specific references to applications or departments limit the reuse of requirements and designs across an organization. Requirements that are intended for reuse should reflect the current state of the organization. It is important that stakeholders validate the maintain requirements before they can be reused. Guidelines and tools list resources that are required to transform the input into an output information management approach. Provide guidance or directions on how requirements will be managed for reuse. There are two outputs from this task.

First, output is maintained requirements, which are defined once and available for long term usage in future initiatives. Second output is maintained designs, for example, a self contained solution component that may be reusable once defined to recap requirements. Lifecycle Management Knowledge Area describes the task that the businessman has performed in order to manage and maintain requirements and design from inception to retirement. In this session, we have learnt about tasks to maintain requirements. Using this task, we can ensure that requirements and designs are accurate and current throughout the lifecycle and facilitate reuse where appropriate. In the next session, we will learn about tasks to prioritize requirements.

3. Prioritize Requirements

Requirement lifecycle management knowledge area describes the tasks that the business owners perform in order to manage and maintain requirements and designs from inception to retirement. In this session, you will learn about tasks to prioritize requirements. Using this task, we can assess the value, urgency and risk associated with particular requirements and designs to ensure that analysis and or delivery is done on the most important one. The purpose of prioritized requirements is to rank requirements in order of relative importance. Prioritization is performed by ranking requirements to determine the relative importance to stakeholders. Priority refers to the relative value of a requirement or to the sequence in which it will be implemented. Prioritization is an ongoing process. Priorities can change as the context changes.

Prioritization seeks to ensure that the maximum value is achieved. There are two inputs to this task. First, input is all type of requirements and second input is design. To perform this task, we need to first determine basis for prioritization and it should be agreed by relevant stakeholders. The requirement may be prioritized basis benefits as a result of implementing the given requirement. The benefit provided can refer to a specific functionality, desired quality or strategic goal, or business objective. The requirement may be prioritized. This is penalty. Penalty can be in form of negative consequences from not implementing a requirement such as regulatory or policy demand imposed on the organization. Penalty can also be in form of negative consequence of not implementing a requirement that improves customers’experience.

The requirements may be prioritized basis cost or the efforts and resources needed to implement given requirement. Cost is often used in conjunction with other criteria such as cost benefit analysis. The requirements may be prioritized basis risk involved in implementing a given requirement for example, risk of requirement not delivering expected value or risk of implementation difficulty or risk of stakeholders not accepting solution component or risk of technical feasibility of solution, et cetera. Requirement with highest risk is given higher priority so that we can minimize resources that are spent before learning that requirement cannot be implemented. The requirements may be prioritized basis dependencies. For example, one requirement cannot be fulfilled unless other requirement is also fulfilled. Dependencies may also be financial, resource availability, ETCA.

The requirements may be prioritized basis time sensitivity or time to market scenarios. Many times, implementing requirements after a certain date will not result in value for the business. Benefit can only be achieved if we can deliver functionality ahead of competition. Requirements may be prioritized basis stability or likelihood that requirements will change. This can be due to incomplete analysis or lack of agreement between stakeholders. The requirement which is not stable is given lower priority to minimize rework and wasted efforts. Requirements may be prioritized versus regulatory or policy compliance requirements that must be implemented in order to meet regulatory or policy demands imposed on the organization. Such requirements get higher priority over stakeholders priorities. We also need to manage challenges of prioritization. Each stakeholder may value something different resulting in conflicts among stakeholders.

Apart from this, stakeholders may find it difficult to provide lower priority to any requirement or want to keep all requirements on high priority. This may impact the ability to make necessary trade offs to implement requirements in a given cost, time and efforts. Similarly, prioritizing all requirements using a single criteria may result in conflicts and hence would be challenging. And finally, we need to continuously prioritize requirements as the context evolves and as more information becomes available, the basis for prioritization may be different at different stages. For example, initially requirements may be prioritized at high level basis benefits. However, as requirements are refined at more granular level, they may be reprioritized basis different criteria such as technical constraints and after finding cost for implementing each requirement, they can again be prioritized basis. Cost guidelines and tools list resources that are required to transform the input into an output.

Business constraints such as prevailing regulations, current contractual obligations and business policies can be used to prioritize requirements and designs. Similarly, information on costs, timelines and benefits from change strategy, domain knowledge and solution scope can be used to prioritize requirements and design requirements. Architecture provides information on relationship between requirements and hence can be used to prioritize requirements and designs related to other high priority requirements. Requirement management tools or repository can be used to maintain requirements attributes including priorities of requirements and designs. Governance Approach provides guidance all directions on approach to prioritize requirements and designs. There are two outputs from this task.

First output is prioritized requirements and second output is prioritized design. Both requirements and designs are addressed for further work. This is their priority to recap requirement. Lifecycle Management Knowledge area describes the task that a businessman has performed in order to manage and maintain requirements and designs from inception to retirement. In this session we have learnt about tasks to prioritize requirements. Using this task, we can assess the value, urgency and risk associated with particular requirements and designs to ensure that analysis and or delivery is done the most important ones. In the next session we’ll learn about tasks to assess requirements changes.

4. Assess Requirements Changes

The Requirement lifecycle Management Knowledge area describes the tasks that the business owners perform in order to manage and maintain requirements and design from inception to retirement. In this session, you will learn about tasks to assess requirements changes. Using this task, we can evaluate new and changing stakeholder requirements to determine if they are within the scope of a change or need to be acted on. The purpose of SS requirements changes is to evaluate the implication of proposed changes to requirements and designs. This task is performed as new needs, requirements or possible solutions are identified. These may or may not align with the solution scope and or change strategy. We need to assess effects of proposed changes in terms of conflicts with other requirements, increase in risk, impact on time to deliver or resources required, and effect on the solutions value.

There are three input to this task. First input is the proposed change such as changes in business strategy, stakeholder and legal or regulatory changes. Second input is requirements and third input is designed. To perform this task, we need to determine the level of assessment formality needed to assess requirement changes. This is the availability of information, the importance of the change and as per business analysis governance approach.

Please note that Business analysis governance approach is an output of business analysis, planning and monitoring knowledge area. In predictive approach, more formal assessment of proposed changes is required as the impact can be disruptive and can lead to substantial rework of completed tasks and activities. While in adaptive approach, less formal assessment of proposed changes is required as iterative and incremental techniques tend to minimize the impact of changes.

In this continuous evolution or exploratory approach to develop solution reduces the need for formal impact assessment. For each change in requirements, we need to perform impact analysis to assess or evaluate the effect of a change. Traceability is a useful tool for performing impact analysis.

In this, we review the impact of changes in one requirement to all related requirements and or solution components. Each related requirement or component may also require a change to support the new requirement. We need to analyze the impact of proposed change by considering increase in benefits by accepting the change and total cost of implementing the change which includes the cost to make the change, the cost of associated rework and the opportunity cost in terms of solution features that need to be sacrificed.

We also need to consider impact to customers or business processes, impact to schedule or delivery dates, level of urgency or importance of proposed change such as regulatory safety issues, etc. Finally, depending upon the planned governance approach, stakeholders with approval authority, including business analysts, need to resolve impact by approving, denying or deferring the proposed change. It is the responsibility of business analysts to document and communicate impacts and resolutions to all stakeholders. Guidelines and tools list resources that are required to transform the input into an output change strategy domain knowledge, legal or regulatory information and Solution Scope provides the context and helps to assess proposed changes in requirements.

Governance Approach provides guidance or directions regarding change control and decision making process and roles of stakeholders. Requirements Architecture provides information on relationship between requirements and hence can be used to identify requirements that are impacted by proposed changes in requirements. There are two output from this task. First output is requirement change assessment, and second output is design change assessment. Both outputs provide the recommendations to approve, modify or deny a proposed change to recap requirement. Lifecycle Management Knowledge Area describes the task that the business owners perform in order to manage and maintain requirements and design from inception to retirement. In this session, we have learned about tasks to assess requirements changes.

Using this task, we can evaluate new and changing stakeholder requirements to determine if they are within the scope of a change or need to be acted on. In the next session, we’ll learn about tasks to approve requirements.

5. Approve Requirements

Requirement lifecycle Management Knowledge Area describes the task that the business has performed in order to manage and maintain requirements and design from inception to retirement. In this session, you will learn about tasks to approve requirements. Using this task, we can work with stakeholders involved in the governance process to reach approval and agreement on requirements and designs. The purpose of approval requirements is to obtain agreement and approval of requirements and designs to continue business analyst work and or construction of the solution. The approval process is defined by the task plan. Business analyst, governance of business analysis, planning and monitoring knowledge area. Please note that it is the responsibility of business analysts to obtain stakeholder approvals. To get approvals, we need to ensure clear communication of requirements, designs and other information to the key stakeholders.

Approval of requirements and designs may be formal or informal. Predictive approaches typically have approvals at the end of the phase or during the change control meetings, while adaptive approaches typically approve requirements just in time before construction and implementation of a solution. There are two inputs to this task. First, input is the verified requirements that are checked to be of sufficient quality for further work. Second, input is designs that are ready to be used for further development. To perform this task, we need to understand stakeholder roles and authority levels. We need to understand who has decision making responsibility and who has authority for providing sign offs.

We also need to identify stakeholders who are not directly involved in decision making but can influence decisions. Such influential stakeholders should be consulted or informed about the requirements. We also need to manage conflicts and issues. In this, we need to maintain stakeholder support by seeking consensus on an ongoing basis before requesting final approvals. Stakeholders may have different viewpoints, priorities and interpretations of requirements and design, which can lead to conflicts. We need to resolve conflicts by facilitating communication between stakeholders so as to make them appreciate needs of the others. We also need to gain consensus by ensuring that the stakeholders with approval authority understands and accepts the requirements.

We need to facilitate approval by presenting requirements and addressing any questions or concerns. Approval is provided by stakeholders if they believe that sufficient value is there to justify investment in a solution. And finally, we need to track approval status, record approval decisions, and communicate the same to relevant stakeholders to inform them regarding which requirements and designs are currently approved and in line for implementation. In this, we can use requirement maintenance and tracking tools to record approval decisions and maintain an audit history of changes to requirements, such as what was changed, who made the change, the reason for the change, and when the change was made.

Guidelines and tools list resources that are required to transform the input into an output change. Strategy and solution scope can help to manage stakeholder consensus and to assess alignment to the business needs, governance approach and legal or regulatory information, provide guidance on the process to be followed, and identify stakeholders with authority to approve requirements. Requirement management tools or repository can be used to record requirement approvals. There are two output from this task. First, output is approved requirement and second output is approved design. Both output provides information on what is agreed by stakeholders and is ready for use in subsequent business analysis or solution development efforts to recap requirement.

Lifecycle Management Knowledge Area describes the task that business owners perform in order to manage and maintain requirements and design from inception to retirement. In this session, we have learned about tasks to approve requirements. Using this task, we can work with stakeholders involved in the governance process to reach approval and agreement on requirements and designs. In the next session, we will learn about involvement of stakeholders in performing various tasks of requirement. Lifecycle management knowledge area.

6. Involvement of stakeholders

Apart from business analysts. IIBA baba guide describes generic list of stakeholders who are likely to participate in performing various tasks or who will be affected by it. In this session, we will learn about involvement of stakeholders in performing various tasks of requirement lifecycle management knowledge area. By the end of this session, you should be able to remember involvement of stakeholders in performing various tasks of requirement lifecycle management knowledge area. This slide maps stakeholders involved in performing various tasks of requirement lifecycle management knowledge area.

Please note that all stakeholders are involved in performing all tasks of this knowledge area. Customer and end user may be involved in verifying traceability, prioritization and changes in requirements and design. Customer and end user may also be involved in performing reviews and approval of requirements. Domain, subject matter expert or domain SME may have recommendation on traceability on requirement changes and may also get involved in reviews and approval of requirements. Domain SME may also be involved in ensuring relevance of maintained requirements on a periodic basis. Implementation subject matter expert or implementation SME may provide inputs on traceability and prioritization from technical perspective and may use maintained requirements for periodic enhancements.

Operational Support may use traceability and maintain requirements for their work. Operational Support may also review requirements and changes to ensure they can support it. Project manager uses traceability, prioritization and requirement changes to manage related project activities. Project manager also manages activities pertaining to requirement approvals. Regulator may get involved to confirm compliance to standards, legal and regulatory constraints during the requirements. Lifecycle sponsor’s approval is required on traceability, prioritization and changes to requirements. Supplier is affected by how and when requirements are implemented. Tester uses traced and maintained requirements to plant testing.

Tester is also involved to review impact due to changes in requirements and in approving requirements from their quality perspective. Please pause and study the involvement of various stakeholders in performing various tasks of requirement lifecycle Management Knowledge Area to recap requirement lifecycle Management Knowledge Area describes the task that the business analysis performs in order to manage and maintain requirements and design from inception to retirement. Requirement. Lifecycle Management Knowledge area includes following business analysis tasks.

Using trace requirement tasks, we can analyze and maintain the relationship between requirements, designs, solution components, etc. For impact analysis, coverage and allocation. Using maintained requirement tasks, we can ensure that requirements and designs are accurate and current throughout the life cycle and facilitated reuse where appropriate.

Using prioritized requirement tasks, we can assess the value, urgency and risk associated with particular requirements and design to ensure that analysis and or delivery is done on the most important ones. Using SS Requirements Changes task, we can evaluate new and changing stakeholder requirements to determine if they are within the scope of the change and needs to be acted on. Using approved requirement task, we can work with stakeholders who are involved in the governance process to reach approval and agreement on requirements and designs.