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

6. Requirements and Traceability

Trace Requirements guidelines and Techniques After completing this topic, you should be able to recognize the guidelines and techniques used during the Trace Requirements task. Domain knowledge is the knowledge and expertise needed by the business analyst to support Traceability. In the example of the grocery store chain, the business analyst will need to be familiar with retail processes and reporting. Requirements of management, legal and regulatory information are regulations and rules that must be followed, especially if the organization is heavily regulated. Information Management the approach includes decisions regarding the Traceability approach, which is determined in the Business analyzes plan. There are many tools to support requirements management. IBM Rational Doors captures, traces, analyzes, and manages changes to requirements.

HP Quality Center captures, edits and cracks requirements and enables testing early in the life cycle to improve quality. Those test cases will align directly to the requirements. Blueprint provides a centralized repository and reporting and analytics. It enables the reuse of requirements and role based collaboration among the stakeholders and implementation team. Guidelines and Tools The guidelines and tools include domain knowledge, knowledge and expertise needed to support traceability legal and regulatory information, regulations and rules that must be followed, and information management approach decisions regarding the Traceability approach.

Examples of Requirements management Tools examples of Requirements management Tools let me remind you are the IB Operational Doors, which captures, traces, analyzes and manages changes to information the HP Quality Center, which captures, edits and tracks requirements and enables testing earlier in the life cycle to improve quality. Blueprint, which provides a centralized repository, reporting and analytics, and enables the reuse of requirements and role based collaboration and the Test Truck, which enables stakeholder collaboration, requirements capture and requirements traceability.

The test truck enables stakeholders to collaborate. It also enables requirements capture and requirements traceability even if there are changes. These techniques are used when tracing requirements. Business Rules Analyzes aligns business rules to requirements. One business rule may inform two or more requirements. For example, the business rule to apply a charge for plastic grocery bags will impact the user interface and the calculations of the grocery bill. A high level future state process is traced to business goals and feature sets.

As the initiative progresses, the obstructed functions are traced to the process, activity and task levels as well as to requirements. To ensure requirements are within scope, tracing the requirements to a scope model is helpful. Techniques techniques that can be used are Business Rules Analyzes, process modeling and scope modeling supply consumer scope models show how information is shared within a system. Data flow diagrams are especially useful when tracing data needs.

For example, a data flow diagram illustrates how data flows through a system and which entity provides or consumes the data. Functional decomposition is used to break down features for or high level function into lower level requirement requirements. The business needs trace business requirements which break down. For example, the feature feature traces to facilitate the process of checking out groceries without the need of staff intervention the business requirement is to enable a consumer to find the price for the item the solution requirement will include search functionality so that the customer chooses the correct price. Functional Decomposition a flow chart illustrates how data flows through a system with business need at the top. You can imagine this business needs are broken down into several business requirements each business requirement is broken down into several stakeholder requirements. Each stakeholder requirement is broken down into several solution requirements this is Functional Decomposition.

7. Trace Requirements – Inputs and Elements

Trace requirements. Stakeholders and Outputs After completing this topic, you should be able to recognize the role of stakeholders with respect. Tracing Requirements and Designs There are many stakeholders involved in tracing requirements. The sponsor will approve the trace requirements, requirements, and the relationship. The domain subject matter expert makes suggestions on how requirements are traced to a solution component or allocated to a phase or release. Operational Support stakeholders provide information assisting them to trace an issue to a root cause. The traceability matrix is particularly helpful for the project manager. He or she will use these documents to manage project change and scope and to determine when implementation work has been completed. A tester will trace requirements to test cases and identify any gaps in test coverage.

The implementation subject matter expert uses traceability documents during the implementation of a solution and may update the traceability metrics. These subject matter experts use the documentation to trace components to the business needs and identify dependent requirements. Operational Stakeholders There are several operational stakeholders who each have a different function. The sponsor approves relationships. The domain subject matter expert makes recommendations. The operational support uses documents for help desk support. The project manager uses documents for project change and management.

