Re: Sample software requirement docs

[Ned Bedinger <nbedinger -at- USWEST -dot- NET>]

--------------------------------------------
An example of a Functional Design
--------------------------------------------

I once developed templates based on the .  The developers I worked
with had a variety of reasons for not using SLM, but as far as
documentation is concerned, SLM provided cogent source material and myriad
opportunities for me to work alongside the developers, updating their docs
or gathering info for my own writing tasks.

The following template for functional design is an excerpt from the SLM
(Carnegie-Mellon System Lifecycle Management methodology for software
development), and is
copyrighted. Sorry about the formatting, you'll have to do a little work on
it if you're a visual thinker.

I post it as an example of how a Functional Design spec CAN be generalized
and yet be specific enough to code from. I believe Carnegie-Mellon
developed this methodology for government work (NASA supposedly uses it),
so your MIL group might have access to a more
current version of the entire lifecycle methodology. They tend to cast it
more now as Process Maturity than Lifecycle, I think.  Please (everybody)
give them credit and do not represent this as anything but their work,
which is not in the public domain.

1.      FUNCTIONAL DESIGN
1.1.    Functional Design Document
1.1.1.  Data flow diagram (DFD)
A graphic depiction of an existing or proposed system or a portion of a
system.  The DFD breaks the system into functional pieces, showing all
interfaces between components and consists of processes, sources,
destinations and stores the data.  The DFD answers the following four
questions:
What processes make up the system?
What data is used in each process?
What data is stored?
What data enters and leaves the system?
A data flow diagram is easily understood by the client and powerful enough
to show parallel activities.
1.1.2.  Process flowchart
A graphic representation of the new business and/or system flow focusing on
both manual and automated procedures including depiction of all decision
points.  This is often the predecessor to the system flowchart.
1.1.3.  Transaction descriptions
Descriptions of the expected types of transactions and any unique
indicators identifying transactions of special interest.
1.1.4.  Process descriptions
Detailed descriptions of the processes outlined in the process flowchart.
1.1.5.  Menu structures
A description of the purpose of each menu in the system, a graphics layout
of each menu, what options are available from each menu, and how many
levels there are.
1.1.6.  Input descriptions
A description of the information that comes into the system.  It specifies
how the data enters the system (e.g., screen, tape, form/document, data
stored in a file or database) and what the format and content are.

ID

Title

Purpose

Sort

Field descriptions

Field edits

Field navigation

Data characteristics

Default values

Sample

1.1.7.  Output descriptions
A description of the information that leaves the system.  It specifies how
the data leaves the system (e.g., screen, tape, form/document, data stored
in a file or database) and what the format and content are.
ID

Title

Purpose

Sort

Field descriptions

Data characteristics

Media

Distribution

Frequency

Sample

1.1.8.  Interface descriptions
A description of what other systems are affected and how.  It identifies
what data is passed and with what frequency.
1.1.9.  Access levels
A definition of what groups need what types of data.  Data ownership and
responsibility are identified with information as specific as possible in
classifying levels of access (read, write or update), which may be detailed
to the field element level.
1.1.10. Data function matrix (CRUD)
A high-level mapping of functions to entities which insures that the
required data is available to support all functions and that all data is
required.  For example, a Create, Read, Update, and Delete (CRUD) Matrix.
1.1.11. Technology requirements
Identification of what needs to be in place to allow the system to function
with respect to the hardware, database management system (DBMS), software
and network.  What is currently available and what is yet needed is itemized.
Hardware

Software

Network
1.1.12. Implementation strategy
A high level overview of the approach to be used to transform the system
from a test to a production system.  The strategy used is closely tied to
the conversion plan and selects the most appropriate implementation method
for the project.  Four widely accepted implementation methods are
:parallel, direct cut-over, pilot, and phased-in.  The implementation plan
and the conversion plan containthe details of the implementation strategy.

1.1.13. Acceptance test plan
A document identifying the test strategy and test data to be used to test
for customer acceptance of the new system.  The plan describes specific
acceptance and non-acceptance criteria.
1.1.14. Conversion plan
A plan for conversion of three arenas must be addressed: data, technology,
and process.  Will existing data be impacted ?  Will new data require
initialization?  What (if any) algorithms are involved to convert old
records to new formats?

1.2.    Customer documentation
The material the customers will use in operating the systemduring the life
of the system.
1.3.    Next phase plan
A detailed schedule of the tasks, milestones, and people involved in the
project phase being planned.

------------------------------------------

Hope this helps.

Edward Bedinger
Technical Communications
Edword Co.
206-782-0378

---------------------------------------------------------------------------
If this were merely my opinion, I'd probably keep it to myself.
My employer is not responsible for my expressions.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=