Any organization desirous to adopt or improve systems engineering needs to be aware that research into the nature of systems engineering has identified a number of defects in the current systems engineering paradigm. This paper discusses eight of these defects and ways to fix or compensate for them.

1. Eight deadly defects in
systems engineering and
how to fix them
Dr Joseph Kasser
Leverhulme Visiting Professor
Cranfield University
j.kasser@cranfield.ac.uk

2. Agenda
1. Selection of independent alternative solutions
2. The V Model
3. Lack of a standard process for planning a project
4. The Waterfall model
5. Unanswered and unasked questions
6. Lack of a metric for the goodness of Requirements
7. Focus on technological solutions not solving
customer’s problems
8. The need to focus on people as well as process
• Summary
• Questions and discussion

3. The selection of
independent alternative
solutions
• The systems engineering process has
identified three alternative candidate
solutions (A, B and C)
• “C” gets the highest score
• Which one is the optimal?
• Possibly none of them
• Possibly a combination of the best parts of
all of them
3

4. The “V” Model

5. Defects in the V
Model
• Lacks ‘prevention of defects’
• Definition of successful test?
• Design works from requirements
• T&E work from the need
• T&E identify defects and plan to find them
after they have been built into the system
• Why not prevent the defects?
* Kasser 1995 5

6. The Project Cycle Test
Requirement
Design
Acceptance
criteria
(property of a requirement)
6

7. Prevention of defective
requirements
• Requirements Workshop
at UMUC and UniSA
• FRED and Tiger Pro
• Figure of Merit for
document
• Produced attitude
change in student’s
perceptions
• Produced better
requirements
7

8. Lack of a standard process
for planning a project
Determination of objectives Determination of Resources
Generate preliminary work plan (risks)
Draft work plan version 1
8

9. Lack of a standard process
for planning a project
Determination of objectives Determination of Resources
Identify and study lessons learned from previous projects
Generate preliminary work plan (risks)
Negotiate objectives and resources
Draft work plan version 1
9

10. The Waterfall model
• Waterfall approach does not cope well with
changing requirements.
• Change the production process from the
waterfall approach to some type of rapid, spiral,
or other methodology
– Iterative waterfalls
– Spiral focuses on Risk Management
• Result
– Some improvement
• comparing Chaos 1995 with Chaos 2004
10

11. Assumption behind
Waterfall model
Contract award
Waterfall Intermediate milestones
(product reviews)
Vision of product
Desired
11

12. Real world of
changes
Contract award Desired
(moving target)
Waterfall Intermediate milestones
(product reviews)
Vision of product
12

13. Assumptions behind
Cataract model
Contract award Desired (keep your
eye on the balls)
Cataracts Intermediate milestones
(product reviews)
Configuration Control
(Stage Gates)
Visions of product (converge)
13

14. Unanswered and
unasked questions
• Unanswered questions
– Can you tell if the project is in trouble?
– What percentage of the project is complete?
• Unasked questions at SRR
– Are requirements with the following properties
really needed?
• High cost, high risk
• Low priority, high cost
• Low priority, high risk
– Is this projected risk profile industry standard?
14

15. Project Priority profiles
(object-oriented
requirements)
Why are we
investing in
this system?
15

16. Project Risk profiles
(object-oriented
requirements)
Risk: Is this
reasonable?
16

17. Most successful IS of
the 20th century?
• RAF Battle of Britain
Command, Control, &
Communications System
– No computers
– Germany had better
Radar Technology
– RAF evolved and used
an integrated system
– Adequate technology
• System?
• System of Systems?
• Complex System?
• Network enabled system?
17

18. Not solving
customer's problems
• “the systems engineer is primarily interested in making equipment
changes” [Goode and Machol, 1959] page 130).
• The problem the executive had was to secure at all
times, live and accurate data concerning the exact
conditions of the business. [Farnham, 1920] page 20)
• [Beer, 1972] page 244) describes a conceptual system.
– British War Room in the Battle of Britain
– NASA’s control room at the Manned Space Flight Center in Houston,
Texas.
– bits and pieces of it existed at that time.
• Beer proposed a control centre
• Today’s technology allows for personal desktop portals accessing
information via software agents in an integrated digital or network
centric environment.
18

19. Complex or
complicated?
19

20. The need to focus on
people as well as process
• Literature
– Is full of advice as to
how to make projects
succeed
– Has little if anything to
say about the
proliferating process
standards
20

21. The need to focus on
people as well as process
• Systems engineering is a way of life
– (Hitchins 1998)
– Integration of
• Schedules
• Design, Testing and Integration
• Systems of Systems divide?
• Are we focusing on the right things?
– The Standards do not provide metrics that can
predict the failure of a project.
• (K&W, 1998)
21

22. Summary
 Selection of independent alternative solutions
 The V Model
 Lack of a standard process for planning a
project
 The Waterfall model
 Unanswered and unasked questions
 Lack of a metric for the goodness of
Requirements
 Focus on technological solutions not solving
customer’s problems
 The need to focus on people as well as
process

23. Questions?