The term Cardinal Point Specification refers to a requirement specification which identifies specific statements of requirement relating to certain spot points within the requirement space. If the term is used then there will be a recognition that the requirement specification is not comprehensive. Implicit in the use of a CPS is the assumption that the required system will meet other requirements normally associated with such a system and also that performance between the cardinal points will be acceptable. Where a CPS is used as the basis of a contractual requirement care must be taken to ensure that the totality of the requirement does not lead to a system which is highly tuned to the cardinal points.

Introduction

This chapter is concerned with change primarily in the context of change associated with working methods (eg. introduction of new technologies or management practices), though issues associated with organisational change are also discussed.

Change from well established ways of doing things is usually harder than you think, and to be successful involves a lot of politics.

Introduction

Pressures for Change
Common Causes of Failure in Implementing Change
Characteristics of Successful Change
Checklist for the management of change
Change, from the Individual's Viewpoint
Miscellaneous Notes
Organisational Change
The Costs of Change
The Politics of Change

A checklist is nothing more than a list of things to be considered, which are then ticked off as they are considerd. It is a way of imparting experience/knowledge from one person or group of people to others.

Checklists can be used in almost any area, and are, in general, under utilized.

Introduction

Use of Checklists
Benefits of Checklists
Tips on effective use
Points to Watch out For

The Chief Engineer is the person with responsibility for understanding the totality of the design itself, in so far as it can be understood.  In general they are expected to be the person  most skilled/knowledgeable with respect to the design and should have wide experience of the types of design of interest.

The Chief Engineer could be the engineering manager responsible for the design team, or could be largely independent from the design team acting as an independent auditor and approval authority for the design.

Introduction

Chief Engineer as Technical Quality Assurance
Potential Chief Engineer Project Roles
Chief Engineer for Organisation

An ability to think clearly is one of the most important skills a person can have. It is a pre-requisite and vital component of effective planning and action. It is particularly important in a system engineering and project management context because by its nature each project is complex, unique, and with plenty of opportunity for poor thinking. The consequences of poor thinking, and the related issue of poor communication, can be very dire and be the difference between success and failure of the project.

This section identifies the core concepts behind clear thinking, which largely relate to some relatively simple concepts from 'Logic', principally those relating to the analysis of Arguments.  Whilst this may put you off, please note that with a little bit of effort these concepts are easy to understand, and without making that effort it is unlikely you will develop good thinking skills.

If you don't feel up to making the effort to understand the principles behind clear thinking, then at least look at the Clear Thinking Guidelines identified below, which summarize the practical result of understanding the underlying principles.

Introduction

Terminology
The importance of being able to analyse Arguments
The structure of, and types of argument
Deduction:
Induction:
Test of 'Beyond Reasonable Doubt' (BRD)
Abduction:
Concepts of Proof and Truth
Clear Thinking Guidelines - Summary/checklist
Clear Thinking Guidelines - Detailed
Causes for lack of application of clear thinking
Fallacies
Applications of Clear Thinking - Assessing/Deriving Causal Statements
Applications of Clear Thinking - Analysing an argument
Applications of Clear Thinking - Analysis of texts
Applications of Clear Thinking - Verbal Arguments
Structured and Formal Techniques to support clear thinking

Commercial Issues
[Press for File]

Commercial Issues are issues associated with legal agreements. Most of the detailed considerations of this are addressed under CONTRACTING and PROCUREMENT.

There is however a soft distinction between CONTRACTING/PROCUREMENT and Commercial issues in that contracting/procurement issues tend to be focused upon agreements in a project context, ie. whether or not specific agreements are satisfactory in the context of the project itself; whilst commercial issues takes a wider view of the interests of the organisation as a whole.

Introduction

Commercial Financial Issues
Commercial Legal Issues
General Terms and Conditions
Commercial Strategic Contracting Issues

Compatibility with respect to a system might be an issue associated with either:

1. The system working with other systems without mutual interference.
2. The sub-systems/components of the system working together without mutual interference.

Careful attention to potential compatibility problems needs to be paid during the design process. Where they do arise then it may be necessary to place limitations on operations, ones that might seriously inconvenience the system user.

Introduction

Examples of potential Compatibility Problems
Interoperability
Limitations on Operations due to Incompatibilities

The term CAD is most widely associated with drawing the design in 2D schematic or 3D virtual reality formats.  It allows the design to be analyzed in an electronic format before commitments are made to producing the real thing.  Although  widely associated with 'spatial' representations, the term CAD is also sometimes used to include the management of product data in an electronic format, and sometimes used to include other elements of modeling a design within a computer.

Introduction

Potential capabilities of CAD tools
Potential benefits of CAD tools
Use of CAD as part of an integrated design process
Notes on the implementation of CAD systems
CAD and CAM
Choosing a CAD system
CAD Terminology and Concepts

Concessions are raised against a requirement when there is a known shortfall, but a decision is made by the authority placing the requirement to proceed.  The concession may include an agreement to fix later, or to fix on other production copies.

Introduction

Configuration and control is concerned with:

