A Personal Perspective on the Engineering Design Process and Design Qualification
By: Daniel N. Wilke
Tags: Engineering, Process, Design, Mechanical Engineering

This document is a personal reflection on the Engineering Design Process. An outline used to guide young engineers through the steps of the engineering design process and documentation. The engineering design process and documentation thereof is not unique, however, the process outlined is in my view sensible. The approach outlined is focused on ensuring that each step adds value. This ensures that the time spent in the design process is justifiable and sensible. In addition, it serves as a sanity check on the understanding of the process. When you find yourself doing something that is not clearly adding value to the design, then there is a either problem with understanding of the process or the process is flawed.

Hopefully this document enables you to document and communicate a technical engineering design sensibly. Hopefully one day it would enable you to register as a professional engineer after having accumulated sufficient practical engineering experience.

This document is aimed at finalists or young engineers that have had several engineering design courses, but struggled to assimilate the various aspects of the design process and documentation that is often covered over several years and between design courses. As a result, this document is void of examples, and rather focused on the primary and elementary concepts and principles of engineering design.

What is Engineering Design

Engineers actively change the world they live in by solving problems in their environment. As active changers of their environments they develop new products and processes or improve existing ones. The co-founder of the NASA Jet Propulsion Laboratory (JPL) epitomised this

Scientists study the world as it is, engineers create the world that never has been — Theodore von Karman¹.

Engineering design is a systematic process to identify suitable and sensible solutions from a set of feasible solutions. Formally, engineers would refer to these as an under-specified or under-determined class of problems. As a result, engineers distinguish between multiple feasible solutions based on additional criteria that often include cost, manufacturing, logistics, robustness and complexity.

Any sufficiently complex problem over a sufficiently large domain of designs is non-linear. Hence, engineering design is non-linear and requires iteration to solve. Iteration is therefore expected and inherently part of the engineering design process. However, iteration is expensive, in particular when you need to iterate between initial and final phases of the engineering design process. For example, after completing a design of a product or process and only then realising that a vital function or aspect was missed may require a complete redesign to resolve. This is any design engineers’ nightmare, and there are plenty of actual examples that reflect these mistakes. These include basic mistakes, such as commissioning a school’s bathroom for wheelchair-bound children that cannot close. Sadly, this was only discovered during the inauguration thereof. This resulted in a costly redesign, but thus should never have happened, and mistakes like these point to an inadequate design process.

To avoid such mistakes, engineers use an engineering design process to eliminate or limit extreme iterations between phases. The aim is to isolate iterations between consecutive phases. Hence, the engineering design process is a meaningful approach to systematically solve engineering problems in an iterative manner. Each step of the engineering design process has clear purpose and directed outcomes.

Design Process versus Design Documentation

The design process is inherently iterative, requiring iteration between the various steps of the design process. Ideally, iterations are kept between adjacent steps, but oversights sometimes result in iterations between components that are far apart in the design process. The latter ones are costly and a good design engineer eliminates them. To assist, a sensible design process should be followed. An Example of such a process is outlined in Fig 1 following a five-step process that include identifying and quantifying the need, exploring designs that are realised and documented.

Fig 1: Outlining the Engineering Design Process and Documentation

There is an inherent dilemma between the design process and documenting a design. The design process is inherently non-linear, but ideally we want to document the design such that it reads linearly, as far as possible. That is when reading a design report, it must make sense when reading the document from front to back.

Therefore, design documentation aims to coherently and linearly represent an inherently iterative process. This can be achieved in various ways. It is evident when considering the User Specification, Engineering Problem Statement, Functional Analysis and Literature Study. My personal preference for Identifying the Need is the User Specification, Problem Statement and Functional Analysis. This is followed by Quantifying the Need by considering the Impacts of Design and Literature Study. The primary role of the Literature Study is to quantify the need, explore potential concepts to resolve functions and resolve the known unknowns of the design, and hopefully uncover some unknown unknowns of the design in the process.

