Every now and then we get asked to do a code/design review on a project. 99.9999% of the time this is because the project has gone really badly wrong, and by code/design review they actually mean "can you rescue the project for us?". But on the assumption that it is a review that they want I started thinking about a useful document.
An important point to understand is that a design review and a code review are very different processes. Ideally the design review should be completed before too much code is written (demo and feasibility code are the exceptions). The outputs from this are an acceptance that the design is appropriate to everyone involved in the process. Whereas a code review is a confirmation that the code has been written to acceptable standards and this will be prior to release (or in sometimes prior to incorporation into the project)
The reason for this type of documentation is primarily to help the design process, enforce and remind about standards and give traceability to any decisions or exceptions.
Anyways I was asked to go and do a code review of a project and I thought that in the spirit of enlightenment that I should review the code against the customers criteria rather than SSDC's standards. The inspiration for the questionnaire came from Arnoud de Kuijper's Use Case wheel.
By grading the project, we should be able to ascertain review criteria that are important to the customer. This is pretty much my first draft of the questionnaire and here is where you come in.
Are there any other questions that can be asked?. Also looking at the headings I feel some clarification is needed. But in the spirit of conversation I thought I'd put it out there and see what occurs.
There's no time limit so add questions and comments any old when.
Next year in the spirit of open source, I will be releasing all of our processes and documents to the wide world.