LE FastCounter
Foreword
The System/subsystem specification (SSS)
specifies the requirements for a system or subsystem and the methods
to be used to ensure that each requirement has been met. Requirements
pertinent to the system or subsystem external interfaces may be
presented in the SSS or in one or more interface requirements
specifications (IRSs) and referenced from the SSS. Reference SSSDID
for more information.
Insert the "Table of Contents" here.
Consult DI-IPSC-81431 and 'Documentation Standard' when preparing this document.
Identify the system to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
State the purpose of the system or subsystem to which this document applies.
Summarize the purpose and contents of this document.
This document comprises of six sections:
Describe any security or privacy considerations associated with its use.
Identify the project management systems documents
here.
e.g., Project Plan, System Engineering Management Plan, Configuration
Management Plan, Documentation Standard, etc.
The
This section shall be divided into paragraphs to
specify the system requirements, that is, those characteristics
of the system that are conditions for its acceptance. Each requirement
shall be assigned a project-unique identifier to support testing
and traceability and shall be stated in such a way that an objective
test can be defined for it.
Each requirement shall be annotated with associated qualification
method(s) (see section 4) and, for subsystems, traceability to
system requirements (see section 5), if not provided in those
sections. The degree of detail to be provided shall be guided
by the following rule: include those characteristics of the system
that are conditions for system acceptance; defer to design descriptions
those characteristics that the acquirer is willing to leave up
to the developer. If there are no requirements in a given paragraph,
the paragraph shall so state. If a given requirement fits into
more than one paragraph, it may be stated once and referenced
from the other paragraphs.
If the system is required to operate in more than
one state or mode having requirements distinct from other states
or modes, this paragraph shall identify and define each state
and mode. Examples of states and modes include: idle, ready, active,
post-use analysis, training, degraded, emergency, back-up, wartime,
peacetime.
The distinction between states and modes is arbitrary. A system
may be described in terms of states only, modes only, states within
states, or any other scheme that is useful. If no states or modes
are required, this paragraph shall so state, without the need
to create artificial distinctions. If states and/or modes are
required, each requirement or group of requirements in this specification
shall be correlated to the states and modes. The correlation may
be indicated by a table or other method in this paragraph, in
an appendix referenced from this paragraph, or by annotation of
the requirements in the paragraphs where they appear.
Itemize the requirements associated with each capability of the system. A "capability" is defined as a group of related requirements. The word capability may be replaced with "function", "subject", "object", "or other term useful for presenting the requirements.
Identify the required system capability and itemize the requirements associated with the capability. If the capability can be more clearly specified by dividing it into constituent capabilities, the constituent capabilities shall be specified in subparagraphs.
Specify the requirements, if any, for the system's external interfaces. This may reference one or more 'Interface Requirements Specifications' (IRSs) or other documents containing these requirements.
Specify the requirements, if any, imposed on interfaces internal to the system. If all internal interfaces are left to the design or to requirement specifications for system components, this fact shall be so stated. If such requirements are to be imposed, see previous paragraph (3.3) for a list of applicable topics.
Specify the requirements, if any, imposed on data internal to the system. Include requirements, if any, on databases and data files to be included in the system. If all decisions about internal data are left to the design or to requirements specifications for system components, this fact shall be so stated. If such requirements are to be imposed see 3.3 for a list of topics.
Specify the requirements, if any, pertaining to system quality factors. Examples include quantitative requirements concerning system functionality (the ability to perform all required functions), reliability (the ability to perform with correct, consistent results; such as mean time between failure for equipment), maintainability (the ability to be easily serviced, repaired, or corrected), availability (the ability to be accessed and operated when needed), flexibility (the ability to be easily adapted to changing requirements), portability of software (the ability to be easily modified for a new environment), reusability (the ability to be used in multiple applications), testability (the ability to be easily and thoroughly tested), usability (the ability to be easily learned and used), and other attributes.
Specify the requirements, if any, that constrain
the design and construction of the system.
For system-level specifications, this paragraph does not apply. For subsystem-level specifications, this paragraph shall contain:
This section contains information of a general or explanatory nature that may be helpful, but is not mandatory.
This system/subsystem specification shall ...
Insert here an alphabetic list of definitions and their source if different from the declared sources specified in the 'Documentation standard'.
Insert here an alphabetic list of the abbreviations and acronyms if not identified in the declared sources specified in the 'Documentation Standard'.
Will be "not applicable" for the initial issue.
Revisions shall identify the method used to identify changes from the previous issue. i.e., change bars, etc.
See also system/subsystem specification - DID
This page is under construction
Back to Home page MANAGING STANDARDS Home page
Please send any beneficial comments or identification of errors
using the following form to: kenr@wysywig.airtime.co.uk