To ensure that the Design Document is sensible, it needs to serve two purposes. It has to be digestible for first time reading, in addition, it also needs to serve as a reference document that can easily be extended. It is important to keep in mind that the design document you are working will likely be extended by numerous engineers as part of a design team. Hence, the document needs to serve its purpose when the design needs to be completed, modified or extended.

This requires that you communicate the design process logically and with clarity such that it carries purpose and meaning. At any point in the design, you need to critically assess whether what you do or communicate adds value. Any step of the process or activity that does not add value to the design is a red flag that a step in the process is misinterpreted or the order of the steps are wrong.

1. Identify the need

1.1 User Requirements Specification (URS)

The User Requirement Specification (URS) describes the business needs that the user requires from the design. It is a vague, qualitative and often anecdotal description of the problem that outlines the requirements of the user. The URS is formulated in discussion with a client and should express its use and business context, i.e. once-off, mass production, high-end product or economic solution, financial constraints, budget, social, legal, health and safety and environmental considerations. Initial client meetings serve the purpose of formulating the URS.

For the documentation, each specification in the URS must be numbered so that it can be referenced in the later on in the document, in particular the Engineering Problem Statement.

1.2 Engineering Problem Statement (EPS)

The Engineering Problem Statement identifies, within a technical and engineering context, what is required to turn the URS into a complete Technical Design Specification. The Technical Design Specification requires each specification to be quantifiable (boxed within upper and lower bounds with defined units). It is a technical translation of the URS; hence each URS must be addressed in the EPS and referenced, i.e. it should be clear and explicit that the EPS addresses the URS.

First, clear context and scope of the design as agreed with the client must be given. A systematic breakdown of the problem follows. That is the primary aims of the design, what is involved in achieving those primary aims, what are the essential function(s) of the design, what are primary and dominant physics and engineering and design (strength vs stiffness vs hardness design), principles that may dictate the design, are there relevant design codes or regulations for the design, what are the inputs and outputs of the design, parameters that needs to be measured and controlled etc. must be clearly and purposefully communicated. Critical thinking is required to translate a URS into an EPS.

Depending on the design, some of these considerations will have clear answers from your engineering knowledge, while others will need to be investigated.

The aim of the EPS is to sensitise the designer to the what’s that need to be considered to end up with a complete Technical Design Specification. It is therefore critical that the EPS concludes with points that include the following (Principle/Specification (PS) — Understanding/Quantity (UQ)):

Known — Knowns: PS you know with associated UQ. Known — Unknowns: PS you know but need to identify the UQ and as you proceed with the design process you proceed are aware of the following. Unknown — Knowns: implicit or implied PS of which you know the UQ, but don’t consider as you are unaware that they are relevant and important. Unknown — Unknowns: PS and UQ are important for the design, but you don’t know.

The EPS requires critical thinking and iteration to formulate. As you iterate, Unknown — Unknowns will be uncovered and become Known-Knowns. I think it is more sensible if your EPS concludes with 1–4, where 1–4 reflects your first round formulating the EPS. 3–4 then serves to document what initially unknown-knowns and unknown-unknowns were uncovered following the design process. This serves the explicit purpose of informing the design engineers of potential pitfalls when they review the design report.

Hopefully, you see that the EPS is a technical way of thinking about the problem that identifies the primary aims and functions for the Functional Analysis (FA). Together the EPS and FA informs the literature study and gives clear goals and outcomes for the literature study. The EPS, when conducted properly, is, in my view, the most critical part of the design process, as a properly executed EPS avoids iterations between design steps at the extremes.

1.3 Functional Analysis (FA)

The Functional Analysis (FA) elaborates on the essential aim(s) or function(s) identified in the EPS. The FA identifies all the functions that need to be realised to address the functional aspects of the EPS Problem Statement.

