Hello! Welcome to the second module of our course.
In the first module, you built an excellent foundation in the "how" of CAD, learning to create parts, assemblies, and detailed drawings in Onshape. Now, we shift our focus to the "why." This module, "Engineering Workflow and System Design," is all about simulating the process and mindset of a professional design engineer. We'll move beyond just using the tools and start applying a systematic approach to solving engineering problems.
Today's lesson addresses the learning outcome: Write clear design requirements and specifications for a mechanical system. This is arguably the most critical step in the entire design process. Getting this right ensures that you solve the right problem and that your final design is successful. It's the engineering equivalent of building a strong foundation before erecting a building.
1. What Are Requirements and Why Do They Matter?
There's a well-known saying in engineering, often attributed to Albert Einstein: "Given one hour to save the world, I would spend 55 minutes defining the problem, and 5 minutes resolving it." While the attribution might be incorrect, the sentiment is spot on. Time spent understanding and quantifying the problem is more valuable than time spent solving the wrong one.
In engineering, requirements are how we define the problem. They are a formal way to record what a system needs to do and to establish the criteria for success.
To get a high-level overview of this concept, let's watch a short introductory video.
An Introduction to Requirements | Systems Engineering, Part 4
This video from MATLAB's Systems Engineering series provides an excellent introduction to requirements. It frames the 'problem definition' phase and breaks down what a requirement consists of.
Watch the first 2 minutes and 7 seconds (00:00 - 02:07). Focus on the three key components of a requirement: a description, a rationale, and a way to verify it.
As the video explains, every requirement should answer three questions:
- What does the system need to do? (The description)
- Why does it need to do it? (The rationale, which traces back to a customer or stakeholder need)
- How will we know it's done correctly? (The verification method)
Requirements can be broken down into different types. The same video explains some common categories using a simple toaster example.
An Introduction to Requirements | Systems Engineering, Part 4
Now let's look at the different types of requirements you'll encounter.
Continue watching from 02:07 to 03:57. Pay attention to the distinction between functional, performance, and constraint requirements.
To summarize the key types for a mechanical system:
- Functional Requirements: Define what the system does. Example: "The system shall convert rotational motion to linear motion."
- Performance Requirements: Define how well the system performs a function. These are quantifiable. Example: "The system shall move the load at a speed of 50 mm/s."
- Constraint Requirements: Define the boundaries and limitations of the design. Examples: "The total mass shall be less than 5 kg," or "The system must operate using a 24V power supply."
2. From Vague Ideas to Specific Requirements
In a professional setting, requirements aren't created in a vacuum. They are derived from a comprehensive understanding of the product's goals. This is often captured in a document called a Product Design Specification (PDS). A PDS is a broad document that captures everything from performance and safety to market positioning and manufacturing constraints.
This guide provides an excellent, detailed checklist of what goes into a PDS. It's a great illustration of the big-picture thinking required at the start of a project.
This document on the Product Design Specification (PDS) from Union College shows the breadth of information that informs a design. It's the source from which we'll derive our specific engineering requirements.
Skim through the first three main sections: 'A. Product design & performance issues', 'B. Market issues', and 'C. Capability issues'. You don't need to memorize the list, but appreciate the scope. This checklist is a powerful tool for ensuring you haven't missed a critical aspect of the design problem.
Once we have this big picture, our job as engineers is to distill it into a list of specific, actionable Engineering Requirements. The most important characteristic of a good engineering requirement is that it must be testable or verifiable. If you can't objectively test whether the requirement has been met, it's not a good requirement.
The following resource explains this distinction and provides a clear structure for writing effective requirements.
Engineering Requirements – Introduction to Mechanical ...
Now, let's focus on the art of writing a good engineering requirement. This resource from the University of Arkansas Pressbooks explains the key characteristics and provides a clear format to follow.
Read the sections 'Requirements versus Specifications', the part describing the elements of a properly formatted requirement, and the 'Example – Mechanical Pencil Requirement'. Focus on the core idea that an engineering requirement must be testable. Note the proposed structure: ID, subject, predicate, object, rationale, and verification method.
As the resource highlights, a requirement like "The pencil should be comfortable" is poorly written because "comfortable" is subjective and not verifiable. A good requirement is specific: "The mechanical pencil shall have a grip diameter of 10 mm."
Test your understanding!
A stakeholder for a new portable speaker says, "I want it to be easy to carry around and have a long battery life."
How would you translate this into at least two specific, testable engineering requirements using the structure discussed in the reading?
Show answer
Here are some possible answers. The key is that they are specific, measurable, and verifiable.
- REQ-M-01: The device mass shall be less than 1.5 kg.
- Rationale: To allow for easy transport in a backpack without significant user fatigue.
- Verification: Weigh the final assembly on a calibrated scale.
- REQ-P-01: The device shall play audio continuously at 75 dB SPL (Sound Pressure Level) for a minimum of 8 hours on a full charge.
- Rationale: To ensure the device can last a full workday or social event without needing to be recharged.
- Verification: Conduct a battery rundown test with the device playing a standardized audio signal at the specified volume, measuring the time until shutdown.
3. Structuring a Requirements Document
Individual requirements are useful, but their power comes from being collected and managed in a structured document. This document becomes the central source of truth for the design team, guiding all subsequent decisions, from calculations and CAD to testing and validation.
A requirements table is a common format. It organizes all the key information in one place, allowing for easy review and tracking.
This table format is exactly what we will use for our projects.
Application: Project 1 - Linear Motion System
Let's start applying this immediately. The first major project for your portfolio will be a Linear Motion System. Here is the high-level problem statement:
Design a small, desktop linear actuator to move a 1 kg payload horizontally over a distance of 200 mm. The system will be used for an automated camera slider for hobbyist product photography. It should complete a full traversal in under 5 seconds and be relatively compact.
Using this statement, let's draft the first few engineering requirements for our project.
| ID | Description | Value | Units | Importance | Verification |
|---|---|---|---|---|---|
| REQ-P-01 | The system shall support a horizontal payload. | ≥ 1 | kg | 1 (High) | Test with 1kg mass. |
| REQ-P-02 | The system shall provide a minimum travel distance. | ≥ 200 | mm | 1 (High) | Measure travel range. |
| REQ-P-03 | The system shall traverse the full range in the maximum time. | < 5 | s | 2 (Medium) | Timed test. |
| REQ-C-01 | The overall length of the system in its most compact state. | ≤ 400 | mm | 2 (Medium) | Measurement. |
| REQ-F-01 | The system shall provide smooth, continuous motion. | - | - | 1 (High) | Inspection, video. |
| REQ-C-02 | The system shall be powered by a common DC source. | 12 or 24 | V DC | 1 (High) | Analysis, inspection. |
Notice that REQ-F-01 is qualitative. While we strive for quantitative requirements, some, like "smooth motion," are initially defined qualitatively and later verified through inspection. We could make it more specific by setting limits on vibration or jerk, but for now, this is a good starting point.
This document will be our guide for the entire project. In the upcoming lessons, every design decision we make—from selecting a lead screw to designing a bracket—will trace back to meeting one or more of these requirements.
Conclusion
In this lesson, you've taken the first and most critical step in a professional engineering workflow. You've learned how to move from a vague idea to a set of clear, actionable targets that will guide your entire design process.
Here are the key takeaways:
- Define the problem first: A successful design starts with a deep understanding of the problem, captured in clear requirements.
- PDS vs. Engineering Requirements: A Product Design Specification (PDS) captures the broad product vision, while Engineering Requirements are the specific, testable, and quantifiable statements derived from it.
- A good requirement is unambiguous: It specifies a value, a unit, and a method for verification.
- Requirements drive design: The requirements document is the central "source of truth" that justifies your design decisions.
You've now drafted the initial requirements for our first portfolio project. In our next lesson, we will continue setting up our professional workflow by addressing the learning outcome: Organize project files and documentation for a professional engineering workflow. We'll create a structured project folder and see how documents like the PDS and requirements list fit into a well-managed design process.