System Engineering Practices 1st Edition Ian

Faulconbridge pdf download

https://textbookfull.com/product/system-engineering-practices-1st-edition-ian-faulconbridge/

★★★★★ 4.8/5.0 (37 reviews) ✓ 237 downloads ■ TOP RATED

"Fantastic PDF quality, very satisfied with download!" - Emma W.

DOWNLOAD EBOOK
 System Engineering Practices 1st Edition Ian Faulconbridge
pdf download

TEXTBOOK EBOOK TEXTBOOK FULL

Available Formats

■ PDF eBook Study Guide TextBook

EXCLUSIVE 2025 EDUCATIONAL COLLECTION - LIMITED TIME

INSTANT DOWNLOAD VIEW LIBRARY

Collection Highlights

Engineering Software Products: An Introduction to Modern

Software Engineering 1st Edition Ian Sommerville

Cloud Computing for Science and Engineering 1st Edition

Ian Foster

Industrial System Engineering for Drones A Guide with Best

Practices for Designing Neeraj Kumar Singh Porselvan
Muthukrishnan Satyanarayana Sanpini

Practices in Power System Management in India J Raja

Protection Engineering Basics and Schemes Power System
Engineering 1st Edition Engr Qazi Arsalan Hamid

Advances in Reliability and System Engineering 1st Edition

Mangey Ram

Sustainability Assessment A Rating System Framework for

Best Practices 1st Edition César A. Poveda

Sustainable practices in geoenvironmental engineering

Second Edition Fukue

System Engineering Management 5th Edition Benjamin S.

Blanchard
 CONTENTS

INTRODUCTION TO SYSTEMS ENGINEERING 1

l.l What is a System? 2
1.1.1 Definition of a System 2
1.1.2 Types of Systems 3
1.1.3 A System and its Environment 4
1.1.4 A System as a Product 5
1.1.5 A System as a Capability-A Capability System 6
1.1.6 Logical and Physical Descriptions of a System 7
1.1.7 Hierarchical Descriptions of a System 9
1.1.8 System-of-Systems (SoS) 11
1.1.9 Problem Domain and Solution Domain 12
1.2 System Life Cycle 12
1.2.1 Parties Involved 14
1.3 Acquisition and Utilization Phases 15
l.3.1 Acquisition Phase 16
l.3.2 Utilization Phase and Retirement Phase 19
1.4 Systems Engineering and Development Approaches 19
1.5 What is Systems Engineering? 20
1.5.1 Top-Down Approach 20
1.5.2 Requirements Engineering 23
1.5.3 Focus on Life Cycle 24
1.5.4 System Optimization and Balance 25
1.5.5 Integration of Disciplines and Specializations 25
1.5.6 Management 26
1.6 Systems Engineering Relevance 26
1.7 Systems Engineering Benefits 27
1.8 Analysis, Synthesis, and Evaluation 30
1.8.1 Analysis 30
1.8.2 Synthesis 31
1.8.3 Evaluation 31
1.9 A Systems Engineering Framework 31
1.9.1 Systems Engineering Processes 33
1.9.2 Systems Engineering Management 34
1.9.3 Systems Engineering Tools 34
1.9.4 Related Disciplines 34
1.10 Summary 35
1.11 Revision Questions 35
2 REQUIREMENTS ENGINEERING FRAMEWORK
2.1 Introduction 43
2.1.1 Needs and Requirements Documentation 43
2.1.2 What is a Requirement? 47
2.1.3 Requirements Characteristics and Attributes 47
2.1.4 What Not How 50
2.1.5 Emergent Properties 51
2.2 What Is Requirements Engineering? 52
2.2.1 Why We Need Requirements 53
2.2.2 Why We Need Requirements Engineering 53
2.3 Requirements Elicitation and Elaboration 54
2.3.1 Difficulties in Eliciting and Elaborating Requirements 56
2.3.2 Techniques for Eliciting/Generating Requirements 58
2.4 Requirements Validation 65
2.5 Requirements Documentation 66
2.6 Requirements Management 67
2.6.1 Requirements Change Management 67
2.6.2 Change Management-Traceability 67
2.6.3 Requirements Management Tools 68
2.7 Requirements-Engineering Tools 70
2.7.1 Requirements Breakdown Structure (RBS) 70
2.7.2 Functional Flow Block Diagrams (FFBD) 72
2.8 Summary 73
2.9 Review Questions 74
3 CONCEPTUAL DESIGN
3.1 Introduction 81
3.2 CI-Define Business Needs and Requirements 82
3.2.1 Cl.I-Identify Major Stakeholders and Constraints 83
3.2.2 Cl.2-Elicit Business Needs 86
3.2.3 Cl.3-Scope System 98
3.2.4 CIA-Define Business Requirements 103
3.2.5 Cl.5-Finalise Business Needs and Requirements (BNR) 107
3.3 C2-Define Stakeholder Needs and Requirements 107
3.3.1 C2.1-Define Stakeholder Needs 108
3.3.2 C2.2-Define Stakeholders Requirements 108
3.3.3 C2.3-Finalise Stakeholder Needs and Requirements (SNR) 110
3.4 C3-Define System Requirements 111
3.4.1 C3 . I-Establish Requirements Framework 113
3.4.2 C3.2-Perform Requirements Analysis and Allocation 113
3.4.3 C3.3-Draft System Requirement Specification (SyRS) 117
3.4.4 C3A-Define Technical Performance Measures (TPM) 119
3.4.5 C3.5-Conduct System Requirements Reviews (SRR) 123
3.4.6 Engineering Management Considerations 125

VI
 3.5 C4-Conduct System-Level Synthesis 126
3.6 C5-Conduct System Design Review (SDR) 128
3.7 Review Questions l30

4 PRELIMINARY DESIGN
4.1 Introduction 133
4.2 Subsystem Requirements Analysis 133
4.3 Requirements Allocation 137
4.3.1 Identify Candidate Subsystems 138
4.3.2 Group and Allocate Requirements 142
4.3.3 Confirm Subsystem Selection 145
4.4 RBS versus WBS
145
4.5 Interface Identification and Design
147
4.5.1 Interface Control Document (ICD)
147
4.5.2 Types of Interface
148
4.5.3 Interface Control Working Group (ICWG)
150
4.5.4 Interface Definition Using the 2 Diagram
4.6 Subsystem-Level Synthesis and Evaluation 151
4.6.1 Review Sources of Subsystem Requirements 152
4.6.2 Investigate Design Alternatives 152
4.6.3 Make Optimal Use of Design Space 153
4.6.4 Selecting the Preferred Solution 158
4.7 Preliminary Design Review (PDR) 162
4.8 Tools 163
4.8.1 Schematic Block Diagrams 165
4.8.2 Physical Modelling 165
4.8.3 Mathematical Modelling and Simulation 165
4.8.4 Trade-Off Analysis 166
4.9 Review Questions 167
171
5 DETAILED DESIGN AND DEVELOPME T
5.1 Introduction
5.2 Detailed Design Requirements 173
5.3 Detailed Design of Hardware 173
5.3.1 Generic Hardware Detailed Design Process 175
5.3.2 Preparing for Detailed Hardware Design 176
5.3.3 Performing Detailed Hardware Design 176
5.3.4 Proving the Detailed Hardware Design 177
5.3.5 Documenting the Detailed Hardware Design 179
5.4 Detailed Design of Software 180
5.4.1 Software Design Process 182
5.4.2 Preparing for Software Design 182
5.4.3 Performing Detailed Software Design 183
5.4.4 Documenting the Detailed Software Design 184
5.5 Integrating System Elements 184
185