A simple approach to construct a FA is to imagine using the product as a black box (without imagining a realisation of the product). This allows you to identify all functions over the life cycle (ideal case) or use cycle of the product. The FA only identifies the functions/sub-functions that needs to be realised, not how they could be realised.

It is critical to realise that the FA state the functions— there should be no components or reference to components made. Each function / sub-function needs to be numbered for referencing later-on in the Literature Study (LS) and Technical Design Specification (TDS).

2. Quantify the need

2.1 Impacts of the Design (ID)

It is critical to consider the social, legal, health, safety and environmental aspects of the design early on. This ensures that these considerations actually influence decision making of the design. It is important that engineers apply due diligence when considering the ID, and not merely comply to aspects as an afterthought. ID ensure that we design products that are sustainable and responsible. Hence, the ID should clearly dictate and quantify specifications in the TDS.

2.2 Literature Study (LS)

The literature study is not for leisure reading or a collection of interesting facts or titbits. The literature study is requires that a set of clearly defined tasks are executed, i.e. it requires reading with purpose. Before you start reading, you need to make sure you have a clear understanding of the outcome(s) that you want to achieve. These are informed by the what’s that have been identified in the EPS and FA.

The literature study needs to start by identifying and grouping clear goals that needs to be achieved, referenced from the EPS (known-unknowns, unknown-unknowns and known-unknowns) and FA. If the EPS and FA cannot be sensibly grouped, they merely reflect the PS or function from the EPS and FA that need to be quantified.

A compact and sensible LS starts by clearly listing each Literature Study Goal (LSG) (with its own unique reference number) with references to the EPS and FA, a reference to the Section Number under Literature Study where it is discussed, a Quick Summary of the Findings & Value Ranges that was obtained, and a Reference List for the Sources. A table is often well suited to communicate this. This allows a reader to look at the table and see a complete summary of the entire literature study upfront. The reader can then go to the relevant sections to see the details and reasoning behind your findings. In addition, the table with item numbers can be referenced as required in the report. This also quickly guides you to identify what is relevant and what is irrelevant to share with the reader.

This allows a hasty reader/future referencing of the report to be purposeful and efficient, i.e. the purpose and outcome of the literature study is presented upfront, without requiring a lengthy search and read through the section to see the outcome.

2.3 Technical Design Specification (TDS)

The Technical Design Specification (TDS) is the combined and compact version of the PS, FA, and LS. Each specification is quantified with ranges, not single numbers but ranges with explicit lower and upper bounds with relevant units. The TDS follows from the PS, FA and LS and should not include any new specifications not discussed before. Each TDS should be clearly referenced from the PS, FA and LS. The priority for each TDS can be communicated here with a clear motivation, or it can be done during the CS stage.

TDS includes All Functions with quantified performance indicators as well as quantified financial constraints. All items listed in the TDS must be measurable i.e. quantified by some quantifiable measure.

3. Design exploration

All functions in the TDS must be addressed by Concept Generation (CG) (either modular or combined) or standard by components selection.

3.1 Concept Generation (CG)

A concept always aims to fulfil the functional aspects of the TDS. A single concept generation can aim to fulfill one function or multiple functions at a time, when they can be sensibly lumped into a single concept. Hence, the TDS that each CG phase addresses need to be clear and referenced. These TDS aim to address the need to form the criteria for concept selection during the concept selection phase.

Each concept must be accompanied by a hand sketch that clearly illustrates how the concept will address all the functions it aims to address. The hand sketch can be annotated for clarity. The sketch must be referenced in the text and discussed in sufficient detail to assist the reader. This is essential should the drawing have failed at communicating the concept with clarity.

Each concept, an abstraction/generalisation, must be distinct to achieve the intended functional outcomes. A different concept requires a different conceptual approach (distinct abstraction / general notions) to fulfil the function specified in the TDS.

The selected concept sets the potential for your design — a good final design requires a good concept and a good realisation of the concept during the detail design. In turn, the are many ways to achieve a poor final design, which can be achieved by having a good concept that is poorly realised, a poor concept that is properly realised, and of course a poor concept that is poorly realised.