The tester may trace requirements for test plans. Other Stakeholders the implementation subject matter expert uses traceability document during implementation of a solution, the customer may be consulted about traceability relationships. The end user may require specific relationships between requirements. The supplier is affected by implementation requirements. The customer may be consulted about traceability relationships to ensure that their needs are being met. The end user may need specific trace requirements and will identify those requirements that are dependent and those requirements that satisfy a solution component.

The supplier has a lot of input into traceability and will provide information about which requirements are affected by the solution. The outputs of this task are the trace requirements and trace designs, which have clearly defined relationships with other requirements. Solution components which, according to the guide and I quote, are support of a solution that can be people, infrastructure, hardware, software, equipment, facilities, and process assets. Getting back to our example of the grocery chain, the need to pay for groceries with cash will be traced to the payment components of the solution, such as the ability to accept legal tender notes and coins. Traced Requirements and Designs the outputs have clearly defined relationships with other requirements, solution components, releases basis, and iterations. You.

8. Trace Requirements – Guidelines and Techniques

Exercise trace requirements. After completing this topic, you should be able to recognize what’s involved in developing Requirements traceability documentation. Therefore, in this exercise, you will demonstrate your understanding of what involved in developing Requirements Traceability documentation. The concept of traceability is used as part of the Requirements lifecycle management process. Why should business analysts familiar with the concept of traceability? Here we have the options. It is performed instead of due diligence as part of the Risk Analyzes component of project management. It helps to predict a project’s outcome in terms of return on investment. It helps to reveal where there are gaps in requirements.

And finally, it separates the Requirements Lifecycle Management knowledge area from all other business analysis methodologies or processes. Here you have the answer. Remember, stop for a minute, try to find your own answers and then compare. And here you have the options. Option One this option is incorrect. Traceability is not a substitute for due diligence. It is used to trace solution requirements back to Stakeholder Requirements and forward to the solution. Option Two this option is incorrect. Traceability isn’t used to predict future outcomes. It is used to trace requirements back to stakeholder needs and forward to the solution.

Option Three this is the correct option. Traceability facilitates impact Analyzes. As a business analyst, you can review the impact of requirements to see if changes need to be made to requirements when adding new functionality and inconsistencies and gaps will be revealed. Option Four this option is incorrect. Although Traceability is used within the Requirements Lifecycle Management Knowledge area, it doesn’t separate requirements management from other methodologies. What are the two dimensions of Traceability? Here we have the options. The capacity to provide the information that’s used to trace an issue back to its root cause, the ability to trace forward and backward through multiple versions of a single requirement, the ability to trace requirements backward but never forward in anticipation of a solution. And finally, the ability to trace how a requirement relates to other requirements. And here you have the answer. Option One this option is incorrect. The subject matter expert provides this information which is used during Traceability. Option Two this option is correct. A requirement should be traced forward and backward through multiple versions. Option Three this option is incorrect. Requirement has traceability if it can be traced forward to project artifacts such as test cases as well as backward. Option Four this option is correct.

Requirements are traced to each other to ensure consistency and to help manage changes. What are the inputs to the Trace Requirements task? Here have the options. Trace requirements, requirements, designs and trace designs. And here you have the answer. Option One this option is incorrect. The inputs of the Trace Requirements task are Requirements and designs. Trace Requirements are an output of the task. Option Two this option is correct. Requirements are one of the inputs of the Trace Requirements task. These inputs are traced to various elements such as Goals or objectives, businesses or stakeholders, businesses or stakeholder requirements, and also business rules. Option Three this option is correct. Designs are one of the inputs of the Trace Requirements Task.

These inputs are traced to various elements, including other requirements, solution components, or other work products. Option Four this option is incorrect. The inputs of the Trace Requirements Task are requirements and designs. Trace designs are an output of the task. There are various factors around tracing requirements that a business analyst must consider. What should you consider when performing the Trace Requirements task? Here you have the options whether the level of formality provides adequate value, whether the repository that you are using is traceable, the amount of effort involved in the trace, the nature and relationship of requirements, and which requirements management tools fit your needs. And here you have the answer. Option One this option is correct. Solution component designs are typically has a lower level of abstraction than requirements designs, so you need to consider the value expected from each link when tracing requirements. Option two. This is incorrect. A repository is used to store and manage business analyzes information.

