Login or register (free and only takes a few minutes) to participate in this question.
You will also have access to many other tools and opportunities designed for those who have language-related jobs (or are passionate about them). Participation is free and the site has a strict confidentiality policy.
Explanation: In engineering etc. "justification" refers to the substantiation of the design (on paper) by means of calculations based on national and or international standards, regulations, codes of practice, etc. and is generally referred to as "verification" (though personally I like "substantiation").
-------------------------------------------------- Note added at 3 hrs 11 mins (2004-06-20 15:15:51 GMT) --------------------------------------------------
Design Validation
Testing to ensure that product conforms to defined user needs and/or requirements. Design validation follows successful design verification and is normally performed on the final product under defined, operating conditions. Multiple validations may be performed if there are different intended uses.
Design Verification
Testing to ensure that all design outputs meet design input requirements. Design verification may include activities such as: Design Review, Performing Alternate Calculations, Understanding Tests & Demonstrations and Review of Design Stage Documents Before Release.
[http://www.thequalityportal.com/glossary/d.htm]
What is design? The Merriam-Webster Collegiate Dictionary defines design as \"to create, fashion, execute, or construct according to plan.\" And verify? It is: \"to establish the truth, accuracy, or reality of.\" Considering these ideas, it seems plain that when we fashion, execute, or construct according to a plan we are inherently attempting to do it truthfully, accurately, and realistically. So is this correct by construction? Indeed not! Hard as we may try, we make mistakes in design, often because of a lack of understanding.
Design and verification are two parts of a whole; there really is not, or should not be, a distinction between the two disciplines. Indeed, it is often useful to have different intellects applied to these two views of a single design element, but that doesn\'t mean there should be a wall between them. On the contrary, the two roles should be treated more like players on a team. The roles can and should be readily interchanged across design elements or through time.
Consider the design and verification process for a typical system on chip (SoC). The design team decides to reuse certain pieces from previous designs, purchase some pieces of intellectual property (IP) from other third parties, and construct some elements entirely anew. Some of the engineers are assigned to \"clean up\" the legacy code. Others get the job of evaluating and selecting IP from available vendors. And others get to start fresh with a blank sheet for their blocks.
As the engineers explore the \"legacy design\" elements, are they designing or verifying? They actually believe that these components worked correctly in the previous design, but they\'re not at all certain about how they work, or whether they\'ll work completely in the new design. So they need to explore the behavior of the existing logic, thoroughly understand it, and perhaps modify it for their purposes. This process is simultaneously \"fashioning to a plan\" and \"establishing the truth.\"
Indeed, the engineers who are evaluating IP are doing exactly the same thing. They devise a scheme to check whether the commercial IP does what the vendor says - to establish the truth and accuracy of the claims. Is this evaluation or verification? Can we tell the difference? And once they procure the stuff, what will they do? Real-world experience says that more often then not, they\'ll need to modify the IP to re-construct it according to their specific plan.
And what of the engineers who got what is usually considered to be the best assignment, designing the brand-new blocks? Can they simply construct according to plan and let someone else establish the truth of their work? Typically not. They will likely construct at least a rudimentary testbench for their own blocks to check that they basically work, at least in isolation.
So we already see that the design engineers are performing a mix of tasks, both creating according to plan (designing) and establishing the truth of the work (verifying.) This has been going on all along, even though at times some companies have created organizations and flows that thwart the effort by encouraging designers to throw things over the wall to verifiers.
[http://www.us.design-reuse.com/articles/?id=3718&print=yes]
Explanation: In engineering etc. "justification" refers to the substantiation of the design (on paper) by means of calculations based on national and or international standards, regulations, codes of practice, etc. and is generally referred to as "verification" (though personally I like "substantiation").
-------------------------------------------------- Note added at 3 hrs 11 mins (2004-06-20 15:15:51 GMT) --------------------------------------------------
Design Validation
Testing to ensure that product conforms to defined user needs and/or requirements. Design validation follows successful design verification and is normally performed on the final product under defined, operating conditions. Multiple validations may be performed if there are different intended uses.
Design Verification
Testing to ensure that all design outputs meet design input requirements. Design verification may include activities such as: Design Review, Performing Alternate Calculations, Understanding Tests & Demonstrations and Review of Design Stage Documents Before Release.
[http://www.thequalityportal.com/glossary/d.htm]
What is design? The Merriam-Webster Collegiate Dictionary defines design as \"to create, fashion, execute, or construct according to plan.\" And verify? It is: \"to establish the truth, accuracy, or reality of.\" Considering these ideas, it seems plain that when we fashion, execute, or construct according to a plan we are inherently attempting to do it truthfully, accurately, and realistically. So is this correct by construction? Indeed not! Hard as we may try, we make mistakes in design, often because of a lack of understanding.
Design and verification are two parts of a whole; there really is not, or should not be, a distinction between the two disciplines. Indeed, it is often useful to have different intellects applied to these two views of a single design element, but that doesn\'t mean there should be a wall between them. On the contrary, the two roles should be treated more like players on a team. The roles can and should be readily interchanged across design elements or through time.
Consider the design and verification process for a typical system on chip (SoC). The design team decides to reuse certain pieces from previous designs, purchase some pieces of intellectual property (IP) from other third parties, and construct some elements entirely anew. Some of the engineers are assigned to \"clean up\" the legacy code. Others get the job of evaluating and selecting IP from available vendors. And others get to start fresh with a blank sheet for their blocks.
As the engineers explore the \"legacy design\" elements, are they designing or verifying? They actually believe that these components worked correctly in the previous design, but they\'re not at all certain about how they work, or whether they\'ll work completely in the new design. So they need to explore the behavior of the existing logic, thoroughly understand it, and perhaps modify it for their purposes. This process is simultaneously \"fashioning to a plan\" and \"establishing the truth.\"
Indeed, the engineers who are evaluating IP are doing exactly the same thing. They devise a scheme to check whether the commercial IP does what the vendor says - to establish the truth and accuracy of the claims. Is this evaluation or verification? Can we tell the difference? And once they procure the stuff, what will they do? Real-world experience says that more often then not, they\'ll need to modify the IP to re-construct it according to their specific plan.
And what of the engineers who got what is usually considered to be the best assignment, designing the brand-new blocks? Can they simply construct according to plan and let someone else establish the truth of their work? Typically not. They will likely construct at least a rudimentary testbench for their own blocks to check that they basically work, at least in isolation.
So we already see that the design engineers are performing a mix of tasks, both creating according to plan (designing) and establishing the truth of the work (verifying.) This has been going on all along, even though at times some companies have created organizations and flows that thwart the effort by encouraging designers to throw things over the wall to verifiers.
[http://www.us.design-reuse.com/articles/?id=3718&print=yes]
xxxBourth Local time: 09:58 Native speaker of: English PRO pts in category: 36
The translation workplace 
peer agreement (net): +2
