Page 294 -

10.3 System procurement 277

2. When a system is to be built specially, the specification of requirements is part
of the contract for the system being acquired. It is therefore a legal as well as a
technical document.
3. After a contractor has been selected, to build a system, there is a contract nego-
tiation period where you may have to negotiate further changes to the require-
ments and discuss issues such as the cost of changes to the system. Similarly,
once a COTS system has been selected, you may negotiate with the supplier on
costs, licence conditions, possible changes to the system, etc.

The software and hardware in sociotechnical systems are usually developed by
a different organization (the supplier) from the organization that is procuring the
overall sociotechnical system. The reason for this is that the customer’s business is
rarely software development so its employees do not have the skills needed to
develop the systems themselves. In fact, very few companies have the capabilities
to design, manufacture, and test all the components of a large, complex sociotech-
nical system.
Consequently, the system supplier, who is usually called the principal contractor,
often contracts out the development of different subsystems to a number of subcon-
tractors. For large systems, such as air traffic control systems, a group of suppliers
may form a consortium to bid for the contract. The consortium should include all of
the capabilities required for this type of system. This includes computer hardware
suppliers, software developers, peripheral suppliers, and suppliers of specialist
equipment such as radar systems.
The procurer deals with the contractor rather than the subcontractors so that there
is a single procurer/supplier interface. The subcontractors design and build parts of
the system to a specification that is produced by the principal contractor. Once com-
pleted, the principal contractor integrates these different components and delivers
them to the customer. Depending on the contract, the procurer may allow the princi-
pal contractor a free choice of subcontractors or may require the principal contractor
to choose subcontractors from an approved list.
Decisions and choices made during system procurement have a profound effect
on the security and dependability of a system. For example, if a decision is made to
procure an off-the-shelf system, then the organization has to accept that they have
very limited influence over the security and dependability requirements of this sys-
tem. These largely depend on decisions made by system vendors. In addition, off-the-
shelf systems may have known security weaknesses or require complex configuration.
Configuration errors, where entry points to the system are not properly secured, are
a major source of security problems.
On the other hand, a decision to procure a custom system means that significant
effort must be devoted to understanding and defining security and dependability
requirements. If a company has limited experience in this area, this is quite a difficult
thing to do. If the required level of dependability as well as acceptable system per-
formance is to be achieved, then the development time may have to be extended and
the budget increased.