West M. Developing High Quality Data Models
Подождите немного. Документ загружается.
14.4 Similarities, Differences, and
Relationships to Other Things
There are a number of other kinds of things that system
components are sometimes confused with, coincident with, or
related to. Keeping the different kinds of things in their own
box, and understanding the relationships between them is nec-
essary to avoid making mistakes. They are
• Ordinary physical objects
• Roles in activities or associations
• Functional objects
• The class of activity performed by a functional object
The following sections outline the distinctions and relation-
ships between each of these and system components.
14.4.1 Ordinary Functional Objects
Ordinary physical objects do not survive all their parts being
changed at once. This would result in a new ordinary physical
object. On the other hand, a system component does survive such
a change. It is possible that although a part is designed to be
replaceable , it actually does not get replaced during the life of the
thing it is a part of, and the part was created in situ and was
destroyed in situ as part of the whole. So it is possible (but unlikely)
that a system component coincides with the ordinary physical
object installed. The object is then both an ordinary physical object
and a system component, but simply as a matter of accident.
14.4.2 Participants in Activities and Associations
It is perfectl y possible for a participant in an activity to be a
system component. The ear lier football example illustrates this.
The eleven players are participants in the activity. However,
they are also system components, because the person filling the
position of one or more of the eleven players can be replaced.
However, this does not mean that all system components are
participants in activities or associations. So for example, P101
performs a pumping operation in normal operation. However,
when the Crude Distillation Unit is shut down, P101 is not per-
forming a pumping activity. However, it is still a system compo-
nent of the Crude Distillation Unit.
14.4.3 Functional Objects
A functional object is something that is intended to perform a
function (class of activity). It is common for a system component
to also be a functional object. For example, the pump P101 is a
functional object as well as a system component. However, that
182 Chapter 14 SYSTEMS AND SYSTEM COMPONENTS
does not mean that all system components are functional
objects or that all functiona l objects are system components.
14.4.4 The Class of Activity Performed by a
Functional Object
In the design process for a process plant, the first thing that
you do is set out the processes that are to be performed to
determine the inputs and outputs (mass and energy) and to
decompose the process and sequence the steps to such a level
that you can identify the functional objects that will perform
the process steps. These process steps are classes of activity
(rather than being a process execution). Some have suggested
that these are what the tags of a process plant are all about. You
cannot start up a class, however, and you can start up P101 (or
at least that is what plant operators think they are doing). So
tags are the system components that are going to perform the
class of activity, not the class of activity itself.
14.5 Do I Need a Separate Set of Classes
for System Components?
One of the conseq uences of introducing systems compo-
nents is that we now seem to have two kinds of pumps: a sys-
tem component pump and an ordinary physical object pump.
Do we really need both of these?
You may recall that we talked about some properties being
temporally dissective; that is, if the property applies to the
whole, then it applies to any temporal part of it. Being a pump
is temporally dissective, but being a whole life pump is not. So
if we look at a system component pump, we find that each of
its existent states is a state of an ordinary physical object pump.
There is no state of exi stence that is not also a state of an ordi-
nary phys ical object pump—though not necessarily a state of
the same ordinary physical object pump. So we can say quite
happily that a system component pump is a pump, and that an
ordinary physical object pump is a pump, so we do not need a
separate class for each. Of course if we want those pumps that
are ordinary physical objects, or those pumps that are system
components, then we can construct those classes with ease.
14.6 Extending the Framework for System
and System Component
Figure 14-6 shows a data model that reflects the preceding
analysis. The key entity types are highlighted.
Chapter 14 SYSTEMS AND SYSTEM COMPONENTS 183
Reading through the diagram, a system is an ordinary_
physical_object that has a number of system_components as
parts. A system_component is a physical_object that can be
replaced, and that can go through periods of nonexistence. An
installed_object is a state_of_system_component that is also the
state_of_ordinary_physical_object of the ordinary_physical_
object installed, for the whole period of its installation.
This basic pattern can be specialized for particular circum-
stances. For example, complex artifacts are usually systems and
can be modeled with a direct specialization of the basic pattern
for systems and system components as shown in Figure 14-7.
The key entity types are highlighted. Note that some relation-
ship types from the basic pattern are not shown.
The patter n also applies to the person_in_position of a per-
son to a position in an organization, but this time the speciali-
zation is not quite so straightforward, as Figure 14-8 shows.
A positi on is an organization_component that is part_of an
organization.Aperson_in_position is a state_of_person that is
also a state_of_position for the whole time a perso n holds that
position.
Some people model person_in_position as a relationship
type between person and position. The question then arises as
state_of_
physical_object
physical_object
ordinary_
physical_object
state_of_
system
state_of_ordinary_
physical_object
system
installed_
object
state_of_system_
component
system_
component
(RT) temporal_part_of S[1:?]
(RT) temporal_part_of S[1:?]
(RT) temporal_part_of S[1:?]
(RT) temporal_part_of S[1:?]
(RT) part_of > component_of S[1:1]
Figure 14-6 Data model for system and system component.
184 Chapter 14 SYSTEMS AND SYSTEM COMPONENTS
to whether it was the position or the person who performed
some activity. In this model, you can see that it is the person_
in_position that perfor ms the activity, which means that both
the position and the person performed it.
You might also be asking right now whether you really need
this entire data model just to assign a person to a position. The
answer is no. What I have done here is show all the working. You
need to have the detail there in the background, but that does
not mean you have to show it to your customers. An example of
what you might show your customers is illustrated in Figure 14-9.
state_of_
functional_object
functional_
object
(RT) temporal_part_of S[1:?]
state_of_ordinary_
physical_object
state_of_ordinary_
functional_object
state_of_
system
state_of_
functional_system
state_of_
system_component
state_of_
functional_
system_component
(RT) temporal_part_of S[1:?]
functional_
system_
component
(RT) component_of S[1:1]
(RT) temporal_part_of S[1:?]
system_
component
functional_
system
installed_functional_
system_component
installed_
object
(RT) temporal_part_of S[1:?]
ordinary_
functional_object
ordinary_
functional_object
system
Figure 14-7 Systems that are complex artifacts.
Chapter 14 SYSTEMS AND SYSTEM COMPONENTS 185
14.7 Concluding Remarks
In this chapter, I have taken an
extended look at a particular data
model pattern, that of the system and
system component. I have shown how a
4D analysis clarifies what sorts of things
system components are, and I have
shown how this pattern turns up in a
number of different contexts.
state_of_intentionally_
constructed_object
state_of_system_
component
system
state_of_
organization
state_of_
organization_
component
state_of_
position
state_of_
person
person
biological_
system
state_of_
biological_system
person_in_
position
installed_
object
position
organization_
component
system_
component
intentionally_
constructed_object
(RT) temporal_part_of S[1:?]
(RT) temporal_part_of S[1:?]
(RT) temporal_part_of S[1:?]
(RT) temporal_part_of S[1:?]
(RT) component_of S[1:1]
organization
Figure 14-8 Assignment of person to position in organization.
person_in_
position
organization
position
person
part_of
state_of_position
state_of_person
Figure 14-9 A version of person and position for the
customer.
186 Chapter 14 SYSTEMS AND SYSTEM COMPONENTS
15
REQUIREMENTS SPECIFICATION
CHAPTER OUTLINE
15.1 A Process for Procurement 187
15.1.1 Card Purchase 188
15.1.2 Purchase on Demand 188
15.1.3 Purchase Standard Product 189
15.1.4 Purchase for Stock 189
15.1.5 Purchase by Tender 189
15.1.6 Comparison of Tender and Card Process es 190
15.2 Requirements Specification 191
15.2.1 Overview 191
15.2.2 A Data Model for Requirement and Requirement
Specification 194
15.2.3 Requirement Specifications 194
15.2.4 A Data Model for Elements of a Requirement Specification 196
In previous chapters I have been looking at some of the ele-
ments of a procurement process. In this chap ter I will start by
considering the procurement process as a whole and then focus
on the final key element of a procurement process, the require-
ments specification.
15.1 A Process for Procurement
Figure 15-1 shows a very general high level procurement
process that covers a wide range of procurement situations,
though I am certainly not tr ying to suggest that it is the last
word in procurement processes.
At this level it looks as if one process fits all needs, but this is
not the case. Figure 15-2 shows a number of different cases that
will cause variations in the process, and information, required.
The graph shows purchase processes for different areas of an
Item Volume, Item Value map.
The scales on the axes will vary depending on the size of the
organization, and the place where the lines are drawn may vary
for different product categories.
187
15.1.1 Card Purchase
Card purchases are those low-value purchases where the
person who has the card has the requirement and the authority
to make the purchase of that value for that product category,
but stock of the product is not held. Examples include most of
what is often thought of as incidental expenses such as meals,
books, and travel costs. However, for some categories standard
products may be specified. These are the characteristics of this
type of procurement:
• Low value
• Low volume—not worth keeping a stock
• End user, purchaser, and authorizer are the same
• May be through a standard supplier or
for standard products
• Payment before delivery
15.1.2 Purchase on Demand
Purchase on demand is a pr ocess for
relatively low volume and medium value
items where the person with the require-
ment does not have the financi al authority
to make the purchase. He has to submit
the requirement and the proposed solu-
tion for authorization of the expenditure.
Identify
requirements
Select
solution
Agree
contract
Exchange
goods and
money
Figure 15-1 An example procurement process.
Purchase by
tender
Purchase on
demand
Purchase
standard
product
Card purchase
Purchase
for stock
Item volume
Item value
Figure 15-2 Different types of
procurement.
188 Chapter 15 REQUIREMENTS SPECIFICATION
The overhead of identifying and managing standard products is
not worth the value of business this represents. These are the
characteristics of this type of procurement:
• Medium value items
• Volume low, and not worth having a standard product
• Authorizer not the same as purchaser or end user
• Purchase by order and payment on receipt of invoice
15.1.3 Purchase Standard Product
The value of busin ess in this area is sufficient, or compatibil-
ity in use is important enough that standard products in various
product categories are chosen and volume discounts are agreed
upon. However, purchases follow identification of requirements,
rather than for being purchased for stock, and then issue from
stock. Examples include computer hardware, mobile phones,
and industrial equipment. The characteristics of thi s type of
purchase are as follows:
• Medium value, medium volume items
• Compatibility of items of the same type may be important
• Purchase agreements with suppliers may be in place
• Payment occurs on receipt of invoice
• Authorizer is not the end user
15.1.4 Purchase for Stock
High volume items, of low and medium value, often con-
sumables, are often held as stock by an organization and then
issued from stores to those who need them. Standard products
will be supplied from suppliers with whom long-term contracts
are in place that take maximum advantage of the volume of
business represented. Authorization comes in the selection of
suppliers and the agreement of the supply contracts. These are
the characteristics of this type of procurement:
• High volume, low to medium value products
• Volume purchase agreements with suppliers with agreed
delivery times
• Stock management
• Issue from stores
• Payment by account
• Authorizer not the same as the end user
15.1.5 Purchase by Tender
High-value, usually one-off items are often purchased using
a competitive tender process. These high-valu e items represent
Chapter 15 REQUIREMENTS SPECIFICATION 189
a significant investment and so there will be several stages
of authorization. At the requirements level there will be a num-
ber of parties bidding, followed by a selection process among
the bidders. There will then be a contract agreement phase,
which will perhaps include provision for stage payments and
penalty clauses. The characteristics of this type of procurement
are:
• Low-volume, high-value items
• Multiple authorizations at different stages
• A requirements development stage with separate authorization
• A tender process to select the supplier
• A complex contract perhaps with penalty clauses and stage
payments
15.1.6 Comparison of Tender and Card Processes
What you can see from the earlier descriptions is that
although all these types of procurement follow the same basic
pattern, the details may be different, both in the process fol-
lowed and the information required. To make this point,
Table 15-1 compares the two extremes, Purchase by Tender and
Card Purchase.
Notice that there is no point of contact betw een these two
extremes.
Although you can see from Table 15-1 that recording the
requirements specification is not necessary for a card purchase,
it is needed for all the other sorts of procurement. So in the rest
Table 15-1 Comparison of Tender and Card
Procurements
Purchase by Tender Card Purchase
Identify
Requirements
Detailed processes and requirements documentation with
formal authorization process.
Cursory process with no
information recorded
Select Solution Detailed process with price/performance analysis of
alternate tenders.
Cursory process with no
information recorded
Agree Contract Non-standard, one-off contract for the particular
procurement. May have penalty clauses.
Standard retail purchase
governed by Sale of Goods
legislation
Exchange Goods
and Money
Payment may be staged, with final payment withheld until
the performance of the product is confirmed.
Payment before delivery
190 Chapter 15 REQUIREMENTS SPECIFICATION
of this chapter I will look at what a requirements specification
is and describe a supporting data model.
15.2 Requirements Specification
15.2.1 Overview
A requirement is about something that you want to exist in
the future, as opposed to something in the present or the past.
“Possible worlds” is the way I deal with this kind of situation.
Since the requirement is a spat io-temporal extent, we can talk
about it existing whether it is in the past, the present, or the
future. A requirement is one in the future, and since we there-
fore cannot be certain if it is part of the possible world that we
are part of, then it is part of some possible world in which our
plan for it does come to pass.
A requirement will also be of some other type, and although
a requirement can in principle be for any spatio-temporal
extent, in practice it is most often for a functional object, a
thing that has an intended role in an activity, and in particular
for a system or a system component. I’m going to use a car as
an example of a requirement that is a system and a pump as a
component of a process plant to demonstrate an example of a
requirement that is a system component. Pumps are common
pieces of equipment used across a wide range of industries,
and depending on the type and the industr y, an organization
might either purchase them on demand, or have determined
standard products that they will purchase for higher volume
applications—for example, inclusion as a component in another
product.
I want to start by reviewing what we do when we buy some-
thing like this.
A requirement will usually be for a state_of_functional_
object—something that has an intended role. Most likely it will
be for a state_of_functional_system or a state_of_functional_
system_component. I’d just like to loo k at these two for a
moment.
The procurement of a car is an example of meeting a
requirement for a whole system. Figure 15-3 illustrates this
case for a car. Notice that the requirement is not the same
thing as the whole life of the thing procured, but it is an asset,
that is, an owned state of a physical_object. It exists owned by
its manufacturer before it meets your requirement, and it may
be sold or otherwise disposed of before the requirement ends,
or indeed it may outlast the requirement.
Chapter 15 REQUIREMENTS SPECIFICATION 191