by an organization, the industry itself will do so. The key factors are the requirement for audit and the fact that directors and other responsible people can be imprisoned for signing a statement that later turns out to be false, particularly if there are catastrophic financial and/or life-threatening results.
It is as yet unclear what the implications of this are and how the audits will work in practice. What is certain is that the threat of imprisonment is concentrating the minds of a lot of people who wish "appropriate procedures" to be put in place.
While this will obviously affects the whole of CM, it is going to be particularly interesting to review the effects on agile initiatives. In a previous column  we reviewed agile methods, and the concern about them from the point of view of traceability. For example, how does a director know that there are no backdoors in the products produced by his or her company? Does it make a difference if the development team used XP and the requirements are only stored on index cards?!
This is going to be a huge area. Indeed, recently, there has been a rash of seminars announced on this subject as consultancies jockey for the privilege of educating worried directors and holding their hands through implementation and deployment.
The impact upon effective yet necessary CM for agile development will be very large indeed, and many are already starting to see and feel it. In CM terms we need to quickly and easily see the status of any change, version, request or build provided:
- Task-Based Development will play an important role here too : Some kind of task-based scheme (see Austin Hastings article  on how Task-level commit (TLC) is one ingredient on the road to task-based development (TBD)) will be a key plug-point for integrating with (and tracing to) project management activities, estimates, requirements, tests, and verification/validation/auditing.
- Real Tracking Tools - the fervor to resist automated project & change tracking tools in favor of index card will have to give way to the inevitable realities of mandated traceability. Cards may still be used as an effective means of engaging in dialogue and a tactile mechanism for gathering and enacting stories and scenarios. But even then they will need to be supplemented with automated electronic tools that connect a projects "tracking" database with that of the rest of the organization in order to perform effective portfolio management at the organizational level, as well as search, sort, query, report, and "refactor" issues across all projects or products in an overall program.
- Dynamic Event-Based Traceability (such as that attempted by the SABRE project and DePaul University Requirements Engineering lab) will become more desirable as a means of automating much of the requirements traceability burden. Look for hand-crafted solutions to be scripted together initially (some might even make use of the new annotation and metadata features in J2SE 5.0 ), and then for commercial tool-support and/or open-source efforts a few years afterward.
- SCM and Requirements Repository Integration/Unification - typically, source code version repositories are separate from the repositories used by requirements management tools such as DOORS, Requisite-Pro, and CaliberRM. This poses a significant enterprise integration and deployment/upgrade/support burden on organizations trying to integrate the two in order to facilitate traceability and change-tracking:
- The Requirements Management tools typically have wonderful facilities for attaching and viewing meta-data and links and taking a container-based view of collections of items, while lacking considerably in areas of branching and merging and baselining when it comes to having to support multiple projects/variants/sites. The