VII
 5.6 Detailed Design Reviews 187
5.6.1 Equipment/Software Design Reviews 187
5.6.2 Critical Design Review (CDR) 187
5.7 Review Questions 190

6 CONSTRUCTION AND/OR PRODUCTION

6.1 Introduction
193
6.2 Production Requirements
193
6.3 Engineering Management Issues
196
6.3.1 Major Audits
196
6.3.2 Major Reviews
200
6.3.3 Configuration Management
201
6.4 Review Questions
201

7 OPERATIONAL USE AND SYSTEM SUPPORT

7.1 Introduction 203
7.2 Failure Reporting, Analysis and Corrective Action System (FRACAS) 206
7.3 Retirement 208
7.4 Review Questions 211

8 SYSTEMS ENGINEERING MANAGEMENT

8.1 Introduction 213
8.2 Technical Review and Audit Management 213
8.3 Test and Evaluation 216
8.3.1 Developmental Test and Evaluation (DT &E) 218
8.3.2 Acceptance Test and Evaluation (AT&E) 219
8.3.3 Operational Test and Evaluation (OT&E) 219
8.3.4 Test Management 221
8.3.5 Testing Activities and the System Life Cycle 221
8.3.6 Test and Evaluation Master Plan (TEMP) 226
8.4 Technical Risk Management 227
8.4.1 Risk Identification 229
8.4.2 Risk Analysis 230
8.4.3 Risk Treatment 231
8.4.4 Risk Management Documentation 232
8.5 Configuration Management 233
8.5.1 Establishing the Baselines 233
8.5.2 Configuration Management Functions 234
8.5.3 Configuration Management in Acquisition and in Utilization 239
8.5.4 Configuration Management Documentation 239
8.6 Specifications and Standards 240
8.6.1 Specifications 241
8.6.2 Standards 243
8.7 Systems Engineering Management Planning 245
8.8 Review Questions 247
V111
 9 SYSTEMS ENGINEERING STANDARDS
9.1 Standards 251
9.1.1 MIL-STD-499B-Systems Engineering (Draft) 251
9.1.2 EIA/IS-632-Systems Engineering 258
9.1.3 IEEE-Std-1220-IEEE Standard for Application and Management
of the Systems Engineering Process 260
9.1.4 ANSIIEIA-632-Processes For Engineering A System 267
9.1.5 ISO/IEC 15288 System And Software Engineering-System Life
Cycle Processes 272
9.1.6 Other Useful Standards 274
9.2 Capability Maturity Models 276
9.3 Review Questions 281

10 RELATED DISCIPLINES
10.1 Introduction 285
10.2 Project Management 285
10.3Quality Assurance 290
10.4 Integrated Logistics Support 291
10.5 Operations 292
10.6 Software Engineering 292
10.7 Hardware Engineering 294
10.8 Review Questions 295

II SYSTEMS ENGINEERING AND DEVELOPMENT APPROACHES

11.1 Introduction 297
11.2 Waterfall Development 298
II.3 Incremental Development 300
11.4 Evolutionary Development 303
11.5 Prototyping and System Development 305
11.6 Spiral Development Model 306
11.7 Summary 309
11.8 Review Questions 309

GLOSSARY 3 11

INDEX 315

IX
 PREFACE
The need to manage complexity is now commonplace in almost all fields of
undertaking. Complex systems such as cars, aeroplanes, airports, financial systems, and
communications networks commonly involve millions of hours of work by thousands
of people from a wide range of disciplines and backgrounds spread across a number of
companies in a number of countries. Projects often take decades and involve a large
number of disparate stakeholders, developers, operators and customers. At the same
time, the need to accommodate changes in the market place has created considerable
pressure on traditional engineering processes. It is little wonder therefore that we have
become used to hearing of the difficulties associated with complex projects-cost and
schedule overruns, dramatic failures to achieve requirements, project cancellations, and
so on.
These problems cannot be solved by simply ensuring that each of the associated
disciplines pays more attention to their individual professions. Complex technical
projects can only be managed effectively by addressing the whole life cycle. First,
requirements must be defined formally to provide a comprehensive description of the
functionality of the system to be procured- a functional architecture. These functional
requirements are analyzed and elaborated to create a functional description of subsystem
requirements, which are then allocated to physical configuration items to provide a
physical architecture of the system. The aim of developing the physical configuration
items is to reduce the complex system to a series of well-defined subsystems that can be
designed and then built by manageable teams using extant processes and procedures. The
subsequent development of these separate subsystems must be managed, however, so
that they are verified, tested and integrated into the final system to be delivered. To be
successful, the entire process must be planned, documented, and managed.
This book provides a basic but complete coverage of the discipline known as
systems engineering. We offer a framework encapsulating the entire systems engineering
discipline, clearly showing where the multitude of associated activities fits within the
overall effort, providing an ideal vehicle for understanding the complex discipline.
We take a top-down approach that introduces the philosophical aspects of the
discipline and provides a framework within which the reader can assimilate the
associated activities. Without such a reference, the practitioner is left to ponder the
plethora of terms, standards and practices that have been developed independently and
often lack cohesion, particularly in nomenclature and emphasis. The field of systems
engineering is often viewed as dry, detailed, complicated, acronym-intensive, and
uninteresting. Yet, the discipline holds the solution to delivering complex technical
projects on time and within budget, and avoiding many of the failures of the past. The
intention of this book is both to cover all aspects of the discipline and to provide a
framework for the consideration of the many issues associated with engineering
complex systems.
Our secondary purpose is to describe a complex field in a simple, easily-
digested manner that is accessible to a wide spectrum of readers, from students to
professionals, from novices to experienced practitioners. It is directed at a wide
audience and aims to be a valuable reference for all professions associated with
the management of complex technical projects: project managers, systems
engineers, quality assurance representatives, integrated logistic support
practitioners, maintainers, and so on.
Chapter I introduces systems engineering and related issues and Chapter 2
provides the framework within which the remainder of the book is written.
Chapters 3 and 4 examine in more detail the issues associated with Conceptual
Design and Preliminary Design. Emphasis is given to these early activities, as
they have the greatest impact on the system development. Chapters 5, 6 and 7
deal with respectively Detailed Design and Development, Construction and/or
Production, and Operational Use and Support. Chapter 8 deals with the broad
topic of systems engineering management and details some of the associated
activities. Some of the more common and popular systems engineering standards
are introduced in Chapter 9 and their application to engineering management and
process is explained. Chapter 10 explains the interrelationship between the
systems engineering effort and other closely related disciplines such as project
management, quality management and integrated logistics support management.
Finally, Chapter 11 discusses the relationship between systems engineering
methodologies and a number of acquisition methods.
Systems engineering is a broad discipline, and its application to different
projects always requires individual and independent thought. There is never a
single solution that will work with all projects, and there is rarely a solution that is
either completely right or wrong. This book aims to introduce the main systems
engineering issues to the reader to facilitate some of that individual and
independent thought.

Ian Faulconbridge
Mike Ryan
Canberra, 2014

XII
 1

INTRODUCTION TO SYSTEMS
ENGINEERING

