1. Software Engineering: Analysis and Design - CSE3308
CSE3308/CSC3080/DMS/2000/3
Monash University - School of Computer Science and Software Engineering
Software Engineering: Analysis and Design - CSE3308
What is Analysis and Design?

2. Lecture Outline Defining Analysis and Design
Why do Analysis and Design?
Types of Analysis and Design

3. Definitions
Many different definitions of the difference between analysis and design
In the past there was common agreement
Was viewed as follows:
Description of the Problem
Description of the Solution
Essential
Model
Implementation
Model
Role of the Analyst
Role of the Designer

4. Definitions (2) Structured Analysis and Structured Design
Different Tools used to develop system
often different teams used to do analysis and design
Clear distinction between tasks
Leads to the Analysis/Design Wall

5. Definitions (3)
With newer development methods, the divide between analysis and design breaks down
the concept of seamlessness
that an essential model is very difficult to develop without reference to the implementation issues
the increasing emphasis on requirements analysis
Some commentators see only
Requirements Analysis
High-level Design
Low-level Design
The debate rages on!

6. Definitions (4) Systems Analysis Systems Design
Process of defining a problem, gathering the requirements and developing an analysis model representing those requirements
Describing the problem the system means to solve
Systems Design
Process by which the analysis model is transformed into a model which is capable of being implemented
Describing the solution to the problem

7. Why do analysis and design?
Add formality
Reduce errors
Improve communication between participants
Get the requirements right!
Can be a factor of 100 in the cost of fixing analysis and design errors from analysis phase to maintenance phase
Generate documentation

8. Cost of Analysis/Design Errors

9. Source of Errors

10. Types of Analysis/Design
Top-down Analysis and Design
Structured Analysis
SADT
Object-Oriented Analysis and Design
Object Modeling Technique (OMT)
Booch OOA&D
Unified Modeling Language (UML)
OPEN/Mentor (Australian based) Brian Henderson-Sellars and Object-Oriented Pty. Ltd.
Data-Driven Analysis and Design
Jackson System Design
Warnier-Orr Method
Soft Systems Methodology

11. Data-driven Analysis and Design
Structure of system is driven by mapping system inputs to outputs
Software structure can be directly derived from the data structure
More concentration on timing and scheduling than in Structured Analysis and Design (specifically Jackson System Design)
Both methods have been extensively used but have only a very small market share

12. Soft Systems Methodology (SSM)
Developed by Peter Checkland
Aims to represent the multiple perspectives that users have of a system

13. Soft Systems Methodology vs. Hard Systems Engineering (1)
“Hard” systems engineers are used to producing a well-defined system to achieve clearly stated objectives
In many real situations, things are less clear:
“See what you can do to help us” (Marketing director of textile business)
“Make me a plan” (Owner of small carpet-making business)
“Try to improve the project” (Director of British Aircraft Corporation, with reference to the Concorde project)

14. Soft Systems Methodology vs. Hard Systems Engineering (2)
The traditional activity of “Hard” systems engineers is “how-oriented”: How can this need be met? (design)
This assumes that what to do is already defined
SSM endeavours to address the question: What is needed? (requirements analysis)
SSM is a system of enquiry. Several notional systems which might be relevant are:
defined and modeled
compared with the perceived problem situation
used to articulate a debate about change, which takes in both “whats” and “hows”

15. Naming Relevant Systems
System names must be written such that a model of the system can be built.
These names are known as root definitions.
A root definition expresses the core purpose of a purposeful activity system.
The core purpose is always expressed as a transformation T of entity “input” into some new form of that entity “output” input
Transformation
process
output

16. CATWOE
Well-formulated root definitions should be prepared by consciously considering each of the following elements:
C - Customers: the victims/beneficiaries of T
A - Actors: those who would do T
T - Transformation process: the conversion of input to output
W - Weltanschauung: the worldview which makes this T meaningful in context
O - Owners: those who could stop T
E - Environmental constraints: elements outside the system which it takes as given

17. Root definition
A full root definition’s core transformation T would be: “a system to do X by Y in order to achieve Z” where
T is the means Y,
Z is related to O’s longer term aims
Y should be an arguably appropriate means for doing X
It is generally useful to write root definitions with the XYZ formula in mind

18. “The Three Es”
Any transformation T of input to output can be judged successful or unsuccessful on three criteria:
Efficacy
Does the means work?
Efficiency
amount of output divided by amount of resources used
Effectiveness
is T meeting the longer term aim?
Also mention Ethicality and Elegance

19. Root Definition

20. Root definition (2)

21. Rich Pictures

22. Types of Analysis in SSM
Role Analysis
Social System Analysis
Political System Analysis
SSM provides tools to integrate the three types of analysis
Problems with integrating results of the analysis with design/implementation of an information system
Soft Systems Methodology In Action by Peter Checkland and Jim Scholes Hargrave Library 003 C514S