Essential Systems Engineering: A Lifecycle Process

John Azzolini

NASA/Goddard Space Flight Center

Code 704

Greenbelt, MD 20771

**ABSTRACT.** A systems engineering process is presented which supports
the project lifecycle with improved rigor. The incorporation of specific
structure and discipline results in a process which is requirements
based, with added value in the planning, execution and reporting of
design, implementation, integration, verification, and validation
activities.

The concept of the validation basis is introduced and discussed. It is a
key concept in the development of this process.

INTRODUCTION

There has been much recent effort toward defining systems engineering
processes. Much of the emphasis has been on front end requirements
capture, analysis, and tracing methods and tools. It is generally well
accepted that sound requirements methods result in fewer system changes.
Fewer changes result in lower costs. This is precisely because it is the
later part of the project development lifecycle, implementation,
integration, verification, and validation, where the rate of expenditure
is the highest.

It is probable that there are as many approaches to the systems
engineering process as there are organizations performing systems
engineering. In practice, even the definition of a systems engineer\'s
responsibilities varies widely. The process discussed in this paper
attempts to capture the most essential activities and products of
systems engineering, in a way which supports the project development
lifecycle.

The process presented is the result of many lessons learned in the
author\'s assignment as Lead Spacecraft System Engineer for Goddard\'s
X‑Ray Timing Explorer (XTE) mission. The XTE mission has a budget of
\$225 million dollars and the spacecraft development effort employs
approximately 175 engineers. It is from this perspective that this
process has evolved. The author believes that other types and sizes of
systems can be developed within this structure.

Experience shows that the quality of the early systems engineering
activities has a strong influence on the quality of the later
activities. Sound requirements analysis and hierarchical structure can
improve the accountability and quality of system implementation,
integration, and verification. Rigorous and ongoing validation, the
establishment of validation bases, and verification planning and
execution are key factors in the quality of the process and resulting
system.

DEFINITIONS

The correspondence between the presented definitions and the Functions,
Requirements, Architecture, and Test (FRAT) process, (Mar 1993) and
(Whitten et al. 1994), is shown.

**Essential Systems Engineering Process.** A set of activities, an
interaction of these activities, and a set of products resulting from
these activities. The process includes Requirements Analysis, Operations
Concept Development, Design Synthesis, Risk Analysis, and Validation and
Verification activities.

**Requirements Analysis.** The activity of identifying and structuring a
set of functional requirements (FRAT: Functions), performance
requirements (FRAT: Requirements), and assumptions, which meet a set of
objectives.

Objectives. A set of goals and constraints that define the success of
the system. These include what the system must accomplish, the system
lifetime, the environment in which the system must perform, and cost,
schedule, legal, and mandated constraints.

Functional Requirements. Concise statements of what a system must do to
satisfy its objectives.

Performance Requirements. Concise statements of how well a system must
perform its functions to satisfy its objectives.

**Validation Basis.** A set of functional and performance requirements
which define the success of a systems subordinate elements. In the case
of the full system, the validation basis is the set of objectives.

**Operations Concept Development.** An activity of defining the manner
in which the system will be operated. It may be viewed as the highest
level design synthesis activity. It is at this stage that the definition
of mission architecture and the allocation of mission functions begins.
The operations concept includes operations activities, facilities,
equipment, commanding and data collection, and staffing. It evolves into
operations plans and procedures.

**Design Synthesis (FRAT: Architecture).** An activity of designing and
selecting a system that will meet the objectives and satisfy the
functional and performance requirements.

**Risk Analysis.** An activity of identifying elements of the system,
and areas of the program development process, which have small margin or
high uncertainty in meeting objectives (Risk Items). Also, the activity
of determining ways of reducing the impact of the identified risk items.

**Validation and Verification.** Activities to determine the correctness
of the system.

Validation. The activity of determining if the system design meets its
objectives. It asks: Did we build the right system?

Verification (FRAT: Test). The activity of determining if the system is
correctly implemented. It asks: Did we build the system right?

