Write the product question down before it becomes a design question
The accelerator page names the customer's real obstacle plainly: in the early stage it is often unclear whether the product can be made, how to make it, how much it costs, and where the risks sit. Those four items are answerable, but only if the requirement document states them as questions with a defined subject. A sentence such as "a mobile unit for a paid car-wash bay" is a starting point; a paragraph that states the bay layout, who operates the machine, what the operator is expected to clean, and what failure would make the purchase wrong is what an engineering team can assess.
Two writing rules hold at this stage. Separate the customer's market claim from the product's function: "there is demand for X" is context, "the machine must do Y without Z" is a requirement. And separate hard constraints from preferences, because an early technical assessment treats them differently - a fixed water point, a restricted aisle width, or an existing component supply is a constraint, while a preferred appearance or a handling detail is a preference that can move.
Document the functions as core, auxiliary and optional
Requirement definition and product sorting is the first named service module, and its sub-items are a documentation checklist in themselves: usage-scenario analysis, target customer and application scenario, classification of core and optional functions, confirmation of product form and usage, cost objective and price range, and project priority. Writing functions into those three buckets - core, auxiliary, optional - is the part most briefs skip. It decides what a principle prototype has to prove and what can wait for an engineering prototype.
For a cleaning-equipment project, that list usually reads as behaviour rather than hardware: steam mode or hot-water mode, wet or dry output, how the water supply reaches the machine, whether the unit is pushed, driven, or fixed, what the operator does between jobs, and what the machine must tolerate from a site. Each line should be traceable to a person's task on the site, not to a component.
Put the system boundaries in writing, not in someone's head
The technical feasibility module names the systems an assessment walks through: mechanical structure, electrical control, the steam, water and vacuum system, mobile platform and structural load, key component selection, and manufacturing and assembly. The requirement document does not need to solve any of them. It needs to say which of them exist in this product and which interfaces between them must be respected, so the assessment has a subject. A project where nobody wrote down that the machine must run from a wall water point, for example, discovers that fact as a rework in the mechanical layout.
Where a system is out of scope for the first stage, record that too. "Vacuum function is not in the first prototype" is a decision that protects the schedule; silence on it produces a prototype that someone expects to have it.
Record acceptance in test language, not adjectives
Hardware testing is where adjectives in a brief stop being useful. The testing page states the principle directly: a product's ability to operate does not mean it is reliable, and testing exists to expose problems before small-batch production or delivery. Its blocks name what can be documented in advance - control panel and HMI behaviour, execution mechanism action, alarm and protection functions; performance items covering the conditions the machine must hold at, with the page listing flow, suction and energy consumption and the cleaning result on the surfaces it is bought for; stability through continuous running, repeated start and stop, and fault reproduction; safety through electrical inspection, leakage and emergency-stop testing, pipeline sealing and high-temperature protection; and life and reliability checks on key components, switches and buttons, with fatigue and wear observation.
So each requirement line gets an acceptance clause in the same document: what condition is applied, what is observed, what counts as passed, and who signs. The reason is practical - if the requirement is written only as "stable", the test team must invent a criterion, and the two sides discover later that they invented different ones.
Write the risk list as an owned register
The accelerator's risk module asks for a technical risk inventory, cost risk analysis, mass-production risk assessment, supply-chain risk and safety and reliability warnings, with suggestions for the next stage. In a requirement document these are most useful as rows with three columns: what could go wrong, which requirement it threatens, and who answers it - the customer, the supplier, or both. An open risk that has an owner is a plan; an open risk in a paragraph of cautions is a hedge.
One FAQ answer on the accelerator page is worth remembering at this point: if the assessment concludes the project is not suitable for further development, that outcome still counts as value, because it arrives before large-scale investment. A written risk register is what makes that conclusion defensible instead of arbitrary.
Keep one column for the decisions you are not making yet
A requirement document also records deferrals. Whether the route runs from principle prototype to engineering prototype to small-scale trial production, or starts at an engineering prototype, is a decision the accelerator makes with the customer; the document's job is to state what the first prototype must prove and what it is explicitly not required to prove. The same applies to the split between the two service offers: the accelerator decides how the project starts, product development carries it through structure, electrical control, prototype manufacturing, BOM and production import. Writing that boundary in the brief is what stops a stage-one quotation being compared with stage-two deliverables.
Match the documents to the people who will use them
The accelerator's deliverable list names the outputs a well-documented requirement set should reach: requirements analysis, product feature list, feasibility assessment, module architecture, preliminary technical solution, prototype development route, core component suggestions, preliminary cost assessment, risk checklist, development cycle suggestion, next-stage plan, and a basis for a development quotation. Each line exists because a specific reader needs it - a procurement file, a supply-chain check, a prototype test plan, a factory inspection standard later on.
For projects that need people as well as documents, the integrated engineering team services page lists the roles that consume this paperwork: mechanical, electrical, automation, test, manufacturing and project engineering support, allocated by project phase, with outputs running from the technical proposal and drawings to test plans, problem lists and acceptance data. A requirement document that names those roles as readers is usually the one that gets read.
What to hold the first review to
Before any stage fee is agreed, a short review of the written set answers most later arguments. Ask for the core, auxiliary and optional functions in one list; the systems in scope and the interfaces between them; the deferrals; an acceptance clause against every requirement line; and the risk rows with owners. The steam cleaning equipment testing page also answers a common question here: testing can start from a prototype without complete drawings, by first checking the actual machine and then building a plan - but the items that were never written down are exactly the items such a plan is likely to miss.
One caution on figures. Published product pages carry specifications for existing equipment, and those numbers belong to those machines. A new development should be quoted against the written requirement set and a signed assessment, not against a catalogue value lifted from a page.
