Technical Review Document

What is Review Process?

After an implementation is complete, every developer has to present the changes to a reviewer so that the changes can be moved to test and production environments. This should be done after the developer has performed successful unit testing.

This process is known as peer review or technical review. Once the reviewer, who is mostly a technical person from client side, approves the document, the changes go to Test environment for further round of testing.

Once the testing is successful in QA system, the results are shared with business for the cab approval. This is mostly done by the IT head from the client who has technically approved the changes earlier. If the business is OK with the results and changes, your transport request is ready to be moved to Production.

The cab approval meetings occur once in a week mostly on Wednesdays depending on your client. There is also a specific day for movement of changes to Production for some companies, usually Fridays.

Once the changes are moved to Production, the client will ask you to check whether the changes are correctly imported to Production or not. You may also be asked to perform cut over activities if any.

Cut over activities are those activities which are mandatory to be performed once your changes move to Production. For example, after transporting process chain changes, you might have to reschedule the process chain in Production once the changes are moved.

Make sure that you have specified all the cut over activities which are necessary for your transport in your technical review document.

The Peer or Technical Review Document for your development

Mostly the template for peer review document is client specific and will be shared to the project team by the client. However, there are some generic points which a good technical document must have. Some of these points are listed below which might be helpful to the developer-

  1. Mention all the new objects created in a tabular form – include technical name, description and type in the table.
  2. Mention mapping details in the transformation in a tabular form – indicate source field, target field and type of rule used for mapping
  3. Mention all the DTPs along with their technical names
  4. Provide relevant comments in the routines along with little explanation
  5. Mention the transport request details
  6. Provide screen shots wherever possible
  7. Keep the text technical and short, do not unnecessarily elaborate
  8. Keep version information and update the document after any changes
  9. If any process chains are included, provide scheduling information as a cut over task once the changes are live
  10. Provide user requirement and justification at the start of the document