| I got the following template from the old DOCUMENT conference and
converted it to BL07. I use the DOCPLAN doctype to get the signature
stuff on the title page to come out right. It originally had different
tags ( <BYLINE> instead of <BY>, I think) that didn't work in BL07 but
may work in BL08 (which we don't yet have on our cluster, sniff).
-- Nina
P.S. This may or may not be what you're looking for, Rose...
<COMMENT>(****Version 1****)
<comment>*************************************************************
This template contains the SDML coding necessary to produce a
functional specification using the DOCUMENT system. Follow the comments
in this file as a guide to entering text.
To process the file, use:
$ DOCUMENT filename DOCPLAN LN03
(DOCPLAN is a CUP-internal doctype used at ZK. It is a modification of
GENERAL.)
*****************************************************************
A SPECIFICATION is the definitive description in measureable terms of the
goals, capabilities, and external characteristics of a Component Software
Product. It is the commitment of WHAT IS TO BE BUILT as agreed by the
Product Team. (Refer to Phase Review Policy, SDP&P: 7A8-2 for a definition
of the Product Team.)
It is written in response to the Product Requirements. It also usually
corresponds to a reference from a System Specification.
It is the starting point for the design of the product, for identifying the
tasks involved, and for estimating the resources needed to deliver the
product. It is the measure against which the product is evaluated. It is
also used by the Service Organizations and by other Engineering groups,
both Hardware and Software, to plan other components of the System.
Where appropriate the task(s) to achieve and/or verify the goals may be
stated together with the goal in the Specification. A cross-reference
should be made from Section 2 of the Development Plan.
Use the following two questions to determine the appropriate level of
detail in a Specification. The goal is to be able to answer "Yes" to both.
o Can a technical writer produce the user
documentation from this Specification?
o Can comprehensive test cases be developed and the
expected test results determined from this Specification?
The format for a Component Software Product SPECIFICATION is as follows.
***********************************************************<endcomment>
<RUNNING_TITLE>(COMPANY CONFIDENTIAL)
<FRONT_MATTER>
<TITLE_PAGE>
<DATE>
<comment>(This will default to day, month, and year of tag translation.)
<Comment>**********************************************************
The following definitions are referenced in this template. You *must* define
values for these user-defined symbols. If you want, you can reference your
product and version throughout the specification using the names
<REFERENCE>(product_name) and <REFERENCE>(version_number). In the event of name
or version number changes, all you will need to do is to change the definitions
of these tags. For example, you could write a sentence,
<p><REFERENCE>(PRODUCT_NAME) runs on all VAX/VMS systems Version 4.0 and above.
To define symbols, use the <DEFINE_SYMBOL> tag as shown below. If you use it,
replace the second argument (in lowercase) with your product name and version
number.
**********************************************************<endcomment>
<DEFINE_SYMBOL>(PRODUCT_NAME\product-name)
<DEFINE_SYMBOL>(VERSION_NUMBER\version-number)
<TITLE>(Component Software Product\
Specification for\
<REFERENCE>(PRODUCT_NAME) <REFERENCE>(VERSION_NUMBER))
<comment>
For each of the following name lists, you can
add additional names using <BY> tags
Modify or augment the <SUBHEAD1> tags for lists of authorities,
reviewers, and so on.
<endcomment>
<SIGNATURES> <comment>Begins the signature section. Specify
<SIGNATURES>(NEWPAGE) if you want this to
be on a separate page.If you want some
signatures on the first page and some on
the next you can terminate the titlepage
and start a new one as follows:
<ENDTITLE_PAGE>
<TITLE_PAGE>
<SIGNATURES>(NEWPAGE)
<SUBHEAD1>(text)
<BY>(name)
...
<ENDTITLE_PAGE>
<endcomment>
<SUBHEAD1>(Written by:)
<BY>(name\title)
<SUBHEAD1>(Issued by:)
<BY>(name\title)
<SUBHEAD1>(Review Team:)
<comment>enter as many <by> tags as
needed.
<endcomment>
<BY>(name\title)
<ENDTITLE_PAGE>
<comment>
Delete this line or place comment
tags around it if you do not want
to include a table of contents.
<endcomment>
<CONTENTS_FILE> <comment>
To include a table of contents file using
DOCUMENT BL07, follow the procedure described
in the release notes.
<endcomment>
<PREFACE>
<p>
This is a Component Software Product Specification. It is the definitive
description in measureable terms of the goals, capabilities, and external
characteristics of <REFERENCE>(PRODUCT_NAME) <REFERENCE>(VERSION_NUMBER). It is
the commitment of WHAT IS TO BE BUILT as agreed by the Product Team.
<p>
No changes are to be made to the product as described here, unless approved
and documented as an amendment to this Specification.
<comment>*************************************************
The default headings supplied for the preface are
<SUBHEAD1>(Associated Documents)
<SUBHEAD1>(Change History)
You can add headings using <SUBHEAD1>(heading) tags.
***********************************************<endcomment>
<SUBHEAD1>(Associated Documents)
<comment>modify text for each <LE> tag or
add additional tags as needed.
<endcomment>
<LIST>(NUMBERED)
<LE>Description...
<ENDLIST> <comment>End of Associated documents list<endcomment>
<SUBHEAD1>(Change History)
<comment>modify the following and add as many as needed.
<endcomment>
<TABLE>
<TABLE_ATTRIBUTES>(\MULTIPAGE)
<TABLE_SETUP>(3\10\7)
<TABLE_HEADS>(Date\Issue #\Description/Summary of Changes)
<comment>Use as many <TABLE_ROW> tags as required,
using the samples shown as a guide. If you
have a long list, use the tags
<TABLE_ROW_BREAK>(FIRST) and
<TABLE_ROW_BREAK>(LAST) to allow the
table to break across pages.
<endcomment>
<TABLE_ROW>(Date\#\Description)
<TABLE_ROW>(Date\#\Description)
<TABLE_ROW>(Date\#\Description)
<ENDTABLE>
<ENDPREFACE>
<ENDFRONT_MATTER>
<RUNNING_TITLE>(Digital Equipment Corporation --- Software Specification\Company Confidential)
<HEAD1>(Product Summary)
<p>
<comment>A brief summary of key aspects of the
product in order to put this component software
product into perspective as a DIGITAL offering.
<endcomment>
<HEAD1>(Environment)
<P>
<comment>Description of all aspects of the environment
in which this component software product is expected
to be used.<endcomment>
<HEAD2>(Users)
<P>
<HEAD2>(Hardware)
<P>
<HEAD2>(Software)
<P>
<HEAD2>(Services)
<P>
<HEAD1>(Software Capabilities)
<P>
<comment>Complete description of everything that
can be observed from outside the product.
Use the sections that are appropriate.
<endcomment>
<HEAD2>(User Interface)
<P>
<HEAD2>(Hardware Interface)
<P>
<HEAD2>(Other Software)
<p>
<comment>include:
- all inputs and outputs such as commands,
qualifiers, switches, parameters,
files, screen layouts, messages.
- other less obvious items such as
sense switches, lights, peripheral
modes, voltages, device positioning,
calling sequences and condition codes.
- all formatting and validation rules.<endcomment>
<HEAD1>(Publications)
<P>
<comment>Description of the purpose and content
of each book in the publications set.<endcomment>
<HEAD1>(Packaging)
<P>
<comment>Description of aspects of the product
to do with initial presentation and
appearance of the package, to the user.<endcomment>
<HEAD1>(Installability)
<P>
<comment>Description of aspects of the product
that the user perceives from the time
the package is opened, to the time the product
can be put to the use for which it was purchased.<endcomment>
<HEAD1>(Ease of Use)
<P>
<comment>Description of characteristics that
tailor the human interface of the
product to fit the needs of the target user.<endcomment>
<HEAD1>(Performance)
<P>
<comment>Description of the characteristics of
the product under normal operating conditions
and also under extreme or fringe conditions.<endcomment>
<HEAD1>(Reliability)
<P>
<comment>Description of product characteristics
that affect the user's ability to get
tasks accomplished in a dependable, predictable
manner.<endcomment>
<HEAD1>(Maintainability)
<P>
<comment>Description of the characteristics that
will enable ease of diagnosis and correction
of problems in the product.<endcomment>
<HEAD1>(Maintenance)
<P>
<comment>Description of the Maintenance Service
planned for this product.<endcomment>
<HEAD1>(Compatibility)
<P>
<comment>Description of the characteristics that
enable the user to move to this product
from the existing product without undue disruption,
and to use this product with other DIGITAL
and non-DIGITAL products with maximum ease.<endcomment>
<HEAD2>(Product Compatibility)
<p>
<HEAD2>(Standards Conformance)
<p>
<HEAD2>(Internationalization)
<P>
<HEAD1>(Evolvability)
<p>
<comment>Description of the characteristics that
enable the product to be:
- adaptable to suit a changing environment.
- extendable as needed, both by DIGITAL and by
the user.
- transportable to follow migration paths as needed.<endcomment>
<HEAD1>(Costs)
<P>
<comment>Statement of constraints associated with:
- the cost of the project to DIGITAL
- the cost of the product to the User.<endcomment>
<HEAD1>(Timeliness)
<P>
<comment>Statement of constraints associated with
the schedule for delivery of the product.<Endcomment>
<HEAD1>(Constraints)
<P>
<comment>Statement of additional special constraints,
and the tradeoff priorities, if any, assigned to
the goals, capabilities and external characteristics
described in Sections 2 through 15.<endcomment>
<BACK_MATTER>
<APPENDIX>(Draft SPD)
<P>
<ENDAPPENDIX>
<APPENDIX>(Outstanding Issues)
<P>
<comment>List of outstanding issues referenced
by number, with names of people
responsible and completion dates.<endcomment>
<ENDAPPENDIX>
<comment>
Insert additional appendixes as required using the <tag>(APPENDIX) tag. Each
appendix started with the <APPENDIX>(Outstanding Issues) tag must be terminated
with the tag <ENDAPPENDIX>
<endcomment>
<ENDBACK_MATTER>
|