Specifications
A document intended
primarily for use in procurement, which clearly and accurately describes the
essential technical requirements for items, materials, or services including
the procedures by which it will be determined that the requirements have
been met.
Systems Engineering Guidebook,
James N. Martin, CRC Press, pg. 211
Relationship between SOW and
Specifications.
The SOW defines (either
directly or by reference to other documents) all work (non-specification)
performance requirements for contractor effort. Technical design and performance requirements are contained in
specifications. Such specifications are typically referenced in the
SOW, but specific technical requirements should
not be spelled out in the SOW. Together, the specification and SOW
provide what a contractor needs to know in order to prepare a proposal or
bid in response to a Request for Proposals (RFP). The contract
references and supplements the specification and statement of work.
Choosing
the Type of Specification. Simple guidelines are provided below to assist in choosing the
appropriate type of specification. Format guidelines are also provided.
Development
Specifications.
A document which states
performance, interface, and other technical requirements in sufficient
detail to permit design, engineering for service use, and evaluation.
The
General Requirements Document (GRD) and
System Requirements Documents (SRDs which are the tier of specifications immediately below the
GRD) are development specifications.
Lower tier development specifications may also be generated.
Development specification should be maintained current
during production when it is desired to retain a complete statement of
performance requirements.
Format guidelines
for development specs are provided
here.
Product
Specifications
A
document applicable to a production item below the system level which
states item characteristics in a manner suitable for procurement,
production, and acceptance.
Product specifications are oriented toward
procurement or fabrication of a product through specification of primarily performance
requirements or detail design requirements.
Performance Specifications. A
performance specification is used
for for procuring a
component by specifying its functionality - the supplier does the
design. It states requirements in terms of the
required results and provides criteria for verifying compliance, but it
does not state methods for achieving results. It defines the
functional requirements for the product, the environment in which it must
operate, and the interface and interchangeability requirements.
Detail Specifications.
A detail specification is
used for procuring or
fabricating a component by specifying its design - the project
does the design. It specifies design requirements such as
materials to be used, how a requirement is to be achieved, or how an item
is to fabricated or constructed.
Performance and detail
specifications use a common 6-section format (7-sections including
appendices).
Format guidelines for
product specs are
provided
here.
A comparison of the content for
performance and detail specifications is provided
here.
Product Requirements Lists.
Product requirements lists (PRLs) are used for purchasing commercially
available items. PRLs should describe, by functional or performance
characteristics, the available, acceptable commercial products that will
satisfy the Project's needs.
The
format of the PRL is at the discretion of the originator. However, PRLs
must be referenceable documents, signed, and subject to revision control.
Specification Do's and
Dont's
-
Specifications should include all and only those requirements needed to
establish suitability for the intended purpose.
Requirements be so written that compliance with all requirements will
assure the suitability of the item for its intended purpose, and
non-compliance with any requirement will indicate unsuitability for the
intended purpose. Only requirements that are necessary and practicably
attainable should be specified.
-
Requirements should be quantitative rather than qualitative. The
specification must ensure that parties submitting proposals or bids - and
those evaluating them - are equally clear on exactly what the requirements
are. Requirements that are not based on quantitative data are subject to
varying interpretations and misunderstanding.
-
Requirements should be verifiable. The project must be able to
determine through analysis, inspection, or test if a product will perform
as required. Verifiable requirements also assist the manufacturer. By
specifying how a requirement will be verified, the manufacturer has a
clearer idea of what is required.
-
Specifications should exclude unnecessary information. Use the
"What if I left this out?" criterion.
Style Instructions. Specifications should be prepared in the same
style as other controlled documents.
Style instructions for document
preparation are provided
here.
A
sample specification is provided
here.
NCSX v. PPPL Spec Guidelines. PPPL has a procedure for
preparation, review, and approval of specifications and statements of work (ENG-006).
Differences are summarized below.
-
NCSX guidelines provide a clear distinctions between what belongs in a
spec and what belongs in a SOW. ENG-006 does not. There is overlap in the ENG-006
guidelines for specifications and SOWS For instance, ENG-006
guidelines for Section 4 - Test and Inspection Requirements are identical
for specifications and SOWs. Non-technical requirements such as QA
Program requirements, documentation requirements, and deliverables are
strictly in SOWs per the NCSX guidelines whereas they can appear in both
documents in ENG-006.
-
NCSX guidelines require a correspondence between requirements in
Section 3 and how it will be determined that those requirements have been
met in Section 4. ENG-006 does not mandate verification of the
requirements in the specification.
-
ENG-006 provides useful content guidance.
NCSX personnel are encouraged refer to ENG-006 in considering what
requirements should be applied to the contractor effort. However,
NCSX format guidelines should be followed for determining whether those
requirements belong in a specification or SOW.
|