**Baseline.** A version of a product which is configured at a point in
the systems engineering process to serve as the point-of-departure for
subsequent phases.

**Project Lifecycle.** All project lifecycles can generally be broken
into a set of design phases, a set of implementation phases, and a set
of operational phases. For purposes of this paper the design phases are
defined as: Feasibility Design, Conceptual Design, Architectural Design,
and Detailed Design. Implementation, Integration and Test, Deployment,
and Commissioning constitute the implementation phases. The operational
phases include Deployment, Commissioning, Operations and Disposal.

Notice that Deployment and Commissioning are considered as part of both
the implementation and operational sets. Other activities may overlap
sets as well. The design phases and implementation phases define the
project development lifecycle.

THE ESSENTIAL SYSTEMS ENGINEERING PROCESS - DESIGN PHASES

There is no prescribed sequence for the activities in these phases.
Requirements analysis, operations concept development, design synthesis,
risk analysis, and verification planning, along with their respective
validation activities, will generally be performed in parallel. Each
activity will contribute to the refinement of the others. The entire
process is applied to each design phase of the project lifecycle with
increasing detail and refinement. Figure 1 shows the relation of the
activities.

In this section, a brief description of the activities, methods, and
products of the process is presented. An expanded discussion of most
methods will follow.

**Given.** A set of objectives (goals and constraints).

**Requirements Analysis.**

Activity. Develop a hierarchical set of functional requirements which
satisfy the objectives. Attach to each functional requirement a set of
performance requirements which define how well the function must be
performed to satisfy the objectives. During this process identify and
list assumptions.

Method. RAVISH (See methods section).

Products. A candidate functional and performance requirements hierarchy.
A list of Assumptions.

**Operations Concept Development.**

Activity. Determine how the system will be operated. Determine how the
mission functions will be allocated among systems.

Method. Operations Analysis, Functional Analysis, Architectural Design
Studies.

Product. Candidate Operations Concept.

**Design Synthesis.**

Activity. Identify candidate system designs that satisfy the objectives.

Method. Design and Trade Studies.

Product. A set of candidate designs.

**Risk Analysis.**

Activity*.* Identify elements of the design, and areas of the
development process, with high uncertainty or small margin in meeting
objectives. Plan and execute the steps to be taken to reduce the risk.
The results may indicate additional process iteration.

Method. Validation Walkthroughs.

Product. Risk Items Action List.

**Verification Planning.**

Activity. The verification method and specification: procedure,
activity, facility, equipment, and person responsible, for each
requirement (or group of requirements) is specified. High level tests
are frequently used to test the system to many requirements within one
procedure.

Method. RAVISH.

Product. Candidate Verification Plan.

**Validation of Requirements and Assumptions.**

Activity. At the top level of the requirements hierarchy, does the
successful performance of the system requirements ensure the
satisfaction of the system objectives? Working top-down, at all levels,
does the successful performance of the child requirements ensure the
satisfactory performance of the parent requirement? Are the assumptions
valid?

Method. Requirements Validation Walkthrough.

Products. Baseline Requirements Specification, Baseline Assumptions
List.

**Validation of Operations Concept.**

Activity. Ensure that the Operations Concept meets the mission
objectives and that the design supports the concept.

Method. Operations Concept Validation Walkthrough.

Product. Baseline Operations Concept.

**Validation of Design.**

Activity. Evaluate the candidate designs. Do the designs perform all of
the functions required to meet mission objectives? Do the designs
perform these functions to the required level of performance to meet
mission objectives?

Method. Design Validation Walkthrough.

Product. Baseline set of designs.

**Validation of Verification Plan.**

Activity. Evaluate the Verification Plan to ensure that every
requirement (or group of requirements) has verification methods and
specifications.

Methods. Requirements Verification Method Walkthrough, Requirements
Verification Specification Walkthrough.

Product. Baseline Verification Plan.

**Design Analyses.**

Activity. Select a subset of baseline candidate designs for further
refinement.

Method. Decision theory. This may be anything from "Go with your gut
feel" to sophisticated mathematical optimization techniques. The author
prefers using the Analytical Hierarchical Process to support difficult
decisions.

