The document that keeps you on course
The specifications translate the need into requirements that are understandable and checkable. It must not become a novel. A first short, clear version is worth more than an impressive document nobody reads.
Start with the main function
This sentence avoids deciding too early on the number of drawers, the material or the mechanism.
Separate four types of information
| Item | Status | Example |
|---|---|---|
| Maximum volume available in the vehicle | Measured data | To be recorded in the real vehicle. |
| Acceptable weight to carry | To validate | A test with the user, not a value picked at random. |
| Prototype material | Assumption | Plywood to check the shape and ergonomics. |
| Deployment time | Target | To define with the user then to time. |
The minimum sections
- Project object: what must be designed and why.
- Users: profiles and situations of use.
- Functions: carry, store, deploy, work and protect.
- Constraints: dimensions, weight, budget, environment, maintenance and safety.
- Success criteria: tests or measurements to accept the result.
- Excluded items: what the first version will not try to do.
- Open questions: information still missing.
Turn a vague sentence into a testable criterion
| Vague sentence | Testable wording |
|---|---|
| The box must be light. | The loaded weight will be measured and accepted or rejected by the target users during a defined transport test. |
| The workbench must be stable. | The protocol will state the forces applied, the positions tested and the movements considered unacceptable. |
| The storage must be practical. | The priority tools must be found and put back during a timed scenario. |
| Assembly must be quick. | The time will be measured from the start of opening to the full locking of the top. |
From the need sheet below, write short specifications. Create a table with: requirement, reason, status of the value, verification method and the person in charge of validating. Do not invent any value. Put all missing data in an "Open questions" section.
Manage changes
Every important change must be tracked: what changes, why, who asked for it, which other parts are affected and who validates.
Decision: short description.
Reason: measurement, user feedback, cost or safety issue.
Consequences: weight, budget, schedule, plans or tests.
Validation: name or role, date and version concerned.