IIBA ECBA – Business Analysis and Requirements Life Cycle Management

1. Section Overview

Business Analyzes and Requirements Lifecycle Management in this course we are going to begin looking at the Business Analyzes knowledge area called Requirements lifecycle Management. Requirements are the foundation of all your Business Analyzes activities. If the objective of approaching project is to deliver solutions that best meet requirements, then you’d best keep a close eye on those requirements and the designs that address them. So let’s look at what your role is 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 the Business Analyzes core Competency Model. And finally, you have 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 and Trace Requirements stakeholders and outputs before finishing with an exercise on trace requirements.

The third part of the course called Maintain and Prioritize Requirements include maintain requirements, elements and Guidelines maintain Requirements techniques and Stakeholders prioritize requirements, Inputs and elements prioritize Requirements Guidelines and techniques prioritize Requirements Stakeholders and outputs and finally, an exercise on Maintain and prioritize 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 the structure is pretty standard approve requirements, guidelines and techniques and finally, an exercise on assessing and approving requirements. That’s what this course is about. Don’t forget this is course four out of 14 of the Business Analysis Certification program.

2. Requirements Life Cycle Management

Requirements Lifecycle Management After completing this topic, you should be able to describe the requirements lifecycle the purpose of Requirements Lifecycle Management is to ensure that requirements and designs are implemented according to the business and stakeholder needs. The task in this knowledge area are prioritizing requirements, assessing changes and establishing consensus among stakeholders, tracking changes to requirements and designs, and ensuring that the proper alignment of business stakeholder and solution requirement is guaranteed.

Requirements Lifecycle Management impacts and is impacted by activities in solution evaluation. Business Planning and Monitoring utilizes lifecycle management tasks such as how requirements will be prioritized traced and changes managed. The Requirements Analysis and Design Definition knowledge area ensures that requirements and design relationships are traced to each other and to the solution. Strategy Analyzes uses prioritized requirements and designs to assess risk to the value of the solution and to ensure that the value of the solution is brought to the stakeholders. Requirements Lifecycle Management Overview lifecycle Management defines task for prioritizing requirements, assessing changes and establishing consensus and tracking changes to the requirements and designs.

It also ensures proper alignment of business stakeholder and the solution context within Knowledge Area model. The figure one through one of the guide shows strategy analysis, requirements analysis and design definition, but also solution evaluation has three processes in a cyclic diagram that has links going back and between each process elicitation and Collaboration, Business Analyzes, Planning and Monitoring, and Requirements lifecycle Management make up a second process outside of the first cyclic process.

There is a link going backwards and forwards between Elicitation and Collaboration and Business Analyzes planning and monitoring. You will see this in a figure and there is a link going backwards and forwards between Business analysis, planning and Monitoring and Requirements lifecycle Management Elicitation and Collaboration is connected to the link between Solution evaluation and Strategy Analyzes. Business analyzes. Planning and monitoring is connected to the link between strategy analyzes and requirements. Analyzes and design. Definition Requirements Lifecycle Management is connected to the link between Requirements analysis and Design definition and Solution evaluation. A Requirement lifecycle isn’t really cyclical like some other life cycles.

It’s more like linear, like a project lifecycle is. It begins with a representation of a business need as a requirement in the form of a business case or other initiating document. It continues through the development of a solution through a project or initiative and ends when a solution and the requirements that represented are retired. Requirements are maintained throughout the solutions life Cycle as long as the business need remains, the life cycle begins with a need. A potential requirement for example a grocery store chain needs to reduce cost. The objective is to reduce staff by 10%. This can be achieved by installing surf checkout stations. The potential requirement is assessed to ensure that it meets the goals and objectives.

Possibly through a business case, a decision is made either to go forward. This requires approvals and consensus and if that’s obtained, the requirement in this example of the business case which will be managed updated when changes to the existing solutions are needed and when the solution is retired. The requirements will also be retired according to the guide the Body of Knowledge and I quote within the requirements management Lifecycle Knowledge Area the concept of a lifecycle is separate from a methodology or process used to govern business.

