One of my first experiences with developing a requirements document was shopping for my first car.
As a teenager, the line between dream and reality was blurred. I was a huge fan of the TV show Knight Rider, and, in the 90s, it was on cable syndicate all the time. Michael Knight, played by David Hasselhoff long before his days as a judge on America’s Got Talent, had a car called the Knight Industries Two Thousand (KITT). And what a car.
In addition to sophisticated mobile weaponry, KITT boasted AI, commlink, and microsensors that created an overhead view of the vehicle. All of that technology was included with KITT roughly 30 years before it was released to the public in the Amazon Alexa, Apple Watch, and Lexus 360 Panoramic View, respectively. KITT was an amazing dream car.
A few minutes into brainstorming my requirements for my first car, the list looked very similar to the feature set of KITT: sunroof or convertible, sports car, premium sound system with CD player and subwoofer, alloy wheels, spoiler, and heated seats. At that moment, I realized I did not know how to separate wants from needs. Instead, I was only able to articulate what I dreamed of in a car.
To whittle down my list, I should have asked what features would get me from home to school, to my job, then home again. I really only needed the car to drive safely and reliably. In other words, I needed to make the distinction between a steering wheel (need) and a sunroof (want).
Product companies today face similar requirement creep. With so many customizable specs, it can be hard to know which product features are necessary and which are just nice to have. And while we can all dream about cars with two-wheel ski drive and grappling hooks, in reality, KITT would be neither practical for the consumer (Who would actually use all those features?) nor profitable for the manufacturer (How many KITTs could they actually sell?).
In other words, too many or too little features can make or break a product. In this article, I’ll show you how to evaluate and edit your product requirements to ensure that your final product meets customer demand and generates profits.
Separating needs from wants
At some point in the product development process, which may vary by industry or project, developers and marketers must document the requirements of the new product.
This can be as simple as identifying the necessary features of a working prototype or defining a minimum set of performance metrics. It can also be as complex as reviewing multiple rounds of testing, determining failure points, calculating statistics, and evaluating market intelligence.
No matter how simple or complex the task, the output is still a requirements document.
The best way to determine if a feature is actually a requirement is to remove it and test the product without it. For example, a car cannot steer without a steering wheel, it cannot stop without brakes, and it cannot be driven at night without headlights. A car can, however, drive without a sunroof, radio, hood ornament, spoiler, or heated seats (although heated seats are really nice in the winter).
The above examples may seem obvious, but one less obvious is including a legacy feature that no longer qualifies as a requirement.
For example, an optical drive was a once true requirement for many OEM computer systems. That’s because DVD media was the primary method for system recovery, software updates, and external data storage. With the advent of remote system monitoring and management, as well as cloud storage, an optical drive is no longer a true requirement for many solutions. However, an optical drive can still be found on many requirements documents today.
How to define a requirement on a sliding scale
Determining a requirement that is on a continuum can seem more difficult.
Let’s say that in the last test, we determined that a car that only drives straight does not meet the minimum performance metric. So, any car I buy needs a steering wheel. But what if even my requirement (steering wheel) can also be customized?
I can stick with a basic steering wheel, add leather wrapping to it, or add leather wrapping and heat. All three final versions of my steering wheel will steer the car, and leaving out any of those three steering wheels would render the car useless.
These additional features represent a continuum of utility and comfort. To determine the point where “need” ends and “want” begins, evaluate each marginal feature increase. In this example, ask whether the car would turn without the heated feature of the steering wheel. Then evaluate whether the car would turn without the leather wrapping.
This is a simpler process when the features only add on to prior feature sets like in the example above, but it can prove more difficult when the features occur independently of each other.
For example, if the three options were carbon fiber steering wheel, heated steering wheel, or leather-wrapped steering wheel. In that instance, each feature can still be evaluated independently and plotted on the utility/comfort continuum.
All three of those steering wheels will steer the car, and if removed, would render the car useless.
Why a good requirements doc matters
Creating a requirements document is a critical part of product development, and determining each individual requirement can be a challenging process.
Regardless of the specific industry, it’s important to identify true requirements, the so-called “steering wheels” of your product. Insisting on features that are not truly required adds cost to the bottom line and can erode a product’s profitability. Including features that are not necessary also adds failure points.
Filling a requirements document with so-called “sunroofs” may be the difference between a profitable product and an unsuccessful product.
If you and your team would like assistance in determining requirements for your next compute-related product, the engineers at Equus would be happy to help you determine what you need and what is not needed.
And one final thought, I have been through the car buying experience a number of times since my first car, and the car that I drive now does have a steering wheel, but does not have a sunroof.
Want help building your next product’s requirements document? Contact our team at oem@equuscs.com.
