So you’ve developed a set of requirements for some portion of your next systems development project. Now what? Experienced project managers and software developers understand the value of translating requirements into rational project plans and robust designs. These steps are necessary whether the next release represents 1 percent or 100 percent of the final product. As shown in Figure 1, requirements serve as the foundation for project plans, designs, code, and tests. In addition to these connections, there is a link between the requirements for the software to be built and other project and transition requirements. Those include data migrations, training design and delivery, business process and organizational changes, infrastructure modifications, and others.
Figure 1. Requirements drive project planning, design, coding, and testing activities.
All of these post-requirements activities demand ongoing collaboration between the project’s business analyst or product owner, project manager, architect, developers, and testers. This article, adapted from our book Software Requirements, 3rd Edition (Microsoft Press, 2013), presents some guidance for bridging the gap between requirements development and a successful product release through effective design.
From Requirements to Designs and Code
The boundary between requirements and design is not a sharp line but a gray, fuzzy area. Try to keep requirements free from implementation bias, except when there’s a compelling reason to intentionally constrain certain aspects of the design. Ideally, the descriptions of what the system is intended to do should not be slanted by design considerations. Practically speaking, though, projects often possess design constraints from prior products, product line standards, and user interface conventions. Because of this, a requirements specification almost always contains some design information. Include developers in requirements reviews to make sure the requirements can serve as a solid foundation for design.
Architecture and Allocation
A product’s functionality, quality attributes, and constraints drive its architecture design. Analyzing a proposed architecture helps the BA to verify the requirements and tune their precision, as does prototyping. Both methods use the following thought process: “If I understand the requirements correctly, this approach I’m reviewing is a good way to satisfy them. Now that I have a preliminary architecture [or a prototype] in hand, does it help me better understand the requirements and spot incorrect, missing, or conflicting requirements?”
Architecture is especially critical for systems that include both software and hardware components, for systems that interface to many other systems, and for complex software-only systems. An essential step is to allocate the high-level system requirements to the various subsystems and components. An analyst, system engineer, or architect decomposes the system requirements into functional requirements for both software and hardware subsystems. Requirements trace information lets the development team track where each requirement is addressed in the design.
Inappropriate allocation decisions can result in the software being expected to perform functions that should have been assigned to hardware components (or the reverse), in poor performance, or in the inability to replace one component easily with an improved version. On one project, the hardware engineer blatantly told my group that he expected our software to overcome all limitations of his hardware design! Although software is more malleable than hardware, engineers shouldn’t use that flexibility as a reason to skimp on hardware design. Take a systems engineering approach to decide which capabilities each system component should deliver.
Allocation of system capabilities to subsystems and components must be done from the top down. Consider a Blu-ray Disc player. As illustrated in Figure 2, it includes motors to open and close the disc tray and to spin the disc, an optical subsystem to read the data on the disc, an image-rendering subsystem, a multifunction remote control, and much more. These subsystems interact to control the behavior that results when, say, the user presses a button on the remote control to open the disc tray while the disc is playing. The system requirements drive the architecture design for such complex products, and the architecture influences the requirements allocation.
Figure 2. Complex products such as Blu-ray Disc players contain multiple software and hardware subsystems.
Do we have your attention yet? If you want to read more, grab the full article! The article continues the discussion with more on:
- Requirements and Software Design (the famed “fuzzy line” between them)
- Requirements and User Interface Design (a special type of design)
- Requirements to Success (since requirements are a means to an end)
Joy co-authored this article with Karl Wiegers, Principal Consultant at Process Impact, www.processimpact.com. Karl and Joy are co-authors of the recently-released book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.