3.1 Concept Selection (CS)

Concept Selection (CS) must be based on criteria that are motivated from the TDS with clear referencing from the TDS. The importance of each criterion must be given and motivated. A quick discussion on the CS approach needs to be outlined, i.e. whether an absolute comparison or relative comparison between concepts will be conducted etc. The scores for each concept and criteria should be clearly listed and the final concept clearly identified.

Functional aspects of the TDS that have not been addressed by the CG and CS should be selected from standard components and clearly communicated.

The CG & CS phase should confirm that all functional aspects of the TDS have been addressed.

4. Design realisation

To ease communication a detailed concept drawing (CAD) of the design that incorporates all selections from CS is important so that all components in the design for which detailed calculations will be performed can be clearly identified. This concept drawing should be discussed in sufficient detail that the design’s entire functioning is completely understood.

Several design paradigms exist to formalise aspects of the design realisation which include Optimum and Robust Design.

Optimum Design formalises under-specified problems to distinguish between

feasible and infeasible solutions, and to find the best feasible solution given some quantifiable objectives.

Robust Design aims to reduce product variation by reducing the sensitivity of the designed product to variations in the design, manufacturing or environment.

4.1 Detail Design

The detail design should contain an overview section that states all the required calculations that needs to be conducted for the design. These calculations can be structured into appropriate hierarchies with a sensible level of detail as to give a holistic and clear overview that can be referenced. A tabulated version is often convenient as it allows for the outcomes, implications, hours and cost of the completed calculations to be summarised. In addition, when the document is given to another engineer, they can effortlessly identify outstanding calculations.

Note an overview of the calculations allows for the critical assessment of relevant calculations. Calculations can easily be added or removed to allow for a flexible design cycle.

Calculations have to be documented with absolute clarity to ensure that the review engineers can conduct a critical assessment and find mistakes.

Sensible guidelines for calculations are

clearly indicate the component in the concept drawing, followed by its mathematical abstraction, i.e. the component isolated from the rest of the design with boundary conditions, loadings, material and anticipated calculations etc. with motivation, all values used must be listed with clear motivation and appropriate references, before commencing the calculation, a motivated sanity check, typically an order of magnitude estimate, must be given. These are usually from a quick hand calculation or motivated from relevant LS, once the answer is obtained, it must be interpreted, and reflected against an order of magnitude estimate, followed by clear conclusions drawn that highlight the implications of the calculation.

Note that the reflection and feedback cycle is critical for practical engineering design. It reduces negligent mistakes and build appropriate confidence, which is vital for effective engineering.

Given limited time it is sensible to focus on the critical calculations. These need to be identified prioritised in terms of achieving the functionality of the design, i.e. calculations that address the most important and/or majority of the technical specifications, or calculations that are sequential with significant implications downstream.

The completed calculations should be clearly indicated and summarised in the overview calculation table.

4.2 Drawings

The drawing requirements should follow standard graphical communication practices and include the relevant materials, surface finish, tolerances and fit symbols. Detailed hand drawings are done freehand and serve the purpose of efficient and clear communication, often required on-demand in engineering practice.

4.3 Manufacturing & Costing

A complete costing and manufacturing schedule needs to be included for each detailed CAD component. It is important to ensure that the costing is aligned with the business context outlined in the URS.

5. Documentation

5.1 Design Qualification (DQ)

The design, as reflected in the report, must be assessed against the TDS. The specifications from the TDS that have been met must be clearly distinguished from those that have not been met; usually, a table is a convenient communication tool for this purpose.

This table should be followed by suggestions on how to meet outstanding specifications in the TDS. This explicitly communicates insights and inputs of the current designer/engineer for the guidance and input of the next designer/engineer. The follow-up engineer can therefore effortlessly focus and directed his/her attention on the crucial aspects of the design.