Recently overhearing (or..casually over-shouldering) my wife dictating instructions out to a friend reminded me that in our 3.75ish years of marriage I’ve come to learn that outside of a few exceptions, we each tend to give instructions differently. Not necessarily in regards to amount of detail, but rather the scope of details for the instructions. Its a good thing too, since both the approaches we lean towards serve the right purposes.
In Design Controls based Engineering, two (of many) specification documents that are included to outline a product or component development are as (simplified) defined:
- Requirements Specification: Describes the expected output based on input.
- Design Specification: Describes how to deliver the expected output based on input as per requirement.
Take a design example of a box with a button and LED. The Requirements Specification may say:
- Device is to be housed in an enclosure.
- Device shall be battery powered.
- Device shall have an LED
- Device shall have a user interface button
- Device shall illuminate an LED when user presses button.
A Requirements Specification may conjure the following image:
Its a button activated light in a box
The Design Specification may say:
- Device enclosure will consist of a Cracker-Jack box of measured dimensions.
- Device shall use an AA sized 1.5V alkaline battery for power
- Device shall use a red LED of model number, with a 10K current limiting resistor.
- Device shall use a 3mm diameter black intermittent Normally Open push-button of model number.
- Push button is to be installed in series with the power source and LED, to deliver LED activation when button is pressed down.
This image may be drawn from the Design Specification:
Candy coated electronics, yum!
Some types of instructions (such as driving directions, over-the-phone instructions for emergency surgery) default to Design Specification style, as the primary interest is HOW to accomplish the task NOW. Background rationale for the instructions is secondary. Cooking recipes are often “Design Specification” also, however popular publications such as Cooks Illustrated and Cooking For Engineers will spend the time and R&D to narrate in both Requirements and Design Specification contexts.
Often, my main style of instructions is of Requirements Specification, however if there’s critical design specifications (e.g. exact cut length of lead wire for wavelength matching), I’ll include it. The non-critical design specifications are left for the reader to draft and implement. Its not out of laziness, but rather often I won’t have hard design specifications that are transferable to others. Plus, I likely hadn’t taken out the “fuzziness” in the procedures I’m accustomed to.
My wife (and a wonderful Mom for our family) tends to lean towards Design Specification when drafting instructions for others. Her goal is to capture all design implementation details so that (hopefully) someone can replicate it exactly. Repeatability in varying environments is no small feat, so being able to accomplish this is awesome.
In the recent EAF post on Custom Baby Food, I left the long term storage of baby food as putting it into “food-grade containers”. For me, as long as the container was food grade, the Requirement was met. I figured the reader will find the container as appropriate to use. My wife asked me about the volume size of the “single serv” containers we use in our “Design”, to include in her personally delivered instructions.
