I define a component as a delimitable part of a system. For example, I treat a component as a subsystem, module, or service. In software architecture, I see a component as an encapsulated set of coherent objects or classes that jointly achieve a purpose. In testing, I treat a component as a part of the system that I can test in isolation. Therefore, when I view a component in isolation, I treat it as a system by itself.
First, I work with components at different abstraction levels. For instance, I map high-level system requirements to coarse components. Then, I map detailed requirements to lower-level components or classes. In contractual projects, I use stakeholder requirements or vision documents as input. Consequently, I derive system requirements and then assign those requirements to components. In other projects, requirements and component design may co-evolve.
I maintain attributes for components and for the requirements that belong to them. For example, I record the Source, the Owner, and the Next processor for every requirement. In addition, I add technical attributes such as Interface requirement. This helps me and other roles. For instance, the architect needs a structured view to group requirements by technical criteria. Meanwhile, developers need traceability from a requirement to the component they implement. Testers need to know which requirements tests cover and which remain to be tested.
Therefore, I create traceability links between requirements and components. Specifically, I use relationship types such as is_realized_by, is_implemented_by, and is_tested_by. For example, I link a system requirement to a software component with is_realized_by when the component’s behavior leads to fulfillment of that requirement. I link a specific function, class, or method with is_implemented_by when code realizes the requirement. I link test cases with is_tested_by so I can verify requirements and measure test progress. As a result, I can trace requirements backward and forward through design, implementation, and testing.
I use views and filters to present component-related information to different stakeholders. For instance, I filter requirements by component for developers. I generate interface-centred views for architects. I create role-based views so that people see only the information they need. Moreover, I keep the attribute values well maintained. Otherwise, the views and evaluations lose value. Therefore, I choose RE tools that support the evaluations I need.
I manage how components affect testing and change control. For example, when I change a component, I update the requirements and test cases that refer to it. In addition, I evaluate which test cases I must rerun. Consequently, I can estimate the residual testing effort and reduce risks. Furthermore, I group testable requirements per component to support unit and integration testing.
Finally, I apply components as reusable building blocks. Thus, I improve modularity and clarity. However, I stay careful about over-splitting. Specifically, I avoid creating components that blur responsibility or hinder tracing. In short, I treat components as delimitable, testable, and traceable parts of a system. Because of that, I can assign requirements confidently, support architects, help developers, and enable testers to measure progress.