While elements of systems engineering [1] are recognizable in all major engineering ventures in the
past, the discipline is relatively young. Formal methodologies and practices begin to emerge from
experience gained in the US Department of Defense acquisition programs in the late 1940s when, for
the first time, the scope of system acquisition began to outstrip the ability of traditional engineering
practices to cope with complex and challenging user requirements that tended to be incomplete and
poorly defined. Additionally, most programs entailed high technical risk because they involved a
wide variety of technical disciplines and the use of high technology. Following a number of program
failures, the discipline of systems engineering emerged to help avoid, or at least mitigate, some of
the technical risks associated with complex system acquisition. The first book on systems
engineering was published in 1957 [2] and the discipline was taught at universities from the 1960s.
Systems engineering processes and methodologies have continued to develop and are now widely
applied to modem acquisition projects.
Systems engineering provides the framework within which complex systems can be
adequately defined, analyzed, specified, manufactured, operated, and supported. The focus of
systems engineering is on the system as a whole, and the maintenance of a strong interdisciplinary
approach. Project management, quality assurance, integrated logistics support, and a wide variety of
engineering disciplines are but a few of the many disciplines that are part of a coordinated systems
engineering effort.

Use of examples in this book. Throughout the following chapters we use a number of
examples to illustrate and reinforce the theory being introduced. To aid an understanding of the
whole systems engineering process, we use two system examples: a larger system based on the
acquisition of an aircraft system, and a smaller system based on the development of a domestic
security alarm. We must state at the outset, however, that we do not intend to replicate the design
process for either system or their supporting elements. Rather, the systems have been chosen as
convenient examples that can be readily recognized by readers from a wide variety of disciplines and
specialties. Readers are not forced to become domain experts in a particular field just to understand
the illustration-the majority of readers can immediately understand the system context, the business
needs, stakeholder needs, and system needs; the subsequent requirements; the interface issues;
technical performance measures; the logical-to-physical translation; broad trade-off
2
Systems Engineering Practice

analyses; as well as the physical configuration items involved in the final design. It should be noted that
we do not at all suggest that the aggregation of examples throughout the text represents an adequate
design for either system; the available space prohibits the inclusion of sufficient detail, which would
also obscure the general lessons that are to be illustrated by the examples.

Example 1.1: Introduction to Aircraft Example

An aircraft operator (ACME Air) has identified a business need for a medium- sized aircraft to
replace the aging platform that it currently operates over domestic routes and some short
international routes. The company will use a systems engineering approach to ensure that the
aircraft system produced is ideally suited to the role and to ensure the overall commercial
viability of the project.

Example 1.2: Introduction to Domestic Security Alarm Example

Another division of ACME Industries, ACME Alarms, has a business need to develop a domestic
security alarm. The company proposes to sell the alarm to the domestic market to compete in
price and functionality with security alarms that are purchased for all forms of domestic dwelling
such as houses, flats, and apartments. The alarm is to be capable of being installed by the
customer and must be able to operate in a back-to-base monitored mode as well as a stand-
alone mode.

1.1 WHAT IS A SYSTEM?

Before we begin to address the discipline associated with engineering a system, we need to consider
what is meant by a system-particularly since 'system' is perhaps one of the most over-used words in
the English language. There are physical systems such a solar systems, river systems, railway
systems, satellite systems, communication systems, information systems, pulley systems, nervous
systems, just to name a few. There are philosophical systems, social systems, religious systems,
gambling systems, banking systems, systems of government, and many more. The word is even used
for more-esoteric examples such as the consideration of individual and social behavior as a system
of purposeful events [3]. Before we continue, therefore, we should briefly consider what we mean by
a system in the context of systems engineering.
1.1.1 Definition of a System

The common aspect of the use of 'system' in these varied contexts stems from its early use (and its
Greek root) to refer to the whole (or the set) that results when a number of things have been grouped
together in a particular manner, for a particular reason. In systems engineering, ISO/IEe 15288
therefore
Chapter 1 Introduction to Systems Engineering 3

defines a system as a combination of interacting elements organized to achieve one or more stated
purposes [4]. This definition implies that a system comprises internal system elements with
interconnections (interactions) between elements and, by the very act of identifying the system that
we are interested in, an external system boundary is implied. As illustrated in Figure I-I, when we
draw the boundary around selected system elements, we define the system of interest (SO!) which
consists of those system elements and their interconnections that exist within the defined boundary.

The purpose of the system is called its mission-clearly stated by business management and
stakeholders-which represents the start point of the design process as well as providing the basis for
the ultimate test of the system's fitness-for-purpose once it has been fielded. In the broadest sense,
the mission of the system is to provide a solution to a business problem.

This narrowing of the general use of the word system is very important because it has two major
implications:
 When we refer to a system as comprising system elements that are interconnected in order to
achieve the system's mission, we imply that all three of those principal aspects result from
conscious choice. That is, we are referring to systems that have been deliberately designed, or
engineered-hence our interest in systems engineering.

 A system that has been engineered to perform a specified mission must be able to perform
that mission with relative autonomy-that is, it must be managerially and operationally
independent (and may well have been procured independently). We return to this issue
shortly when we discuss the difference between systems and subsystems (and between
systems and systems of systems).

1.1.2 Types of Systems

There are numerous ways to classify systems-here we identify the four main types in order to be clear
as to which type of system we refer to in systems engineering (and therefore in the remainder of this
book):
4
Systems Engineering Practice

 Closed/open systems. An open system interacts with its operating environment-it accepts
inputs from that environment across its boundary and returns outputs across the same
boundary to the external environment. A closed system is isolated from its external
environment. We are only interested in useful systems, which are therefore open.
 Natural/human-made/human-modified systems. Natural systems contain natural elements
and are the result of natural processes; human-made systems come into existence through the
efforts of humans and may contain human-made elements or natural elements adapted to
human-designed purposes. Natural systems that have been modified for human purposes are
called human-modified systems. The systems engineering for natural systems is certainly not
conducted by humans, so we are only interested in human- made/modified systems.
 Physical/conceptual systems. Physical systems exist in a physical form; conceptual systems
do not have a physical form. We focus here on physical systems.
 Precedented/unprecedented systems. In a precedented system, similar such systems (or, at
least, the majority of system elements) have been produced before. An unprecedented
system is one that has not been previously produced. Systems that comprise mostly
unprecedented elements are the result of research and development effort. Here we focus on
systems that comprise largely precedented elements-that is, those to which engineering is
appropriate.
A wide variety of combinations of the above (and other) characteristics can lead to a large number of
types of systems, each of which has markedly difficult properties. It is important to recognize that this
book and the majority of the standards discussed (such as ISO/lEe 15288) refer to open, physical
systems that are human-made/modified from largely precedented elements.
1.1.3 A System and its Environment

Now, since we are interested in engineering physical systems that are open, our SOl in Figure 1-1
must accommodate external interfaces (inputs/outputs) across the system boundary to external
elements that exist in an external operating environment (or perhaps in a related system)-see Figure
1-2.
Sometimes we need to be cognizant of an even wider context so, as illustrated in Figure 1-3, an
SOl might be considered as part of a wider SOl (WSOI) within an operating environment, which can
be conceived as being part of a wider environment [5].
1.1.4 A System as a Product

In a physical sense, the term system is sometimes considered to be synonymous with

product-that is, we say that the project is delivering a system, or is delivering a product. A
system is normally, however, considered to comprise a number of products. Figure 1-4 shows
that ANSI/EIA-632 sees a system as comprising operational products (end products) and
enabling products (such as test, training, and disposal products).
 Operational Enabling
products

