Birds of a Feather Sessions (BoFs) are informal gatherings for discussing of a topic of interest, often without a pre-planned agenda. Ron Koontz from Boeing achieved exactly that when he gathered a crowd of about 25 people to share experiences on his current problem of how to achieve traceability between requirements, architecture, and code.
In the course of sharing experiences as a group we agreed that this was a hard problem and found ourselves asking a lot of interesting questions:
- How can requirements that are safety critical and worthwhile to get complete traceability on (traceability from requirements all the way to code) be determined?
- When complete traceability is required by the customer does every file or source line of code really need to be traceable to a requirement and architecture? How can this be clarified with the customer?
- Since a customer is mostly concerned about ensuring that requirements are satisfied within the delivered code, does this mean architecture needs to be divorced from the traceability cycle?
- What are different reasons for traceability?
- To what extend UML and SySML help with traceability, especially when generating code from architectural views defined with these languages?
- Would it be sufficient to ensure all requirements are tested rather than ensuring that each requirement is traced to architecture and code? Has anyone had any customer accept testability in place of traceability?
- How can architecture design methods such as attributed-driven design (ADD) help in focusing traceability as ADD is based on systematically carrying down quality attributes while decomposing the system into its subsystems?
- How can a quality attribute for traceability be expressed?
As the group adjourned, I was still pondering how well expressed quality attribute scenarios for traceability can help focus the goals and techniques used for traceability. Has anyone had any experience in using quality attribute scenarios for this purpose?
-Ipek Ozkaya, SEI