Defining Project Scope

1. From Intent to Scope: Defining Your Project's Boundaries

Before you start designing, it's critical to establish clear boundaries. A project scope statement serves as a contract for the project, defining what you will do and, just as importantly, what you will not do. This prevents "scope creep"—the tendency for a project's objectives to expand over time—which is a major risk in any engineering endeavor.

A comprehensive scope includes three key parts:

1. Justification: Why is this project being done? (You've already started this with your Project Intent).
2. Scope Statement: A summary of what will be delivered.
3. Focus (In vs. Out): A clear list of what is included and excluded.

For your independent project, being explicit about what's "out of scope" is essential. For example, if you're designing a mechanical system, you might state that the detailed electronic circuit design, firmware programming, or marketing analysis are out of scope. This keeps your efforts focused on the mechanical engineering aspects that will build your portfolio.

2. Defining Engineering Requirements: The "What," Not the "How"

With the overall scope defined, the next step is to detail the specific requirements. Requirements are formal statements that quantify the problem, describe what needs to be designed, and define how success will be measured. In professional settings, this is the most critical part of the process, as all subsequent design, analysis, and testing work traces back to these statements.

A well-written requirement has three parts: a description, a rationale, and a verification method.

As the video explains, there are several key types of requirements relevant to your mechanical project:

• Functional Requirements: Define what the system must do.
  • Example: "The system shall lift a standard 1-liter water bottle."
• Performance Requirements: Define how well the system must perform a function. These must be quantifiable.
  • Example: "The system shall lift a 1kg mass vertically by 300mm in less than 5 seconds."
• Constraints: Define the boundaries and limitations the design must adhere to.
  • Example: "The total mass of the system shall not exceed 2.5 kg."
  • Example: "The design must be manufacturable using 3-axis CNC machining and standard fasteners."

A common pitfall is to write requirements that are vague or define the solution. For instance, stating "The device must be strong" is a poor requirement because "strong" is subjective. A better version is, "The main support bracket must withstand a 50 N static load at its tip with a factor of safety of at least 3.0." This is specific, measurable, and verifiable through FEA.

3. Creating the Product Requirements Document (PRD)

All of this information—scope, requirements, constraints, and deliverables—is compiled into a single document: the Product Requirements Document (PRD). For a hardware project, the PRD is the single source of truth that guides the entire engineering effort.

Another excellent resource, the "Guide to HW Product Requirements Documents (PRDs)" from the Building Hardware newsletter, reinforces that hardware PRDs are comprehensive and should be "locked" before development begins, given the cost of physical changes. It also provides a great example structure that breaks down requirements into subsystems, which is highly relevant for a mechanical project.

For your project, we will create a simplified but professional PRD. Here is a template you can use, combining best practices from the resources.

Your Project's PRD Template

1. Product Name: [Give your project a working title]
2. Version: 1.0
3. Overview & Purpose: [Expand on your 'Project Intent' from the last lesson. Describe the product, who it's for, and the core problem it solves.]
4. Key Deliverables: [What will you produce for your portfolio?]
   • Product Requirements Document (this document)
   • OnShape 3D Models (Parts, Assembly)
   • FEA Report for Critical Components
   • Assembly & Detailed Part Drawings with GD&T
   • Final Design Review Presentation
5. Scope Definition:
   • In Scope: [List what the project covers. e.g., 'Mechanical design of the XYZ mechanism', 'Structural analysis of the main bracket', 'Material selection'.]
   • Out of Scope: [List what you are explicitly not doing. e.g., 'Electrical/control system design', 'Firmware development', 'Cost analysis beyond BOM'.]
6. Functional & Performance Requirements: [This is the most important section. List at least 5-10 specific, measurable, and verifiable requirements.]
   • REQ-001: [Requirement Description]
   • REQ-002: [Requirement Description]
   • ...
7. Design & Manufacturing Constraints: [List the key limitations guiding your design.]
   • Physical: (e.g., Max weight < X kg, Overall dimensions must fit in a Y x Y x Y volume)
   • Manufacturing: (e.g., Parts must be manufacturable via 3-axis CNC and/or 3D printing; Use of standard off-the-shelf fasteners)
   • Project: (e.g., To be completed within the course timeframe)

Below is an example of what a professional list of deliverables looks like. Your list will be a subset of this, focused on the digital design and analysis process.

Your Task: Draft the PRD for Your Project (30 minutes)

Now it's your turn. Using the template above, create the first draft of the PRD for the project you selected in the previous lesson.

1. Create a new document (you can use a simple text editor, Google Docs, or any tool you prefer).
2. Copy the PRD template into your document.
3. Fill out each section based on your project idea.
   • For the Overview, refine your "Project Intent" statement.
   • For Requirements, be as specific and quantitative as possible. Think about loads, speeds, dimensions, temperatures, and factors of safety. This is where you translate a qualitative problem into a quantitative engineering challenge.
   • For Constraints, think realistically about what you can achieve in this digital-only project.

This document will be the guiding star for the rest of your project. Take your time to think through these requirements carefully.

Conclusion

Congratulations on formalizing your project! By defining the scope, requirements, constraints, and deliverables, you have moved from a vague idea to a concrete engineering specification. This PRD is not just an academic exercise; it is the foundational document that ensures a project is well-defined, executable, and successful.

Key Takeaways:

• A Project Scope Statement defines the boundaries of your work, preventing scope creep.
• Requirements must be specific, measurable, achievable, relevant, and time-bound (SMART). They define what the system must do, not how.
• A Product Requirements Document (PRD) is the single source of truth for a hardware project, aligning all engineering efforts.
• Defining requirements upfront is a critical risk-mitigation activity that is standard practice in all professional engineering organizations.

Preview of the Next Lesson:
Now that you have a clear definition of what your product must achieve, the next logical step is to explore how you might achieve it. In our next lesson, you will brainstorm and sketch multiple conceptual solutions to the defined problem, kicking off the creative phase of the design process.