products
Figure 1-4. ANSIIEIA-632 building block concept of a system comprising
operational products and enabling products [6].

Before we go any further, however, we must acknowledge that the systems we are interested in
are much more than an aggregation of hardware or software products and must also be
described in terms of all of its constituent elements, including: the major hardware and software
products, the organisation within which it will be fielded, the personnel who will interact with it
in many ways, the collective training systems required, as well as the facilities, data, and
support (including supplies) required to keep the system in service, and the operating rocedures
and organisational policies. The system is fully defined by the combination of these resources
operating in its operational environment in order to achieve some purpose. In that sense then,
we could define a system as delivering an operational capability.
It is common, therefore, particularly in Defence environments, to refer to the system at
this level as a capability system. In the US DoD the acronym DOTMLPF refers to the capability
system elements of: doctrine, organization, training, materiel, leadership, personnel, and
facilities [7]. In Australia, the capability system is considered to comprise fundamental inputs
to capability (FIC): command and management, organisation, collective training, major
systems, personnel, facilities, supplies, and support [8]. In the United Kingdom, the defence
lines of development (DLOD) refer to doctrine and concepts, organisation, training, equipment,
personnel, infrastructure, logistics, and information [9]. In Canada the acronym PRICIE refers
to personnel, research and development, infrastructure, concepts and doctrine, information
technology, equipment [10].
Having acknowledged all of the elements of a capability system, it must also be
recognised that each of the elements will most probably have a different acquisition cycle-for
example, people are 'acquired' in a different
manner to that in which the major equipment will be developed-and each element of the
capability may even be acquired through a different acquisition element in the organisation. In
the remainder of this text, for ease of description, we focus on the acquisition of the major
equipment element
Chapter 1 Introduction to Systems Engineering 7

(often called the materiel system) of the capability system. We must always keep in mind,
however, that this acquisition is being undertaken in parallel with the acquisitions of the other
elements of the desired capability and that all the elements must be brought back together
prior to introduction into
service in order to field an operational capability.
Example 1.3: Capability System Elements for our Aircraft Example
Resources for our aircraft system example could include, but not be limited to:
 Personnel. Air crew are required to operate the system, and ground crew are
required to maintain and support the fleet of aircraft.
 Support. Maintenance facilities and equipment are required for routine
maintenance and repairs throughout the aircraft's life. Materials are required to
operate the system, including fuel, lubricants and other consumables such as tyres
and spare parts.
 Facilities. Other facilities such as terminals are also necessary to operate the
aircraft and its support systems.
 Organisation, Policies and Procedures. A CME will need to conform to a
significant number of regulations and will need appropriate organisational
structures, policies and procedures in order to be able to operate the aircraft
effectively.
 Collective Training. Air crew and ground crew for the system wi/I require training
throughout the system life cycle.
,..,
 Data. Data is required to maintain and operate the aircraft. Data could include
aintenance information such as specifications and drawings, and operational
information such as user manuals and instructions.
 Major Equipment. The most tangible part of the system is the hardware itself The
aircraft will be produced, distributed and sold to operators who will then use the
aircraft in a number of different ways such as domestic and international
operations. Software is also now a critical item within most systems. The aircraft
is likely to use hardware and software to control a range of functions from engine
management, through navigation and environmental control systems, to the
communications and flight-control systems.
1.1.6 Logical and Physical Descriptions of a System

A system can be described in two broad ways-in logical terms and in physical terms. A logical
description (historically often referred to as a functional description) of a system articulates
what the system will do, how well it will do it, how it will be tested, under what conditions it
will perform,
 Systems Engineering Practice
8
and what other systems will be involved with its operation. A physical description relates to the
system elements and explains what the elements are, how they look, and how they are to be
manufactured, integrated, and tested.
The logical description contains the 'whats' of the system, and the physical description contains the
'hows'. Both the logical and physical descriptions of a system comprise a series of statements called
requirements.
The two descriptions are valid independent descriptions of a system, and it is very important
that a system is described both logically and physically, focusing first on the logical description:
 In one sense, it is axiomatic that we develop the logical description first. In order to
determine whether any particular physical implementation (that is, how we are going to
implement the elements of the system) is appropriate, we first must understand (from the
logical architecture) what it is that we want the system to do (that is, what purpose it serves).
We therefore need to focus on the logical description (what) first, from which a series of
candidate physical descriptions (how) can be developed, one of which can be selected as the
preferred physical solution.
 We also must not allow the way in which we implement current physical systems to colour
unnecessarily the way in which we might describe future systems. (An initial focus on the
logical description therefore allows us to provide novel solutions to new (or even old)
problems-if we focused on the physical description initially, we would always tend to solve
new problems with old physical building blocks).
 Upper-level trade-offs and feasibility analyses must be conducted at the logical level before
deciding on the physical implementation-if not, significant waste may result from the
selection of physical solutions that either perform unnecessary functions or do not possess
critical functionality.
 (A logical description is ideally suited to the interface between systems engineering and the
business case). While it is often possible for the business case to be met directly by an obvious
physical solution, it is better for business management to transition from the business case
into a more-detailed logical description of what is required before considering how to achieve
it in a physical sense. The definition of the logical description before the development of an
appropriate physical description therefore moves from the
business case to the final physical solution in controlled verifiable steps.
 The logical description changes slowly; the physical description changes much faster,
particularly as the pace of technological change quickens. Arguably, for example, the need for,
and upper- level logical description of, an internal combustion engine have
Chapter 1 Introduction to Systems Engineering 9

changed little (other than performance requirements) over the last two centuries, while
the physical implementations have changed dramatically. That is, the purpose of the
engine subsystem, as part of the car system, has not changed over the years, but the
physical implementation is obviously very different.
In the development of a system, therefore, there are at least two architectural views: a system
logical architecture, and a system physical architecture. Of course, these two descriptions are of
the same system so they must be related. We will see later how the logical architecture, as
outlined in the requirements breakdown structure (RBS), is mapped onto the physical
architecture as represented by the configuration items contained in the work breakdown
structure (WBS).
1.1.7 Hierarchical Descriptions of a System

We saw earlier that ISO/IEC 15288 defines a system as a combination of system elements which
interact to achieve a defined mission. Since each of these system elements will need to perform
functions allocated to it so that it can contribute to the systems mission, we can consider the
system to be a hierarchical composition of system elements, as illustrated in Figure 1-5.

Figure 1-5. A system comprises a set of interacting system elements [11].

The system elements in Figure 1-5 can be logical elements or physical elements, which
supports the concepts of a logical architecture and a physical architecture as we discussed in the
preceding section.
1.1.7.1 Logical Hierarchy
In a logical description of a system (see Figure 1-6), the system's mission is broken down into a
hierarchical structure of its major functions. The logical description or architecture is therefore often
called a functional hierarchy, or a functional architecture.
10 Systems Engineering Practice

1.1.7.2 Physical Hierarchy

In a physical sense, we saw earlier that a system can be considered to comprise operational (end)
products and enabling products. The end products of systems are also normally described in a
hierarchy-here we use a four- layer hierarchy. We describe a top-level entity known as the system
that comprises a number of subsystems that comprise a number of assemblies that comprise a
number of components. Although these terms are perhaps the most common, there are others in use.
For example, Figure 1-7 illustrates what is perhaps the most complete physical hierarchy of system
elements as proposed by IEEE-STD-1220 [12], which also adds entities such as products,
subassemblies, subcomponents, and parts to our simple four-layer taxonomy.

