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
- Market requirements. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD.
- 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.
- 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.
- 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.
Nice article Scott, especially the recent discussion re. cascading levels of design. I particularly like the emphasis on the point that decisions are being made at all levels and therefore design is being done at all levels, and it’s a point I tried to make in an article I wrote for Bridging the Gap:
Requirements Versus Design: It’s All Design
Judging from the comments I received, not everyone shares the “it’s all design” mindset, so it’s nice to find someone who does!
And I think the terminology is important. The use of the terms “requirements” and “design” leads to a lot of confusion and I have seen some very real negative effects, like:
1) Business analysts thinking that they are merely a messenger for the business, and that all they need to do is “capture” (scribe) the “requirements” that come out of their stakeholders’ mouths, without any synthesis.
2) “Requirements” documents that don’t have enough detail because the author didn’t want to include any “design”.
3) “Design” documents that are virtually identical to “requirements” documents but with the word “must” replaced by “will” (and maybe converted from future to present tense!). A clear waste of time.
In my view, we should ditch the term “requirements” completely and refer to each level of detail in design terms:
– Business process design
– Functional design (the bits of the IT system that the users care about)
– Technical design (the internal bits of the IT system that the users don’t care about)
That way, everybody would be very clear that they are all involved in design at some level, and it would also be a lot clearer what level of detail everybody was expected to provide.
Say “no” to requirements!
Hi, Tony. I have your article from BTG queued up for reading. Thanks for the link.
I’m not sure this thread is saying “It’s all design” (my posts certainly don’t). I think we’re arguing that the difference between requirements and designs has to do with the stakeholder and the use, not the statement (or other representation).
It would be possible to use only one term exclusively – either term. This has it’s own problems – for example,
* “requirement” can’t be used as a verb like “design”.
* “design” has huge overlaps with other terms like “plan” (noun / verb), “architect” (n/v).
* “design” provokes people to jump to single solutions instead of considering options.
On the last point, this is a huge problem, to the extent that designers are trying to invent business analysis (they call it ‘design thinking’).
We’d all like this to be simpler – but ditching requirements as a term leaves a gap that still needs to be filled.
Note that the above article has moved and can now be found at:
http://www.its-all-design.com/requirements-versus-design-its-all-design/
Thanks, Tony! I updated the link in your original comment in case folks clicked on it before they got to this comment.
Hi,
Thanks for the nice article. You have mentioned that design constraint is a requirement. So is the below a requirement :
I have to update customer info in a system. However for each state the information that is captured is a bit different. Hence we have a webservice provided by each state (one for ny , one for was , one for DE and so on). Apart from basic set of first name / lastname / ssn , the input that these system accept vary slightly. This is a design contraint.
The basic system requirement is that the customer information must be captured by the system based upon geographical state. Should the system requirement also state which service needs to be called for which state and what data needs to be passed?
I am facing a lot of confusion on this –
On one hand if I just state that system must capture customer info based on state then it seems to be open ended and incomplete,. I think i need to define the state and also need to specify what information must be passed.
On the other hand , I feel that having different services capturing different fields is a design decision and when defining the requirements the analyst might not have visibility about the solution.
Please let me know which of these is correct.
Thanks Vivek for the question, and welcome to Tyner Blain!
From the way you phrased things, I suspect the underlying requirement may be something more like “Capture customer information for customers in all 50 US states.” However, you mentioned that the _definition_ of customer information varies by state. That implies that the definition may also vary over time – if different states have different definitions, those definitions may be subject to change, as the states change their policies. I would be inclined to treat the _definition_ of customer information by state as something distinct from the requirements. I would include this either as a set of business rules (customer information for NY = xyz; customer information for NJ = xym; etc) or as a lookup table in a data dictionary.
If writing this as a user story (as an epic), I would say “As a customer in any US state, I will be able to enter my information so that (whatever reason actually lives behind what you shared).” Then for acceptance criteria, I would include “All elements of customer information, as defined for each US state, will be captured.” As you point out, this may be “too big” to do in one work-effort, so I would split it into multiple stories. I’d either start with the least-common-denominator states (perhaps MD, SC, CA all require the exact same info), then incrementally add additional states that share fields, until the last state is supported. Alternately, you may prioritize the sequence based upon the importance of supporting customers from particular states. Start with the most important state (perhaps the one with the most current users, or the one where marketing efforts are currently focused, or the one with the greatest revenue potential), including any other states that require the same information elements (or fewer elements) in that first iteration. Then with each iteration, add the next-most-important, not-already-included state (and similar states), until the least-important state is added.
The key aspect here is separating rules from requirements – the specification of what info is needed for each state is likely to be a business rule – I say likely because I don’t have detailed information beyond your example. It is probably the need to comply with varied state-policies, or a company-driven policy to treat customers in different states differently. In either case, it is a probably a policy that is independent of the application you are developing, that applies to the work you’re doing.
With that in place, there aren’t really any design constraints (in what you describe). There may also be (user interface) designers who will specify the mechanics of how customers enter their information, or (system architecture) designers who will specify the mechanics of how the system will capture what the customers enter (separate UI layer + webservices). For example, you may have a single webservice that captures the information in a single polymorphic call, including the state as well as the captured information – and then the developers can parse the information (from the single webservice) later; or you could have multiple webservice calls. If your requirements are written correctly, you will not be forcing the developers into either architecture, they will be free to choose whichever one is easiest to code / debug / maintain / test. Likewise, your requirements will not force the interface designers to either design a user interface that dynamically updates to show only appropriate fields to customers, or one that disables inappropriate fields, or one that asks all the questions of all customers (even if some information is discarded). Imagine that the list of fields for a given state changes. How much work should the team have to do to adapt the application to support that change?
Hopefully this helps. If not, let me know any questions you have remaining. Thanks again!
@Vivek, there are a number of questions here surrounding what problem you’re trying to solve.
“I have to update customer info in a system.â€
You do? Why?
It sounds like there are some stakeholders who would face a problem if accurate and complete customer information isn’t present in a system. Who are those stakeholders? What problem would exist for them?
The requirement for the end user isn’t likely to be the capture of customer information. Few, if any, users want to capture customer information, only to never conceivably do anything with it. Presumably, they subsequently want to access that information (or have the system access it on their behalf, for a purpose). Why do they want to access it, and under what circumstances? Therein lie the requirements.
Once you’ve decided what problems you’re trying to solve and avoid for end users, determine and document the conditions that indicate the presence of those problems. These conditions – or the negations thereof – are the requirements.
You or a designer may ultimately make a design decision that you will fulfill those requirements by providing the user a means of updating information in the system (keeping in mind that the user probably would prefer that the system automatically use or make accurate and up-to-date information available). And someone can document this design decision in a specification for developers. But it’s probably not a requirement.
This scenario is similar to this one involving backup software and Apple’s Time Machine.
Thanks Roger!
I agree with Roger that the underlying _why_ of the perceived requirement to capture customer information is where you should dig. The real requirement is probably that some other activities require knowledge about the user, not that the user has a requirement to provide the information.
Given that caveat, I hope that the examples I explored in response to Vivek serve as good context about the difference between requirements and design. These are two separate issues (what are the real requirements, and what are design constraints).
Roger’s points, combined with my example also highlight my contention that “requirements” and “design” are alternating layers. Given a “design” that requires the user to provide information to the system (to achieve some other objective), my examples in response to Vivek would be “requirements.” As Roger very clearly explains, there is some not-described-in-this-thread “requirement” that lead to an implied “design decision” to require users to provide information to the system. Like layers in an onion.
Thanks again, Roger and Vivek both!
I’m a bit confused here – I actually think that pretty much anything that the business cares about is a requirement, as sometimes a search for example is a search – it’s not a way something is accomplished.
Let’s take an example:
AS IS: we have a coffee machine which only makes cappucino (coffee with milk). You press the one and only button and it pours coffee with milk into a simple paper glass. We figured out that milk is expensive and not everybody likes coffee that way too, so we want to modify our machine.
TO BE (these are not requirements, but rather an envisioned end state): the machine will now by default make coffee without milk when you press the button. There should also be another button which says “add milk”. If you press that button first and then the “main” button, then you will get your cappuccino, so there’s more effort for getting coffee with milk now (hence presumably less milk will be used). Also, we want to instantly see what coffee we had, so the machine will be loaded with differently-colored paper glasses on either side of it (one color on one side and one on the other). Depending on the coffee type chosen, it will pick one of the sides and pour coffee into a glass of an appropriate color. Glasses should come in separate packs so that nobody has to sort them by color and be of different shape as well, so one wouldn’t accidentally place glasses of the wrong color into the respective side of the machine. We also want to be very specific about which color exactly means what coffee (e.g. black for the one without milk and white for the cappuccino). We also need the machine to use the same amount of energy (or less) than before and now it should be locked, so that only a person with a key would be able to do the maintenance (access rights).
Now if I was a good customer and told you all this, which requirements would actually be requirements and which would go into design?
Alex – this is an excellent set of questions, welcome to Tyner Blain and thanks for asking them. The source of confusion, I believe, is one of perspective. Every one of your examples is both a requirement and a design, depending on the role of the person making the decision. I wrote this article 11 years ago, and did it from more of a “consumer of requirements” single perspective. A few months after this article, I wrote about different perspectives. I also wrote a bit more about understanding what you are actually trying to accomplish a couple years ago. I think if you read those articles in order, it will help put what I’m about to type into better perspective. Over the last decade, as my thinking evolved, my use of language in talking about these concepts has evolved.
I could look at the specification of having different colored paper glasses/cups, and ask the question – “why have different color cups?” In your example, you started down this path – “we want to instantly see what coffee we had.” This is a design decision – “demonstrate what type of coffee the user selected by putting different coffees into cups of different colors.” [I’m using the term “cup” to refer to “paper glass” just because my brain hits a speedbump when i call it a “paper glass” – as an engineer, I think of a “glass” as a drinking container made of the material “glass” and “cup” as a generic term]. You could make other design choices – display a message (or play a message through a speaker, or send a text message to the person getting the coffee) indicating which type of coffee was selected. All of these approaches solve the same problem. So does looking at the coffee, to see if it looks like it has milk in it, for what it’s worth.
Because we could choose among different methods to communicate with the user in different ways – the “requirement” of having different colored cups is really a “design” decision intended to solve the problem of communicating. Once that design decision is made, however, the system-designer is faced with a “requirement” to use two different colored cups. So, the choice is both requirement and design, depending on your perspective.
This applies to every aspect of your example.
I hope this helps, and thanks again for the great question!