Although some tools do use an automated process that relies on a repository, this is not a consideration. Option Three this option is incorrect. The level of effort needed to implement a requirement is considered, not the amount of effort involved in the trace. Option Four this option is correct. You need to consider the nature and use of the relationship between the requirements that you are tracing to ensure appropriateness. Option Five and the last One this option is correct. You need to consider which tools you are going to use to manage traceability. For example, whether to use manual tools or electronic and automated tools. There are various ways to manage traceability. Which techniques can be used when performing the Trace Requirements task? Here you have the options. SWOT analysis, traceability metrics scope modeling and business rules analyzes.

And here we have the answer. Option One this option is incorrect. A SWOT analyzes is used to assess strengths, weaknesses, opportunities and threats. It’s not used during the Trace Requirements task. Option Two this option is incorrect. The traceability metrics is something a project manager would use to manage project change in scope and to determine when implementation work has been completed. Option Three this option is correct. The scope modeling technique can be used to ensure the requirements are within scope by tracing the requirements to a scope model. Scope models show how information is shared within a system. Option Four and the last one this option is correct. The Business Rules Analyze techniques can be used to align business rules to requirements. One business rule may align to two or more requirements.

Each of the stakeholders involved in the Trace Requirements Task will use the relevant traceability documentation for a different purpose. Match stakeholders with how they use traceability documentation. Here we have the options sponsor, supplier domain, subject matter expert, and operational support Stakeholder. And here we have the targets. Approves the trace requirements and the relationship provides information and identifies requirements that may have an impact suggests how requirements are allocated or traced to a solution component provides information that used to trace an issue to a root cause.

And here you have the answer the sponsor will approve the relationship between requirements in the Trace Requirements Task. The supplier has a lot of input into traceability and will provide information about which requirements he or she may be affected by and how the domain subject matter expert makes suggestions on how requirements are traced to a solution component or allocated to a phase or release. And finally, the Operational Support Stakeholder provides information that is of assistance when tracing an issue to its root cause. You.

9. Trace Requirements – Stakeholders and Outputs

Maintain requirements elements and Guidelines After completing this topic, you should be able to recognize guidelines for maintaining requirements. The purpose of the task Maintain Requirements is to ensure the accuracy and relevance of requirements over time where you have have an ongoing need. This begins with an initiative and continuous. Once the solution is implemented, inputs include the requirements and designs. The task is to maintain those requirements over time. The business analyst may use a tool to do this or an Excel spreadsheet.

The outputs are maintained. Requirements and maintain Designs maintain requirements are stored for reuse or if an approved requirements was approved but not implemented, may be resurrected and implemented at a later date. Like maintained requirements, designs can be used for future initiatives and may help to define current state for those future initiatives. Proper requirements maintenance includes clearly naming and defining the requirements, which will enable easy access for those who need them. A SharePoint site with checkin and checkout capabilities ensures some management of the requirements being reused. Requirements management tools are particularly useful in this area. Update relationships of any new or modify requirements which enables traceability maintain requirements. The maintained requirements task has the inputs, requirements, and designs.

The outputs are maintained. Requirements and maintain designs. Maintain requirements proper requirements maintenance include clearly named and defined requirements, easy accessibility, updated relationships and good traceability. The requirements management taxonomy needs to be considered. A taxonomy is a dynamic list of words and phrases that are used to describe the content and includes a name group of similar words, relationships, attributes and entities which are nouns that are easily identified in the content. There are many requirements management tools in the marketplace. These tools will trace requirements and when changes are made, the traceability is maintained as well. These tools ensure requirements are traced to other project artifacts like designs and test cases. Requirements attributes are documented during requirements activity and include source, priority and complexity. This may change even though the requirement itself stays the same.