Product. Baseline candidate designs.

The design phases of the process are refined until one candidate is
selected. In some cases parallel simulation studies or prototyping may
be warranted to support the selection.

VALIDATION BASES

The concept of validation bases is an important one. It provides a
mechanism for distributing the systems engineering process such that no
single systems engineer needs to work with more than a reasonable subset
of requirements.

The validation basis, for each subsystem, specifies only what functions
the subsystem must perform and how well the subsystem must perform them.
This allows design freedom to the subsystem development team
(empowerment), while providing a clear definition of successful
subsystem development.

THE ESSENTIAL SYSTEMS ENGINEERING PROCESS - IMPLEMENTATION PHASES:

The focus shifts to the implementation, integration, and verification
phases as shown in Figure 2. The requirements hierarchy specifies the
system to be implemented. The Verification Plan defines how the system
is to be verified to the requirements hierarchy.

**Subsystem validation.**

Activity. The subsystem team demonstrates the validity of the subsystem
derived requirements and design to the subsystem validation basis.

Methods. Subsystem Validation Review.

Product. Subsystem acceptance for implementation.

**Implementation**.

Activity. The subsystem team designs the system in detail and the
subsystem is built.

Methods. Discipline Engineering.

Products. Subsystem detailed design. Subsystem hardware and software.

**Subsystem Verification.**

Activity. The subsystem team performs the Subsystem Verification Plan.
Results are analyzed, corrections made, and the activity is repeated
until all is well.

Methods. Varied.

Product. Subsystem acceptance for integration.

**System Integration.**

Activity. The subsystems are mechanically and electrically assembled
into the system.

Methods. Varied.

Product. Integrated System.

**System Verification.**

Activity. The System Verification Plan is executed. All of the analyses,
inspections, and tests are performed. Results are analyzed, corrections
made, and the activity is repeated until all is well.

Methods. System Comprehensive Performance Test

Product. System Verification Report.

Once the system is integrated and verified, system level validation
testing is performed. The system is operationally tested in its target
environment (or as close to that environment as practical).

**System Validation.**

Activity. Operation of the integrated system, within its operational
environment, according to its operations procedures.

Method. Acceptance Testing

Product. System acceptance for deployment.

**Deployment and Commissioning.**

During the design phases, it is important to identify functional and
performance requirements which are unique to the deployment and
commissioning phases. The verification of these requirements generally
requires a fully integrated system.

OPERATIONAL PHASES

The operational phases, while part of the mission lifecycle, are not a
part of the system development lifecycle. Frequently, systems engineers
are called upon to assist in problem resolution during these phases (see
figure 3).

METHODS: Structure

\"The pieces I am holding in my hands, what I lack is the clarifying
bond\" (Goethe)

**RAVISH - Requirements Analysis for Verification In a Structured
Hierarchy.**

The RAVISH requirements hierarchy may be viewed as a hierarchy of
compound data structures. These data structures are, in turn,
hierarchies which are vertically fixed and horizontally dynamic. The
data structures contain the validation bases for all subordanant
elements. Figure 4 shows the high level structure.

Each of these boxes (entries) are records as shown in Table 1.

**Motivation.**

• Design is a top‑down process. Functional allocation flows from mission
to system to subsystem to assembly, to component.

• Verification is a bottom-up process. Verification flows from component
to assembly to subsystem to system.

• Work breakdown structures generally assign subsystem responsibility to
a single subsystem lead (or manager).

• The result is that it is most effective to develop a system
requirements hierarchy which groups requirements by subsystem.

  ----------------------------------------- -----------------------------
  **Field Name**                            **Data Type**

  Requirement ID                            A32 ²

  System                                    A2

  Subsystem                                 A2

  Mission Phase                             A2

  Functional Category                       A2

  Functional Requirement                    A2

  Performance Requirement                   A2

  Requirement Type                          A1

  Requirement Title                         A72

  Requirement Text                          A255

  ² Indicates Key Field                     
  ----------------------------------------- -----------------------------

