TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Software functional spec From:jean-daniel_gross -at- millipore -dot- com To:techwr-l Date:Mon, 28 Feb 2000 2:50:27
Hello,
In the pharmaceutical industry, the machines running with PLC's and so far
using software's are based on "Software Functional Specifications" issued
during Engineering and part of the documentation delivered by manufacturer
to end user.
The FS content has been clearly fixed by the ISPE organization into a
guideline called "GAMP3" = Good Automated Manufacturing Practice" currently
Version3, see http://www.ispe.org
The Good Automated Manufacturing Practice (GAMP) Supplier Guide explains
the procedures to be followed, recommended documentation, terminology and
working methods which should be used by suppliers of automated systems to
the pharmaceutical industry to enable users to more easily validate these
systems and assist compliance. The GAMP Guide is now the de facto guide for
Suppliers of Validation of Automated Systems.
In this book, you can read:
Functional Specification
A functional description of the system is developed, covering Mechanical,
Electrical/Hardware and Software elements. Mechanical functionality is
normally defined first, followed by the high level architecture of the
electrical parts, followed by the functions of the controlling software.
The Functional Specification is normally an outline document which
demonstrates compliance, or otherwise, of the functional design with the
User Requirements Specification. Detailed design, architecture etc. is
usually described in the design documents. The following points should be
considered:
The Functional Specification should provide the basis for the development
of the mechanical drawings. The specification should therefore detail the
various stages of the production process.
The Functional Specification should address the modes of operation, the
stoppage conditions, reset operations, signalling and use of interfaces,
the controls carried out and every alarm accompanied by its consequence on
the status of the equipment. It is recognised that, on certain projects,
some of these aspects might be better defined at a later stage, in the
design documents.
Information necessary to define the software is often defined within the
Electrical Diagrams. For example, it is necessary to know exactly what
instrumentation, motors, valves, sensors, etc. are to be installed on the
machine before a full specification of the software that controls such
equipment can be produced. As a consequence, the development of the
software specification overlaps, and often follows, the production of the
Electrical Diagrams (see below). It is therefore often more appropriate to
include software detail in the Software Design Specification.
.../...
Jean-Daniel Gross
Sr Tech Writer and Validation Engineer
