Difference between revisions of "Verification"
(→Why) |
|||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | == What == | |
| − | + | Recommendations for Verification | |
| − | + | [[Image:VerificationSteps.png|500px]] | |
| − | + | ||
| − | + | ||
| + | == How == | ||
| + | |||
| + | '''Ingredients''' | ||
| − | + | * Product Test Specifications | |
| + | * Test Plan | ||
| + | * Product Verification Specification | ||
| + | * Risk Management Documents | ||
| + | |||
| + | '''Process''' | ||
| + | |||
| + | Verification is the activity to prove conformance of the system according to requirements. | ||
| + | |||
| + | The verification of each system requirement can be done by one of the following techniques: | ||
| + | |||
| + | * Inspection | ||
| + | * Review | ||
| + | * Analysis | ||
| + | * Test | ||
| + | |||
| + | Since time (and money) most likely is a limited resource, the verification process should be as efficient and reasonable as possible. In general, tests are very time-consuming and should also be limited to be as simple as possible. | ||
| + | |||
| + | Inspections and reviews can be performed by the developer, a colleague, the customer or other qualified persons. It is recommended that two persons perform an inspection independently. The inspection ensures compliance with the design process by determining the criterion "as designed/as built" . | ||
| + | |||
| + | Analysis is necessary to reduce test time. Here, a Worst-Case analysis (WCA) can be used. If a WCA is not performed, each "parameter" must be tested under all conditions to ensure that the requirements are met. The WCA gives the condition(s) under which the test should be performed. The WCA for each parameter (requirement) is not necessarily a major analysis, but is often only a few arguments to state how the system (or part of the system) performs under different conditions. | ||
| + | |||
| + | Some requirements, such as hardware degradations due to aging, can be most conveniently verified by performing relevant analysis. In minor projects with only a limited number of delivered systems, it is too expensive to use destructive test methods like Hast or Halt: ''Halt'' (Highly Accelerating Limit Test) or ''Hast'' (Highly Accelerating Stress Test) are destructive tests, where the system is imposed to harder and harder ("accelerating") environmental conditions until the system fails. These are alternative methods to verify lifetime degradations. They are also used to investigate the most severe weaknesses of the system. | ||
| + | |||
| + | Test is the most visible method used in the verification process. | ||
| + | |||
| + | A series of electrical, mechanical and environmental stimuli are applied to the design or its sub-systems, and the responses are measured and evaluated in compliance with the specifications and requirements. Consider the need for specialised testing such as: | ||
| + | |||
| + | * EMI/EMC | ||
| + | * Vibration | ||
| + | * Shock | ||
| + | * Humidity | ||
| + | * Temperature altitude | ||
| + | * Explosion | ||
| + | * Salt and dust | ||
| + | * Corrosive atmosphere | ||
| + | |||
| + | == Why == | ||
| + | |||
| + | Verification is the activity to prove conformance of the system according to requirements. | ||
| + | |||
| + | Verification is important to ensure that the product has the features required by the customer. In other words, it is a method to control the quality of the product (system-to-be). | ||
| + | |||
| + | A verification process can be thought of as the activity of testing the system-to-be with regard to all requirement specifications given in the Product Accept Specification document. All possible configurations of the system should (in theory) be tested to prove that the product (system-to-be) meets the requirements. | ||
| + | |||
| + | Sometimes in literature, the verification activity is split into two activities: ''Validation'', which ensures that the functionality of the product is in accordance with the specifications, and ''verification'', which confirms that the results of the design process meet the design requirements. | ||
| + | |||
| + | The verification process should be in the developer's mind through each development phase. When a requirement specification is stated in the Launch or Realisation Phase, it should be accompanied by a thought of how (and when) to verify this requirement. | ||
| + | |||
| + | Since time (and money) most likely is a limited resource, the verification process should be as efficient and reasonable as possible. In general, tests are very time-consuming and should also be limited to be as simple as possible. | ||
| + | |||
| + | After verification, [[Deployment]] comes in natural. | ||
Latest revision as of 10:13, 8 July 2015
What
Recommendations for Verification
How
Ingredients
- Product Test Specifications
- Test Plan
- Product Verification Specification
- Risk Management Documents
Process
Verification is the activity to prove conformance of the system according to requirements.
The verification of each system requirement can be done by one of the following techniques:
- Inspection
- Review
- Analysis
- Test
Since time (and money) most likely is a limited resource, the verification process should be as efficient and reasonable as possible. In general, tests are very time-consuming and should also be limited to be as simple as possible.
Inspections and reviews can be performed by the developer, a colleague, the customer or other qualified persons. It is recommended that two persons perform an inspection independently. The inspection ensures compliance with the design process by determining the criterion "as designed/as built" .
Analysis is necessary to reduce test time. Here, a Worst-Case analysis (WCA) can be used. If a WCA is not performed, each "parameter" must be tested under all conditions to ensure that the requirements are met. The WCA gives the condition(s) under which the test should be performed. The WCA for each parameter (requirement) is not necessarily a major analysis, but is often only a few arguments to state how the system (or part of the system) performs under different conditions.
Some requirements, such as hardware degradations due to aging, can be most conveniently verified by performing relevant analysis. In minor projects with only a limited number of delivered systems, it is too expensive to use destructive test methods like Hast or Halt: Halt (Highly Accelerating Limit Test) or Hast (Highly Accelerating Stress Test) are destructive tests, where the system is imposed to harder and harder ("accelerating") environmental conditions until the system fails. These are alternative methods to verify lifetime degradations. They are also used to investigate the most severe weaknesses of the system.
Test is the most visible method used in the verification process.
A series of electrical, mechanical and environmental stimuli are applied to the design or its sub-systems, and the responses are measured and evaluated in compliance with the specifications and requirements. Consider the need for specialised testing such as:
- EMI/EMC
- Vibration
- Shock
- Humidity
- Temperature altitude
- Explosion
- Salt and dust
- Corrosive atmosphere
Why
Verification is the activity to prove conformance of the system according to requirements.
Verification is important to ensure that the product has the features required by the customer. In other words, it is a method to control the quality of the product (system-to-be).
A verification process can be thought of as the activity of testing the system-to-be with regard to all requirement specifications given in the Product Accept Specification document. All possible configurations of the system should (in theory) be tested to prove that the product (system-to-be) meets the requirements.
Sometimes in literature, the verification activity is split into two activities: Validation, which ensures that the functionality of the product is in accordance with the specifications, and verification, which confirms that the results of the design process meet the design requirements.
The verification process should be in the developer's mind through each development phase. When a requirement specification is stated in the Launch or Realisation Phase, it should be accompanied by a thought of how (and when) to verify this requirement.
Since time (and money) most likely is a limited resource, the verification process should be as efficient and reasonable as possible. In general, tests are very time-consuming and should also be limited to be as simple as possible.
After verification, Deployment comes in natural.
