Beyond Requirements Development


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.

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:

  • 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 units.
  • Ensure that the design accommodates all the functional requirements and doesn’t contain unnecessary functionality.
  • Define each code unit’s intended functionality following the sound design principles of strong cohesion, loose coupling, and information hiding.
  • Ensure that the design addresses exception conditions that can arise.
  • Ensure that the design will achieve stated performance, security, and other quality goals.
  • Identify any existing components that can be reused.
  • Define—and respect—any limitations or constraints that have a significant impact on the design of the software components.

As developers translate requirements into designs and code, they’ll encounter points of ambiguity and confusion. Ideally, developers can route these issues back to customers or BAs for resolution through the project’s issue-tracking process. If an issue can’t be resolved immediately, any assumptions, guesses, or interpretations that a developer makes should be documented and reviewed with customer representatives.

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 is a useful tool for precisely documenting the UI elements that appear in screens and how the system responds to user actions. A DAR model combines visual screen layouts with tables that describe the elements on the screen and their behaviors under different conditions. Figure 3 shows a sample page from a website, and Figure 4 shows a corresponding DAR model. The DAR model contains enough details about the screen layout and behavior that a developer can implement it with confidence.

Figure 3. High-fidelity webpage design

UI Element: Submit a Pearl Page at
Page where users can submit their own life lessons to be posted on the Pearls from Sand blog
UI Element Description
Always “Home” link
“About the Book” link
“About the Author” link
“Blog” link
“Submit a Pearl” link (inactive, different color because it’s the current page)
“Buy the Book” link
“Contact” link
“Name” text field
“City” text field
“State or Province” drop-down list
“Email” text field
“Title” text field
“Pearl Category” drop-down list
“Your Story” text field
“I agree” check box, cleared
“Submit” button
“Pearl Submission Guidelines” link
“Pearl Submission Terms” link
User just submitted a pearl
“Name,” “City,” “State or Province,” and “Email” fields are populated with values from previous pearl.
“Title,” “Pearl Category,” “Your Story,” and “I agree” fields are reset to default values.
UI Element Behaviors
User Action
User clicks on navigation links: “Home,” “About the Book,” “About the Author,” “Buy the Book,” “Contact,” “Pearl Submission Guidelines,” “Pearl Submission Terms”
Corresponding page is displayed
User clicks on either “Blog” link
Pearls from Sand blog opens in new browser tab
User types or pastes text into a text field
User’s text is displayed in field; for “Your Story” field, count of remaining characters is displayed
User clicks on “I agree” check box
Check box toggles on/off
One or more invalid entries
User clicks on “Submit” link
Error message appears for any invalid text entry or length or for required fields that are blank
All fields have valid entries;
User clicks on “Submit” link
Pearl is submitted; pearl counter is incremented; email with pearl info is sent to Submitter and
“I agree” check box is selected

Administrator; successful submission acknowledgment message is displayed.
“I agree” box not checked
User clicks on “Submit” link
System displays error message on this page

Figure 4. Display-action-response (DAR) model for the webpage shown in Figure 3.

From Requirements to 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.

Authors: Karl Wiegers  &  Joy Beatty

Karl Wiegers is Principal Consultant at Process Impact,  Joy Beatty is a Vice President at Seilevel, Karl and Joy are co-authors of the recently-released book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.

Like this article:
  13 members liked this article


Ryan Milligan posted on Tuesday, May 24, 2016 2:44 PM
I like how this article illustrates just how much depends on (good) requirements. I've learned in my experiences as a BA that requirements by themselves accomplish nothing; requirements that can be understood by all parties and leveraged to influence virtually every other aspect of a system are what should really be coveted. Great point about keeping requirements free of design as well; I've had to get creative at times when it comes to explaining why things like radio buttons and drop-down lists aren't explicitly mentioned - that's where wireframes usually save the day. Most of the time it's due to stakeholders requesting what their habits have led them to believe they need when in reality, it pays off to re-evaluate options that may be more efficient.
Duane Banks posted on Sunday, June 26, 2016 1:32 PM
"Use requirements to size the project or iteration."

Karl/Joy, by "requirements" are you referring to high-level or detailed WHATs?

If the former, then I get it.

If the latter, then that's a lot of work to due prior to the project plan.
Karl Wiegers posted on Monday, July 4, 2016 3:52 PM
@DivisionOne, more precisely defined requirements should allow you to generate more accurate estimates. But teams are often asked for precise estimates long before requirements are well understood. The unavoidable consequence is large uncertainties in the estimates. The more vague the requirements, the larger the estimation uncertainties. This is why estimates should be provided as a range, not a point value, and why project plans should contain contingency buffers to account for growth and initial underestimates as requirements become better understood. Otherwise, the first new requirements, or the first one that turns out to be bigger than you thought, will lead to overruns.

The simple fact is, if you want high-res estimates, you need high-res requirements. High-level requirements can yield estimates, but with greater uncertainty. Be sure to communicate this reality to the people who asked for the estimates!
Duane Banks posted on Monday, July 4, 2016 6:01 PM
Hi Karl,

I personally don't buy into hi-res estimates. But businesses don't care what I think about it :).

Only registered users may post comments.



Copyright 2006-2023 by Modern Analyst Media LLC