Engineering requirements — Engineering, 14–17 years
Before designing, engineers turn a need into statements that can be checked. This keeps a vague wish from becoming a disappointing product.
From need to testable target
A requirement says what a product must do or be, without prescribing every detail of how it will do it. “Carry 20 kg for 10 years outdoors” is useful because someone can test both parts. A vague wish such as “make it good” cannot guide a design very far.
The problem of unclear wishes
Projects often fail because different people silently imagine different results. A customer may mean “quiet”, while a designer means “quieter than the old model”. Requirements were developed to make the target visible before time and materials are spent, and to give tests a fair question to answer.
Writing one requirement
A team is designing a phone stand for a bicycle. First, it writes the need: the rider must see the map without holding the phone. Next, it adds checks: the stand must fit phones 65–80 mm wide, survive 30 minutes of rough road, and keep the screen visible. Each target can now be tested.
The trap: describing the solution
It is tempting to write “the product must use aluminium and three screws”. That may block a better idea before it is considered. Materials and screw counts are design choices, not usually the need itself. They become requirements only when a real reason, such as corrosion or a standard, makes them necessary.
Where requirements matter
Requirements are used for bridges, medical devices, apps and even school robots. A hospital device may need to work after repeated cleaning; an app may need to answer within two seconds. In each case, the requirement connects what people need with evidence that the design really provides it.
Keep exploring
Other languages
Loading MyLeoNes™…