Difference between revisions of "Product Acceptance"

From EUDP
Jump to: navigation, search
(Example: Added Used In)
(Why)
 
(4 intermediate revisions by 2 users not shown)
Line 8: Line 8:
 
'''The dish'''
 
'''The dish'''
  
Product Accept Specification  
+
Product Acceptance Specification  
  
 
'''Ingredients'''
 
'''Ingredients'''
  
*     [[Exact Requirements]]
+
* Requirements
  
 
'''Process'''  
 
'''Process'''  
  
Read the documents from the process where you specified the exact requirements. This should give you an unambiguous and complete picture of the customer's needs. Then you need to make a complete specification of how to test and verify each requirement. This might include special test equipment and special test environments. You should also consider how the system-to-be is deployed and if this will influence the verification procedure. Are field tests necessary? Is there interface to other systems? You really need to consider Murphy's Law ("if anything can go wrong, it will")! Moreover, you have to put yourself in the customer's position, since he or she, in addition to accepting the product, is the one to live with it in the future.
+
* Read the documents from the process where you specified the requirements. This should give you an unambiguous and complete picture of the customer's needs.  
 +
* Then you need to make a complete specification of how to test and verify each requirement.  
 +
** This might include special test equipment and special test environments.  
 +
* You should also consider how the system-to-be is deployed and if this will influence the verification procedure.  
 +
* Are field tests necessary?  
 +
* Is there interface to other systems?  
 +
* You really need to consider Murphy's Law ("if anything can go wrong, it will")!  
 +
* Moreover, you have to put yourself in the customer's position, since he or she, in addition to accepting the product, is the one to live with it in the future.
  
 
== Why ==
 
== Why ==
  
The product accept specification is the crucial part of the project. If you succeed in making the specifications right, you keep the lawyers away, you have a happy customer and you make money!
+
The product acceptance specification is the crucial part of the project. If you succeed in making the specifications right, you will keep the lawyers away, you will have a happy customer and you will make money!
  
But why is it then so difficult to make the right product accept specifications? First of all, old Murphy is there ("if anything can go wrong, it will"!) and second of all, you really need to understand the customer's wishes and needs when it comes to the system-to-be.
+
But why is it then so difficult to make the right product acceptance specifications? First of all, old Murphy is there ("if anything can go wrong, it will"!) and second of all, you really need to understand the customer's wishes and needs when it comes to the system-to-be. It seems quite easy to follow the rules and models for development. Why is it then that projects often fail? Well, as a developer you often become enthusiastic and get carried away by a "good" idea. Some tend to jump to conclusions and act before thinking and planning. Unfortunately, you might say, this is part of human nature. It is therefore necessary for the developer constantly to look at the system-to-be from the customer's point of view and constantly make sure that nothing can go wrong. You should not only make sure that the exact requirements are met, but also that the customer will in fact accept the product. This calls for a very good product acceptance specification which you must keep in mind in your quotation and throughout the Realisation Phase!
It seems quite easy to follow the rules and models for development. Why is it then that projects often fail? Well, as a developer you often become enthusiastic and get carried away by a "good" idea. Some tend to jump to conclusions and act before thinking and planning. Unfortunately, you might say, this is part of human nature. It is therefore necessary for the developer constantly to look at the system-to-be from the customer's point of view and constantly make sure that nothing can go wrong. You should not only make sure that the exact requirements are met, but also that the customer will in fact accept the product. This calls for a very good product accept specification which you must keep in mind in your quotation and throughout the Realisation phase!  
+
 
 +
Write down exactly how it is expected to show to the customer that the requirements etc. is fulfilled. Do write it in a way that allows any technical person to redo the steps that shows how the requirements was fulfilled.
 +
 
 +
== Example ==
 +
 
 +
A simple table may hold the verification procedure, it depends into how small pieces the requirements are broken. Some times a reference the the verification procedure may be necessary.
 +
 
 +
[[File:Verificatoin table.png|600px]]
  
 
== Used In ==
 
== Used In ==
Line 30: Line 44:
  
 
Having defined the Product Acceptance the [[Realisation Phase]] is the next major step.
 
Having defined the Product Acceptance the [[Realisation Phase]] is the next major step.
 +
 +
== References ==
 +
[http://www.oir.caltech.edu/twiki_oir/pub/Keck/NGAO/SystemsEngineeringGroup/AppC_HowToWriteAGoodRequirement.pdf How to write good requirements] will ease the tests writing.

Latest revision as of 12:54, 23 November 2020

What

A description of how to ensure that the exact requirements of the system-to-be have been met.

How

The dish

Product Acceptance Specification

Ingredients

  • Requirements

Process

  • Read the documents from the process where you specified the requirements. This should give you an unambiguous and complete picture of the customer's needs.
  • Then you need to make a complete specification of how to test and verify each requirement.
    • This might include special test equipment and special test environments.
  • You should also consider how the system-to-be is deployed and if this will influence the verification procedure.
  • Are field tests necessary?
  • Is there interface to other systems?
  • You really need to consider Murphy's Law ("if anything can go wrong, it will")!
  • Moreover, you have to put yourself in the customer's position, since he or she, in addition to accepting the product, is the one to live with it in the future.

Why

The product acceptance specification is the crucial part of the project. If you succeed in making the specifications right, you will keep the lawyers away, you will have a happy customer and you will make money!

But why is it then so difficult to make the right product acceptance specifications? First of all, old Murphy is there ("if anything can go wrong, it will"!) and second of all, you really need to understand the customer's wishes and needs when it comes to the system-to-be. It seems quite easy to follow the rules and models for development. Why is it then that projects often fail? Well, as a developer you often become enthusiastic and get carried away by a "good" idea. Some tend to jump to conclusions and act before thinking and planning. Unfortunately, you might say, this is part of human nature. It is therefore necessary for the developer constantly to look at the system-to-be from the customer's point of view and constantly make sure that nothing can go wrong. You should not only make sure that the exact requirements are met, but also that the customer will in fact accept the product. This calls for a very good product acceptance specification which you must keep in mind in your quotation and throughout the Realisation Phase!

Write down exactly how it is expected to show to the customer that the requirements etc. is fulfilled. Do write it in a way that allows any technical person to redo the steps that shows how the requirements was fulfilled.

Example

A simple table may hold the verification procedure, it depends into how small pieces the requirements are broken. Some times a reference the the verification procedure may be necessary.

Verificatoin table.png

Used In

The Product Acceptance is used when the development is finished to establish confidence at the customer that he/she received the agreed product.

Having defined the Product Acceptance the Realisation Phase is the next major step.

References

How to write good requirements will ease the tests writing.