Re: Systems Specifications Documentation

[Suzy Davis <andavis -at- AU1 -dot- IBM -dot- COM>]

Hi y'all
Sent this out when someone else asked, so I'm going to the list this time.

Here is an overview of Functional Specification document content.

I haven't checked out any standards for a long time, so I'm not sure what else
they would add.  The standards that should be checked are the Quality or Best
Practice standards your company might have as these may document the
requirements for any specification for Quality accreditation purposes.

Typically the Functional Specifications documents I create are the high level
system design documents for clients to sign-off.  The document is produced by
the software developer/consultant for the client usually from details discussed
and finalised at a system design meeting, or series of meetings between
developers, users and client IT managerial staff.

Sometimes the details are obtained by interviewing client representatives.
Depends on how large the system is.

The Functional Specification document details the functions (system procedures)
of the system to be designed.

The bulk of the document contains a section for each function, or group of
functions performed by the system.  Each function section typically contains a
process flow chart, process flow text (textual expanation of the chart),
Function Definition, Purpose, Description, Process Flow Rules, Business Rules,
Minimum Data Requirements (for the process), Process Rules, Scripting
Requirements, Reporting Requirements and Interfaces.

The appendices may include Issues(which lists issues which need to be resolved
before development or implementation (but couldn't be at the time of the design
meeting/s)),  Assumptions, Design standards , System Constraints , Risks,
Implementation Considerations.

I usually also include summaries of reports required, screens, as these are
often useful to have when moving to the development phase.

The beginning of the document usually has an overview which provides background
in the same way as an Executive Summary might, time frames, generic rules etc,
objectives and scope of the project.

Of course, these vary from place to place, and project manager to project
manager - they all seem to be very particular about what goes in and what
doesn't.

(Detailed Specifications are similar but are for the developers (not clients)
and so need to refer to the funky spec but typically do not contain any chatty
overview info.  The Detailed Spec documents the processes within the process
flows described in the funky spec.  Different systems and projects do have
different requirements for what is included in the detailed spec document).

Hope this helps, and I'm happy to further clarify if necessary (I can't show
you any examples however).


Suzy Davis
Technical Writer

Internet:  andavis -at- au1 -dot- ibm -dot- com
[Standard disclaimer]



 TECHWR-L @ LISTSERV.OKSTATE.EDU
 02/11/98 07:16 PM
Please respond to fred_ri -at- ENG -dot- PRINTRONIX -dot- COM @ internet

To: TECHWR-L @ LISTSERV.OKSTATE.EDU @ internet
cc:
Subject: Re: Systems Specifications Documentation

Well why don't we just get all the responses online, since I would love to get
the info also.

Thanks,
        Richard

--------------------------------------------------------------------------
Richard Frederick                       email:  fred_ri -at- eng -dot- printronix -dot- com
Printronix, Inc.                        Phone:  714.221.2507
Technical Publications                  FAX:    714.660.8682
--------------------------------------------------------------------------

On Wed, 11 Feb 1998, Julie F. Sullivan wrote:

> Does anyone have a set of standards for system specification documents? I
> need to provide my employer with a standard format. I'm particularly
> interested in what information should be included and how it should be
> organized. You can replay to me offline.
>
> julie sullivan
> jsullivan -at- oxmol -dot- com
>


~