EC-19.2 From a Need to a Requirement, and the Block Diagram

What this is and why it exists

The engineering design course later does this formally, with acceptance criteria and a written specification that somebody signs.

This topic does it once, informally, on a single page. The reason for doing it twice is worth stating. A reader who has never written a requirement cannot see what the formal version protects them from. Meeting the failure first, on something small, makes the formal apparatus look like a solution rather than paperwork.

The rule to carry forward is short. A requirement nobody can test is a wish, and a wish is interpreted differently by every person who reads it.

The vocabulary

• Need — what someone wants to be different about their situation.
• Requirement — a statement of what the thing must do, written so it can be checked.
• Acceptance criterion — the test that decides whether a requirement is met.
• Constraint — a boundary the solution must stay inside.
• Specification — the collected requirements and constraints for one design.
• Functional block diagram — boxes naming functions, with labelled arrows for what moves between them.
• Interface — what one block promises to another at their boundary.
• Trade-off — a choice where improving one thing worsens another.
• Brief — a short document holding the need, the requirements, the constraints and the diagram.

The mental model

People describe what they want in terms of the solution they already imagined. Someone asks for a louder alarm when their real problem is that they do not hear the existing one from the next room. Building a louder alarm may not solve it, and may make the product unpleasant.

So the first work is questions rather than answers. When does the problem happen? How often? What do you do now instead? What happens if nothing changes? Those four questions usually reveal a different problem underneath the stated one.

Once the need is understood, requirements are written. A useful requirement has a number and a condition attached, so that a person who was not in the room can check it. Compare these two.

• The alarm should be loud enough.
• The alarm shall produce at least eighty-five decibels measured at one metre.

The first cannot be checked and will be read differently by everyone. The second can be checked by anyone with a meter. It can also be argued with before anything is built, which is when arguing is cheap.

Constraints are a different kind of statement, and confusing the two causes trouble. A requirement is something the design must achieve; a constraint is a boundary it must stay inside. Cost, size, weight, power, time and available skill are all constraints.

One constraint is nearly always forgotten by beginners: what you can actually obtain. A design built around a component nobody stocks, or one that arrives in six weeks, is not a design for a project due sooner. Checking availability belongs at this stage, not at assembly.

The block diagram follows from the requirements rather than preceding them. Boxes name the functions the requirements demand. Arrows show what moves between the boxes, and the arrows have to be labelled, because an unlabelled arrow hides the decision that matters. An arrow may carry a voltage, a message, a current or energy, and those need different things at the boundary.

With the diagram drawn, one more step is worth the time. The same set of functions can usually be connected in more than one way. Put the intelligence in one central part, or distribute it. Do the conversion early or late. Sketching two arrangements and comparing them on cost, complexity and how each fails is cheaper now than discovering the difference during assembly.

The output of all this is one page. It holds the need in a sentence, the requirements as a numbered list, the constraints as a second list, and the diagram. It is written before building, and it is what the finished thing is checked against afterwards. Writing it afterwards is the failure this topic exists to prevent. A brief written to match what you built always says the project succeeded.

What you should now be able to explain or do

• Ask the questions that turn a stated want into an understood need.
• Write a requirement with a number and a condition, so somebody else can check it.
• Distinguish a requirement from a constraint and list both for a small project.
• Include component availability among the constraints rather than discovering it later.
• Draw a block diagram with labelled arrows and say what each arrow carries.
• Compare two arrangements of the same blocks before choosing one.

Check yourself