These documents were created in the development at Digital (then Compaq) of a workflow product whose working product name was NetFlow. The product was released with the name Compaq Approval Expeditor, although it was cancelled shortly thereafter. (You are likely to see both names in the documents.)

Note that for a product development company, changing product names is commonplace, and it is commonplace for early documents to persist with early working names.

Product Requirements Document   A description in general terms of what the product should be able to do. This was written by the product manager, who acted as the surrogate for the customer. This document corresponds to what Ian Sommerville calls User Requirements.

Development Plan   Written by engineering to describe the processes that engineering would use to develop the product.

Functional Specification   Written by engineering as a response to the Product Requirements Document. Provides the concrete description in end-user or marketing oriented terms of what the product will look like and how it will behave. This document corresponds to what Iam Sommerville calls System Requirements.

Client UI Specification   A logical extension of the Functional Specification; in this case, the UI Specification was large enough and detailed enough that it made sense to place it in a separate document. (Note: the project also included a UI specification for the workflow designer, which is not included here.)

Product Architecture Document   Describes the overall architecture of the system in terms that span multiple versions of the system, and that would apply even if the system (or more likely, an additional client) were implemented on an entirely different platform.

Product Design Overview Document   Describes general information about the V1.0 implementation on an NT server and Win-32 client. Note that historically, the core of the design was done with the CASE tool, which was Select Enterprise (see the next two samples). While the CASE tool did an excellent job of capturing detail, it became clear that it didn't do a good job of describing the overview of how the components of the system worked together. Thus, this overview document was written to introduce the design and provide the context for the detail in the following documents.

Client Design Document   One of 4 design documents generated by Select Enterprise, the CASE tool that was used by this project. (Select Enterprise is now defunct, but it was similar in many ways to Rational Rose.) The Client Design Document contains use case diagrams, sequence diagrams, and class definitions for classes that are unique to the client. Sequence diagrams also frequently reference common classes described in the next document.

Common Class Design Document   Also generated by Select Enterprise. This document captured the common class design that was shared by all 4 components of the system.

From other projects:

Task List   An example of using Excel to record and track individual tasks. Note that this spreadsheet is designed to track historical data, so that at the end of the project, people can use that data to fine tune their estimating skills. (This is one of the objectives of Watts Humphrey's Personal Software Process.)

Project Risks List   Used to track the various risks that affected the project. The primary goal was to maintain visibility of the risks, both from the engineering team and others, so that the risks would be addressed. To that end, this was posted on the project web page on the intranet, and was constantly updated as risks were identified and as risks were managed.

Project Issues List   As with the risks, this list was used to track open issues that needed resolution. Again, visibility was the goal, and so this was posted on the project page on the intranet, and was updated as issues were resolved and new issues identified.

Development Methodology   A formal document describing the overall methodology used by a software development organization to manage the planning and development of software products. (Diogenes Software is a fictitious organization.)