Case method document templates

I tend to stick fairly closely to the Oracle Case Method. It's very similar, in principle, to SSADM the UK government's methodology. If the site that I am working at is not using Case (Designer 2000) fully then I'll use one or more of the documents below to fill in the gaps. I use these documents as a starting point.

Project Standards manual ( Standards.pdf - 80k )

Standards, Standards ... Every project that's trying to produce a quality product needs standards. In my experience they often go to different extremes. Far too many, so no one uses them or none at all, so no one uses them. I've tried to concentrate on the on the design area.

Initial Study Report ( InitialStudy.pdf - 12k )

The Initial Study Report, sometimes called a Strategy report, follows on from a project proposal. The strategy looks at various possible solutions to the project proposal and selects one, which is carried forward into the analysis phase of the project.

Analysis report ( Analysis.pdf - 14k )

The analysis phase of the project is all about defining the requirements. You can think of this as writing the question in an exam. As well as functional requirements design constraints should also be defined. Constraint might be budget, time scales, computer hardware used software used etc.

Design report ( Design.pdf - 15k )

The design report follows on from the analysis phase. The best way to think of this part of the project is answering the question posed in the analysis phase. The design report should contain a full database design and show which functional areas map to module definitions. At this stage I would expect to see one more than a page of detail per module.

Module spec - Screen ( Screen.pdf - 20k )

The old maxim garbage in garbage out is so true. That why its important to carefully specify the screen forms. One of the great things about Oracle is that if a strong database design has been created its possible to generate a default screen form and copy the constraints from the database into the screen. i.e. if a field only allows (Y,N), in the database, then that's what the screen allows and so there is no reason to send invalid data to the database. i.e. The client handles the validation. Although this specification was designed for Oracle Forms 3, it could still be used to spec VB programs and other similar screen forms. The important areas to define are:- the field level validation, the record level validation, special processing i.e. What happens when I press this button. It goes without saying spec should show a screen layout!

Module spec - Report ( Report.pdf - 17k )

A lot of this stuff is obvious. So obvious that people don't bother with the documents and that's how mistakes are made. The spec needs to detail a layout, the layout needs to relate the fields on the report to the database tables and fields. Calculated fields need to be specified ie The calculation method. It's always a good idea to give examples, which can be used as test cases.

Module test spec ( UnitTest.pdf- 7k )

You can't inspect quality into a product at the system testing phase. The quality needs to be there right from the start of development. ( See project life cycle document ) for a discution of this. At the module level its good practive to document exactly what was done to prove that the module does what the specification says it should. e.g. if a field says ( Y, N ) can be entered, check what happens if Y, N, Null, Some other value are entered. Positive testing is important but more important for robust software is the negative testing.

System test spec ( SystemTest.pdf - 11k )

The system test plan should concentrate on the following areas:- The exercising of interfaces between modules, Performance and Volume testing, Checking that the system satisfies all of the requirements specify in the analysis report.

Meeting Agenda ( Agenda.pdf - 3k )

Meeting agenda! What's this one doing here? You'd be suprised how many people call meetings and don't specify what the purpose of the meeting is. For a meeting to be effective there should always be an agenda which the chairman sticks to.

Meeting minutes ( Minutes.pdf - 3k )

Minutes of a meeting? Why is this here? Again if you're going to have a meeting its important to document what decisions were made and reasons behind them. Also action points need to be assigned so that progress is made. The key to a successful meeting is clear communication ie Everyone needs to have one agreed document that specifies what was desided.

Form - Change request ( ChangeRequest.pdf - 6k )

The key to a well run project is clear communication. Once a system has gone into production there needs to be a machanism for requesting changes to the system. This form is a good starting point. It details all of the information that should be collected.

Form - Database change request ( DBChangeRequest - 7k )

When code is released into the production system, database changes often need to be made. This form records what the database changes are and what versions of scripts should be run etc.

Form - Source code release ( ChangeRelease.pdf - 4k )

In a large system with multiple versions of code its important to know which version of code contains the change you want to release. This form documents the version of modules that should be released to the production system.

Implementation Plan ( Implementation.pdf - 21k )

Implementation plan Often a very large release will require an implementation plan to co-ordinate the various groups that might be involved. An example might be large scale database changes that required a special backup to be made before they are applied, only will the installation of new computer kit and release of software. Who should do what when? If things go wrong how do we revert to the existing system? All of these questions should be answered by an implementation plan.

Estimating ( Estimating.pdf - 15k )

How long is this going to take? This has got to be one of the most difficult questions to answer. Often the truth is not the answer the manager want wants to hear. Learn how to structure your approach to creating estimates.

Copyright © 1999 Peter N. Crompton
Email Address: Peter_Crompton@Yahoo.com
Last revised: October 1999