The operational requirements for the specific project
shall be stated in the 'System/subsystem specification' and will
be reviewed at regular intervals.
Impacts on the stated system operational characteristics, mission
objectives, threat, environmental factors, minimum acceptable
system functional requirements, technical performance, and system
figure(s) of merit stipulated, proposed, or directed for change
shall be analyzed during the conduct of the contract.
These impacts shall be examined continually for validity, consistency,
desirability, and attainability with respect to current technology,
physical resources, human performance capabilities, life cycle
costs, or other constraints.
The output of this analysis shall verify the existing requirements
or develop new requirements which are more appropriate for the
mission.
Mission requirements and its operational, support and the functions
and characteristics of the computer system within the overall
system together with the identification of the system development,
support, and users within the acquirer organizations shall be
described in a 'System/subsystem specification(s)' and the specific
'Operational concept document'.
Acquisition streamlining (in accordance with the principles of
MIL-STD-248) shall be performed to ensure project acquisitions
are effective and efficient. Acquisition streamlining shall be
performed for all new, re-engineered, modified, etc., systems
and subsystems for the specific project.
System/subsystem specifications shall specify the requirements
for a system as an entity and include the performance and design
requirements as well as the performance requirements related to
manning, operating, maintaining and logistically supporting the
system allocating requirements to functional areas and defining
interfaces between those areas.
The initial issue of a 'System/subsystem specification' shall
be based on parameters developed during the demonstration and
validation phase. These parameters shall establish the initial
definition of the system which will be refined in subsequent stages
of development. The system/subsystem specification(s) shall be
continuously updated until it establishes a functional baseline
and will form a stable basis on which "Development specifications"
for hardware (HWCI) and software (CSCI) can be prepared.
Acquisition Managers shall be trained in program (project) management.
Mission analysis shall be performed by program managers using
a variety of analysis and technology capability studies.
The analysis of missions and its functions; missions
will be identified and a mission profile will be constructed.
This profile will segment the mission into discrete and well defined
mission phases. Mission conditions will be described which will
include, as a minimum, operational conditions such as normal,
contingency, and emergency operation. For each mission phase under
each mission condition, a sequence of top-level functions or capabilities
will be identified.
System requirements can be identified as two types:
Mandatory requirements
Mandatory requirements state the minimal requirements necessary to satisfy the customer (acquirer) need.
After defining the mandatory requirements alternate
candidate designs can be proposed which satisfy the mandatory
requirements - usually known as preference requirements.
These preference requirements shall be evaluated to determine
the "best" designs.
Preference requirements should:
Note:
The requirements for the 'Project Management
System' shall be analyzed and the documentation prepared and agreed
by the executive and senior management before the System Requirement
Review.
For each mission and function under each mission
condition, user tasks and task sequence shall be identified.
Task requirements shall be identified as:
The outputs from this analysis are; lessons learned
which influence the design and management of the specific system
or subsystem, analysis, and allocation of functions, etc.
Sensitive analyses shall be used to identify the requirements
and parameters that will have the greatest effects on cost, schedule,
and performance. The results will be used to allocate resources.
In many cases the acquirer may not be fully aware
of his needs. It is therefore essential that the needs are expressed
as definitive requirements by expertise being available to convert
perceived needs into realistic requirements.
Rapid prototyping and flexible designs can help in removing any
mis-conceptions, unrealistic requirements and overlooked details.
Talking to two levels up and down in the organization can provide
useful and beneficial information.
Models should be developed to explore any possible
alternative concepts. System models can be in the form of; mathematical,
physical devices, computer simulations, flow diagrams, block diagrams,
or similar methods.
The best alternative model should be maintained and used to provide
information throughout the system life cycle.
Validation of the requirements shall ensure that the requirements
are consistent and realistic. If it is found that the requirements
are unrealistic e.g., requesting a perpetual-motion machine then
the project should be stopped awaiting resolution.
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