A lot of technical writers get experience helping engineers or other technical subject matter experts respond to requirements through proposals, design documents, or documenting actual finished products. Requirements, of course, are a list of things that a customer wants a new product or service to do. However, what if you find yourself on the other side: developing and writing those requirements? Today I’ll provide a high-level explanation of the process, seasoning the discussion with examples from activities you might already do at home.

The Engineering Process

Requirements in an engineering context are necessary to establish the potential scope of a product or service. An organization or customer has a need that must be met by an outside provider because they lack the internal capability or expertise to do it themselves. Requirements are a list or description of what they want their needed solution to do for them. To write requirements, an organization will often focus on quantifiable goals:

• What result do they want the new item to produce?
• How many do they want?
• How much are they willing to pay for this new item?
• How will the new item interact with the organization’s existing infrastructure?
• What are the key metrics by which the new item’s performance will be measured?

If you’re a government agency, you might have very specific requirements, to the extent that you prescribe the method of delivery. This type of constraint is designed to ensure that the organization gets a known quantity. For example, let’s say the U.S. Government in the 1850s or 1860s wanted mail delivered cross-country as quickly as possible. If the government insisted on horse-based delivery because it already had a large herd of horses or stations for feeding, corralling, and caring for them, the Pony Express would be the hooves-down winner.

However, if the primary criteria was speed, the Government might not specify how an organization would deliver the mail as long as it was fast. Locomotives would then be the eventual winner…later followed by the horseless carriage (automobile/truck) or the airplane.

Generally, a customer will dictate a specific solution when there is a lot riding on the outcome and they can’t afford to get too creative. They just want to know that it will be done. If a customer doesn’t know how to do something or they are looking for new approaches, they will be less specific about the method and more concerned about the outcome.

And even if a customer seeks a new solution for an existing challenge, they will often still dictate certain constraints to ensure that the new product or service–whatever it is–fits within their existing operation. They will specify “interfaces,” such as computer types, file output types, power requirements, data formats, or physical linkages to existing equipment, as well as operational/engineering standards that the provider must comply with for legal, safety, technical, or financial reasons. As a result, if someone proposes a great new gadget but it’s so new that it cannot physically plug into a wall socket or share data in a way that the customer’s existing computers use, the new solution is effectively useless.

I’ve Never Done This Before, What Am I Getting Into Here?

Actually, if you’ve ever bought a car, planned a vacation somewhere you’ve never been before, or even written a grocery list, odds are that you’ve written requirements.

• When you’re grocery shopping, you need to feed X number of people for Y number of days within a budget of $Z. You might also have requirements related to nutrition, allergies, or other needs that affect your other choices.
• If you’re buying a car, you don’t just go to a dealership and pick a vehicle at random. Again, you have a set of requirements you want fulfilled:
  • Within your budget
  • Number of passengers
  • Amount of cargo
  • Appearance/color
  • Fuel efficiency
  • Ease of maintenance
  • Ability to interface with electronic gadgets
• If you’re thinking of changing careers or buying a new home, you might have to weigh the following:
  • Money
  • Location
  • People
  • Climate
• If you’re taking an extensive vacation somewhere you’ve never been, again, you need to balance a list of requirements, which (like most government or business needs) must incorporate the needs of multiple people, including:
  • Budget
  • Amount of time available
  • Climate
  • Activities
  • Cuisine
  • Scenery
  • Language(s) spoken

And so forth. Generally, the more complex the project/problem you have to solve and the more money on the line, the more well-thought-out the requirements must be.

Hints to Effective Requirements Gathering

Let the numbers speak for themselves

Engineers are keen on identifying their Figures of Merit, sometimes called FOMs. This would be the quantifiable outcomes of a project that measure whether a proposed solution is successful or not. I first encountered this approach in a class I took at Disney.

After identifying the FOMs, you weigh each of them against each other: On your vacation is cost more important than location? Is cost more important than climate? Is cost more important than cuisine? After weighing cost against all the others, weigh the next factor against all the others. Ideally, these judgments would be given numerical values so you could see not just which FOM would “win” the most number of times, but at what intensity level or “weight.” Then you start measuring each of your possible choices, evaluating how well each one meets your various criteria (again, number values are useful here) to see which one comes out on time. Don’t like your answer? Perhaps you need to revisit how you ranked them in the first place.

In any case, it helps to apply some numbers to your requirements so that decisions are not made on a purely gut level, but something resembling an agreed-upon, objective standard.

Ask if X is really necessary

To prevent “scope creep” or requirements conflict/confusion, it’s worth considering a minimalist approach to developing requirements, where new “needs” have to buy their way in. This keeps the to-do list for your prospective bidders (and your ability to evaluate them) simple. I mentioned earlier that requirements can constrain engineering decisions, and to some extent that’s useful. However, it’s worth asking if the ability to produce a particular type of data or outcome is really a “Level 1” requirement or if it’s something that can be negotiated later. The more requirements you lard onto a project, the more you have to monitor and the more opportunities there are for conflicts or problems to creep up.

And while it used to drive some of my previous managers crazy, there is a constructive intent behind the guy who raises his hand and asks, “Is this really necessary?” Example: one large space project I worked for had over 900 top-level requirements! Care to guess how easy/fun that was to manage? Bottom line: focus on what the primary goal is: solve the problem or ensure that you’re able to supervise the outcome?

Keep it simple, silly

The “KISS” principle (originally, “Keep it simple, stupid!” but some folks found that offensive) applies to writing requirements as it does to the solution proposed for meeting them. You’re not conducting a quiz or trying to ask trick questions: you want your audience to understand what you want so they can deliver what you want. A badly written requirement–meaning one that is convoluted, contradictory, or unclear–will result in a bad response.

You can do this!

Copyright secured by Digiprove © 2019 Bart Leahy