48610 Chap.5 The Engineering Design Process and Requirements
The Engineering Design Process and Requirements
Week 4 changes what the subject asks of you. Until here you have been learning representations; now you must decide what object to make and be able to justify it.
The tutorial guide is candid that product development normally takes a subject of its own, so what you get is a simplified four phase process: analyse the engineering problem by studying its requirements and splitting it into sub problems, develop and structure alternative solutions, assess and select among them, then refine and implement.
The guide notes that the middle two phases iterate, running from rough ideas through more detailed concepts and hand drawings to computer models, sometimes with simple prototypes built purely to find out whether a partial solution works.
Two tools come out of the first phase.
A requirement list records each requirement with its value and direction, whether minimum, exact, maximum or a range, plus a unit, the person responsible, the source it came from, and the method by which its fulfilment will be tested. Requirements are never deleted when they change: they are struck through and re-entered under the name of whoever made the change.
A function structure splits the task by what has to happen rather than by what parts exist, stating the main function as a verb acting on an object and deriving the sub functions needed to realise it. The prototyping project publishes five sub functions and deliberately declines to name any sub assembly modules, on the grounds that doing so would constrain your design.
What this chapter covers
- 01
The four phase process and where iteration actually happens
- 02
Project planning: tasks in sequence, owners, milestones and deadlines
- 03
Why the plan reveals dependencies rather than dates
- 04
Requirement analysis as the test of quality: neither under nor over performing
- 05
Requirement list columns and the minimum, exact and maximum distinction
- 06
Traceability through the source and owner columns
- 07
Crossing out rather than deleting a changed requirement
- 08
Qualitative requirements that cannot be given a unit
- 09
Testing a requirement at concept, model and prototype stages
- 10
Main functions and sub functions stated as verb, object and context
- 11
The five sub functions published for the prototyping project
Six requirement rows for a bench top can crusher
- +1Operating force, maximum 120 N. The direction is a maximum because anything above it excludes users. Source: the club's own trial with the weakest volunteer, which is a measurement rather than an assumption. Test at concept stage with a moment calculation on the lever and at prototype stage with a spring scale on the handle.
- +1Crushed thickness, maximum 25 mm, sourced from the bin capacity reason the club gave; test by crushing five cans and measuring each with a calliper. Bench thickness, exactly 38 mm, because the clamp has to fit that bench; recording it as exact rather than as a maximum is the honest description.
- +1Mass, maximum 8 kg. The club gave a reason but no number, so the 8 kg is our engineering judgement and the source column must say so rather than implying the club stated it. Test with a scale.
- +1Disassembly for cleaning, qualitative, so the exact value column carries a plain yes and the requirement text defines what disassembly means. Cost of materials, maximum 60 dollars, which the club never mentioned at all, which is precisely why writing it down makes it visible and arguable.
Key terms
- Requirement list
- A structured table of requirements, each with a value and direction, a unit, a responsible person, a source and a test method. It is the record of what the design must achieve and why.
- Main function
- A statement of what a product must do, written as a verb acting on an object with context if needed. It describes the purpose of the whole system without naming any component.
- Sub function
- One of the actions necessary to realise the main function, also written as a verb acting on an object. Splitting by sub function rather than by part keeps alternative solutions open.
- Traceability
- The property of a requirement list that lets you trace every entry back to where it came from, so that a later decision to relax a requirement can be judged against its origin.
- Gantt chart
- A project schedule laying tasks out in sequence against time, with the responsible team member named against each and milestones and deadlines highlighted.
- Milestone
- A fixed point in a project plan at which a deliverable is due, such as the live conceptual design session, as distinct from a task, which occupies a span of time.
- Over performing
- Exceeding a requirement in a way nobody asked for, which costs mass, material or margin. The guide treats it as a quality failure in the same way as under performing.
The Engineering Design Process and Requirements FAQ
Why run a process when the group already has an idea?
Because the conceptual design task marks the reasoning rather than the idea. Its deliverables are a project plan with roles, a systematic requirement list with sources and test methods, a morphological table with at least five sub functions and at least five partial solutions each, a pro and con selection, three fully described configurations and a scoring matrix.
A group that jumps straight to its favourite concept has nothing to submit for most of those, whatever the concept turns out to be worth.
What does it mean that a product can over perform?
It means exceeding a requirement in a way that costs something and buys nothing. A device asked to throw three to four metres that reaches twelve is not impressive; it has spent mass, material and probably safety margin on capability nobody requested, and it may now fail an adjustability requirement because it cannot be turned down.
The guide defines sufficient quality as neither under performing nor over performing, and the requirement list is what lets you tell the difference.
Why must a changed requirement stay visible on the list?
Because the list is a record of decisions rather than a snapshot of the current design. A silently edited list cannot tell you whether a value was always 400 grams or whether somebody relaxed it when the prototype failed, so the reasoning behind the change is lost. The convention is to cross out the outdated row, leave it in place, and add a new row with the updated value and the name of whoever changed it.
How do I test a requirement before anything is built?
With a calculation. The guide asks for an initial rough evaluation already during the conceptual design phase, and in practice each requirement gets tested three times with three different instruments: at concept stage by a rough calculation such as a moment or an energy estimate, at model stage using the modeller's own evaluation of mass and dimensions, and at prototype stage by a physical measurement.
Filling the test column properly in Week 4 turns the report's requirement testing section into transcription later.
Assessment move
Do the Week 4 tools on your own project rather than on the worked example, in the tutorial, while a tutor is in the room. Build the requirement list in a spreadsheet from the start, with the columns as given, and put a name in the owner column for every row even when the whole group agreed it.
Write the function structure before anyone sketches anything, and check it by looking for nouns: if a sub function names a part, rewrite it as an action. Keep the schedule in the same file, and put the workshop induction and the materials purchase on it as tasks with owners, because both have lead times that only become visible when they stop you.
Working through The Engineering Design Process and Requirements in 48610? Sia is AskSia’s AI Engineering tutor — ask any 48610 The Engineering Design Process and Requirements question and get a clear, step-by-step explanation grounded in how 48610 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
