The purpose of requirements traceability is to establish a method to validate acceptance of the implementation in each phase of development. Three types of project outcomes can be the subject of requirements traceability: more requirements, testing, and design.

Traceability from requirements to test plans is the most common type because it is essential for successful project implementation. The ability to track relationships between requirements helps validate the integrity and completeness of the whole scope, establish backward compatibility, and improve the system's quality.

However, the link between requirements and technical design requires a different approach because it introduces many-to-many relationships between two large sets of data. This article describes a methodology for implementing and using this kind of traceability in a large-scale IT project.

What is B2AT?

Business to architecture traceability (B2AT) is a powerful systems engineering pattern that effectively creates and manages relationships between functional and technical aspects of systems and applications.

B2AT enables collaboration between two project communities: those focused on business (scope, functionality, testing) and those focused on technology (architecture, design, development, and operations).

This collaboration is based on the following agreements:

1. Business aspects of the project scope are accurately and clearly represented by a collection of requirements.
2. A hierarchy of systems, components, and sub-components represents technical aspects of the project scope.
3. The project goal is to change the systems and components (2) so that their functionality satisfies the requirements (1).

Such relationships can be presented in the format of a matrix:

Rows of the B2AT matrix represent both functional and non-functional requirements (capabilities) and columns represent systems and components (assets). Intersections of assets and capabilities hold one or several B2AT work items. These items are used to indicate the following:

• Dependency – this requirement is implemented (at least partially) using this component;
• Reference to design that indicates how exactly this component implements this requirement;
• Work – list of design and development activities that are required to implement this functionality;

The state of the B2AT matrix represents specific architecture and design implementing a given scope of requirements. Any changes to the scope, requirements, or architecture may require reviewing or modifying not only system design, but also the B2AT matrix. This matrix can be created at any level of detail, from enterprise architecture to a class-level OOD.

Using B2AT

B2AT can play an important role in many aspects of the project lifecycle because it enforces requirements management and helps each team focus on its specific goals.

Requirements Management

Managing requirements for a complex system requires a rigorous process and special tools. One of the aspects of this process is to keep functional requirements separate from a technical solution. That may be challenging when you need to specify technical dependencies between systems. For example, a valid requirement may state that the user can send email notifications from a web page. Someone may also add that the email server shall provide a web service interface. However, the second statement implies a technical solution and must be separated from requirements.

B2AT offers a simple way to separate these types of statements and avoid confusion. The request to add a web services interface to the email system is not a requirement but rather a B2AT work item. It links to the original functional requirement (row) and to the system component – the email server (column). Since this interface can be used by other components for sending email messages, the same work item can potentially cover other functional requirements.

By linking requirements from different functional areas or scope items, B2AT specifies technical dependencies that have to be maintained on the functional level. In the example above, every system planning to send email notifications must consider how users will manage so many auto-generated messages.

Summary: B2AT provides a structured approach and tools that help architects, developers, and business analysts develop and validate a complete set of business and system requirements.

Architecture and Design

Beyond a particular size and level of complexity, it is impossible to design a stable system without establishing traceability between system requirements and design. In other words, any architect or developer uses a traceability approach similar to B2AT, even if it needs to be documented and formalized as a process. The nature of component-based systems requires envisioning a two-dimensional matrix to validate many-to-many relationships between system components and functional requirements.

B2AT brings a structured approach to this process that includes the following steps:

• Identify the project scope by specifying major system features and capabilities. Document and review the system requirements associated with these features.
• Identify primary systems and components and document architecture decisions.
• Develop a preliminary B2AT matrix to validate that all necessary systems and components are accounted for.
• Estimate effort and revise project scope.
• Finalize design and complete B2AT by providing more detailed work items.

It's important to note that while the B2AT deliverables (work items and matrix) are significant, they cannot replace the primary design artifacts such as system architecture, context diagrams, DB models, process models and sequence diagrams, deployment architecture, etc. Instead, the B2AT serves as a crucial tool for complementing and validating the design.

Summary: The B2AT approach provides a structured framework for a process architects and developers naturally use to design large and complex information systems. Its practicality and relevance are evident in its ability to establish traceability between system requirements and design.

Effort Estimation

Each project relies on estimations for planning and budgeting purposes. There are two significant challenges in producing accurate estimates of system development efforts:

• Valid estimates can only be produced by people who are familiar with both requirements and design. However, estimation is usually required before requirements are finalized.
• Accurate estimations are based on project measurements, but every system release brings new requirements. There is no comparison base that can be used to estimate development efforts.