For example, during a project, a requirements priority may change because its value can be realized later. The source of requirement could include a process owner, a domain subject matter expert, implementation subject matter expert as well. Priority is maintained throughout the project as they do change as other requirements are introduced. Maintain attributes. Attributes are collected during elicitation. Examples of maintain attributes are requirement, source, priority and complexity. Complexity refers to how difficult it is to implement the requirement. For example, there may be multiple data integration points needed to implement a management dashboard. Requirements that will be reused reflect the current state and are considered for continued use. They should be clearly named and defined and made easy to retrieve.

Reusability depends on the level of abstraction. For example, business requirements may be reused by the same department or other departments but have limited reference to a specific solution. These requirements tend to lend themselves to their use. Lower level requirements are allocated to specific solution components and therefore are less likely to be reused. Requirements must be validated against the current state before being reused. Information management approach from the Business Analyzes plan is the only guideline for the maintain requirements task. It describes how information should be used and stored. It includes access rights and the location of the information.

It defines how the business analyzes information is used. It also defines the reuse of requirements, which could include information such as contractual and regulatory requirements, business rules and process documents. Reusing requirements requirements must be clearly named and defined and easily retrievable. Reusability depends on the level of abstraction and requirements must be validated against current state before being reused. Information Management Approach it describes how information should be stored, accessed and used. And it defines five the reuse of requirements.

10. Exercise – Trace Requirements

Maintain requirements. Techniques and Stakeholders After completing this topic, you should be able to recognize how techniques are used to maintain requirements. The following techniques are used when identifying requirements for use functional decomposition illustrates the business need and how it breaks down into business requirements, stakeholder Requirements and Functional Requirements. This illustration is ideal when looking for requirements for reuse. As mentioned earlier, the higher the level of abstraction, the better the requirement is for reuse.

Process models help to identify operational areas that may be candidates for requirements reuse. For example, a domain that is subject to constant regulatory changes is a perfect candidate for requirements reuse. Use cases and scenarios are excellent document candidates for reuse by other departments. Use cases for product sales may be reused by a service sales department. Like use cases, use stories can be used by other departments with the same types of personas identifying requirements for reuse. The techniques are functional decomposition, process modeling, use case scenarios, and user stories.

The following technique facilitates reuse business Rule Analyzes Business rules are perfect candidates for reuse. A business rule is atomic, and one business rule could constrain more than one processor system. Payment terms are an example of a business rule that can be used in contracts, invoices and for specific products. Data flow diagrams illustrate information flow that may be similar in multiple departments. The data flow of product and service sales will contain much the same information for orders and invoicing. Data models can be used to identify structures across the enterprise.

Customer and order data provide common descriptions and structures. Document Analyzes uses information management plans from other initiatives to provide insight into those requirements that are available for reuse.

The business analyst will determine which use cases address the domain subject matter experts need facilitate reuse. The techniques to facilitate reuse are business rule analyzes, data flow diagram, data modeling and document analysis. A sample data flow diagram covers a basic order process. The customer places an order, the order is received and an invoice is generated and sent to collect payment and subsequently the customer from receive order. The orders move to ship books, the warehouse fills the order and the order is shipped and received by the customer.

This may be an example. Subject Matter Experts The domain subject matter experts ensure that needs are accurately reflected. Implementation subject matter expert. Perform regression test and impact analyzes. The subject matter expert reviews the use case goal and the user post to functionality to ensure that they accurately reflect his or her need. The subject matter expert would also validate any business rules and data needs necessary to complete his or her daily task.

An implementation subject matter expert, such as a quality assurance of software developer, will use existing requirements to update test cases and to conduct regression testing. Operational Support uses existing models like process models to confirm the current state reviewing the inputs, activities and outputs. They will identify gaps to ensure that the future state aligns to their needs. The regulator ensures the reuse requirements meet regulatory standards. The tester will use functional decomposition to create the right level of test cases. He or she will also utilize user stories, scenarios and used cases to create test plans and cases. Other Stakeholders the operational support uses process models to confirm current status. The regulator ensures compliance standards are met, and the tester uses functionally composition to create test plans and test cases.