In the world of engineering, clarity is king. No matter what you’re working on, the way you communicate requirements can make or break the success of the entire effort. 

A great example that I often refer to is “Mary Had a Little Lamb.” It’s a simple example, hearkening back to childhood, but it’s powerful in illustrating how easily things can go awry with vague or ambiguous requirements.

How do you interpret “Mary Had a Little Lamb”?

At first glance, this statement seems straightforward, but let’s break it down. Depending on who’s reading it, this simple sentence could be interpreted in several very different ways:

• Mary owned a small lamb: Most people might initially assume that this means Mary had possession of a lamb that was small in size.
• Mary consumed a lamb: Did Mary eat lamb for dinner?
• The lamb was small only at a specific time: Maybe the lamb was little only during the time Mary had it, but it grew later.
• Mary was followed by a lamb: If we’re being poetic, perhaps the lamb followed Mary around and not just to school one day. (Pro tip: Don’t be poetic when writing requirements.)
• Mary gave birth to a lamb: In some contexts, “had” could imply that Mary gave birth to the lamb, which introduces a whole different scenario.

The Engineering Context

When you’re writing engineering requirements, this kind of ambiguity is the last thing you want. Imagine if each member of your team interpreted a requirement differently—one builds a system to own a lamb, another builds one to eat it, and a third builds it to follow someone around. The result? Chaos, rework, and a lot of wasted time and resources.

“Mary Had a Little Lamb” underscores the importance of being specific, detailed, and clear in your requirements. In engineering, there is no room for assumptions or vague language. What might seem obvious to you could be interpreted in entirely different ways by others.

Avoiding Ambiguity in Requirements

To avoid the pitfalls that our friend Mary encountered, here are a few strategies for writing clear engineering requirements:

• Use precise language: Words like “little,” “some,” or “often” can be open to interpretation. Be specific with quantities, sizes, and timelines.
• Avoid ambiguous terms: Replace words that can have multiple meanings with more explicit terms. Instead of saying “She had a lamb,” say “Mary owns a lamb that weighs 20 pounds (with +/- 2 oz. tolerance if that’s acceptable, of course).”
• Clarify assumptions: Don’t assume everyone has the same background knowledge. Spell out any assumptions that could affect understanding. Using the Terms feature in DOORS Next to create a dictionary for your project is a great way to avoid problems down the line.
• Provide context: If a requirement cannot be understood by itself, ensure it’s completely understood when viewed as part of a traceability matrix. Requirements Management tools like DOORS and DOORS Next can really help ensure that the related context up and down the Systems Engineering V is always visible to users. 
• Can you test it?: What would the steps for testing whether Mary did indeed have a little lamb be? Writing a proposed test and working backwards from the test steps could not only help your requirements be written better, but considering testing from the start could affect the entire design of your system. Plus, your testers will thank you for involving them early and often, leading to a more cohesive team.

The Takeaway

“Mary Had a Little Lamb” is a simple reminder that in engineering, the devil truly is in the details. When requirements are clear and unambiguous, teams can align more easily, work more efficiently, and ultimately, deliver better results. So, the next time you’re drafting a requirement, remember Mary and her lamb—and make sure there’s no room for misinterpretation.

Clear communication is the foundation of success, whether you’re managing a small project or complex system. Let’s ensure our engineering requirements are as precise as our engineering itself.