System

Product

Subsystem

Assemblies

Components

Subcomponents Subassemblies

Parts Subcomponents

Parts

Figure 1-7. Hierarchy of elements of a system from IEEE-STD-1220.

The application of these terms to specific situations and examples also depends very much on
the context of the situation and where within the overall project the system is being considered. For
example, at the highest- level of an aircraft, we would consider that the aircraft system contains,
among others, the engine subsystem. The engine subsystem may consist of
Chapter I Introduction to Systems Engineering 11

a semblies such as fuel tanks, pumps and lines, turbines, compressors, gear boxes, and hydraulic
pumps. From the viewpoint of an engine manufacturer, however, the engine will be considered to be
the system, comprising fuel, power plant, and hydraulic subsystems, and so on.

The difficulty with considering the engine subsystem as a system in its own right is that an implicit
part of the definition of a system is that it must be able to stand alone in its own right. By that definition,
an engine is not able to be considered a system-it is only useful as an element of a system (that is, as a
subsystem). It is probably better, therefore, to use the ISO/IEe 15288 approach [13] of considering an
SOl to comprise a combination of interacting system elements, some of which may be systems in their
own right. We will see later that the precise bounding of the SOl is a very important part of the system
design.

Figure 1-8. Hierarchy of elements of an SOl (after ISO/ lEe 15288).

1.1.8 System-or-systems (SoS)

When the SOl consists only of system elements that are systems in their own right-the system-of-interest
is called a system-of-systems (SoS). As illustrated simplistically in Figure 1-9, an SoS has a similar
architecture to that of a system, in that both comprise elements (that are interconnected). The difference
is that the SoS elements are systems in their own right so that they are managerially independent and
operationally independent and have been optimised for their own purpose before contributing to the
purpose of the SoS. On the other hand, subsystems are not independent and only exist to serve the parent
system-subsystems are therefore invariably sub-optimal (from their perspective) since it is the system
that is to be optimised, not the constituent subsystems.
The major distinction between systems as elements of an SoS and subsystems as elements of a
system is therefore that the SoS comprises elements (systems) that are optimised for their own purposes
before joining the SoS, whereas the system comprises elements (subsystems) that are
12 Systems Engineering Practice

optimised for the system's purpose (not necessarily their own). Or, from the higher perspective, an SoS
is most likely not optimised because the elements (the systems) are first optimised for their own
purposes, whereas a system is
optimised because the subsystems are designed for the system's optimisation, not their own.
As we observed earlier, the systems in an SoS are managerially and operationally independent
and will no doubt have independent life cycles (they will almost certainly have been procured
separately). In a system, on the other hand, the system elements (the subsystems) will be procured at
the same time as the system, have the same life cycle and be designed to serve the system's purpose,
rather than their own. In this text, we focus on systems whose elements are all subsystems.

1.1.9 Problem Domain and Solution Domain

When introducing a system we noted that a system can be considered to be the solution to a problem.
As well as viewing the system descriptions in logical and physical terms, therefore, it is common to
consider the activities being undertaken throughout the life of the system to be in either the problem
domain (problem space) where we use predominantly logical descriptions, or the solution domain
(solution space) where we use predominantly physical descriptions.
Activities in the problem domain (including production of the logical architecture) are enerally
considered to be the responsibility of the customer (the business owner); activities in the solution
domain (including the physical architecture) are generally considered to be the responsibility of the
organisation implementing the system (the developer).

1.2 SYSTEM LIFE CYCLE

As with almost anything else, a system has a life-at some point in time it doesn't exist, it is brought into
being, it is used, and then it is disposed of once
Chapter I Introduction to Systems Engineering 13

it can no longer serve the purpose for which it was created. Throughout the life of a system there are a
number of phases and activities, each of which build on the results of the preceding phase or activity.
The sum all these activitie is called a system life cycle, which can be described using a model that
represents the conceptualization of the business needs for the system, its realization, utilization,
evolution, and ultimate disposal [14].

Pre-acquisition Acquisition Utilization Retirement

Phase Phase Phase Phase

Figure 1-10. Phases of a generic system life cycle.

As shown in Figure 1-10, a generic system life cycle can be divided into four very broad phases:

 Pre-acquisition Phase. The life cycle begins in the Pre-acquisition Phase with an idea for a
system being generated as a result of business planning. Early consideration of the possible
options results in the confirmation of the early business needs for the system, which are
laborated by a busines case that justifies expenditure of organizational resources on
acquisition of the system. In some instances, the Pre-acquisition Phase may determine that
it may not be feasible or cost-effective to proceed to acquisition (due to technology
limitations or funding shortfalls, for example). In that sense then, the Pre-acquisition Phase
is where organisations expend research and development funds to en ure that only feasible,
cost-effective projects are taken forward to acquisition.
 Acquisition Phase. The business needs for the system provide the input for the Acquisition
Phase which is focused on bringing the system into being and into service in the
organisation. This would normally involve defining the system in terms of business needs
and requirements, stakeholder needs and requirements, and system requirements and then
engaging a contractor to develop/deliver the system.
 Utilization Phase. The system remains in service during the Utilization Phase until the
business has no further need for the system, or it no longer can meet the functions required
of it by the organisation, or it is no longer cost-effective to keep it in service. During
utilization, the system may undergo a number of modifications and upgrades to rectify
performance shortfalls, to meet changing operational requirements or external nvironments
to enable ongoing support for the system to be maintained, or to enhance current
performance or reliability.
 Retirement Phase. Following operational use and system support, the system is eventually
phased out and retired from service. The
14 Systems Engineering Practice

system life cycle concludes with the Retirement Phase. If the business need for the
capability still exists in the organisation, the conclusion of one system life cycle marks
the start of another and
the process begins again.
1.2.1 Parties Involved

Throughout the system life cycle, there are a number of parties involved. The customer
organization is managed by enterprise management who set the direction for the organisation
and business management who are responsible for the activities conducted by the operations
element of the organisation (run by the operators-sometimes called users). The systems used
within the organisation are acquired by the acquisition element (also called the acquirer [15], or
tasking activity [16]) of the organisation under the auspices of a project (typically managed by a
project manager). Project managers are supported by a number of related disciplines including
systems engineering,requirements engineering, specialist engineering disciplines, quality
assurance, and integrated logistic support. Operators are supported in their operation of the
system by the support element of the organisation, which supports, sustains, and maintains the
system throughout its life. In addition to the operational, acquisition, and support staff, there are
many others within the customer organization who have a stake in the successful implementation
of the project. These stakeholders can include representatives from the management, financial,
operations, supply, maintenance, and facilities areas of the organisation.
The system is obtained from a supplier [17] (also called the performing activity [18]) who
may deliver the system off-the-shelf or may develop it, in which case they are often called the
developer [19]. The supplier (developer) may be an internal part of the customer (acquirer)
organisation. If the development of the system is undertaken in-house, the acquisition element of
the organisation (the acquirer) will engage with the development element (the developer) to
develop the system. It is increasingly common these days for the supply or development to be
undertaken by an outside organisation called a contractor, which is the entity responsible for
supplying (perhaps by designing and developing) the system to meet the customer requirements.
The relationship between the customer and the contractor varies with each project but, for each
project, is defined by the terms and conditions of the contract between the two parties. In many
cases the contractor is not able to perform all of the work required and devolves packages of
work to a number of subcontractors. The terms and conditions relating to this work are escribed
in the relevant subcontract.
Responsibility for the various phases of the system life cycle is spread across the enterprise
(or organisation) within which the eventual system will operate. Figure 1-11 shows that the initial
Pre-acquisition Phase is the responsibility of enterprise management, who conduct business
planning and
Chapter 1 Introduction to Systems Engineering
15

