Writing Requirement Sets

students, in design and manufacturing, a good idea only becomes a successful product when the requirements are written clearly. 📘 A requirement set is the written list of what a product must do, how well it must do it, and the limits it must meet. In this lesson, you will learn how to write requirement sets that are clear, testable, and useful for design teams. This matters because weak requirements can lead to confusion, redesign, wasted materials, and products that do not meet user needs.

By the end of this lesson, you should be able to:

explain the main ideas and terms used in writing requirement sets,
apply design reasoning to turn user needs into engineering requirements,
connect requirement writing to users, society, and other stakeholders,
describe where requirement sets fit inside the wider topic of Requirements and Stakeholders,
use real examples to judge whether a requirement is strong or weak.

What a Requirement Set Is

A requirement set is a structured collection of statements that defines the target for a product or system. It usually starts with user needs, then translates them into engineering requirements that the design team can measure and test. In simple terms, a need is often broad, while a requirement is specific. For example, a user may say, “I want a backpack that is comfortable.” That is a need. A better requirement might be, “The backpack shall distribute a load of $10\,\text{kg}$ with no pressure point exceeding the agreed comfort limit during a $30$-minute wear test.” That version is more precise and testable.

Writing requirement sets is part of the wider process called requirements and stakeholders. Stakeholders are all the people or groups affected by the product. They can include users, customers, manufacturers, maintenance staff, retailers, regulators, and local communities. Each stakeholder may care about different things. A school chair, for example, must fit students, be affordable for the school, be safe according to regulations, and be durable enough for years of use. A good requirement set tries to balance these needs without becoming vague.

A useful requirement set often includes several types of requirements:

functional requirements, which describe what the product must do,
performance requirements, which describe how well it must do it,
constraint requirements, which describe limits such as size, cost, materials, or standards,
environmental and social requirements, which include safety, sustainability, and accessibility.

Turning Needs into Clear Requirements

The key skill in writing requirement sets is translation. User needs are often expressed in everyday language, but engineers need statements that can be designed, checked, and tested. This is where careful wording matters. A strong requirement should be clear, specific, realistic, and measurable.

A common way to write a requirement is to use the word “shall.” In engineering documents, “shall” usually means mandatory. For example:

Weak: “The product should be lightweight.”
Stronger: “The product shall have a mass of less than $2.0\,\text{kg}$.”

The first version is vague because “lightweight” can mean different things to different people. The second version gives a measurable limit. Another example:

Weak: “The bottle must be easy to open.”
Stronger: “The bottle shall be openable with one hand using a force of less than $20\,\text{N}$ by $95\%$ of users in a usability test.”

That stronger requirement is better because it states the condition, the measure, and the target group. It also links to testing. If a requirement cannot be tested, it is hard to know whether the final product meets it.

A well-written requirement set also avoids mixing different ideas into one sentence. For example, “The lamp shall be cheap, bright, and stylish” combines cost, performance, and appearance. It is better to separate these into individual requirements:

The lamp shall cost less than a target manufacturing cost.
The lamp shall provide an illuminance of at least $300\,\text{lx}$ at the desk surface.
The lamp shall have a finish approved by the design team.

Splitting requirements helps designers make decisions and helps testers check each item separately.

Qualities of Strong Requirement Statements

When writing requirement sets, it helps to check each requirement against a few quality rules. A strong requirement is usually:

clear: it has only one meaning,
specific: it describes one thing,
measurable: it can be checked with a test or inspection,
realistic: it can be achieved with available technology and resources,
complete: it includes enough detail to guide design,
consistent: it does not conflict with other requirements.

For example, “The case shall resist a drop from $1.5\,\text{m}$ onto concrete without cracking” is clear and testable. But “The case shall be very strong” is not specific enough. Another example: “The chair shall support $120\,\text{kg}$” is measurable, but it may still need more detail, such as the test method, duration, and safety factor.

In many projects, requirements are written in a hierarchy. Top-level requirements describe the whole product. Lower-level requirements describe subsystems or parts. For example, for a bicycle:

Top-level requirement: the bicycle shall safely carry a rider on a paved road.
Frame requirement: the frame shall withstand a vertical load of $1500\,\text{N}$ without permanent deformation beyond the specified limit.
Brake requirement: the braking system shall bring the bicycle from $20\,\text{km/h}$ to $0$ within the target stopping distance under dry test conditions.

This breakdown helps teams manage complex products because each part can be designed and checked separately.

Stakeholders, Society, and Design Decisions

