Validation/Systems Engineering (Part 1)

In this article we’ll look at the technical leg of project management that enables the development of a hardware product, which we will call validation/systems engineering. This is often known simply as “systems engineering” but this simplified title is often confused with other functions (IT systems, in particular). Ultimately the goal is product validation through determining, managing and testing vs. valid requirements, we will therefore use the term “validation/systems engineering”.  

Let’s start with the definition of project management as 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.

Validation engineering is 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.  The validation engineer works with subject matter experts to establish a system breakdown structure, manages and maintains requirements and facilitates the execution of verification testing to ensure the (valid) requirements are met.  Ultimately, the goal is good product quality within design and manufacturing process capability constraints.

Notice valid product requirements not only ensure customer value but help establish “product or design scope” (similar to a project managers WBS).  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 manufacturing 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 especially when the system is modeled in it’s entirety. Alternatively, we can assume one big process block “System Design & Analysis”.) 

Either way, we can focus on the first layer…

…and summarize some recommendations as follows:

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 – Facilitate Quality Function Deployment (QFD).	The value of the product to the customer might not be maximized.  The product may not be competitive.
Validate system-level / product requirements should occur before conceptual design begins.	Validation Engineer and Design Team – modeling and analysis of the conceptual design.	Design concept may be inadequate.  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 if validation is not maximized beforehand.
Actively manage requirements and monitor the capability of the design (and manufacturing process) to meet valid requirements.	Validation Engineer – manage requirements and corresponding test cases in a requirements management database or controlled documentation. Identify and mitigate the risk of not meeting requirements throughout 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.

Finally, it may be necessary to validate the product in the customer’s environment especially where test conditions cannot be duplicated by the developers of the product. Ideally, this would be minimized in order to mitigate the risk of exposing defects to the customer.

It is apparent that early validation, monitoring design quality and risks and robust verification vs. valid requirements can be a competitive advantage in your hardware product development process.