In the case of a component-based system, the reason for both challenges is that you cannot break development effort by functional scope – it can only be done by component. For example, no one can tell you how long it takes to add email notification capability to an order management system. Still, estimating how long it takes to add a web service interface to the existing email server is easy. You need compare apples to apples. If the record shows that developers spent 24 hours adding a new web service to a system in the last project, then they will probably spend the same amount of time doing a similar task in the next release.

B2AT can produce accurate estimations because it breaks tasks by technical components, not functionality. Each work item includes effort for the following activities: detailed component design, coding, unit testing, build, configuration, and deployment scripting. Since each work item can serve multiple functional requirements, these estimations cannot always be exclusively associated with only one scope item. Removing functionality from list of requirements not always reduce amount of work. Unless removing the requirement (row) also retires the component work (column), your estimate may stay the same.

Summary: B2AT provides a systemic approach to producing accurate estimations of development effort. It can also measure actual effort and use it in the next round of estimation.

Project Planning

There are many ways the B2AT can help create robust and accurate project plans. In an agile environment, requirements are usually finalized after development starts. In this case, it makes sense to postpone development on components that may still require changes in design. B2AT provides clear traceability from requirements to design. Project managers can plan sprints using only work items linked to the approved requirements.

The maximum result can be achieved if you combine requirements management, B2AT traceability, and project planning tools in one system that uses a shared database. In this case, you can automatically record process measurements that can be used in the next release as a basis for estimations.

Change Management

If requirements change, it is essential to identify when and why they changed. Very often, changes happen after design or even development is started. In this case, tracing and translating these changes down to design and source code is imperative.

Every developer is responsible for a set of components and has to maintain their design and source code. Without a traceability system, it is almost impossible to keep track of changes to the requirements. B2AT provides a means for such traceability.

The change management process often only tracks changes to the requirements and ignores possible adjustments to the design. Such changes can happen during development or testing phases and are usually the result of design or architecture oversight. Adjustments may also initiate some changes due to performance or security test results.

Any system design changes affecting system functionality must be traced back to requirements. Depending on the severity of the changes, updating testing scripts or even notifying customers that the system's functionality will be modified may be necessary.

Remember that even if changes to the requirements have been identified by tracing changes in the design, such changes may consequently affect other design areas. Therefore, they have to be traced back to the design. This way, B2AT helps identify dependencies between different components, and the traceability will be complete.

Summary: B2AT provides tools that facilitate the change management process, reducing risks by establishing end-to-end visibility into the project scope and design.

Testing

Since test cases are linked to business and system requirements, the test team receives all benefits related to the change management process. Whether clients or the development team has initiated changes, B2AT will help trace the changes back to the requirements and test cases.

Also, in an agile environment, testing starts before development is completed. If B2AT is used for project planning, it can also help identify functionality that is ready to be tested. As developers complete tasks and update the status of B2AT work items, it is easy to track which requirements have all work items completed and can, therefore, be tested in QA.

Summary: Traceability from requirements to the testing scripts is usually straightforward and does not require a B2AT matrix to maintain. However, B2AT can still be helpful to the testing team.

Benefits

The B2AT introduces a whole new dimension of requirements traceability and contributes to several aspects of the project life cycle: requirements management, design, estimations, planning, change management, and testing. B2AT offers several valuable benefits:

• Greater Visibility. B2AT provides end-to-end visibility into the scope, design, and dependencies for all project teams and stakeholders.
• Minimize risk. For any change in requirements, B2AT finds a list of impacted technical components. This allows assessing risks and the overall impact of a change before it's made.
• Reduce development costs. Provide accurate estimations that can be used to assess the cost of features. Help validate architecture and design to avoid costly development rework.
• Improve quality. Ensure all requirements and quality standards are met. Identify reusable components to help optimize development and maintenance.
• Increase productivity. Keep the team in sync and reduce administrative overhead. Accelerates collaboration and innovation by providing a single data story to share requirements and design information.
• Complete test coverage. Ensure all requirements are properly tested before a release.

All these benefits contribute to greater project success - on time, on budget, and within scope.

The benefits of using the B2AT method outweigh the overhead time and cost by at least 2x. This ratio is greater for large, complex projects that involve integrating several systems and coordinating multiple development teams. With a consistent process, structured templates, and the help of a modern requirements management tool, much of the process can be automated and streamlined.