| Well, since no one stepped forward, I went ahead and converted the
.RNO file I had. The results follow the <FF>. Enjoy.
<FRONT_MATTER>
<TITLE_PAGE>
<DEFINE_SYMBOL>(PRODUCT_NAME\prod_name)
<DEFINE_SYMBOL>(VERSION_NUMBER\vers_number)
<DEFINE_SYMBOL>(DRAFT_NUMBER\draft_number)
<TITLE>(Design Specification for\<REFERENCE>(PRODUCT_NAME)
<REFERENCE>(VERSION_NUMBER))
<LINE>(BIGSKIP)Draft <REFERENCE>(DRAFT_NUMBER)
<LINE>(SMALLSKIP)<DATE>
<SIGNATURES>(NEWPAGE)
<SUBHEAD1>(Issued by:)
<BYLINE>(??\Project Leader)
<BYLINE>(??\Supervisor)
<SUBHEAD1>(Approved by:)
<BYLINE>(??\Funding Manager)
<BYLINE>(??\Development Manager)
<SUBHEAD1>(Reviewed by:)
<BYLINE>(??\Product Manager)
<BYLINE>(??\Implementer)
<ENDTITLE_PAGE>
<CONTENTS_FILE>
<PREFACE>
<P>This is a design specification for <REFERENCE>(PRODUCT_NAME>
<REFERENCE>(VERSION_NUMBER). It is intended to serve as a guide to
developers working on the project. It is <EMPHASIS>(not) intended for use,
review, or information by anyone not directly involved with the project.
This document will be revised as design decisions are made and/or altered to
ensure the success of the project.
<SUBHEAD1>(Associated Documents)
<LIST>(NUMBERED)
<LE>To be supplied
<ENDLIST>
<SUBHEAD1>(Revision History)
<TABLE>
<TABLE_ATTRIBUTES>(\MULTIPAGE)
<TABLE_SETUP>(3\10\7)
<TABLE_HEADS>(Date\Issue #\Description/Summary of Changes)
<TABLE_ROW>(<DATE>\<REFERENCE>(DRAFT_NUMBER)\Current state of document)
<ENDTABLE>
<ENDPREFACE>
<ENDFRONT_MATTER>
<RUNNING_TITLE>(<REFERENCE>(PRODUCT_NAME) Design Spec\Draft
<REFERENCE>(DRAFT_NUMBER))
<RUNNING_FEET>(Company Confidential -- Do NOT distribute)
<HEAD1>(INTRODUCTION)
<COMMENT>
This section is, in effect, a mini functional specification to
introduce the reader to the product. Relate briefly how the product
fits with other products in the product line and define briefly the
nature of the targeted user of the product.
<ENDCOMMENT>
<HEAD1>(PROJECT CONVENTIONS)
<HEAD2>(Implementation Language)
<COMMENT>
Define the nature of the source language used for coding the product.
<ENDCOMMENT>
<HEAD2>(Labels and Symbols)
<COMMENT>
Describe labels and symbols and any special conventions for deriving them.
<ENDCOMMENT>
<HEAD2>(Subprogram Interfaces and Calling Sequences)
<COMMENT>
Describe standards and conventions for passing of data and control between
programs.
<ENDCOMMENT>
<HEAD2>(Data Formats and Representations)
<COMMENT>
Describe data formats for:
o Memory
o Off-line storage on various media in configuration
o Communication between programs
o Transmission over remote links
Note and explain any deviations from DEC standards.
<ENDCOMMENT>
<HEAD2>(Default Condition Handling Philosophy)
<COMMENT>
Describe the philosophy of handling default conditions (that is, "What
assumption does the product make when there are no explicit directions given
to it?")
<ENDCOMMENT>
<HEAD2>(Error and Exception Reporting)
<COMMENT>
Describe the symbols, formats, and code sequences for dealing with error and
exception conditions. Define the conventions and standards for interprogram
error communications as well as for communication with the operator and users
of the system.
<ENDCOMMENT>
<HEAD2>(Unusual Conditions Treatment Philosophy)
<COMMENT>
Describe how the product deals with rare or "impossible" conditions arising in
the code.
<ENDCOMMENT>
<HEAD1>(DESIGN OVERVIEW)
<COMMENT>
This section describes, in narrative form, the major modules of the product
and their operation. In "top-down" fashion, narrate first the overall
operation of the system, identifying the key components, and then the
architecture of each of the major components. Make liberal use of visual
(block diagrams, macro-level flow charts, information on significant
intermodule communication, and so on, to help the reader obtain a good
architectual overview. The intent is not to delve into significant details at
this point in the specification, but to provide the reader with a good
conceptual understanding of the product's design.
<ENDCOMMENT>
<HEAD1>(TABLES, QUEUES, AND BUFFERS)
<COMMENT>
This section defines all key tables, queues, and buffers utilized in the
product. Spell out table layouts, with the definition of each field in the
tables, queues, and buffers. Where possible, provide additional information
(Such as who enters or retrieves data from each field in the table, queue or
buffer). Narrate or depict the key interfaces betweem tables, queues and
buffers and spell out explicitly all limitations and restrictions.
<ENDCOMMENT>
<HEAD1>(OVERVIEW OF MAJOR MODULES)
<COMMENT>
The design overview (Section 3.0) provides a "top-down" look at the
architecture and major modules of the overall product. This section provides
the design overview of each of those major modules in a similar fashion. In
essence, this is the next level of detail in the description of the product's
implementation.
<ENDCOMMENT>
<HEAD1>(KEY ALOGRITHMS)
<COMMENT>
This section defines and describes the key alogrithms used in coding the
product and the rationale for their selection.
<ENDCOMMENT>
<HEAD1>(MAINTAINCE AND DIAGONSTIC TOOLS AND PROCEDURES)
<COMMENT>
This section describes all the tools and recommended procedures for maintaince
of the product and the diagnosis of faults in the system. Where appropriate,
include listings of symptoms and cures, "cookbook"-like methods, and so on.
<ENDCOMMENT>
<HEAD1>(SYSTEM TEST DESCRIPTION)
<COMMENT>
This section describes how the product will be quality assured. Include a
definition of the strategy for testing (embedded code, limit checks, methods,
and so on) and the architectural descrition of the system test package. In
general, this section should be a microcosm of the entire Product Design
Specification Outline.
<ENDCOMMENT>
<APPENDIX>(NAME OF APPENDIX)
<ENDAPPENDIX>
|