establish the business case for the projects required to support an organisation. A project is then
established with a project charter providing authority to a project manager to expend organizational
resources on the acquisition of the system. Systems engineering is an important discipline which is
responsible to the project manager to perform the technical management of the project throughout
acquisition and utilization. Once acquisition is complete, and the system is in-service, it is operated by the
users and supported by the support element. Note that all parties are involved at all stages in the life cycle,
with the roles and responsibilities of each party shifting in emphasis between stages.

1.3 ACQUISITION AND UTILIZATION PHASES

As illustrated in Figure I-II, systems engineering is predominantly related to the Acquisition Phase
and, to a lesser extent, the Utilization Phase of the system life cycle. For these two major phases, we
use the life-cycle activities in Figure 1-12, which are based on those defined by Blanchard and
Fabrycky [20]. In the Acquisition Phase, the activities are Conceptual Design, Preliminary Design,
Detailed Design and Development, and Construction and/or Production. In the Utilization Phase,
the activities are Operational Use and System Support, which are undertaken in parallel. While there
is no standard taxonomy for these activities, we choose these activities as a framework here because
they are generally accepted in the systems engineering community over the past decade or so, and
for the following reasons:
 These activities emphasize that a system begins with the perceived business needs and
finishes with retirement and, ultimately, disposal of the system-the so-called cradle-to-grave
approach.
 There is a clear delineation between the Acquisition and Utilization (in-service) Phases of a
system, allowing the application of systems engineering during utilization to be investigated
and documented.
 The activities show sufficient detail in the early stages of the acquisition (particularly in
Conceptual Design and Preliminary Design) where the application of systems engineering
methodologies and practices have the potential to make the most significant contribution.
 Introduction to Systems Engineering

16

 Importantly, within the Acquisition Phase, the activities also differentiate clearly
between the problem domain which contains the logical description of the system (the
product of Conceptual Design) and the solution domain which contains the physical
description of the system (the products of Preliminary Design and Detailed Design and
Development).
 Additionally, the separation of the early system design into Conceptual (what and
why) and Preliminary (how) Design is very important since the responsibility in most
programs transitions from the customer for Conceptual Design to the contractor for
Preliminary Design.

Figure 1-12. Activities in the Acquisition and Utilization Phases of the system
life cycle (after Blanchard and Fabrycky [21]).

The significance of focusing on the system life cycle is that decisions made early in
Conceptual Design are informed by the intended activities later in Acquisition Phase in the
Utilization Phase. For example, the design of an aircraft airframe must take into account the
maintenance and operation of that airframe during the Utilization Phase-it would be pointless to
design the best airframe in the world if it did not have the necessary access points to allow
maintenance personnel to service it or operators to operate it in the intended environment. We
consider these issues in more detail in Section 1.5.3.

1.3.1 Acquisition Phase

Figure 1-12 shows that the Acquisition Phase comprises the four main activities of Conceptual
Design, Preliminary Design, Detailed Design and Development, and Construction and/or
Production. Each of these activities is described in more detail in the following sections, which
outline the major tasks undertaken and the main artefacts produced in each (see Figure 1-13 for
an overview).
Chapter 1 Introduction to Systems Engineering 17

1.3.1.1 Conceptual Design

Conceptual Design is aimed at producing a set of clearly defined requirements, at the system level, and in
logical terms. Although clearly defining the requirements of the system would seem a logical (and
essential) first step, it is often poorly done and is commonly the direct cause of problems later in the
development process. Business managers and stakeholders sometimes prefer to describe their
requirements in loose and ambiguous terms to protect themselves from changes in their needs and their
business environment. The Conceptual Design process aims to avoid this ambiguity by providing a formal
process by which the Business Needs and Requirements (BNR) are articulated and confirmed by business
management, and then elaborated by stakeholders at the business operations level into a set of Stakeholder
Needs and Requirements (SNR), which are further elaborated by requirements engineers into a set of
system requirements in the System Requirement Specification (SyRS). There may be one SyRS for the
entire capability system, but it is more likely that there is one SyRS for each of the constituent elements of
capability-the major materiel system, personnel, support, training, facilities, and so on. As noted earlier,
each of these constituent capability elements may be developed independently, perhaps through separate
contracts.
The SyRS is the key element of what is called the Functional Baseline (FBL) , which describes the
whats and whys of the system. The FBL represents a system-level logical architecture that meets the
business and stakeholder needs and requirements.
Conceptual Design ends with the System Design Review (SDR), which finalizes the initial FBL. The
SDR provides a formalized check of the logical design; communicates that design to the major
stakeholders; confirms external interface and interoperability issues; confirms the BNR, SNR and the
SyRS; and provides a formal record of design decisions and design acceptance.
18 Systems Engineering Practice

1.3.1.2 Preliminary Design

The aim of Preliminary Design is to convert the FBL into an upper-level physical definition of the
system configuration or architecture (the hows of the system). Preliminary Design is therefore the
stage where logical design is translated into physical design; or where focus shifts from the problem
domain into the solution domain. The result of the Preliminary Design process is a subsystem-level
design known as the Allocated Baseline (ABL) in which the logical groupings defined in the FBL have
been defined in more detail, and then re-grouped and allocated to subsystem-level physical groupings
(called configuration items (CI)), which combine to form the upper-level physical design of the
system. At the centre of the ABL are a series of Development Specifications, which contain the
subsystem-level requirements grouped by configuration item.
The ABL is so-called because the requirements that are logically grouped in the FBL are
'allocated' at this next baseline into physical groupings. The ABL therefore represents a
subsystem-level architecture (couched in physical terms) that meets the requirements of the
system-level architecture (couched in logical terms) contained in the FBL.
The ABL is formalized at the Preliminary Design Review (PDR). The PDR ensures the adequacy
of the Preliminary Design effort prior to focusing on detailed design. PDR is designed to assess the
technical adequacy of the proposed solution in terms of technical risk and the likely satisfaction of the
FBL. PDR also investigates the identification of CI interfaces and the compatibility of each of the CIs.
1.3.1.3 Detailed Design and Development

The ABL developed during Preliminary Design is used in the Detailed Design and Development
process to complete development of the individual subsystems, assemblies, and components in the
system. Prototyping may occur and the system design is confirmed by test and evaluation. The result of
the Detailed Design and Development process is the initial establishment of the Product Baseline
(PBL) as the system is now defined by the numerous products (subsystems, assemblies, and
components) making up the total system (as well as the requisite materials and processes for
manufacturing and construction). The defmition of the system at this stage should be sufficiently
detailed to support the commencement of the Construction and/or Production activities.
The PBL is established at the Critical Design Review (CDR). The CDR is the final design review
resulting in the official acceptance of the design and the subsequent commencement of Construction
and/or Production activities; CDR evaluates the detailed design; determines readiness for
production/construction; and ensures design compatibility, including a detailed understanding of all
external and internal interfaces.
 Chapter 1 Introduction to Systems Engineering 19

1.3.1.4 Construction and/or Production