Table 1. Record Structure

**Structure.**

• A strict top‑down allocation of requirements

• Allocation flow is from system to subsystem then to mission phase.

• Functional Requirement Categories are developed for each subsystem.

• Functional requirements are specified without performance numbers
using a single simple sentence for each.

• Performance requirements are attached to the functional requirement.

• The verification method for each functional and performance
requirement is specified.

• The verification specification: procedure, activity, facility,
equipment, and person responsible, for each requirement (or group of
requirements), is defined.

**Rationale.**

• By grouping requirements by subsystem, each subsystem team has a
definitive set of system level requirements (validation basis) that
defines subsystem success. (Clarity)

• By specifying requirements for each mission phase, design
consideration is given to each phase equally. This avoids \"Band-Aid\"
approaches to providing the functionality required. It also establishes
and maintains an operational awareness throughout the project lifecycle.
(Uniformity)

• By defining function categories for each subsystem, functional
requirements groups are formed. This allows other subsystem to reference
these groups (e.g. Electrical system requirements). (configurability)

This also has the psychological advantage of reducing a large number of
functional requirements into a smaller set of categories.

• By making each functional requirement separate from its associated
performance requirements, functional validation of the hierarchy is
simplified. (Associativity)

• By grouping performance requirements with each functional requirement,
the items which are needed to verify the functional requirement are
clearly identified as a group. (Modularity)

• By specifying the verification method and specification for each
requirement, early identification of unique verification tasks,
equipment, and facilities is provided. (Verifiability)

• The hierarchy is internally self-tracing. (Traceability)

METHODS: Discipline

**Requirements Validation Walkthrough.**

• Identify and validate assumptions.

• Identify and correct unallocated requirements and orphan requirements.

• Validate the requirements hierarchy to the objectives.

• Establish margins.

• Identify TBDs and Risk Items.

• Generate action lists and schedule closure of the actions.

**Operations Concept Validation Walkthrough.**

• Validate Assumptions.

• Ensure that the system, if operated according to the operations
concept, will satisfy mission objectives.

• Ensure that the system design supports the operations concept.

• Identify TBDs and Risk Items.

• Generate action lists and schedule closure of the actions

**Design Validation Walkthrough.**

• Validate assumptions.

• Validate the design to the requirements hierarchy. • Identify TBDs and
Risk Items.

• Generate action lists and schedule closure of the actions.

**Requirements Verification Methods Walkthrough.**

• Validate assumptions.

• Ensure that each requirement has a specified verification method.

• Identify all unique analyses, inspections, and tests needed for
verification.

• Identify all special bench test equipment (BTE), ground support
equipment (GSE), or facilities needed for verification.

• Identify TBDs and Risk Items.

• Generate action lists and schedule closure of the actions.

**Requirements Verification Specification Walkthrough.**

• Validate assumptions.

• Ensure that there is a procedure, activity, facility, test equipment,
and responsible person for each requirement or group of requirements.

• Identify TBDs and Risk Items.

• Generate action lists and schedule closure of the actions.

INTERFACES

Until recently, interface requirements and specifications were not
supported by RAVISH. The XTE Project successfully uses stand-alone
Interface Requirements and Control Documents to specify and control
interfaces.

We now plan to capture interface requirements at the mission phase level
within the data structure. This allows the inclusion of these
requirements within the subsystem validation basis.

ESSENTIAL SYSTEMS ENGINEERING AND MIL-STD-499B

A process flow diagram, which represents the Mil‑Std‑499B mission design
phases, is shown in Figure 5. Generally, there is little contained
within the Essential Systems Engineering process which is incompatible
with this standard. There are, however, several differences in the way
the process is executed and in its scope.

Notice that in the Functional Analysis/Allocation block, requirements
are allocated to all functional levels. In practice, the presented
process achieves the same end. The focus, however, is on breadth rather
than depth as each level is designed. The validation bases provide the
mechanism for including subsystem designers in the system design
process. This inclusion results in system level cognizance for the
subsystem leads and their ownership of the subsystem requirements.

