Engineering Design Lifecycle: From Requirements to Testing

Learning from Major Failures

• • • • • • Chernobyl Nuclear Disaster (1986) The 4th reactor at the Chernobyl Plant in Ukraine exploded during a safety test, releasing massive radiation. Design shortcomings — an unstable reactor core and lack of a robust containment structure — combined with operator errors under ambiguous test protocols. Over 336,000 people were displaced; 56 died within weeks; and thyroid cancer surged among exposed children.
          • Concorde Paris Crash (2000) Shortly after takeoff, Concorde Air France Flight 4590 ran over metal debris on the runway, tearing a tire that ruptured a fuel tank. The ensuing fire caused both engines on one wing to fail. The supersonic airliner crashed into a hotel, killing 113 people and grounding the fleet for 15 months, signaling the end of commercial supersonic travel.
          • Space Shuttle Challenger Explosion (1986) An O-ring seal in one of Challenger’s solid rocket boosters failed in unusually cold launch-day temperatures. The compressed rubber lost elasticity, allowing hot gases to breach the joint and ignite the external fuel tank. Seventy-three seconds into flight, the vehicle disintegrated, killing all seven crew members.
          • Hyatt Regency Skywalk Collapse (1981) Two suspended walkways at the Kansas City Hyatt Regency hotel gave way under the weight of roughly 2,000 people gathered during a dance. A last-minute design change doubled the load on a single support rod, which failed, causing 114 fatalities and nearly 200 injuries.
          • Space Shuttle Columbia Tragedy (2003) Foam insulation from Columbia’s external tank broke off during launch and struck the orbiter’s left wing. The puncture went undetected, and upon reentry, superheated gases entered the wing structure, leading to the vehicle’s breakup and the death of seven astronauts.

  .

Chernobyl Nuclear Disaster

Root Causes of Design Breakdowns

• • • • • • Unrealistic or exaggerated assumptions about operating conditions
          • Inadequate understanding of the core problem’s complexity
          • Improperly defined design parameters or constraints
          • Manufacturing and assembly defects that compromise component integrity
          • Errors in calculations, often under tight schedules
          • Insufficient prototyping, experimentation, and data collection
          • Technical drawings that omit critical details or contain inaccuracies
          • Flawed reasoning processes despite correct initial assumptions

  .

The Systems Engineering Perspective

fundamentals of Systems Engineering. Nasa Systems Engineering Handbook. Sp-2016-6105 Rev2

A Five-Stage Framework for Design Problem-Solving

1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. 1. Problem Definition
                                 2. Data Gathering
                                 3. Option Generation
                                 4. Solution Evaluation
                                 5. Validation and Implementation

   .

1. Understand the problem. This defines the issue.

• Understand and explain the main need. Make sure it is clear.
• Write a short, clear statement about the problem.
• Set clear goals for success. Define what is in and out of scope.

1. 1. 1. 2. Data Gathering

• These are scientific and industry reference books.
• You can use online technical databases and digital libraries.
• We have academic journals and conference papers.
• There are also trustworthy internet resources available.

1. This is about Option Generation.

• Be curious and comfortable with unclear situations. You should not fear the unknown.
• Be open to new experiences and different viewpoints. Embrace new ideas.
• Be ready to take smart, thought-out risks. Do not be afraid to try new things.
• Pay close attention to small details. Also, understand the bigger picture. See how everything connects.
• Be persistent and confident. Actively look for problems to solve. Be proactive.

1. 1. 1. 4. We evaluate the solution.

• We compare different options carefully. We use engineering principles for this.
• We use tools to help us decide. Examples include Pugh matrices and cost-benefit analyses.
• Experienced people are involved. End users are included when possible.
• We write down why we chose a certain option. This is our documented reason.

1. This is about validation and implementation.

• Prototyping involves building working models. These models verify performance in real-world settings. For example, wind-tunnel tests check aircraft parts. It confirms they work as expected.
• Concurrent engineering combines design and production tasks. These tasks run at the same time. This helps find problems early. It also speeds up how fast products get to market.
• Detailed documentation means creating full technical reports. These reports help others understand the design. They also allow others to copy or make the design again.
• Intellectual property management involves filing patents. Patents secure exclusive rights for a design. In return, the design must be fully disclosed to the public.
• Testing and verification mean doing repeated trials. These trials happen at every step. They find and fix flaws. This happens before a product goes into mass production.

The Iterative Nature of Design

Conclusion

Engineering Design Process Stages

Frequently asked questions

What is engineering design?

What are the stages of the engineering design process?

Is the engineering design process linear?

Why is collaboration important in engineering design?

Sources and standards

• Industrial Designers Society of America is a professional group. It serves industrial design in the US. This society helps design practice.
• Nielsen Norman Group conducts usability research. They use proven usability facts. These facts apply to how people interact with products.
• USPTO offers patent basics. This is official guidance. It covers filings for new products, both provisional and non-provisional.

Verification and validation are not the same activity

Building a traceable test plan

• Every requirement has an ID. It also has an acceptance rule and a way to check it. This check can be a test, analysis, inspection, or demonstration.
• Before testing, each method names the sample size. It also states the conditions and the passing rule.
• Results connect to the requirement ID. This shows any gaps in coverage. These gaps are seen right away, not found later during an audit.
• If something fails, it creates a change record. This change then causes a retest. All things it might affect are retested.
• Verification uses parts intended for production. These parts are made by the actual production process. It does not use prototypes.
• Validation involves real users. They perform real tasks. No engineer stands next to them during this process.

Typical test costs and durations

Where V&v Programs Go Wrong

• We tested prototypes. These were not production parts. So, the results did not transfer.
• The design changed during testing. We did not retest affected requirements. This was a problem.
• Requirements lacked measurable acceptance criteria. So, it was hard to say what passed or failed.
• Tests used a sample size of one. But variation was the main question for these tests.
• We skipped pre-compliance testing. This led to finding an EMC problem late. The schedule had no room for fixes.
• There was no validation at all. The product was checked against a spec. But users never checked the spec.

V&v Readiness Checklist

• All requirements are numbered and measurable. Each requirement has a specific verification method assigned.
• The test plan is reviewed and approved. This happens before any samples are built.
• Samples should reflect final production. They come from production tooling and processes when possible.
• EMC and safety pre-compliance is completed. This occurs before booking full certification slots.
• A change control process is active. The retest impact is assessed for every change made.
• Validation sessions are scheduled with real users. These happen in their actual environment before production release.