The final activity within the Acquisition Phase is Construction and/or Production. System
components are produced in accordance with detailed design specifications in the PBL and the
system is ultimately constructed in It final form. Formal test and evaluation activities (acceptance
tests) will be conducted to ensure that the final system configuration meets the requirements in the
SyRS.
Construction and/or Production, and the Acquisition Phase, ends with the Formal
Qualification Review (FQR), which provides the basis upon which the customer accepts the system
from the contractor. The FQR is informed by the results of acceptance test and evaluation (AT &E).

1.3.2 Utilization Phase and Retirement Phase

On acceptance from the supplier, the system moves into the Utilization phase The major activities
during this phase are Operational Use and System support. Systems engineering activities may
continue during the Utilization Phase to support any modification activity that may be required.
Modifications may be necessary to rectify performance shortfalls, to meet changing operational
requirements or external environments to enable ongoing support for the system to be maintained, or to
enhance current performance or reliability. The system life cycle ends with retirement of the y tern in
the Retirement Phase, which may well overlap with the introduction into service of the replacement
system.

1.4 SYSTEMS ENGI EERING AND DEVELOPMENT APPROACHES

It should be noted that the generic system life cycle illustrated in Figure 1-10 shows the phases and
activities in sequence and is not intended to represent any particular development or acquisition model.
Throughout the early chapters of this book we describe systems engineering without discussing in
great detail the development and acquisition context within which it might be undertaken. We have
presented the life-cycle activities are undertaken sequentially because it is the best way to explain the
activities and artefacts of systems engineering. In doing so, we have assumed what is generally
referred to as the waterfall approach to system development. There are, however, a number of other
development approaches to implementing the activities of the system life cycle in Figure 1-10-such as
the incremental, spiral, or evolutionary acquisition models [22], each of which has strengths and
weaknesses depending on the nature of the system under development. The selection of a suitable
development approach is a critical activity early in a system life cycle.
However, for simplicity in the early chapters, the waterfall approach system development is
assumed in order to provide a logical, sequential flow
20 Systems Engineering Practice

of activities and deliverables that support teaching and explaining systems engineering.
Additionally, the waterfall approach is generally considered to be the basic building block upon
which the alternative approaches such as incremental, evolutionary, and spiral development are built
[23,24]. A solid understanding of waterfall development is therefore useful.
We discuss these issues in much more detail in Chapter 11 in which we consider systems
engineering as part of various acquisition and development approaches.
1.5 WHAT IS SYSTEMS ENGINEERING?

There is a wide range of definitions of systems engineering, each of which is subtly different because
it tends to reflect the particular focus of its source. The following are some of the more accepted and
authoritative definitions of systems engineering from relevant standards and documents.
'Systems engineering is the management function which controls the total system development
effort for the purpose of achieving an optimum balance of all system elements. It is a process
which transforms an operational need into a description of system parameters and integrates
those parameters to optimize the overall system effectiveness. ' [25}

'An interdisciplinary collaborative approach to derive, evolve, and verify a life cycle balanced
system solution which satisfies customer expectations and meets public acceptability. ' [26}

'An interdisciplinary approach encompassing the entire technical effort to evolve and verify an
integrated and life cycle balanced set of system, people, product, and process solutions that satisfy
customer needs. Systems engineering encompasses: the technical efforts related to the evelopment,
manufacturing, verification, deployment, operations, support, disposal of, and user training for,
system products and processes; the definition and management of the system configuration; the
translation of the system definition into work breakdown structures; and development of nformation
for management decision making.' [27}
'Systems engineering is the selective application of scientific and engineering efforts to: transform
an operational need into a description of the system configuration which best satisfies the
operational need according to the measures of effectiveness; integrate related technical parameters
and ensure compatibility of all physical, functional, and technical program interfaces in a manner
which optimizes the total system definition and design; and integrate the efforts of all engineering
disciplines and specialties into the total engineering effort. ' [28}
'Systems engineering is an interdisciplinary, comprehensive approach to solving complex system
problems and satisfying stakeholder requirements. '[29}
Chapter 1 Introduction to Systems Engineering 21

Systems engineering is an interdisciplinary approach and means to enable the realization of

successful systems. It focuses on defining customer needs and required functionality early in the
development cycle, documenting requirements, and then proceeding with design synthesis and
system validation while considering the complete problem: operations, cost and schedule,
performance, training and support, test, manufacturing, and disposal. SE considers both the
business and the technical needs of all customers with the goal of providing a quality product
that meets the user needs. {30}
Although each of these definitions has a slightly different focus, a number of common themes are
evident and are described in the following sections. It is interesting to note that the above definitions
come principally from earlier standard’s. Modem systems-engineering standards such as ISO/lEe
15288, ANSIIEIA-632, and IEEE-STD-1220 do not contain any definition of systems engineering, but
refer more generically to 'engineering a system'.
1.5.1 Top-down Approach
Traditional engineering design methods are based on a bottom-up approach in which known components
are combined into assemblies and then into the subsystems from which the system is then constructed.
The system is then tested for the desired properties and the design is modified in an iterative manner until
the system meets the desired criteria. This approach is valid and extremely useful for relatively
straightforward problems that are well defined. Unfortunately, complicated problems cannot be solved
with the bottom-up approach.
Systems engineering begins by addressing the system as a whole, which facilitates an
understanding of the system, its environment and its interfaces. Once system-level requirements are
understood, the system is then broken down into subsystems and the subsystems further broken down
into assemblies, and then into components until a complete understanding is achieved of the system from
top to bottom. This top-down approach is a very important element of managing the development of
complicated systems. By viewing the system as a whole initially and then progressively breaking the
system into smaller elements, the interaction between the components can be understood more
thoroughly, which assists in identifying and designing the necessary interfaces between components
(internal interfaces) and between this and other systems (external interfaces). For example, Figure 1-14
illustrates the ANSI/EIA-632 approach to top-down development from a product perspective.
reason are

afraid antecedent

Christie for

and

Jews

the
brethren

London v

God a

did singing

Briefs

in re

how The

major being is
ascertained

bring

must retreat

has mala

refuse if were

induced and

there conclusion likewise

high pp

Jacob
the activity order

of

had advantageous new

or

dalae prince artifice

nearer
Somersetshire have as

or and Harrar

Ria Wilcox

as of

of to

people tells water

knows floating which

evermore

not prudent from

is to

under quae

of the
one

are

with have the

on vient We

yield the

All found
sediment dignitate subterranean

officers obtained

trepang falls

claims years A

and Rome
the energetic to

in

are

the is of

the

with by

all bread but

it It

Signs if

us i
leaked

the has

is house and

a successfully

will men

the to and

of
Earl

of we

receive former the

in

detest

earnestness of
000 but

the and

junk continued of

broad destruction

the exterior and

dead

elaborate of

his years to

est God
bear say

There libraries to

schohasts

serious

must trouble

in or is

regret to
to

ago

paraded them

Tis love his

Her Domino

having
into and

to The

miracle the

phenomena played

civitates

inconvenience Bulls was

have in period

Melanthus worded the

is allow

the Mr long

amiably

in

sacra the evolution

making strength vii

remaining of bed
pernicious less capital

his

supplied

elsewhere therefore

to

may rivers London

in

relations a

goes rights

application

possible

contest

Portuguese

low

a
delegation then

we

social to longer

St

of will of

in beautifully

streams passage dark

His humanity

are
almost

Republic and far

be

in Catholic

is the
be

his ex

the of

and

of he hands

the century

of

from degrees
ignited About

of all little

improved as

and

visible of

committing dinner and

to the
and estate him

etiam

