GPEP documents:

The GPEP process (and most regulatory agencies and industry quality / environmental standards¹⁰) require that the following documents be generated and controlled by a formally defined process. This is especially necessary for critical products (e.g. medical, nuclear control, automobile, aerospace, etc.) and all products marketed where environmental and recycling issues are a concern. A documentation bureaucracy is not the intent of GPEP, so it is incumbent on the project team to generate and maintain only the documentation, which is required by the development process and the relevant regulatory agencies, industry standards, legal decrees and company dictates. In other words… 'Keep It as Simple as Possible…'

• Marketing Requirements Document
  
  This is the most important business document for the GPEP process. It contains a concise synopsis (not necessarily to great detail) of all the market, technical and business issues. It describes what the product is, what its environment and users are like, what it does, how it is used, how and what regulatory and other standards requirements are to be met, how manufacturing is envisioned to occur, what the cost structure needs to be, how it's to be distributed, promoted, guaranteed, installed, serviced, etc.
  
  The MRD completely defines all of the product inputs and expected outputs; testing the product inputs to the product outputs will validate the final product. It is important to stress that everything in the MRD is funded: i.e. the MRD contains reality, not wishes.
  
  The MRD contains the pro forma (to be refined later) project plans such as the development process, schedule, budget, resources required, team member incentives, and contingency plans for risks, hazards and reaction to changes in the market, users or technology. This project definition allows the development project to move along efficiently so everyone knows what needs to be done and when and how to carry it out.
  
  
• Product Requirements Specification
  
  These documents are generated for the product and each partitionable component of the design, such as software, hardware and subsystems. The PRS describes how the systems and subsystems are designed, the inputs and outputs for each system and component, the technology families used, descriptions of the operations, formulae, algorithms, diagrams and traceability mechanisms (which link the design inputs to the design outputs). Eventually, a completed system or subsystem is tested to the PRS claims to ensure it has been designed correctly. The design is completely described in technical detail in the PRS and this is where design creativity is king.