ENGR10006 Chap.2 Design Decisions, Feasibility and Modelling
Design Decisions, Feasibility and Modelling
Every design process generates alternatives but ships one. This chapter covers how Lecture 4 frames that choice: assessing technical feasibility first, then evaluating options against economic criteria such as net present value and payback period and against environmental, social, institutional and reliability criteria, with safety throughout.
It compares the seven methods teams use to reach decisions, from authority without discussion to consensus, and the review questions that follow a decision. From Lecture 6 it adds the vocabulary of design parameters, design variables and constraints, and the role of physical and virtual prototypes in iteration, alongside the idea that a model is an approximation good enough for an engineering decision.
A worked example classifies the parameters of a real flooding plan, and practice items ask you to choose a decision method for a robot strategy dispute.
What this chapter covers
- 01
Technical feasibility and the laws of nature
- 02
Economic evaluation tools
- 03
Non-economic evaluation criteria
- 04
Seven decision methods in teams
- 05
Reviewing a decision after it is made
- 06
Design parameters, variables and constraints
- 07
Model fidelity and approximation
Worked example · free
Classifying parameters for a coastal flooding plan
- +1The 300-bag limit has been fixed, so it is a constraint; it belongs to the economic or institutional group because it reflects the resources available.
- +1Wall height is still a design variable that the team can trade against wall length within the bag limit.
- +1Keeping the main road clear is a constraint set by the client and falls in the social group, since it protects access and evacuation.
Key terms
- Design parameter
- A physical property whose value determines the form and behaviour of a design.
- Decision by consensus
- A team decision that every member supports after discussion.
- Decision by expert
- A team decision delegated to the member with the most relevant knowledge.
- Payback period
- The time a project takes to recover its initial cost, one of the economic tools named in lectures.
- System reliability
- An evaluation criterion rated on project integrity and system redundancy.
- Prototype
- A first or preliminary version, physical or virtual, used to gather data for the next iteration.
- Model fidelity
- How closely a model's behaviour matches the physical realisation it represents.
Design Decisions, Feasibility and Modelling FAQ
What is the difference between a design variable and a constraint?
A variable is a parameter the team can still choose, such as an enclosure depth. Once its value is fixed, for example by committing to one MDF sheet, it becomes a constraint that limits every later choice. The same quantity can move between the two during a semester.
Which decision method should our team use?
The lecture lists seven methods without ranking them. Quick, reversible choices can go to one member with authority, while choices that change the whole design, such as how many objects the robot collects per pass, deserve discussion and either expert input or consensus.
Do evaluation criteria matter if our project is clearly feasible?
Yes. Feasibility answers whether something can be done; evaluation answers whether it should be done and which option is best. Writing down the criterion that separated two options is what turns a design choice into analysis in the report.
What does model fidelity mean here?
It is how well a model predicts the real system. Lecture 4 notes that physical laws are often only part of a model, and that a scientist sees the model as flawed while an engineer sees the realisation as flawed, so state assumptions and test the prediction.
Assessment move
Build a two-column page for your own project. In the left column list every parameter you can think of, from dimensions and thresholds to schedules; in the right column mark whether it is still a variable or already a constraint, with the date it was fixed. Revisit the list after each milestone.
Next, take one real decision your team made and rewrite it in four lines: the options, the evaluation criterion that separated them, the decision method used, and the evidence from a test or prototype. Practise naming the seven decision methods by their two features, whether the group discusses and who carries the call, rather than memorising the order.
For feasibility questions, answer can-it-be-done with physics or technology and should-it-be-done with at least one economic and one non-economic criterion. Bring these habits into the report method section, where the rubric asks how the team organised its work and justified its design choices.
When you revise, test yourself by explaining one decision from another stream in the same four lines; if the structure works there too, you have learned the method rather than the example. Keep the variable-and-constraint list in the team folder so every member works from the same version.
