Thinking about Quoins: Strategic Traceability of Architecturally Significant Requirements
Sept./Oct. 2013 (Vol. 30, No. 5) pp. 16-18
0740-7459/13/$31.00 © 2013 IEEE

Published by the IEEE Computer Society
Thinking about Quoins: Strategic Traceability of Architecturally Significant Requirements
Jane Cleland-Huang
IN MY LAST COLUMN, I talked about the notion of using architecturally savvy personas to depict quality concerns as personalized, architecturally significant user stories, and then leveraging these user stories to drive a system's initial design. 1 But as we all know, initial design is just the first step. A system is never static, and therefore its design often evolves (sometimes rather rapidly) over time. This leads to the well-known problem of architectural degradation, which occurs when the architecture gradually and persistently drifts away from the original design. Continuing in that vein, I'll talk here about using traceability 2 to help identify and monitor the critical sensitivity points of the design so that maintainers don't inadvertently degrade system qualities as they implement otherwise innocuous changes.
Before I go further, I should explain that I realize that many consider traceability to be a dirty word—I get it!—but please bear with me as I make my case for using traceability strategically to track how a system realizes and satisfies stakeholders' architecturally significant requirements over time. 3 To set the stage, let's think about the kinds of things that are useful to trace. The way medieval architects designed and built their castles illustrates this idea beautifully. Quoins were used at the corner junctions of two load-bearing walls to distribute weight and relieve pressure (see Figure 1 ). Quoins provided an architectural solution that satisfied pervasive requirements for a castle to not only endure potential erosion caused by weather conditions but also to withstand enemy attack. After all, that was the main purpose of building the castle in the first place.




Figure 1.. Quoins are clearly visible on the corner between the two load-bearing walls. They're essential to the long-term integrity of the castle's structure and provide an architectural solution that satisfies pervasive requirements.



These castles changed over time as they were expanded, modified, and reinforced. Change was slow; key architectural decisions were frequently well understood and readily visible. Original architectural decisions were considered and often carefully preserved during construction and reconstruction processes.
Where Are Our Requirements Quoins?
So why do we as requirements engineers and software architects care about quoining? The reason is simple: our software systems have their own quoin equivalencies. Unlike medieval castles, which evolved slowly, software systems change quickly, almost continually. But, because architectural decisions often aren't visible to developers, decay and rot set in. Consequently, the system qualities that are important to stakeholders gradually erode. We must identify and expose the system quoins to the software developers who are responsible for maintaining the system.
How Do We Keep Quoins Visible?
Software traceability presents a solution for tracking and exposing quoins. Trace links can be established among key stakeholder concerns, architecturally significant requirements, important architectural decisions, and sections of code in which architectural decisions are implemented. This basic set of trace links means that developers working on sensitive areas of code can stay informed of underlying architectural decisions and their associated requirements. Placing this information at developers' fingertips doesn't inhibit them from making changes; however, it does equip them to make informed changes.
But Doesn't Traceability Add Excessive Overhead?
Traceability must be strategically planned. Typically, it's neither cost-effective nor particularly valuable to trace every single requirement. In fact, such traceability would likely create an unmaintainable, brittle infrastructure underlying an otherwise (hopefully) flexible design. Effective traceability must live and breathe along with the system that it supports. It mustn't prevent change from happening or make change more difficult, but it should inform change by ensuring that developers understand underlying architectural decisions and their associated quality concerns during the change analysis process.
Figure 2 depicts a basic traceability information model showing the information that should be captured to trace architecturally significant requirements. Trace links are established from key quality concerns through architectural decisions to lower-level design and code. This contrasts with typical practice, in which architectural decisions are captured as a simple list with no backward traceability explaining why decisions were made or which particular quality goals they were designed to satisfy.




Figure 2.. A basic traceability information model depicts the paths needed to support key quality concerns' traceability.



Trace links can be captured in a simple table. For example, Table 1 shows a very basic trace matrix capturing two architecturally significant requirements and their associated design decisions. (These examples are taken from the mechatronics traceability system I described in my July/August 2013 column. 1 ) These architectural decisions represent our system's quoins.

Table 1.. A fragment of a trace matrix* documenting dependencies among architecturally significant requirements, architectural decisions, and code.



How to Use These Trace Links Effectively
Once trace links are created, they need to be made available to project stakeholders to support actual tasks. Imagine a scenario in which a developer starts modifying an architecturally sensitive part of the code and is informed of underlying architectural decisions, their rationales, and contributing requirements. The developer will receive useful information at the time of need and can implement a change without inadvertently degrading the quality of the architectural design.
Unfortunately, one of the greatest inhibitors of cost-effective traceability in practice stems from our lack of useful cross life-cycle tool support, especially when requirements, design, and code are managed across different tools and environments. We need to address this challenge by creating better traceability tools that operate seamlessly across requirements management, design, and implementation environments. By creating strategic trace links supported by effective tooling, we can place useful information at our developers' fingertips to help preserve architectural qualities and ensure that a system not only initially satisfies, but continues to satisfy its stakeholders' quality concerns.

References