A Robust Requirements Method

But what if you are developing the pacemaker programmer we described above? What if your teams are developing six integrated products for a product family that is synchronized and released twice a year? You employ 800 developers in six locations worldwide, and yet your products must work together. Alternatively, what if you are a telecommunications company and the success of your company will be determined by the success of a third-generation digital switching system that will be based on the efforts of 1,000 programmers spanning a time measured in years ? What then?

Then you will need a truly robust requirements method. One that scales to the challenge at hand. One that can be tailored to deliver extremely reliable products in critical areas. One that allows developers in other countries to understand the requirements imposed on the subsystem they are building. One that can help assure you that your system satisfies the hundreds of use cases and thousands of functional and nonfunctional requirements necessary for your application to work with other systems and applications ”seamlessly, reliably, and flawlessly.

So now we come full circle to the robust requirements management method expressed in Figure 30-3. Its characteristics are briefly explored below.

Figure 30-3. A robust requirements method

Concept. Given the complexity of the application itself and the likelihood that few, if any, features can actually be implemented and released before a significant amount of architectural underpinnings are developed and implemented, we add a range of concept validation techniques, storyboards, prototypes , architectural models, and the like. Each will bring us closer to our goal of understanding the intended behavior of the system we are about to build.

Vision. In order to assure understanding among a large number of stakeholders, developers, and testers, the vision, both short-term and long- term , must be documented. It must be sufficiently long-range for the architects and designers to design and implement the right architecture to support current and future features and use cases. The whole product plan should be extended to describe potential variations in purchase configurations and likely customer deployment options. The plan should also define supported revision levels of compatible applications.

Requirements. The use cases are elaborated as necessary so that prospective users can validate the implementation concepts. This ensures that all critical requirements will be implemented in a way that helps assure their utility and fitness. Because some elements of the application are critical, all alternative sequences of events are discussed and described. Pre- and post-conditions are specified as clearly and unambiguously as possible. Additional, technical specification methods (analysis models, activity diagrams, message sequence diagrams) are used to describe more clearly how the system does what it does and when it does it.

Supplementary Specification/Nonfunctional Requirements. The supplementary specification is as complete as possible. All platforms; application compatibility issues; applicable standards; branding and copyright requirements; and performance, usability, reliability, and supporting requirements are defined.

Tooling. Larger, more distributed teams require industrial-strength software tooling. Analysis and design tools further specific system behavior, both internal and external. Multisite configuration management systems are employed. Requirements tools both support requirements traceability from features through use cases and into test cases and track changes and change history. The defect tracking system extends to support users, including customers, from any location.

Project Control. Larger projects require higher levels of project support and control. Requirements dashboards are built so that teams can monitor and synchronize interdependent use-case implementations . A change control board is created to weigh and decide on possible requirements additions and defect fixes. Requirements analysis and impact assessment activities are performed to help understand the impact of proposed changes and additions.

Taken together, these techniques and activities in our robust requirements method help assure that this new system ”in which many tens or hundreds of person-years have been invested and which will touch the lives of thousands of users across the globe ”is accurate, reliable, safe, and well suited for its intended purpose.