New-Tech Europe Magazine | May 2016

Figure 1 - Dynamic current dominates with higher operating voltage

Figure 1 - Dynamic current dominates with higher operating voltage

3. It is achievable. The requirement is technically possible, given the constraints. 4. It is traceable. The requirement can be traced from lower-level requirements and can trace to higher- level requirements. 5. It is unique. This standard prevents contraction between requirements. 6. It is simple and clear. Each requirement specifies one function. It is also common to use specific language when defining requirements to demonstrate intention. Typically, we use SHALL for amandatory requirement and SHOULD for a nonmandatory

and external customers. This identifies any difficult test methods early on in the development and allows us to determine the resources required. • Identify technical performance metrics. These spring from the compliance matrix and comprise requirements that are at risk of not achieving compliance. ASSIGN ENGINEERING BUDGETS Every engineering project encompasses a number of budgets, which we should allocate to solutions identified within the architecture. Budget allocation ensures that the project achieves the overall requirement and that the design lead for each module understands the module’s allocation in order to create an

requirement. Nonmandatory require- ments let us express desired system attributes. After we have established our requirements baseline, best practice is to create a compliance matrix, stating compliance for each requirement. We can also start establishing our verification strategy by assigning a verification method for each requirement. These methods are generally Test, Analysis, Inspection, Demonstration and Read Across. Creating the requirements along with the compliance and verification matrices enables us to: • Clearly understand the system behavior. • Demonstrate the verification methods to both internal test teams

New-Tech Magazine Europe l 39