Analyzes work requirements lifecycle a flow chart, as you will see illustrates the requirements lifecycle starting with business need or requirement then development of solution and finally solution and requirements retired the lifecycle as a process. The figure 501 of the guide is a flow chart that illustrates the lifecycle process starting with potential requirement which leads to the assessed process which continues to where the bring forward decision has to be made.

If the decision is no, then control goes back to potential requirement if the decision is yes, this leads to the approval consensus decision process. If the decision here is no, control returns to potential requirement if the decision is yes, this will lead to the managed processes which involves the steps trace, maintain and prioritize.

3. Requirements Management and the BACCM (TM)

Requirements management and the Business analyzes core concept model. After completing this topic, you should be able to recognize how Business Analyzes core concepts are applied while managing requirements. Requirements lifecycle management ensures that the requirements are traced back to the business need. The requirements are prioritized and maintained to ensure the need is met. The current state is assessed to determine if there are any gaps in the case of the grocery store, the one that I just gave in the previous lesson.

The existing processes and information technology, including the current manned checkout stations, are analyzed to determine if the current capabilities will support the desired state. Any requirements coming out of this activity will be managed to ensure that they continue to meet the business goals and objectives. The task in the requirements lifecycle management determine how changes to requirements and designs are evaluated during an initiative to ensure that they meet the stakeholder needs.

The task trace requirements in requirements lifecycle management ensure a requirements trace back to the business need and forward to the solution. For example, a request to add an online purchasing application would be assessed to determine if it aligns to the need to reduce staff and forward to the solution to determine if there are any impacts. The Needs The six properties of requirement lifecycle management are needs, changes, solution, context, value and stakeholders. Each of the properties is connected to the other five. Requirements must be identified needs and must be traced prioritized and maintained.

Changes Stakeholders may want changes to requirements and designs and to evaluate any proposed changes. Solutions solutions through the line with requirements and should trace requirements and designs. When maintaining requirements, the context is analyzed to support tracing and prioritization requirements. The context for the grocery store may include a review of attitudes of customers related to store serve. If the attitude is positive towards the change, then their needs are likely to be a high priority. Requirements are maintained as long as the business has the need. This means that the requirements provide value.

This can be extended to other initiatives through requirements reviews. Circumstances change as the stakeholder needs the business analyst communicates with stakeholders to ensure that they have an understanding of how the solution meets their needs. Once the stakeholders agree that the solution provides value, the requirements can be approved. Context Requirements management activities must fit with context and analyze context to ensure that they do. Value requirements may be used for other initiatives. Maintain them to extend their value. Stakeholders stakeholders may change their mind. Work closely with them to maintain understanding, agreement and approval.

4. Requirements Life Cycle Management Input/Output Diagram

Requirements and Traceability after completing this topic, you should be able to describe the concept of traceability. A trace requirement aligns to the business need. This manages solution scope. For example, the need for an easytouse interface interface will trace back to ensure it meets the business need. In the case of the grocery store chain, the one we used before, the need for customers to serve themselves means an interface that supports them through the process with little human intervention.

Trace requirements also align to the solution by tracing forward to project artifacts such as test cases and requirements are traced to each other to ensure consistency and manage any changes. For example, the need to include discount coupons would also trace to the payment functions. Traceability facilitates impact analyzes. For example, a request is made to add corporate purchasing card that awards points. The business analyst will review the impact of requirement to see if any changes are needed to those requirements.

When adding the new functionality, this shows inconsistencies and gaps in requirements. Defining Traceability there are three sets of requirements. The first Requirements box connects to the process backward Traceability and the second requirements box connects to the process forward Traceability. The purpose of Traceability the purpose of Traceability is to facilitate impact Analyzes and show inconsistencies and gaps in requirements. Traceability also indicates which requirements have been satisfied which assist the project manager to determine which tasks are completed. Traceability also supports requirements allocation and release planning.

