The Dilemma of Unwritten Requirements

• Product Design
• Project Management

You will probably hear the word “requirements” at least 793 times in your engineering career, mostly in the context of how important it is, in any project, to agree upon clear requirements before committing to (and hastily proceeding towards) a deadline. Some of those times you may actually follow that advice. Other times it’s just talk, like how you should “wear sunscreen when spending time outdoors” and “eat a diet low in saturated fats and cholesterol” and “obey the speed limit while driving”. Uh huh. Yeah, we didn’t have room in the schedule to write a requirements document… maybe next time.

This article is not about that. You will, of course, find that a good portion of the anguish encountered in engineering projects (especially software projects) is due to unclear requirements that should have been negotiated properly at the beginning of the project. But we won’t talk any more about that, because there are plenty of other articles on the subject.

Instead, we’re going to talk about wooden spools.

A Tale of Two Spools

A few months ago, I needed to make a drum hoist out of a motor. This particular motor had an 8mm diameter shaft. The intent was to get roughly constant torque at low speed, by wrapping some braided fishing line around a drum and tying a weight to one end. I needed it fairly quickly, and I don’t have access to lots of mechanical parts.

But I thought, well, I’ll just get a spool and stick it on the end of the shaft; spools are something I can get anywhwere. When I was a kid, my mother used to sew a lot. She had a bunch of spools she kept in a round plastic rainbow sherbet container, and while she was sewing, sometimes I would play with the spools. Some of them were plastic and some were wood. Well, nowadays all the spools of thread are plastic meant to fit a specific diameter rod on sewing machines — maybe 1/8” or 3/16”, I’m not sure. You can’t just enlarge the hole; the spool is mostly hollow, with inner and outer cylinders and 6 thin spokes connecting them. No more wooden spools, unless you want to buy vintage spools of thread on eBay. I’d remembered seeing wooden spools at craft stores, though, so I went to one at lunch and bought a bag of “Lara’s Crafts” brand wooden craft spools for a few dollars. Yay!

I got back to work and opened up the bag and got kind of a sinking feeling when I took a closer look at the spools. They weren’t what I was looking for. Before I explain, I’ll let you know I did find a spool at another craft store from a different brand — “Tree House Studio” — that I ended up using. Here they are, for comparison:

The spool on the left is from the Tree House Studio bag. Note how round this spool is, and how concentric the inner and outer circumferences are. The spool on the right is from the Lara’s Crafts bag I bought, and it’s a little bit eccentric. Not much, but enough that when you wrap a cord around it and spin it, the eccentricity causes vibration. There’s still small wooden shavings barely attached to the inside of this spool. If you don’t trust me when I tell you the spool isn’t round, I made a video of rolling these spools on a desk:

The wobbling spool is from the Lara’s Crafts bag.

For the record, the Lara’s Crafts spools were manufactured in China; the Tree House Studio spools were manufactured in the United States.

So the question to ask yourself here is — which brand is better?

Requirements and Trade-offs

I had a requirement for my application, shared by the wooden thread spools of yore, of concentricity, so that when the spool is placed on a round shaft, the distance from the outer diameter of the spool to the center of the round shaft is approximately the same, regardless of the spool orientation.

But I went and bought decorative wooden spools. And in the process of translating from utilitarian sewing implements, to “crafty” material, that requirement of concentricity was dropped. If you’re selling to craft stores, you don’t need to worry whether spools are concentric.

My expertise is in electronics and signal processing, not woodworking… but my guess is that the Chinese spools are made of a less expensive wood, and were turned on a lathe while green, with little delay between when the trees were cut and the wood was milled into spools; green wood still has water remaining in it, and when it dries, undergoes warping. The U.S. brand most likely tried to emulate real spools of thread, using dried hardwood, which is more expensive.

Let’s imagine we’re in the craft spool business, and we have a choice, because there is no requirement for concentricity:

• We can use cheap green wood and maximize profits. Remember these are decorative wooden spools.
• Or we can pay a little more and try to make concentric wooden spools that look like spools of thread.

