Download - Royal Australian Navy

Developing Capability Definition
Documents
SEA 1442 Phase 3 is an
endorsed project and the
Integrated Project Team (IPT),
including members from
Capability Systems, are
developing the initial version of
the capability definition
document suite for the Phase 3
request for tender (RFT). The suite
includes the Operational Concept
Document (OCD), Function and
Performance Specification (FPS)
and Test Concept Document
(TCD). To provide the
Commonwealth with diversity in
approach to the MBCIS solution,
three independent prime system
integrators were engaged early,
yielding significant benefits for
the Commonwealth as insight into
the range of problems that could
result from the development effort
was gained.
The SEA 1442 IPT team will
consolidate the capability
definition documents with
stakeholders from DNC4ISREW,
Force Element Groups (FEG),
System Project Offices (SPO) and
other RAN agencies into a
capability baseline that will form
the basis of a contract between
Capability Systems and DMO. The
DMO will use these documents
for the contract baseline for
tender activity.
Systems Engineering Issues
The DMO’s Capability Definition
Documents Guide (CDDG)
provides significant advice
concerning the content of the
OCD, FPS and TCD, the
applicability of the various
Defence Architecture Framework
(DAF) views and an indication of
the system engineering approach
that must be followed to ensure
stakeholder needs translate into
effective capability.
The IPT is maintaining the
consistency of the various DAF
views to completely describe the
system by managing changes as
they occur. Often, views are
generated in Word or PowerPoint
formats and require a great deal
of effort to manually maintain
consistency once changes are
made. This ‘engineering by
Microsoft Office’ approach is
considered inadequate for the
specification of complex systems
such as the SEA 1442 Phase 3
MBCIS. The complexity of the
Phase 3 MBCIS stems not only
from the technology involved but
the potential number of other
systems to which it interfaces.
While the CDDG provides
information about the content of
the DAF views, it does not provide
guidance about how the views
should be kept holistic and
complete. A robust and clearly
articulated system engineering
process in the context of a C4ISR
(Command, Control,
Communications, Computers,
Intelligence, Surveillance and
Reconnaissance) framework is
required to guide systems
engineering efforts within the
project office and maintain the
integrity of the system model
being developed.
For this reason, the project office
decided to integrate a systems
engineering standard into the
foundation set out by the CDDG
for the development of the
capability definition documents.
By mandating a more rigorous
process that details what and
how tasks such as requirements
and functional analysis are
implemented, those working on
the project are better guided in
producing a suite of mutually
consistent documents with
improved integration.
The choice of which standard to
integrate into the process was
determined on basis of the
standard’s quality, detail and
popularity in Defence industry, as
outlined below.
SE Standards
There are many standards
applicable to the engineering of
complex communications
systems, written by several global
authorities. One of the standards
considered was the Electronics
Industry Alliance 632 (EIA-
NAVY ENGINEERING BULLETIN SEPTEMBER 2003
632:1998), identified by the
ASDEFCON(SM) template. It is an
engineering policy standard
requiring a complete and
integrated technical effort from
identification of need through to
disposal. Oriented towards control
and surveillance by the customer,
its principle value is contained
more in the guidance associated
with the 33 abstract requirements
than the description of
recommended engineering
processes.
In contrast, the Institute of
Electrical and Electronic
Engineering 1220 standard (IEEE
1220:1998) is similar to the EIA-
632 but details systems
engineering processes and its
application throughout the
system life cycle. It defines an
engineering model involving
numerous processes and
associated planning that comply
with the requirements of EIA-632
and emphasize verification and
validation. Each
analysis/verification loop forms a
phase of the overall process. This
standard was selected because it
contained detailed content, which
suited the SEA 1442 Phase 2B
project definition study and the
relative immaturity of the
processes within the project
office.
It is anticipated that as the
project office’s capabilities
mature, the less restrictive EIA-
632 standard will be utilised for
controlling engineering efforts in
the SEA 1442 Phase 3
acquisition.
Process
The systems engineering process
(SEP) defined in IEEE 1220
contain three phases:
requirement analysis/verification,
functional analysis/verification
and design synthesis/verification.
Each phase may be iterated
many times during system
specification to ensure validity
and consistency of the resultant
requirement, functional and
logical baselines. A simplified
overview of this process is shown
in Figure 2.
71
Broadly speaking, two iterations
of the entire IEEE 1220 SEP will
be conducted during the
development of the SEA1442
capability documents, at two
levels of detail. In the first
iteration, the OCD and TCD are
developed in parallel, using as
inputs all the draft documents
created by the collaborative effort
with contractors mentioned
earlier and further stakeholder
engagement by the project office.
This iteration codified the highlevel
requirements of the
warfighter, and sketches out the
first few levels of the functional
and logical hierarchy of the
system. On completion of the
OCD, the FPS is developed using
a second major iteration of the
IEEE 1220 SEP, translating the
requirements of the OCD into
technical specifications at far
greater detail and filling out the
lower levels of the hierarchies.
These major iterations are shown
in Figure 3.
The CDDG guidance was
extended by mapping it onto the
SEP defined in IEEE 1220. The
mapping involved relating all
parts of the CDDG to IEEE 1220
processes and the various
sections of the capability
definition documents to process
outputs.
The mapping created breakpoints
in the development process of
the definition documents where
quality and consistency between
the various sections of the OCD,
FPS and TCD could be checked.
As a consequence of explicitly
embedding the iterative nature of
the SEP into the CDDG, conflicts
or variances discovered at each
phase of development trigger
another iteration of a phase in a
controlled manner in accordance
with the IEEE 1220 standard. This
approach is in contrast with the
CDDG, where updating the
documents on receiving feedback
is considered nearer the
conclusion of the development
process.
The development of the
integrated development process