Determining hardware requirements: how to
Your hardware requirements are typically produced from three sources; the product requirements, risk management and design-specific standard’s requirements.
Hardware requirements derived from product requirements are predominantly functional. To define the requirement, we must ask the question: “what does the hardware sub-system need to do, or contribute, in order to fulfil each product requirement?”
In some cases, a hardware requirement will completely cover a product requirement, but in other cases it may only be one of several elements needed. For example, a requirement to control temperature may involve the need for software, system and mechanical requirements, as well as hardware.
The risk management process, typically a design Failure Mode and Effects Analysis (FMEA), could identify additional hardware requirements as risk reduction measures. For example, an independent overtemperature cut-out may be required as a risk mitigation for a temperature controller failure.
International standards such as IEC 61010-1 and IEC 61010-2-101 are written by industry experts and, whilst they may seem like just a necessary hurdle to marketing a product, they frequently contribute to a more robust and safer design. To minimise the risk of non-compliance when the final design is tested to these standards, it's prudent to thoroughly review the standards in relation to the specific design and produce design-specific standards requirements.
The hardware requirements should, as far as possible, be design independent, concentrating on what’s required rather than how to implement it. They should be succinct, necessary, unambiguous, singular and verifiable.
Top tip: When writing a requirement, consider about how it will be verified! This may prompt you to re-word some of the requirements to enable this.
Determining your hardware requirements can be a challenging prospect, however discussing them with experts like Team Consulting can help to streamline the process. Once you have a reasonable draft of your hardware requirements, it’s time to start thinking about traceability, to link each product requirement, risk management output requirement and standards’ requirements to the appropriate hardware requirement. The traceability can be implemented with a manually created ‘Trace Matrix’, or we can use a dedicated requirements tracking database such as Helix.
The Trace Matrix will not only trace hardware requirements, but will also be associated with the SRS (Software Requirements Specification), risk analysis and other documents as appropriate for the design. Subsequently, traceability will be added for your verification tests and finally the verification results documents.
Verification: planning
The last step before writing verification tests is to produce a verification plan that will describe the approach and structure of the verification documentation, including the hardware verification protocol.
The hardware verification protocol may include the precise test methods or may reference separate test method documents. Everything may be included all in one protocol or there may be one protocol per verification test. What’s appropriate for your project is likely to be based on your existing procedures (if applicable), project complexity and maximising flexibility whilst minimising the number of documents. Whatever the structure, it needs to be documented in the verification plan.
Verification: testing
Each hardware requirement will be tested by one or more verification tests, though one verification test can also cover several hardware requirements. Remember the trace matrix, that’s where we keep track of it all!
When coming to write each verification test, to provide the required objective evidence (that the design meets the hardware requirements) various methods may be employed. The default method is empirical testing, but depending on the nature of the requirement, tests could include inspection of manufacturer’s data, component certifications, calculations and third-party test lab reports. In the case of requirements derived from standards, the verification test is usually just a requirement to reference to the test laboratory's certification.
Each test should include sufficient information for a qualified test technician or engineer to perform the test, listing any requirements for specific equipment or operating conditions. It should include the requirement to record their name, date, test reference, device ID, equipment and calibration details, and an acceptance criteria (based on the requirement).
Top tip: It is important to ensure that all aspects of a requirement are fully tested. Watch out for requirements with the words “or” plus “and”, or with ranges of operation that need to be tested at their limits.
The method may include a pro-forma for the results. This can be valuable in ensuring all the required information is recorded in a consistent and logical manner.
Dry-run tests and pre-requisities
Once the verification tests have been drafted, they should be “dry-run" on the current design (despite not being final). Firstly, this will help resolve issues with the test method itself, but it will also help check that all the required test equipment is available and may provide early detection of failures before you’ve committed to a final production design, which can save both time and money!
For formal hardware verification testing the following pre-requisites must be recognised:
- Documentation: the hardware requirements, verification plan, hardware verification protocol/s and verification test methods (if separate documents) must all be issued. Note that the hardware requirements must be issued before the verification protocol /test methods.
- Test samples: the verification testing must use “production representative” samples, i.e. from a completely documented final design including issued drawings, Bill of Materials (BOMs) and manufacturing test specifications (e.g. device master record). The production process must also be fully controlled, including: assembly instructions, equipment used and calibration status, manufacturing test records, traceability of components, assembly operator training and more. So, typically these are sample devices from a fully documented production pilot batch.
- Verification test fixtures: any verification test fixtures must be documented with exclusive IDs, so it can be known exactly what fixture was used for a specific test.
- Training: trained test operators – including the use of fixtures and standard test equipment as appropriate.
When the above are satisfied, you will be ready to start hardware verification.
Hardware verification
During verification, retain all original results data and ensure it can be attributed to a specific person and instance of performing a test, together with its full record and equipment used. This should all be stipulated in the test method or protocol.
Top tip: Keep all your results in a single sub-directory (or otherwise uniquely associated). If you need to re-run all or a part of the hardware verification, create a new sub-directory to store the new results and data.
Once the results are complete, they should first be reviewed for completeness, together with the appropriateness and integrity of any supporting documentation. Then a verification report is generated, indicating the overall result, references to the results and all supporting documents and any deviations (planned or unplanned) from the test method or protocol with a justification.
Verifying that your hardware works as intended can be a difficult process, however it is a necessary step to ensuring you have a functioning and effective device. By working with experts such as Team Consulting, you can make sure this process is streamlined to help save time, money and effort during your development.
