Establish a Technical Data Package

PA technical data package provides the developer with a comprehensive description of the product or product component as it is developed. Such a package also provides procurement flexibility in a variety of circumstances such as performance-based contracting or build to print.

The design is recorded in a technical data package that is created during preliminary design to document the architecture definition. This technical data package is maintained throughout the life of the product to record essential details of the product design. The technical data package provides the description of a product or product component (including product-related life-cycle processes if not handled as separate product components) that supports an acquisition strategy, or the implementation, production, engineering, and logistics support phases of the product life cycle. The description includes the definition of the required design configuration and procedures to ensure adequacy of product or product-component performance. It includes all applicable technical data such as drawings, associated lists, specifications, design descriptions, design databases, standards, performance requirements, quality assurance provisions, and packaging details. The technical data package includes a description of the selected alternative solution that was chosen for implementation.

A technical data package should include the following if such information is appropriate for the type of product and product component (for example, material and manufacturing requirements may not be useful for product components associated with software services or processes):

• Product architecture description
• Allocated requirements
• Product-component descriptions
• Product-related life-cycle process descriptions, if not described as separate product components
• Key product characteristics
• Required physical characteristics and constraints
• Interface requirements
• Materials requirements (bills of material and material characteristics)
• Fabrication and manufacturing requirements (for both the original equipment manufacturer and field support)
• The verification criteria used to ensure that requirements have been achieved
• Conditions of use (environments) and operating/usage scenarios, modes and states for operations, support, training, manufacturing, disposal, and verifications throughout the life of the product
• Rationale for decisions and characteristics (requirements, requirement allocations, and design choices)

Because design descriptions can involve a very large amount of data and be crucial to successful product-component development, it is advisable to establish criteria for organizing the data and for selecting the data content. It is particularly useful to use the product architecture as a means of organizing this data and abstracting views that are clear and relevant to an issue or feature of interest. These views include:

• Customers
• Requirements
• The environment
• Functional
• Logical
• Security
• Data
• States/modes
• Construction
• Management

• Determine the number of levels of design and the appropriate level of documentation for each design level. Determining the number of levels of product components (e.g., subsystem, hardware configuration item, circuit board, computer software configuration item [CSCI], computer software product component, computer software unit) that require documentation and requirements traceability is important to manage documentation costs and to support integration and verification plans.
• Base detailed design descriptions on the allocated product-component requirements, architecture, and higher level designs.
• Document the design in the technical data package.
• Document the rationale for key (i.e., significant effect on cost, schedule, or technical performance) decisions made or defined.
• Revise the technical data package as necessary.