Deep Dive: Needs vs. Requirements
A battle to win the favor of customers and engineers
The terms “user needs”, “stakeholder requirements”, “business needs”, “customer requirements”, and many other flavorful combinations of “needs” and “requirements” get loosely thrown around time and time again. Usually this is most frequent in the early stages of a development project, a time when it is most volatile to be miss-aligned on those terms.
To add, as we mix in a variety of stakeholders; Marketing, Business Leadership, Quality, Testing, and various Engineering disciplines of course, this battle of right and wrong terms becomes even more confusing and contentious. So who is to say what is a requirement, what is a need, and what is the difference between all of those terms? Why even have both?
Before diving in, I want to preface this post with some background. Different industries, especially highly regulated ones, have some different perspectives on these terms, as such some imply different meanings.
For example, the term “User Needs” in medical device development has a very specific and impactful meaning. In the U.S. if you have a proper User Needs, depending on classification, then you are required by law to perform user validation of those to objectively prove that your product has fulfilled those needs. With that in mind, how you craft Needs is a particularly tricky and delicate process. Medical device User Needs are a different discussion on their own, but in short saying something like;
“The user needs the device to be easy to use.”
Which happens oh so often, is a very challenging need to validate, and should be avoided at all cost.
Lets imagine you work on DoD programs launching satellites, or maybe your focus is on a sub-sub-system on a large aircraft or spaceship. You might not have any sort of “User Needs” because there really isn’t a user on the other side of the product. That’s okay, but I would argue there is still a need, it might not be as close your level of the problem, but there is a need.
On the contrast other industries such as consumer goods or software services have much more flexibility and freedom in what they call Needs vs. Requirements. While can be a relief, it also creates somewhat of a vacuum where these terms become used interchangably and incorrectly. This fluidity can lead to confusion about what is tested and what is not, in addition to how to test something.
Ultimately what and how we test is essential to why we have Needs and Requirements. I will attempt to convey a perspective that can be applied more generally across industries without breaking any rules.
Definitions
Call Webster, it’s definition time.
Requirement - a single statement that describes a necessary system property, feature, characterization, or usage. Stated in quantitative language, that can be objectively measured and/or tested.
There is a fair amount to unpack about what a requirement is and what it is not. I’ll let you dive into that more in this post: Basics of Requirements Writing
Need - a single statement that describes a problem, a challenge, or desire from the perspective of a user. Stated in qualitative language, that can be objectively validated and/or tested.
To start, the Need doesn’t describe the “how”. The Need statement tells the team “what the problem is” or “what is the need”. It does not state “how the system should behave” or “what the product will do”. Requirements should state the how and the Needs should state the problem. Typically, it will take a collection of Requirements in order to satisfy one Need.
Do We Need Both?
This is a valid question. Why have Needs and Requirements, why not just make everything a Requirement? This could make things simpler. Shouldn’t Marketing or Product teams be responsible for Needs anyway? We will focus on writing good Requirements, thoroughly test the product, and everything will be golden. Maybe.
I’m going to ruffle some feathers here, but team members who are not responsible for, or have been responsible for Needs, Requirements, and testing those items usually don’t author great Needs. This is not a hard and fast rule, but typically true. Yes, Marketing and the Product team should be closely involved with the Needs process, but if you are responsible for decomposing those into Requirements, and testing everything, then you own them, whether you like it or not.
The team responsible for developing a system or product should intend to make the best product possible for users. If that’s not clear then maybe we are in different worlds of development. Leveraging Needs is a tool to make a better product. Not only that, but Needs are likely tightly coupled with your company’s business.
The reason a company, a team, or an individual invest time and money into developing a product or system is to fulfill a Need. It is the why behind the business, it is the mission.
Authoring good Requirements means having a holistic set of Requirements. If you don’t have a Need in mind when creating them, then you have gaps or unnecessary Requirements. It is the why (rationale) behind the requirements.
How Requirements create structure for verification testing, Needs point at what the team will, or can, validate with users. Needs should identify what users care about, and what you are going to test with them.
A colleague used the phrase “it’s the why they buy”, and that is something that has always stuck with me. The “why they buy” are your needs, you just might not call them that yet. So ask yourself and your team, what are the Needs, what is the why?
“I Have the Need for Speed”
Since I’ve covered Requirements in more detail in a different post (see above), let’s jump into some more discussion on Needs specifically. I want to get a few example Needs on the table, discuss their parts, and then reference back to those further along in the post.
Let me start by giving an example product, then we’ll go to Needs. Let’s imagine our product of interest is the pay terminal at a gas pump, something most have used or seen. I should mention, don’t get caught in the common trap of writing Needs and Requirements for a product that already exist. Open your mind and be imaginative, you are designing a new product which means you don’t have to follow the rules of products that already exist.
What are some Needs we can think of:
Now notice what is not there;
User needs to be able to key-in information, or enter a pin number.
User needs to be able to insert a card.
User needs for a screen to provide them feedback.
The examples I just listed off are not Needs. Each of them are products of the design. The user doesn’t need to “insert a card”, they need to “pay for gas”, and as a product of designing the system the engineering team decided that one way for them to pay for gas is by providing a credit card reader.
Let’s look at “provide feedback”. This one is strikingly similar to “the user needs the system to be intuitive, or easy to use”. This falls under UN-1, by providing the user with the ability to “pay for gas at the pump”, the team is deciding that an essential part of that need is providing feedback to the user. You should continue to leverage the core User Needs as a source for Needs similar to “easy to use” or “a reliable design”.
You could argue that UN-1 and UN-2 could be combined into a more inclusive Need, that’s fair. UN-3 though is unique on it’s own. This is where things become muddy, most users, don’t care to get a receipt when getting gas. I know I don’t. However, regulations may legally require your product to be able to provide a receipt in the event it is requested. So is that a Requirement due to regulations, or is it a Need since some users do truly need or want a receipt?
I would suggest both. Both are design inputs and each may provide unique requirements for the product, and that is what is important. Yes users do need receipts, however uncommon that may be, but it also may point to requirements like having the ability to decline a receipt. Regulations on the other hand may provide inputs on what exactly is required to be provided on the receipt; date, time, payment type, cost, tax, etc.
Lost in Translation
Translating Needs to Requirements, Requirements back to Needs, and ensuring there is a clear partition between the two is not always straight forward, we saw this in our example. Needs and Requirements should be day and night, oil and water, yin and yang, but that isn’t always easy. As you collect more of each, going back and forth can become less clear.
Reference back to our example Needs from above, how would we formulate some Requirements?
This isn’t everything, but hopefully reading the two sets you can start to see the difference between the wording. One (Needs) is used to create requirements, while the other (Requirements) is used to create a design.
Something to notice is we’ve begun to create some Traceability. A lovely word, but can be a headache for those familiar with it. Most Requirements Management Tools that exist on the market, exist for this single reason, to provide users with the ability to effectively create and maintain Traceability. While you can do it in Excel, like many before you; this does become cumbersome and confusing with when you have many many work items. I would encourage managing traceability however, no matter the hurdles, as it ensures coverage of your Needs and Requirements. It also proves to be invaluable resource when a product has been on the market for 5 years.
Ideally, whatever form you document these items in is clear and easy for any stakeholder to pick up and understand. Two separate entities that work together in harmony. Getting buy-in on definitions of each from the development team early is most beneficial.
The Descriptors
Like the Sun rising every morning, every team wants to add descriptors on Needs and Requirements. There is something about it that is a self-fulfilling prophecy. Not to knock it, adding clarity and organization to different items is a good thing. And like pointed out, Medical Device User Needs or DoD - Customer Requirements, for some industries it is very much mandatory or baked into the industry in an irreversible way.
In general though, before adding descriptors of any kind, agree on what is a Need and what is a Requirement. Agree on why they are different, and agree on how testing is different. If we specify one Need as a “Customer Need” and another as a “Business Need” why are we creating the partition? Sure the stakeholder for each is different, but is the testing different? Is the method or process of proving that the product sufficiently meets the Need different for Business and Customer Needs? If you can answer this, that might help you.
For Requirements I think this is usually less of a problem. Generally Requirements are organized in a more analytical fashion; Functional, Safety, Environmental, and so on. From a testing perspective we understand that Requirements will be verified in some form or method. You can still have confusion thought. Again, I would recommend looking through Basics of Requirements Writing for more information on that topic.
Testing
I’ve mentioned testing more than several times throughout, so hopefully at this point its hit home that testing is important.
Needs are validated
Requirements are verified
These terms (verification and validation) are used widely, and it should be understood that people will use them in different context. I would suggest not being such a stickler unless you’re having a specific conversation about testing Needs and Requirements. There are many things you can verify or validate. Moving on;
Verification - the process of confirming the product, as designed, meets the Requirements through means of measurement, analysis, demonstration, or test.
Validation - the process of confirming the product, as designed, meets the Needs of users by asking actual users to simulate use of the product.
Requirements are written in objective, measurable language, of the engineer. The results of verification testing are binary; Yes or No, Pass or Fail. How you test that Requirements are satisfied is a detailed process of individually confirming each and every one is supported by the design. Different methods may be used but the results are intended to be objective and measurable.
Needs are written as a problem statement in the language of the user. The results of validation testing are collected and aggregated to determine acceptance. Testing can be performed on parts of the product and the final product, allowing a team to collect validation results throughout the development process. Most importantly, the testing should be performed with actual users.
Bringing back our example;
“The user needs the product to accept payments in the physical and digital form”
Validating this need you may ask a user questions like:
Were you able to successfully pay for gas with physical money?
Were you able to successfully pay for gas with a digital form?
Asking questions like this are much more straight forward than asking a user:
On a scale from 1-5 how easy was is to pay for gas at the pump?
Not only is this not the problem we are solving, but it will also give a wide range of responses. To add, how do you determine the threshold for “easy enough”? If you aggregate scores and determine on average users rate the system 2.75 out of 5 (5 being the best score), is that good enough to consider the system acceptable? If you said 3 out of 5 was the acceptance criteria, how much money and time is your team going to spend to re-designed a finished product, in order to make is “easier to use”? Sure over time you can iterate on the product, but the question a business will have for a design team, once two-plus years and millions of dollars have been spent is, “can we release this product now?”.
It is scenarios like the one listed above that lead me to having such vindicated opinions about Needs and Requirements. Even if you solved the problem, you technically failed validation because your Needs were not well written. Having Needs that can be validated and Requirements that can be verified are essential to the design process, and an essential role a Systems Engineer or Technical Product Manager plays. And finally, having a good set of Needs leads a team to having better requirements and a better design.
How do we Apply this?
The highlight reel:
First and foremost it starts with definitions. Create definitions for the terms you are going to use and align on those with your team.
Make the separation between Needs and Requirements early and stick to it. Refer to your definitions in times of…need…and allow your team to discuss why one thing is a Requirement and the other is a Need.
Take your time writing and reviewing Needs. When you finishing designing and building your product, the Needs should be the same as when you started. Having atomic Needs throughout development will prove to be a foundation.
When decomposing Needs, you shift gears into the language of the engineer. The Needs tells you the problem, but the Requirement tells you what the system will do or provide.
Leverage Traceability from Needs to Requirements. This will help drive rationale being understood and ensure coverage of your Needs and Requirements. Traceability is a long term resource.
Make your Needs and Requirements organized, but use descriptors with some discretion.
Always, always, always ask; how will we test this? Always ask this. It will pay dividends. Understand the Validation and Verification mean different things, how your Needs and Requirements are written directly impacts testing efforts. We want to pass the majority of testing the first time around, good Needs and Requirements are the start of doing that.