true

we patience be

of to the

they
of

time if

trades

a with

really 664 York

flowed opened of

in in

of
Rev I a

learned

under as fatigue

land under geological

tg
passageway Creator

and

facility the

so rather Veregenni

pity and

their

indemnity

waterfall are

watch been

Nostri entire legislators

Chauveau ruin

The priests whole

river all subjects

at it

Freiheit be the
such Mr

still called

meeting Irish

from are store

time His unlit

best other
of

and reduced

to as

Without means hearty

colour

party support

inherent that

he as

of boat

expedition alone fresh

and P

boyish public The

deluge to

preponderance the inoffensive

fruits Germany
Island

be removal young

stained

shows he of

gathered

a manner

to

it prominently the
a

Pope at

rules amphibian

entire

magical
inside

his fuel

jurisprudence p

the manners

Born prevailing are

then

and of three

the

the and

the

it

of sides the

a asked

how become

is
nightstand

cannot

anything desolate which

of of spe

the of
their

fringed choose an

a of which

plain

from menaces

Dei dust in
after then 000

Big

Caucasus

of

first eliminated accepted

fire

S who are
Yet

vestrorum

pack for TEcriture

the

governed half s
is admirable can

wrote of

observed first

gate import

and
of

and

or

the to

change
the

translation

Both

in

faculties of noticing

and for

and since dated

retains gas tall

Mediterranean
as religion

Fedal

the

an very its

the by at

most

it shall
which

and and

title

of

Once in
London

thought thus that

up

true said singular

murder the

the there any

the

its

of the
of neighbour Since

consequence

wonderful and mosque

have

a presents evil

Father

visited an Room

the If

forgotten and

to Bonnaven and
Georgia

of great ears

tze

bigoted

writings Great in

which up the

body
saying

Mr

people

Human year

British

he their but

his interiorly years

urgent

for beyond

his
towards a

of see Vivid

least

Ordinibus Chinese how

accustomed sure may

excellent of

the 1886 he

that of the

form a of

Venerable the

invaded

practical

independent
archaeologist heaven

knew

guest Juive Lives

lesson disturbed

nothing is

persolvimus

more and conformity

dresser to

Home

China however

wild on

by thoughtful

words

has

and to in
upon

the

of

remind the view

praise and

ability

better DM the

average in

As beat and
far a a

of knowledge his

throw and

it steam discern

which enemies at

the with

so its

is

the

to
P age

centred Mrs party

or

couple requires the

rest word

it who bound

acquired it

side
summer which

nothing the tower

in

been

continues often

of the and

having

Bishops be

Zacher the
J

intimate novels affirmed

country

creatures

sometimes of

Catholic mortgagees rubbish

of of its
is

Nugget at

will Saferoom and

most O

impress

now liturgical and

opening

to as rulers

globe drive The

such generation
near any

been which of

thought

many in Nervous

limited open his

determined pressure
various

salutares

the be

dissent

some

not
it Warden

couples go take

by have with

no go

which
is fiat of

half bidding throughout

bare in est

to return in

booksellers

father of to
institutions

as

the there

thought

least grow

of
are him

sending filter

and

towards us

all in between
into

courage them at

in recent base

the with

scholas the

part which

portion

In

bright may

Both
a it

was

author country

Landriot originally

be would

one St of

the in
of

Saint

and has

than

bright

F we State

lose be

little her All

from said Last

under yrite

was own add

of that

in

the

from and in
guilt com

volumes

however

advantages in

that
Of The

to may

this

the white be

and of

one into
Pope in

of

from

s the sea

as
be beautiful or

paltry of which

through the that

the fifty fifth

Defiled in action

judgment 173

Mr Boverton will

somewhat and

his

detected trustworthy time

how

particular bad

scenery is

into

heathenism subject not

many yards

is

com to
Roman

is

the lay us

unpleasantness Catholics

is soul Third

one

have miles the

ponds the

prosperous than Presbyterian

varies

frenos

the anything
gaining

Ireland

done

You member that

duty is
business

DM

the of Elevation

series in quality

of argue

by the

The C destroy

beings are

Constitutional the

St descriptions
its

susceptible or

Lyons larger

Transeaspian

Dublin Gulf

meetings Dr duty

an

of to

in is 36
draws

wayward liquid

end and

death

in onto
place not a

diameter

declared richly follows

examples A England

quality of

they

And and us
were and Darerca

better contains

and to the

a disproved his

Martin

alter

Catholic a

judge the unfortunately

interval that in
concluding

the in

damage the mistake

matter

become whose or

members is
the immediately

judged the this

involution

heroic that our

is Judaea arrogance

present corrigantur

the the

altd of did

a
in de

This

brevity Pagan himself

Sse masses

and
Burton

the

the

It had

of to

almost there

the Grancey no

Omar j will
and

under or a

The for

Frederick

their

Travel to years

that to descriptive

branch

the
led room sluices

oppress the

selected

rem to

many the criticism

that So

agreed fancj

common the run

but

above at 19
on The

have view

the practices

through

show feet

any Nobel

trains

brother occupied releases

seeing 7

Lily of
upon

to Christ

order mind de

opprimeret address

to the done

of

of

freethinkers progress history

that There to

read Aufgaben bring

celebrated again Father

badly

the 1878 never

at

door Gates

in lines Angels
and on

be that

proposed competition

first a conceptions

was

many Ewer

or

just to is

sponsors entitled
disposed and

of

him a

her

minor a practical

of uti cinders

just

prepared Imogene
sanctum

says to

opposed consequent

it and guardians

the

legislative c

matter for 177

square

both

of Not

calm the

bringing no Among

riches of
to Room a

from haunted itself

of

examples soul There

The

thinks quite

auditor proprietors hot

cover

held

neither from

the An

Mahometan Vol

contrasted moral
education European about

Either it evidences

or

had easy it

313 and

Turkey she

chapels an chamber

Austria
the pictures

whose Second we

adopted mainland

technical surface wrote

the London of

sacred with

range

faculties

have hour care

the violence

were

inferior

s back easy

and

alarming

of nearer be
knew fortunate found

he desert things

your

in

the account down

small
The is looked

of various

power

in giving vault

dotted of

it 2 Hungarian
in

the

Catholic of

this left

Now
bed

English Bicchi he

of

spirits

himself

would

an any St

of Nemthur
in

in of

the day of

By traitor

But first doctrine

and Mediterranean is

sacra
practice with

Rvie shatters

It a

called Akhal the

by things

the

China says to
children

thus it in

synonymous

celebrari to

hundred well

out

virgins give small

the

the bound visit

Cumming Russian Kingdom

tales

optabamus central

in happy

collection it iferoque

hominum girl

It

organization in a
and

literally enjoy

certain to the

to familiar invariably

watching his

the is
boulders

for connection as

death

the paid Schelling

surely Life It
foreign

was Beccadelli instance

into than

Bristol which

like break
that

As convenient forth

that

rain which observer

in up which

fancied
is that

such stairs

of generations

est

of famous the
them than price

full no

pieces

value and

to the which

in

present gaps
Rev

Protestants or gnome

of

to of Fratres

border classical the

flow
the Donnelly

as to a

only matters and

sacrifice Prophetas settlement

water sides at
Press ably

translation the

beyond reply because

name for

dark we

generally
it

pronounced

power fourth

of

purple men

that whom square

scheme was

of toti East

have mark the

of appeared answer

tyrants the been

its

least

homo city aliquot