0% found this document useful (0 votes)
11 views

03

A system can be described in logical and physical terms, where the logical description focuses on what the system will do and the physical description details how it will be constructed and integrated. It is crucial to develop the logical description first to ensure clarity of purpose and to avoid being constrained by existing physical solutions. Both descriptions are essential and must be related, as the logical architecture informs the physical architecture in system development.

Uploaded by

Cihan kılıç
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views

03

A system can be described in logical and physical terms, where the logical description focuses on what the system will do and the physical description details how it will be constructed and integrated. It is crucial to develop the logical description first to ensure clarity of purpose and to avoid being constrained by existing physical solutions. Both descriptions are essential and must be related, as the logical architecture informs the physical architecture in system development.

Uploaded by

Cihan kılıç
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 2

A system can be described

in two broad ways, in logical terms and


in physical terms. A logical description,
historically, we've often called that a
functional description, articulates what
the system will do, how well it will do it,
how it will be tested, under what conditions
it will perform, and what other systems will be involved with this operation. A
physical description
relates to the system elements themselves that explains what those
elements are, how they look, how
they'll be manufactured, how they'll be integrated,
and how they'll be tested. A logical description
is about what, but the physical
description is about how. But both those
descriptions, of course, are very important, and
they both exist together, and both of them require
what we call later, a series of statements
called requirements. Now, the two descriptions are valid independent
descriptions of the system, and it's very important
that the system is described both logically
and physically. But of course, we must focus first on the logical
description. Now in one sense, it's axiomatic that we develop that
logical description first in order to
determine whether any particular physical
system is appropriate, that is, how we're going
to do it is useful to us. We must first
understand, of course, what it is we want to do, what purpose we want
the system to serve. We therefore need to focus
on the logical description, the what, before we examine a series of candidate
physical descriptions, the hows, of how we might
develop the system, one of which, of
course, is going to be chosen as our preferred
physical solution. The second reason
is we must also not allow the way in which
we currently implement current systems to color unnecessarily the way which
we describe future systems. If we focus on the
logical description, we can then focus on
perhaps novel solutions to new or even old problems. If we focus on the
physical solution first, we will always end up solving new problems with the old
physical building blocks. Third, if we're going
to trade things off, if we're going to actually
trade off value for money, for example, then we
need to do that at a logical level before deciding on the physical
implementation. If not, we may waste significant effort selecting
physical solutions, which either perform
unnecessary functions or don't perform something
which actually is critical. Next, a logical description
is ideally suited to the interface between
systems engineering and the business case. While it's often possible
for the business case to be met directly by an obvious
physical solution, it's probably better for
business management to transition from their
business case into a more detailed logical
description before going on to deciding how to solve that problem
in a physical sense. The definition of a
logical description before the development
of a physical system, therefore moves from
the business case to the final solution in a more controlled, more verifiable way.
The final reason is the logical description
changes much more slowly. The physical description
changes very quickly, particularly these days
with changes in technology. Arguably, for example, the need for and the
upper level description of an internal
combustion engine hasn't changed much over the
last two centuries. Its purpose is to provide
forward motion for the car. But the physical implementation for an engine has
changed dramatically. That is, the purpose of the system as part of
the car hasn't changed, but the way in which
we do it has as we avail ourselves
of new technology. In the development of
a system, therefore, there are the two
architectural views, a system logical architecture, and a system physical
architecture. Now, of course, these
two descriptions are of the same system, so they must be related. We'll see later
how the
logical architecture, as outlined in the requirements breakdown structure is mapped
onto the physical architecture, as it's represented in what we call the work
breakdown structure.

You might also like