Difference between revisions of "Product Acceptance"

From EUDP
Jump to: navigation, search
(Why)
 
Line 30: Line 30:
  
 
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!
 
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.
 +
 +
[[File:Verificatoin table.png|600px]]
  
 
== Used In ==
 
== Used In ==

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.