The standard does not include system verification planning as a part of
the design process. In fact, what is labeled verification in Figure 5,
is defined as validation by the presented process. The Essential Systems
Engineering process has more concurrency of design activities than is
implied by the standard.

Despite these differences, the author believes that the presented
process meets the intent of the Mil‑Std‑499B draft.

TOOLS

The systems engineering process presented in this paper is supported by
a relational database tool developed at Goddard. We have used Borland
Paradox for Windows® on high powered PC platforms.

Paradox has been used to develop a data model with the requirements
hierarchy as the main database. Attached to the hierarchy are detail
databases which provide allocation, verification methods, verification
specifications, and test planning support. The rich query, forms, and
reports capability is used to extract data, and develop user interfaces
and reports. Table lookup and referential integrity features support the
integrity of data entry and update.

The tool is a work in progress. When sufficiently mature, it will be the
subject of a future paper.

SUMMARY

The process is presented with mission objectives, a system level
hierarchy, and subsystem validation bases (mission-system-subsystem). It
is equally amenable to the perspective of other levels (e. g.
system-subsystem-assembly).

The ultimate metric for systems engineering is the success of the
mission. The development of this process, to date, has focused upon
building a successful XTE spacecraft. Without mission success, other
metrics are irrelevant. As this process is applied to other projects,
careful thought will be given to the development of metrics.

Some systems engineers and managers may object to the boundaries and
resources required to implement this process. It is the author's belief
that the benefits more than justify this conformity and investment.
Csikszentmihalyi writes that the Emperor Cicero said, \"to be completely
free one must become a slave to a set of laws\" (Csikszentmihalyi 1990).
The author finds that this process frees one to focus on the activities
most likely to ensure mission success.

ACKNOWLEDGMENTS

The author gratefully acknowledges the superb support, both to the XTE
Systems Engineering Team, and in the development of this process, of Mr.
Michael Bay of Jackson & Tull and Mr. Gary Won of Fairchild Space. He
also would like to recognize the important role that discussions with
Mr. Anthony Fragomeni, Mr. Donald Krueger, and Dr. Michael Ryschkewitsch
of the Goddard Engineering Directorate, and Mr. John Allen of Daedalian
Systems played in the critique and development of this process.

REFERENCES

Azzolini, John, \"Requirements\", and \"System Verification and
Validation,\" Goddard Technical Managers Training Course Materials, 1994

Csikszentmihalyi, Mihaly, *Flow: the Psychology of Optimal Experience*,
HarperCollins Publishers, New York, 1990

Mar, Brian W., \"Systems Engineering Maturity Model,\" presented at the
Third Annual NCOSE Symposium, Washington, D.C., 1993

Goethe, Johann W. Von, Attributed, possibly apocryphal.

Whitten, Carolyn, Keizur, Alan, and Mar, Brian W., \"ASEM - A Simple
Engineering Training and Personal Automation Tool,\" presented at the
Forth Annual NCOSE Symposium, San Jose, California, 1994

Department of Defense (DOD), Mil-Std-499B, Systems Engineering, Draft,
1992

BIOGRAPHY

**John Azzolini is a Senior Systems Engineer currently assigned as
Associate Chief of the Systems Engineering Office, Engineering
Directorate at the Goddard Space Flight Center. He began his career at
Goddard in 1967. During the ensuing period, he performed assignments in
the areas of control system analysis and design, flight software
development, simulation test-bed development, robotics, and systems
engineering. These assignments supported many missions, among them, the
International Ultraviolet Explorer (IUE), the Solar Maximum Mission
(SMM), the Solar Maximum Repair Mission (SMRM), and the Broad Band X-Ray
Telescope (BBXRT) Two Axis Pointing System (TAPS). Since 1991, he has
served as the Lead System Engineer for the X-Ray Timing Explorer (XTE)
spacecraft. Mr. Azzolini also serves as an instructor at Goddard's
Technical Manager Training Course, teaching course segments on
requirements and verification and validation.**