Requirement sets are not only about the end user. They must also consider societal requirements, which are expectations from society, law, and ethical responsibility. These may include safety, environmental impact, accessibility, and responsible use of materials. For example, a plastic water bottle may need a requirement related to recycled content or recyclability. A public building product may need accessibility features so that people with different abilities can use it.

Stakeholder needs can conflict. A manufacturer may want lower cost, while users may want higher comfort, and regulators may demand stricter safety. Writing requirement sets involves balancing these needs while keeping the product feasible. This is one reason requirements are often prioritised. A project team may label some requirements as essential, while others are desirable but not mandatory.

Consider a school lunch tray. The user wants it to be easy to carry. The kitchen staff wants it to be durable and stackable. The school wants it to be low cost. Society expects it to be safe and hygienic. A strong requirement set could include statements like:

The tray shall withstand at least $5000$ stacking cycles without cracking.
The tray shall be cleaned using standard school dishwasher conditions.
The tray shall have rounded edges to reduce injury risk.
The tray shall be manufactured within the agreed unit cost.

Notice how each requirement connects to a stakeholder concern. This is what makes requirement writing a bridge between people and engineering.

Common Mistakes and How to Avoid Them

One common mistake is writing requirements too late. If requirements are not written early, the team may design the wrong product and discover problems after manufacturing begins. Another mistake is writing requirements that are too vague. Words like “good,” “nice,” “strong,” or “modern” do not give enough information on their own.

A second mistake is using design solutions instead of needs. For example, “The product shall use aluminium” is not always a requirement unless there is a real reason, such as weight, corrosion resistance, or recyclability. It may be better to write the requirement as “The product shall have a mass of less than $1.8\,\text{kg}$” or “The product shall resist corrosion in humid conditions for $5$ years.” That gives the design team freedom to choose the best material.

A third mistake is creating conflicting requirements. For example, asking for maximum strength, minimum mass, and the lowest possible cost may be impossible all at once. In real projects, trade-offs are normal. That is why requirement sets should be reviewed carefully by the design team and stakeholder representatives.

A fourth mistake is forgetting how the requirement will be tested. Every requirement should have a path to verification, such as test, inspection, analysis, or demonstration. For example:

Test: “The product shall survive a $1.0\,\text{m}$ drop test.”
Inspection: “The product shall include the required warning label.”
Analysis: “The beam shall have a factor of safety above the agreed limit.”
Demonstration: “The interface shall allow users to complete the task without training.”

How Writing Requirement Sets Fits the Whole Topic

Writing requirement sets is a central step in Requirements and Stakeholders because it connects the early investigation of needs to the later stages of design, materials selection, prototyping, and manufacturing. Before a team chooses materials or dimensions, it needs to know what the product must achieve. After requirements are written, designers can compare options, test prototypes, and check whether the final design satisfies the original brief.

This lesson also links to the broader syllabus idea of capturing user needs, capturing societal requirements, and translating needs into engineering requirements. First, the team listens to users and other stakeholders. Then it records what matters to them. Finally, it converts those ideas into statements that engineers can work with. Without this translation, design choices are likely to be based on guesses rather than evidence.

For example, if students complain that a desk chair is uncomfortable, the team should not stop at “make it nicer.” Instead, it might identify a need for better posture support, then write requirements about seat height, backrest angle, load capacity, and material durability. That written set becomes the basis for sketches, material choices, prototypes, and tests.

Conclusion

Writing requirement sets is about turning broad needs into precise statements that guide design. students, this process is important because it helps teams understand what the product must do, who it must satisfy, and what limits it must meet. Strong requirements are clear, measurable, realistic, and connected to stakeholder needs. They reduce confusion, support testing, and improve the chance that the final product will work well in real life. In Design, Materials and Manufacturing 2, requirement writing is one of the most important steps between understanding the problem and creating a successful solution. ✅

Study Notes

A requirement set is a structured list of what a product must do and the limits it must meet.
Needs are often broad; requirements are specific and testable.
Use clear language, often with the word “shall,” for mandatory requirements.
Good requirements are clear, specific, measurable, realistic, complete, and consistent.
Avoid vague words like “good,” “strong,” or “easy” unless they are defined.
Split combined ideas into separate requirements when possible.
Requirements should link to stakeholders such as users, manufacturers, regulators, and society.
Societal requirements can include safety, accessibility, and sustainability.
Every requirement should be verifiable by test, inspection, analysis, or demonstration.
Requirement writing is the bridge between user needs and engineering design decisions.