• identifying a precise description/referencing to a given entity
• ensuring this definition is maintained as the entity changes
• maintaining traceability as the entity changes (preferably including identification of the reason for change)
• providing facilities to support investigation of the consequences of change, particularly by identifying all authorities that might be affected by a proposed change.

The primary elements of configuration and control are:

• configuration identification
• change control
• configuration status accounting
• configuration auditing

Introduction

Configuration Identification
How to identify configuration items
Change Control
Objectives of change procedure
Potential Reasons for change
Steps in Change Control Procedure
Priorities to Change
Configuration status accounting
Configuration auditing
Persons/Groups involved in Configuration Control
Typical Contents of a Change Request Control form
Change Request Register
Sample CRC Assessment Checklist
Items and Build Standards brought under C and C
Contents of Configuration Management Plan
Miscellaneous Issues
Software Tool Support
Miscellaneous Techniques used in C and C

This chapter addresses Consultants/Specialists in the context of their being independent persons providing advice, rather than their being bought in labour with specific responsibilities on the project.  [The later is addressed under CONTRACTING - see Service Support Sub-Contracts.]

Competent and appropriate consultants/specialists can save enormous amounts of time and money and contribute significantly to the success of a project. Incompetent or inappropriate consultants/specialists can lead to the waste of large amounts of time and money and indirectly contribute to the failure of a project.

Introduction

Is a consultant/specialist required?
Contracting for Consultancy
Confidentiality Agreements
Internal Management Issues

The term Context is here used to describe two specific ideas:

1. The general philosophy of providing context information to help other people understand why things or statements are the way they are.
2. A formal Context Description/Statement which might be included within a specification, in particular though not limited to a Requirements Specification. This is a specific example of the implementation of (a).

Introduction

What is Context Information, and Why Give It
Examples of Context information for an activity
A Context Statement within a Requirements Specification
Example Content of a Context Statement in a Requirement Specification
Benefits of providing an Overall Context Statement within a Requirement Specification
The Context Statement as a statement of Fitness For Purpose.
Illustration of Use of Context Statement
Context Statements in Handbooks

Contracts are legal agreements with one's customers and one's suppliers.

This chapter addresses general contracting issues relevant to both customer and supplier contracting, and addresses the particular issues associated with contracting with the customer and contracting with suppliers.

Introduction

Why Contract?
General Scope of Contract
Terms relating to Costing/Pricing a Contract
Discussion of Different Types of Contract
Avoiding Contract Disputes
Criteria for contract type selection
Practical Tips
Customer Contract Management
Supplier Contracting
Contracting Strategy Issues
Responsibility for contracting with suppliers

Cost-Benefit is the trade-off of what is gained at what cost. There is generally a need to maximise cost-benefit in some way, ie. be effective in the use of resources.

Introduction

Cost-Benefit in Monetary terms
Cost-Benefit as Cost-Effectiveness
Cost-Benefit as Subjective Judgment
Cost-Benefit as an everyday way of thinking
Less Tangible Costs/Benefits

Cost-Effectiveness is a comparison of cost against effectiveness. It is both a general principle which underlies most decisions as well as occasionally being explicitly used as a quantification technique to support specific types of decisions.

Introduction

Cost Effectiveness As A General Principle
Quantification of Cost-Effectiveness
The quantified Cost-Effectiveness trade-off
The Cost Effectiveness Requirement for Systems
Example Applications of Principle of Cost Effectiveness - Conceptual
Cost-effectiveness and Cost-benefit

A cost model is simply a break down of costs for something such as a project or the life-cycle support to a system. It is model in the sense that the total cost will be made up of component parts, and changes in the costs of the component parts will lead to changes in the total cost.

A common format for a Cost Model is a spreadsheet, which allows changes in component parts to be easily assessed in terms of their impact on total costs.

Introduction

Cost is the most important constraint upon system design. In decision making, high level attention is often focused on the cost element; and only if cost is kept within certain 'reasonable' bounds will certain options be acceptable.

Introduction

Components of Cost
Design to Cost
Cost Minimisation
Issues associated with economies of scale

Advances in technology and engineering, and larger consumer markets, has led to a large number of products being on the market which can be used in complex systems, either as they are or after a certain amount of configuration.

The term COTS is applied in the context of a system where an item which has been designed and produced for some unrelated purpose, is considered for use within the system.

The use of COTS can be attractive since it avoids the need to develop and support special purpose items.  However it can also have its risks, particularly in the fact that many COTS products quickly become obsolescent.

Introduction

Implications of introducing Commercial Standards
Risk of Obsolescence
Risk of Dependency upon COTS supplier
Risk of potential reduced flexibility
Risk of reducing ability to fix problems
Potentially increased costs
Some risk reduction measures associated the use of COTS products.
Additional issues in a large system project environment

This chapter considers the Customer, from the viewpoint of a system project.  It advises that those responsible for a system project must ensure they understand the underlying customer needs, not just what is written down in the requirements specification.

Introduction

Customer Needs
Questions for effective customer liaisons
Note on Customer being always right
Note on Customer Interfaces