You’ve developed a set of requirements for 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. All of these post-requirements activities demand ongoing collaboration between the project’s business analyst or product owner, project manager, architect, developers, and testers.
From Requirements to Design to Code
The boundary between requirements and design is not a sharp line. 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 hardwarecomponents, for systems that interface to many other systems, and for complex software-onlysystems. An essential step is to allocate the high-level system requirements to the varioussubsystems and components. An analyst, system engineer, or architect decomposes thesystem requirements into functional requirements for both software and hardware subsystems.
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.
Software Design
Software design receives short shrift on some projects, yet the time spent on design is an excellent investment. The requirements for most products can be satisfied with numerous software designs that will vary in their performance, efficiency, usability, robustness, and the technical methods employed. If you leap directly from requirements into code, you’re essentially designing the software mentally and on the fly. You come up with a design but not necessarily with an excellent design. Poorly structured software that’s not easy to modify is the likely result. As with requirements, excellent designs result from iteration. Make multiple passes through the design to refine your initial concepts as you gain information and generate additional ideas.
Shortcomings in design lead to products that are difficult to maintain and extend and that don’t satisfy the customer’s performance, usability, and reliability objectives.
You needn’t develop a complete, detailed design for the entire product before you begin implementation, but you should design each component before you code it. Formal design is of most benefit to particularly complex projects, projects involving systems with many internal component interfaces and interactions, and projects staffed with inexperienced developers. All projects, however, will benefit from the following strategies.
Software Design Strategies
- Develop a solid architecture of subsystems and components that will permit enhancement over the product’s life.
- Identify the key functional modules or object classes you need to build, as well as defining their interfaces, responsibilities, and collaborations with other
- Ensure that the design accommodates all the functional requirements and doesn’t contain unnecessary
- Define each code unit’s intended functionality following the sound design principles of strong cohesion, loose coupling, and information
- Ensure that the design addresses exception conditions that can
- Ensure that the design will achieve stated performance, security, and other quality
- Identify any existing components that can be
- Define—and respect—any limitations or constraints that have a significant impact on the design of the software
User Interface Design
Your requirements explorations probably took at least tentative steps into user interface design. UI design is so closely related to requirements that you shouldn’t just push it downstream to be done without end-user engagement. Use cases can lead to dialog maps to show user navigation options, wireframes that sketch out screen layouts, prototypes that demonstrate interaction behaviors, and ultimately into detailed UI designs. Sometimes a simple sketch conveys enough information for the UI designer to build effective screens, working with user representatives to validate the design. Other situations will benefit from more detailed UI specifications. A Display-Action-Response (DAR) model might be useful for precisely documenting the UI elements and their behavior.
...And, Success!
The ultimate deliverable from a software development project isn’t a set of requirements—it’s a solution that meets the customers’ needs and expectations. Requirements are an essential step on the path from business need to satisfied customers. If you don’t base your project plans, designs, and acceptance and system tests on a foundation of high-quality requirements, you’re likely to waste a lot of effort trying to deliver a solid product. Strive for a sensible balance between off-the-top-of-the-head coding and rigorous specification that will reduce the risk of building the wrong product to an acceptable level.