While the requirement has been satisfied, it can be allocated to a solution component designs are also traced. They are traced in the same fashion as requirements. A process model is a design and so processes have to be traced. The new self service process model would be traced back to the functional requirement to ensure that they support the process. Business requirements are traced back to the need. The subsequent stakeholder requirements are traced back to the business requirements and forward to the solution requirements.

Solution requirements are then traced back to the stakeholder requirements and forward to system design, software code and test case. The purpose of Traceability other purposes of traceability are that it indicates which requirements have been satisfied and supports requirements allocation and release planning. Examples of Traceability process traceability components are value chain, business process, sub, process activity and task. The components are all connected with two sided arrows.

You will see this in an image. The software requirements traceability components are business Needs, Business Requirements, Stakeholder Requirements and Solution Requirements all connected with two sided arrows. Solution Requirements is made up of three processes design, code and test.

5. Exercise – Understanding Requirements Management

Trace requirements, inputs and Elements after completing this topic, you should be able to recognize issues around tracing requirements that a business analyst must consider. The purpose of traceability is to ensure the alignment of requirements and designs at different levels and ensure changes to one level are reflected properly on the related requirements and that a solution is conforming to the requirements. In order to do this, the inputs are the requirements and the designs, and the task is to use various tools and techniques to trace the requirements both forward and within the requirement structure.

The output is traced requirements and trace designs, which will be continually managed throughout the initiative. Requirements and designs are the input to the trace requirements. Task requirements are traced to the business goals or objectives, the needs of the business and stakeholders, the solution requirements themselves, and the components of the solution transition requirements are also traced. These include data conversion and training. The business rules need to be traced to the appropriate requirements, and requirements will be traced to other work products such as solution designs.

Trace Requirements the task trace requirements has the inputs, requirements and designs, and the outputs are traced. Requirements and Trace Designs input requirements and designs requirements are traces to goals or objectives, business or stakeholder requirements, solution requirements or components transition requirements, business rules and other work products. Designs are traced to other requirements to ensure there is alignment and that the design accurately reflects the requirement itself. Requirements design are also traced to solution component designs.

Solution components designs are typically at a lower level of obstruction than the requirements design, so they should align and other war product designs such as process maps. The business analyst must consider the value expected from each link in traceability when tracing requirements and the nature and use of the relationship between those requirements.

An ease of use requirement will trace to the user interface designs to ensure that the customer experience is the same or better than when interacting with the checkout clock requirements. Relationships that are considered by the business analyst include derive relationships, which are between two requirements when one is derived from another requirement. This is used to link requirements at different levels of obstruction. Obstruction refers to the level of detail from conceptual, which is the business need, to the logical level, which is the requirements and designs and the physical level, the solution itself.

A business requirement to include discount coupons will trace to the stakeholder requirement, which is deduct the amount of the coupon from the cost of groceries at a physical level. The resulting programming artifact would also include a formula to calculate the amount of the coupon from the total grocery bill. Input Requirements and Designs designs are traced to other requirements, solution components and other war products. Level of Formality The business analyst must consider the value expected from each link when tracing requirements and the nature and use of relationships created. A high level of formality plus a high number of requirement leads to a high effort to trace requirements. Relationships that Impact Traceability the relationship types are derived, depends, satisfy and validate. A depends requirement includes necessity if a related requirement is implemented and it is dependent on another, where one requirement must have the functionality of the other to work.

Also, the level of effort needed to implement is considered if one requirement is easier to implement if another is implemented. For example, the inventory system already exists. The integration between the new system would be easier than creating an entirely new inventory system. This relates to forward traceability where a functional requirement is needed in a solution component and when a requirement is traced to a test case, it is referred to as a validate relationship.

The business analyzes approach details methods that will be used to manage traceability there are various ways to manage traceability. Those include manual tools such as traceability metrics in a spreadsheet or electronic and automated tools which include the use of requirements management application which will automate traceability or a repository. Repository is used to store and manage business analyzed information tools used to trace requirements. The tools used to trace requirements deal with business analyzed approach details, methods, manual versus electronic and automated tools, and traceability through the use of a requirements management application or repository.