Which do we choose? If we go with the profit-maximizing option, we get spools that are noticeably uneven, but we make more money. If we try to go for higher quality, we may be at a competitive disadvantage. Could we compromise and try to make a little more profit with spools that aren’t perfectly concentric but not as noticeably so as the cheap option?

Here’s the thing — if we choose, we’re wrong.

Unwritten Requirements

Every engineering project has unwritten requirements, some collections of implementation details that impact how a product behaves. Sometimes they are internal details, and it’s well within the purview of the implementers to choose whichever approach they see fit. If they are externally visible, they should be brought to the attention of the customer. There’s nothing wrong with choosing something for a prototype as an example, or making a recommendation to the customer. But the customer needs to have the choice, even if that choice is to let the implementers manage smaller details. (“Do you want to graph data in red lines or green lines by default?” “Well, I’m not sure… what would you recommend?”)

I would hope that the buyers from these craft stores met with the spool manufacturers’ representatives and went over the design trade-offs (cheap? or quality?) and made it their choice, rather than just a cost competition.

You might be thinking, well, there shouldn’t be any unwritten requirements; if questions like these come up, then the customer hasn’t done their homework properly and made a complete specification.

On one hand, that’s a good point. It’s important to specify the requirements of any engineering project clearly and precisely. Let’s say your company is hiring a software contractor. Yes, you should write up a specification of what their work product needs to do. But we don’t live in a world where the only communication between the customer and the contractor is the requirements document. If you’re forced to have that arrangement, my condolences. Feedback from the contractor can help you reach a complete requirements document much more quickly than if you have to write up everything in a document on your own. Furthermore, the questions that come back from the contractor can help you make sure that the contractor has read and understood the requirements. I’ve been on several projects with contractors, where there weren’t any questions from the contractor about the spec, and we didn’t find out until later that the contractor really hadn’t done their due diligence in understanding the specifications. Usually the misunderstood requirements were the more difficult ones to meet, and the projects had schedule overruns due to technical snags. (Now that I think about it, a certain prohibition on brown M&Ms comes to mind.)

On the other hand, I’m comfortable asserting that it is impossible to specify any engineering project completely in advance for anything but the most trivial project. There will always be some important unforeseen detail that comes to light in the middle of the architecture or design phases — especially if it’s a software development project. (Agile methods take this into account; the waterfall model does not.) It could be some minute detail about error messages or log files, discovered halfway through the design process. If you discover a new requirement, and everyone agrees it should be a requirement, then add it to the requirements document.

Back to unwritten requirements:

Sometimes you really can’t specify them ahead of time. Maybe there’s a trade-off, or there’s something that’s a preference but not a requirement. Here’s an example: Let’s say you’ve got an embedded motor controller, and you have to decide what accuracy to use for the current sensing. Super-accurate op-amps with sub-millivolt offset voltage? Well, you can buy them, but that will raise the cost and give you fewer options. Or maybe you use a less accurate amplifier, and you turn to calibration to reduce the error. But this requires you to know more about the second-order sources of error (drift, temperature sensitivity, etc.), and there’s the manufacturing cost of calibration. Or maybe you want to live with a less accurate current sensing system… but then it affects torque ripple and eats into the current capability.

Or you’ve got a behavioral detail, like a vibrating feature for a steering wheel in a car: you want the steering wheel to vibrate when the car drifts too close to a lane line. What frequency should the vibration have? What amplitude? Should it vibrate parallel or perpendicular to the steering wheel axis? Sinusoidal vibration or random? Should the vibration be modulated in a pattern? What pattern and what repeat rate? If this is a really important feature, maybe you should have done your homework and completed usability studies and made these details into a formal requirement. Or maybe it’s only moderately important and you just need something that seems aesthetically correct. Or maybe you want the flexibility of allowing the car’s driver to configure the vibration details to their liking.

In any case, I’ll say it again: When there are trade-offs or design choices that have an externally-visible impact, get input from the project customer.

Best of luck in your next project!

© 2015 Jason M. Sachs, all rights reserved.

Sign in