Include the name of the document's author, author's telephone and email address.
Contributors:
List contributors to this document, and the nature of
their contributions.
Primary Contact:
All questions and comments about the project should
be addressed to the primary contact. It will be the responsibility of
the primary contact to answer or direct the questions or comments to the
appropriate parties.
The primary contact is usually the Project Leader. Include email link.
Distribution:
List the mailing list, Usenet group, web address, or
other method of intended distribution.
REVISION HISTORY
Date of Revision
Revised by
Description of Revision
Affected Modules
QUALITY CONTROL
Development Methodology
For the
purposes of this project, we are using a simplified Project Life Cycle, the
details of which can be found at www.kuhnllc.com.
Change Control
Detail the change
control plan in two contexts:
The context of changes to the SPECIFICATIONS and DESIGN. Strongly discourage changes to the specifications and design. Encourage up-front thinking and you will be better able to maintain project focus as it proceeds.
The context of change control for documentation, source, and
resources. List how revision control will be accomplished, where the
revision control is located, who has access, etc.
Audit Plan
How do we know we did a good
job? Testing and Peer Review should be addressed here. Reference
previous documentation via hypertext link.
MODULE DESIGN
Functional Requirements
A
statement of the module purpose with a list of functions the module must
perform. List requirements for this module only. Principles to remember are
that individual modules should be cohesive and loosely coupled.
Cohesive means that the module is designed to do one job well. Loosely
coupled means that interfaces are few and no assumptions are made.
Environment
PLATFORM
Indicate the platform on which this
module resides.
LANGUAGE/TOOLS
Indicate the
programming language and any specific development tools used to create and
compile this module.
LIBRARIES
Indicate any programming
libraries required by this module.
EXTERNAL CONDITIONS
List any
external conditions that are not listed in the System Design or that apply
only to this module.
PROCESS DEPENDENCIES
List any
processes that must be active when this module executes.
OUTPUT QUEUES
List any required
output queues here.
PATH REQUIREMENTS
Specify whether
any assumptions are made concerning the locations of information, required
path settings, etc.
Inputs/Outputs
PARAMETERS
List parameters and data types,
and indicate desired function. This info will be used to build the
help switch info for interactive modules.
EXTERNAL VARIABLES
List all
external variables to be used in this module. List their names, data types,
and usage (In/Out/Both)
FILES / TABLES
List all files and
data tables to be used in this module.
File/Table Name
Usage (Input/Output/Update)
Index / Path
Database
OTHER OBJECTS
List anything important
that I forgot.
SCREEN LAYOUTS
This should be a
graphical representation of the screen(s) or window(s), if applicable.
PROGRAM MESSAGES
List all
messages, error or other type, used or issued by this module to other
modules, users or applications. Do not include system generated
error messages.
REPORT LAYOUTS
This should also be a
graphical representation of the report. Fields should be labeled and
described in a key.
Process Specifications
FUNCTIONAL
REPRESENTATION
Possible entries here:
Flowchart
Data Flow Diagram
Graphically depict all components of the module and their
relationships in a hierarchical format following guidelines presented in
Hoskyns MADP course. (basically it's an organization chart depicting
functions instead of people).
Whatever creative method that does the trick and concisely gives a
visual overview of what this thing does.
PSEUDOCODE
Include a functional outline or
pseudocode or action diagram if it isn't too repetitious. You may
want to pseudocode only those functions that aren't immediately obvious from
looking at the Functional Representation.
CALLING & CALLED
MODULES
List all modules that will call this module with entry parameters,
if any.
List all modules that will be called by this module and any
necessary parameters to pass.
Describe data that will populate parameters.
ERROR HANDLING
List all internal
error handling processes or subroutines. Reference external error
handlers.
PROGRAM AUDIT TRAIL
List
procedures and checkpoints to be used to verify program results. Describe
any logging functions performed by the module.
Help Text
Specify where the help text
resides. An exhibit can be used to show the text and how it will be
displayed. Depending on how the project is structured, "Help" may be a
seperate module. If so, you still should create suggested help
information so that it can be catalogued and packaged with the remainder of
the help system. The rest of this document will be important for the
same reason.
UNIT TEST PLAN
Data Requirements
Make sure enough data is included in test files to trigger every condition that must be tested, and that there is a sufficient variety of legal parameters and external variables be indicated for the same reason. You'll want to include known invalid input to test error handling.
Test Script
Provide a script that can be
used to test this particular module. Expected results are entered when
the test is designed. Actual results are filled in when the module is
tested.
Step
Action
Input Data
Expected Result
Actual Result
#
Unit Test Control
Specify any
controls or features to be applied to the unit test environment
specifically.
