2
$\begingroup$

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

I need to ensure that I have included all the salient information concisely 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 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.

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ Cue hollow laughter: my favourite one is what used to be the standard PRD for the engines of military aircraft. "The engines will perform satisfactorily over the full operating range of the aircraft". That's it. All of it. If you asked for more detail, the answer was likely to be "Well, we don't know what the aircraft will be able to do till we have a prototype to start flight testing..." $\endgroup$ – alephzero Aug 16 '19 at 9:49
  • $\begingroup$ see atlassian.com/agile/product-management/requirements $\endgroup$ – Solar Mike Aug 16 '19 at 10:54
  • $\begingroup$ some background information of yourself would allow us to write a more appropriate approach to the question. e.g. Have you ever designed a mechanical product, have you ever read or written a requirement doc? $\endgroup$ – Gürkan Çetin Aug 16 '19 at 18:25
  • $\begingroup$ @GürkanÇetin I am a software architect by profession, ergo, I have written a few requirements docs (e.g. functional and technical). I have no hardware/mech. engineering background, so this is new territory for me in that regard. $\endgroup$ – Homunculus Reticulli Aug 16 '19 at 23:04
  • $\begingroup$ @HomunculusReticulli alright, so you're in fact familiar with requirements, tests, validation/verification. I'll try to sketch an answer accordingly. $\endgroup$ – Gürkan Çetin Aug 17 '19 at 9:22
1
$\begingroup$

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
    1. 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
    1. 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
    1. 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
    1. Requirements Traceability 18
  • 5.1. Traceability to Capability Document or System Specification 18
  • 5.2. Traceability to Subsystems Requirements 18
    1. 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
Improve this answer
$\endgroup$
6
  • $\begingroup$ Fantastic answer, I'm glad you added the FADEC component, because yes, there is a software component that will run the engine and keep it at optimal performance. Regarding the subcomponents, I have already identified them - ideally, I would like them to be designed by different engineers (partly, because of IP issues) - HOWEVER, I don't know as yet, how I can define the interfaces between the sub components, since I have NO M.E design knowledge, If you could shed some light on how I could define the interfaces between the various components, your answer would contain EVERYTHING I need. $\endgroup$ – Homunculus Reticulli Aug 17 '19 at 20:27
  • $\begingroup$ Assuming that the engine has the following parts: Fuel injection System, Turno Charger, Combustion chamber and pistons, assuming I have no M.E. designing skills, but have a "rough sketch" in my head (as a hardware inventor), where these things should roughly be (the idea is an improvement of an existing engine) - is there anyway I can break the engine down into its subcomponents/subsstems and assign a unique engineer per subsystem? $\endgroup$ – Homunculus Reticulli Aug 17 '19 at 20:33
  • $\begingroup$ glad that the answer is useful somehow. :) You do not need to specify all intra-interfaces of the subcomponents, if you will outsource the complete engine system (FADEC, Engine and all other subcomponents (alternator/power distribution, fuel pumps, etc.)) $\endgroup$ – Gürkan Çetin Aug 18 '19 at 6:25
  • $\begingroup$ but if you intend to break the engine down to several subcomponents and outsource them from different sources, than you'll have to define all interfaces inside the documents, or setup such a work-definition that they will obey you orchestrating the interfaces. $\endgroup$ – Gürkan Çetin Aug 18 '19 at 6:27
  • $\begingroup$ Btw, I would not try to play the engine self-integration role, it's a huge task and requires quite a bit of experience and know how. So, I'd go with "give me an engine, deliver this performance" route. $\endgroup$ – Gürkan Çetin Aug 18 '19 at 6:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.