What are the essentials of a good PRD (product requirements document) for a new mechanical device

Question

I need to write a non technical product requirements document for a new machine that I want designed.

I need to write a PRD, and I need to ensure that I have included all the salient information, whilst keeping it brief, focused and to the point.

I have searched online for template PRDs but all of the documents I have come across, assume that the product is software and so do not fit the needs of a PRD for a mechanical device.

Can someone outline here, the structure and sections required for a PRD for a mechanical device (e.g. an engine), failing that, a link to such a document would suffice.

Answer 1

Before we start, just a word of caution that an engine is not only a mechanical device, they come with their own controllers (FADECs), and most of the time they have to integrate with some software (even when they operate through a throttle servo).

Alright, I'll suggest two methodologies, both of them are applicable to many scenarios.

1. The Flexible Way
2. The Well-Specified Way

I've personally gone through both methodologies in aerospace and defense projects.

Flexible way can be used when you don't know the specifics of what you are doing, e.g. you want to outsource the expertise of designing and integration of the subsystem. You can do this when you have good business partnerships with the subcontractor (who will develop and supply the Product). Several of the specifications of the design will eventually change during the project. Specifications may change because of the bigger system or because of the Product itself.

In Flexible way, the Work Description can be more important than the Technical Specifications (=PRD, as you call it). So it's two documents you have to consider:

1. Work Description: HOW will they develop the PRODUCT (including how will they interact with you)
2. Technical Specifications: WHAT will the PRODUCT do, or What properties will it have.

For the flexible way, writing a brief document will suffice. Key Performance Parameters, and Key Characteristics/Properties could be sufficient. So the structure of the document can be as follows:

1. General Specifications
2. Performance Requirements
3. SubPart-A Requirements (Assume that you know the main part breakdown of the Product)
4. SubPart-B Requirements
5. Interface/Integration Requirements
6. Other Requirements
7. Appendix (e.g. CAD data for interface, technical drawings, draft interface control document, etc.)

The Well-Specified way is used when the Product to be developed is so important that you cannot risk changing the specifications on the road. It can be a mission critical subsystem or a performance critical item. For sake of completeness I'll refer you to the Defense Acquisition template. ref

Structure of a System Technical Specification document is as follows:

• 1. Scope/Introduction 8
• 1.1. System or Subsystem Identification 8
• 1.2. System or Subsystem Overview 8
• 1.3. Document Overview 8
• 2. Applicable Documents 8
• 2.1. General 8
• 2.2. Government Documentation 9
• 2.2.1. Government Specifications, Standards, and Handbooks 9
• 2.2.2. Other Government Documents, Drawings, and Publications 9
• 2.3. Non-Government Publications 9
• 2.4. Order of Precedence 10
• 3. System or Subsystem Requirements 10
• 3.1. Required States and Modes 11
• 3.2. System of Subsystem Functional Requirements 11
• 3.2.1. System or Subsystem Function 11
• 3.3. System External Interface Requirements 11
• 3.3.1. Interface Identification and and Diagrams 11
• 3.3.2. Project Unique Identifier of Interface 12
• 3.4. System Internal Interface Requirements 12
• 3.5. System Internal Data Requirements 12
• 3.6. Adaption Requirements 12
• 3.7. Safety Requirements 13
• 3.8. Security and Privacy Requirements 13
• 3.9. System Environmenet Requirements 13
• 3.10. Computer Resource Requirements 13
• 3.10.1. Computer Hardware Requirements 14
• 3.10.2. Computer Hardware Resource Utilization Requirements 14
• 3.10.3. Computer Software Requirements 14
• 3.10.4. Computer Communications Requirements 14
• 3.11. System Quality Factors 14
• 3.12. Design and Construction Contraints 15
• 3.13. Personnel-Related Requirements 15
• 3.14. Training-Related Requirements 15
• 3.15. Logistics-Related Requirements 15
• 3.16. Other Requirements 16
• 3.17. Packaging Requirements 16
• 3.18. Statutory, Regulatory, and Certification Requirements 16
• 3.18.1. Statutory Requirements 16
• 3.18.2. Regulatory Requirements 16
• 3.18.3. Certification Requirements 16
• 3.19. Precedence and Criticality of Requirements 16
• 3.20. Demilitarization and Disposal 17
• 4. Verification Provisions 17
• 4.1. Verification Methods 17
• 4.1.1. Demonstration 17
• 4.1.2. Test 17
• 4.1.3. Analysis 17
• 4.2. Inspection 17
• 4.3. Special Verification Methods 17
• 5. Requirements Traceability 18
• 5.1. Traceability to Capability Document or System Specification 18
• 5.2. Traceability to Subsystems Requirements 18
• 6. Appendix 18
• 6.1. Appendix A: Acronyms and Definitions 18
• 6.2. Appendix B: Key Performance Parameters/Key system Attributes 18
• 6.3. Appendix C: Requirements Traceability Matrices 18
• 6.4. Appendix D: Verification Matrices 19