Systems/Validation Engineering (Part 1)

In this article we’ll look at the technical leg of project management that enables the development of a hardware product. 

Let’s start with a simplified definition of project management:

The planning, monitoring and execution of the project within scope, schedule and resource constraints.  The project manager works with subject matter experts to establish a work breakdown structure and facilitates the execution of WBS activities and deliverables.  Ultimately, the goal is good project quality within the scope, schedule and resource constraints. However, good product quality and reliability depends on systems/validation engineering.

The ‘technical’ (and parallel) process might be described as validation engineering:

The validation, monitoring and execution of product requirements to ensure customer needs are met. 

The validation engineer is the validation process owner and works with subject matter experts to develop complete, accurate and testable requirements, including reliability requirements.  The validation engineer manages and maintains requirements and facilitates the execution of verification testing to ensure the (valid) product requirements are met.  Ultimately, the goal is good product quality and reliability within design and manufacturing process capability constraints.

Notice product requirements not only ensure customer value but establish “product scope”.  If a design does not adequately meet the requirements, the “design scope” is therefore a constraint, and a redesign may be needed.  Similarly, if a process isn’t capable, additional development of the process would be required, adding to “process scope”.

A “V” diagram which illustrates this is provided as follows:

(The assumption here is product requirements are defined, allocated and a “requirements-design-requirements” flow-down approach is used to establish system design/architecture and then subsystem, subassembly-level, and so-on.  The above diagram may therefore be considered somewhat theoretical.  Alternatively, we can assume one big process block “System Design & Analysis”.) 

Either way, we can focus on the first layer:

Based on this layer of the process, below is a summary table of best practice fundamentals (or recommendations), enablers and associated risks:

Recommendation	Enabled by:	Risk (if not performed)
Understand voice-of-the-customer, ensure customer needs are known and are addressed through product requirements, including critical to quality (CTQ) characteristics.	Opportunity Champion – Market Analysis      Validation Engineer – Quality Function Deployment (QFD).	Customer value of the product may be compromised.  Product may not be competitive.
Validate system-level / product requirements should be before conceptual design begins. However, requirements can be further clarified based on modeling & analysis of the conceptual design.	Validation Engineer and Design Team modeling and analysis of the conceptual design.	Design concept may not adequately address customer needs.  Risk of significant redesign.
Validated system-level / product requirements are written such that they make sense for the tester or can be easily translated into test cases.	Validation Engineer – the resource performing the system test can be the same resource that writes the valid, testable system-level / product requirements.	Design inadequacy may be experienced by the customer.
Actively manage requirements monitor the capability of the design (and process) to meet valid requirements.	Validation Engineer – manage requirements in a requirements management database or controlled documentation.  Identify and mitigate the risk of not meeting requirements during product design and development. Operations NPI Engineer – performs process qualification to ensure repeatability and reproducibility.	Inadequacy of the design may not be revealed until late in product development. Risk of significant redesign or a product that is not competitive.