Requirements vs Design - Which is Which and Why?

Requirements versus design - which is what, when and why?

A classic debate. It comes up often. Unfortunately, it’s a source of confusion that causes many teams to shy away from staffing, creating, or managing any formal requirements processes. There’s a discussion on Seilevel’s forum where this has been brought up again, and it’s shaping up to be a fine grudge match here in Austin. Thanks to Cauvin for calling it to our attention. We can’t let the other folks have all the fun, so we’ll chime in too.

We’ve described the software development process before as being like an onion - having multiple layers of abstraction within which you describe the problem and solution. In this post we will translate that perspective into “what is a requirement” and “what is design”.

The layers of abstraction

1. Market requirements. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD.
2. Product requirements. In a process that uses structured requirements, these are the functional requirements, user requirements and business requirements. Design constraints are also requirements (non-functional requirements). Product requirements can be captured in an FRS, SRS, or PRD.
3. Solution design. The architectural description of the implementation, UI and test suite. Design decisions define much of the reality for developers - good design decisions make implementation and maintenance easy. Bad design decisions can make for disaster.
   
4. Implementation. The actual code that is written and running. The user interface that is presented. The tests that are included in a regression suite. We do what we’re asked, in the way that we’re asked.

The point of contention

The debate is over the classification of product requirements. In this post we’ll talk about the red team and the blue team, much like the foosball players in the image above. We’ll also use one of the examples presented in the forum as the anecdote for describing our perspective. I want to avoid putting words in other people’s mouths, so I will hilight my interpretations as being just that. And as interpretations, they may very well be wrong.

My interpretation is that the blue team believes that market requirements are the requirements, and any further specificity should be classified as design (also this). My interpretation is that the red team agrees with what we’ll write in the rest of this post.

A red team quote:

My philosophy on this is simple. If the business or the business users care about it, it is a requirement.

That being said, the business often times cares or wants things that they shouldn’t care about or want, so they do have to be careful not to demand things that truly arent requirements.

An unambiguous description of requirements and design

There is a middle ground between market requirements and design. There is a step in the software development process that happens between “defining the problem” and “designing the solution.”

When talking about market requirements, we describe the problems and opportunities that define the space. A great place to document our insight into the market is in a market requirements document, or MRD. In this hypothetical example, our mythical company is losing customers because they have to wait too long when they are on the phone to get support.

There is an ideation step, where we perform an analysis - as engineers, we would call this a root cause analysis, where we identify why the customers make software decisions based on support-call length, why the call lengths are long, etc. After we identify the root causes, we determine which ones are properly addressed with software, versus process, project, expectation setting or any other solution.

Our mythical company has decided that there will be a software component to the solution, and it will have the goal of reducing support call times.

The instant we decide that this problem is going to be solved with software, it becomes a software product requirement. And a great place to record that information is in a product requirements document, or PRD. We talk more about this in our post, From MRD to PRD - the key to defining a spec. And this is the source of our disagreement with the red team - we believe that these are both requirements, they are distinct, and they should coexist - and still both be labeled as requirements.

At Tyner Blain, we strongly support the use of structured requirements as a means of capturing, managing, and communicating our software product requirements. We start with the GOAL of reducing the average support call time. We define the use cases that capture the support-call process (or story, or scenario - if that’s your term du jour). We articulate the functional requirements (sales rep can find the customer records for the customer on the phone). And we define the design constraints, or non-functional requirements.

This is where we think we agree with the blue team as long as we add the following clarifications. Design constraints are requirements. When our client expresses the need to conform to a corporate look and feel - that’s a constraint. When we describe support for color-blind users - it’s also a constraint (although it is an ambiguous requirement without supporting material or cross-domain experts on the team). Any time we define performance characteristics (search must happen in five seconds), it is a constraint.

In all these cases, we require the software developers to design a solution within the bounds of our constraints. Constraints are requirements.

The implementation team will design (and later develop and test) a solution based upon the requirements. The requirements include constraints on how the implementors are allowed to design and implement.

Where we disagree with the red team

While generally agreeing with the red team (that requirements do exist between markets and designs), there is one statement where we do disagree.

Red team:

If I specify that the support rep must be able to search by last name, partial names, customer ids, address, phone number etc. Is that requirements or design?

Lets say you can agree that the above are requirements

[...]

Are all of those things design? I think it depends on the capabilities of your teams.

We disagree - we believe that these implementation details (by what fields a user should be able to search - and, in fact, specifying that search is the implementation approach) are not part of requirements - they are part of design.

I understand how easy it is to let project realities affect the classification of some design elements as product requirements. I’ve personally made the mistake of taking that perspective to extremes in the past.

Defining details like this (what, exactly, does the software do) are design decisions. Irrespective of the capabilities of the teams, these are design steps. It may be, for a given team, that the product or requirements manager has to help a particular software designer to make good decisions. But that doesn’t make those suggestions into requirements - it just means that the RM is helping with design. And those details would belong in a design document. Yes it’s more convenient for a product manager to put those details into the PRD, but they don’t belong there.

Summary

In conclusion - there is a natural flow from market opportunities to product requirements to design decisions in the state of all value-driven software development projects. These three concepts are distinct. They should be documented distinctly. We suggest using an MRD, a PRD, and a design document. As a simple checklist, think of each idea in this way:

• Am I describing an opportunity and it’s relative value? MRD
• Am I defining a particular opportunity that we’ve agreed to solve with software? PRD
• Am I describing the implementation of the solution? Design Document

Please join in on the discussion - if not here, then at the forum or on Cauvin’s blog.

This article was published on Saturday, February 11th, 2006 at 1:41 pm and is filed under Austin TX, Requirements, Software development, Software requirements specification.
You can leave a comment on this post.
Trackback URL