ENGGEN 115 Chap.1 Engineering Design Process
Engineering Design Process
Engineering design in ENGGEN 115 is an iterative evidence chain. Stakeholder investigation and context research inform a problem specification; ideation creates alternatives; explicit criteria support selection; analysis and prototypes test uncertain claims; and results send the team back to revise requirements or concepts. The exam skill is not reciting phase names.
It is applying each phase to a scenario, separating needs from solutions, and explaining how one output changes the next decision. Professional practice also requires attention to service environment, life cycle, safety, sustainability, ethics, teamwork and communication.
These concerns change who counts as a stakeholder, which constraints are legitimate, how evidence is collected and which trade-offs remain visible in the final recommendation.
What this chapter covers
- 01
Stakeholder influence and interest
- 02
Research methods and evidence
- 03
Requirements and constraints
- 04
Problem specification structure
- 05
Iteration and decision traceability
- 06
Life-cycle and service context
Worked example · free
Frame a stream-sampling support
- +1Identify the field technician and environmental custodian as stakeholders whose needs and controls shape the brief.
- +1State that one person must be able to transport the complete system; this is a user requirement without a prescribed frame.
- +1Require stable bottle support on the expected uneven bank surface, leaving the numerical acceptance limit open until evidence is available.
- +1Add a constraint that no anchoring or loose component may remain in or beside the water after removal.
- +1Require tool-free or explicitly bounded assembly because the operating context may limit equipment and time.
- +1Research the range of bank slopes and surface conditions through observation before selecting a base geometry.
Key terms
- Stakeholder map
- A representation of parties organised by their influence on and interest in the project.
- User requirement
- A statement of what a user must be able to achieve or experience with the design.
- System requirement
- A functional or performance condition that the complete engineered system must satisfy.
- Service environment
- The physical, social and operational conditions in which the design is expected to work.
- Iteration
- A deliberate revision made after new evidence changes the understanding of the problem or solution.
Engineering Design Process FAQ
What is the difference between a requirement and a concept?
A requirement defines an outcome, boundary or performance expectation that success must satisfy. A concept proposes one possible mechanism or arrangement for achieving it. Keeping them separate prevents a favourite solution from narrowing the problem too early and lets several alternatives be compared against the same evidence-led specification.
How do I choose a stakeholder research method?
Start with the uncertainty you need to resolve. Interviews reveal motives, explanations and priorities; observation reveals actual behaviour and workarounds; document review exposes formal constraints and prior evidence; participatory methods let users shape alternatives. Justify the method by the information it can produce, not by convenience.
How is iteration shown in an answer?
Name the result that changes a decision. A prototype may reveal poor access, an equation may predict excessive deflection, or stakeholder feedback may expose a missing requirement. Then state which specification line, concept feature or verification plan should change. That causal link distinguishes iteration from repeating an activity.
How should constraints be written?
State the boundary, its origin and its consequence for the design space. A doorway dimension, prohibited material, service condition or fixed interface can exclude otherwise attractive concepts. Avoid presenting preferences as constraints. Where evidence is qualitative, preserve that uncertainty instead of inventing a precise limit that the brief does not support.
What makes a problem statement useful?
A useful statement identifies the affected people, context, undesirable current condition and outcome sought without embedding a preferred mechanism. It is narrow enough to guide research but broad enough to permit several concepts. Test it by asking whether two structurally different solutions could still respond to the same statement.
Exam move
Take short everyday briefs and practise a strict sequence: stakeholders, evidence gaps, requirements, constraints, three concepts, one selection question and one verification question. Underline solution words that appear before ideation and rewrite them as outcomes. For each later test result, identify the exact earlier decision it could revise. This develops scenario application rather than memorised phase lists.
Build a traceability strip across one page with arrows from evidence to specification, concept, analysis and test. Deliberately introduce a new stakeholder observation and revise every affected item. Compare interview, observation, document review and participatory methods for the same uncertainty, explaining what each could and could not establish.
Under timed conditions, spend the first minute extracting scenario facts before writing process language; this prevents generic answers from outrunning the brief. Once a week, review one completed case from the final decision backward. If a conclusion cannot reach a stated requirement and stakeholder need through visible evidence, repair the missing link before adding another concept.
Finish by naming the most consequential unknown and the cheapest credible way to investigate it. Keep that unknown visible when planning the next iteration. Distinguish evidence already collected from assumptions still requiring investigation.