Difference between revisions of "Product Acceptance"

From EUDP
Jump to: navigation, search
(How)
Line 8: Line 8:
 
'''The dish'''
 
'''The dish'''
  
Product Accept Specification  
+
Product Acceptance Specification  
  
 
'''Ingredients'''
 
'''Ingredients'''
Line 17: Line 17:
  
 
* 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.  
 
* 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.  
+
* 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.  
 
** 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.  
 
* You should also consider how the system-to-be is deployed and if this will influence the verification procedure.  

Revision as of 10:59, 8 May 2015

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 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!

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. 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!

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.