Requirements-driven development and testing in its ideal form has long been considered too challenging by industries who are not forced to follow stringent verification standards. After all, if no one mandates you to drive your development and testing process by a requirements traceability matrix (RTM), then adjusting your entire design and development process in the face of ever-looming deadlines and budget constraints appears not to make business sense. There’s no time for such luxuries—or so it seems.
Just what makes requirements-driven development a challenge?
Ever talk to a customer? Requirements should quantify and communicate the customer’s concept of a product, but often customers don’t know what they need. They have fuzzy ideas of what they want and have a tendency to focus on how a system should be developed instead of what a system’s behavior and constraints should entail. As a result, it’s very easy for requirements to get mired down with poor wording, ambiguities, loopholes, and unnecessary implementation details. And, since the requirements get the whole process rolling, any problem at the requirement level can compound the number of escaped defects at later stages of the development process resulting in ballooning cost.
As systems become increasing complex, their interfaces, expected behavior, and testing costs grow rapidly. Coordinating between the various tiers of activities necessary to realize quality requires disciplined requirements engineering, decomposition, implementation, and testing. Many organizations lack the tools and communication structures necessary to effectively coordinate between engineering teams.
Far too often, the requirements team is isolated in their stovepipe. Once the requirements are released, they quick fall out of sync with the morphing vision of the product. Requirements engineers find themselves playing catch up, trying to connect the customer’s product vision with the implementation being carried out by developers. Requirements driven tests and traceability often lags even farther behind. The result is the RTM is pulled along by the development process rather than being the driving force.
These challenges, and ensuing chaos, are magnified when applied to projects that baseline legacy code. Typically, legacy code has only been subjected to functional tests which may or may not be tied formally to requirements. As new requirements are shoe horned into the existing infrastructure, being true to requirements driving development may require significant rework of the original requirements documents, if they existed to begin with. The new systems may be far more complex than their original counterparts and may be required to adhere to much higher traceability standards and product certifications.
In the absence of certifications requirements, it is tempting for project managers to minimize cost and simply test the deltas from the baseline with a requirements’ driven approach. This leaves testing of baseline functionality to methods used on previous spirals. Invariably, such short cuts typically result in overall escalation of long-term project costs in the form of defects and rework.
Consider that on average 60-70% of all defects can be categorized as requirements related. Following a disciplined approach with robust tools and process mechanisms in place has been shown to consistently reduce cost and improve product quality.
So, how do you keep your requirements management process from running amok? How do you ensure that requirements are updated and linked from design to code and through to testing? How do you create a process and structure where engineering teams are kept up to date of progress and changes throughout development?
Recognizing the need for quality and cost control, implementing mature processes such as CMMI or DO-178B, among others, is critical to addressing this need. Implementing these requirement driven models with tools that link requirements to architecture to code and finally to tests in real-time is critical. Making these artifacts readily available to all involved provides a snapshot to all team stakeholders of where things stand at all levels of granularity.
This transparency not only keeps teams honest, it provides a bridge that horizontally and vertically integrates teams across various engineering disciplines’ stovepipes. With increased visibility, senior leadership can make better decisions with a clear picture of project vision and status, while engineering teams are compelled to update artifacts in a timely manner. As lags in the system start to reduce and as the free radicals start to be removed from the system, the value of requirements driven development can finally be realized.