UNIT 2

SYSTEM ANALYSIS AND DESIGN

K.SRIMATHI
ANNA UNIVERSITY
TOPICS COVERED…
• Systems development methodologies,
• Systems Analysis and Design Tools
• System flow chart,
• Decision table,
• DFD,
• ER,
• Object oriented Analysis and Design,
• UML diagram.
 SDLC: Systems Development Life
Cycle

• SDLC is a Life Cycle

• All systems have a life cycle or a series of stages they naturally undergo.
• The number and name of the stages varies, but the primary stages are conception, development,
maturity and decline.

• The systems development life cycle (SDLC) therefore, refers to the development stage of the system’s
life cycle.

• A Life Cycle
 Methodologies

▪ Is there a difference between the term SDLC and the term ‘methodology’?

▪ SDLC: refers to a stage all systems naturally undergo,

▪ A Methodology refers to an approach invented by humans to manage the events

naturally occurring in the SDLC.
 Methodologies

•A methodology is, a set of steps, guidelines, activities and/or principles to follow in

a particular situation.

• Most methodologies are comprehensive, multi-step approaches to systems development

• There are many (thousands!) methodologies available

INTRODUCTION – SYSTEM DEVELOPMENT
METHODOLOGIES
• A system development methodology refers to the framework that is used to structure,
plan, and control the process of developing an information system.

• A wide variety of such frameworks have evolved over the years, each with its own
recognized strengths and weaknesses.

• One system development methodology is not necessarily suitable for use by all projects.

• Each of the available methodologies is best suited to specific kinds of projects, based on
various technical, organizational, project and team considerations.
Basic Principles:
• 1. Project is divided into sequential phases, with some overlap and splash back acceptable
between phases.

• 2. Emphasis is on planning, time schedules, target dates, budgets and implementation of

an entire system at one time.

• 3. Tight control is maintained over the life of the project through the use of extensive
written documentation, as well as through formal reviews and approval/signoff by the
user and information technology management occurring at the end of most phases before
beginning the next phase.
Strengths:
• 1. Ideal for supporting less experienced project teams and project managers, or
project teams whose composition fluctuates.

• 2. The orderly sequence of development steps and strict controls for ensuring the
adequacy of documentation and design reviews helps ensure the quality,
reliability, and maintainability of the developed software.

• 3. Progress of system development is measurable.

• 4. Conserves resources.
Weaknesses:
• 1. Inflexible, slow, costly and cumbersome due to significant structure and tight controls.
• 2. Project progresses forward, with only slight movement backward.
• 3. Little room for use of iteration, which can reduce manageability if used.
• 4. Depends upon early identification and specification of requirements, yet users may not be able
• to clearly define what they need early in the project.
• 5. Requirements inconsistencies, missing system components, and unexpected development
• needs are often discovered during design and coding.
• 6. Problems are often not discovered until system testing.
• 7. System performance cannot be tested until the system is almost fully coded, and undercapacity
• may be difficult to correct.
• 8. Difficult to respond to changes. Changes that occur later in the life cycle are more costly and
• are thus discouraged.
• 9. Produces excessive documentation and keeping it updated as the project progresses is timeconsuming.
• 10. Written specifications are often difficult for users to read and thoroughly appreciate.
• 11. Promotes the gap between users and developers with clear division of responsibility.
Situations where most appropriate:
• 1. Project is for development of a mainframe-based or transaction-oriented batch system.
• 2. Project is large, expensive, and complicated.
• 3. Project has clear objectives and solution.
• 4. Pressure does not exist for immediate implementation.
• 5. Project requirements can be stated unambiguously and comprehensively.
• 6. Project requirements are stable or unchanging during the system development life cycle.
• 7. User community is fully knowledgeable in the business and application.
• 8. Team members may be inexperienced.
• 9. Team composition is unstable and expected to fluctuate.
• 10. Project manager may not be fully experienced.
• 11. Resources need to be conserved.
• 12. Strict requirement exists for formal approvals at designated milestones.
Situations where least appropriate:
• 1. Large projects where the requirements are not well understood or are changing for any reasons
such as external changes, changing expectations, budget changes or rapidly changing technology.

• 2. Web Information Systems (WIS) primarily due to the pressure of implementing a WIS project
quickly; the continual evolution of the project requirements; the need for experienced, flexible
team members drawn from multiple disciplines; and the inability to make assumptions regarding
the users‘ knowledge level.

• 3. Real-time systems.

• 4. Event-driven systems.

• 5. Leading-edge applications.
1. Classic and Other Software Development
Methodologies
• Will discuss
• The Software Development Life Cycle (SDLC)
• The prototyping model
• The spiral model
• The OO model
 The SDLC
• The ‘classic mode.’
• Still in WIDE use today.
• Captures the major building blocks in development
• Linear sequence
• Highly structured; plan-driven; Heavy-weight process
• Product delivered for evaluation and deployment at the end of
development and testing
• Big bang approach
• Used for major projects of length
• But serves as a framework for other models…
 Prototyping Model
• Replaces some of the parts of the SDLC with an
evolutionary and iterative process.
• Software prototypes are repeatedly provided to
customer for evaluation and feedback.
• Primarily iterate design and implementation.
• Development team provided requirements.
• Ultimately, the product reaches a satisfactory
completion.
• Then, the remainder of the process is carried out in the
context of another model, such as SDLC
 Spiral Model
• Uses an iterative approach designed to address each phases in
development by obtaining customer comments and change, risk
analysis, and resolution.
• The spiral model typically has a ‘spiral’ for each of the traditional
development phases.
• Within a cycle, specific engineering (design, development, etc.)
can take place using any other models, like SDLC, prototyping,..
• The Spiral Model (Barry Boehm) is a risk-centered development
model where each spiral includes major risk activities /
assessments.
• Was developed after SDLC in response to delayed risk in SDLC
• As the SDLC, it is considered a heavy-weight, plan-driven
methodology and is highly structured.
The Object-Oriented Model
• Emphasis here is re-usability via reusable objects
and components.

• Component-based software development.

• For non-available components, developer may

• prototype needed modules,
• use an SDLC approach,
• purchase libraries of objects,
• develop ‘his’ own, etc.
The SDLC
• Requirements Definition:
done by customers
• Analysis: analyze
requirements to form an
initial software model
• Design: Detailed definition
of inputs/outputs and
processes including data
structures, software
structure, etc.
The SDLC
• Coding: Design
translated into code.
• Coding includes SQA
activities such as
inspections, unit tests and
integration tests
• Many takeoffs from this:
These tests done by
developers: individual
(unit), group or team
(integration tests….)
The SDLC
• System Tests: Goal: to
discover errors / correct
errors to achieve an
acceptable level of quality.
Carried out by developers
prior to delivery.
• Sometimes ‘acceptance
tests’ carried out by
customer or in conjunction
with developer
The SDLC
• Installation / Conversion:
• After testing, system is
installed and/or replaces an
existing system;
• Requires software / data
conversion
• Important to not interrupt
daily activities during
conversion process.
• Install incrementally, run in
parallel; turn switch and
live with it, etc.
The SDLC
• Operations and
Maintenance:
• Hopefully done for years.
• Maintenance:
• Corrective
• Adaptive
• Perfective

• Lots of variations to the

classic SDLC many in
response to problems….
• Notice the feedback
loops?
Prototyping - Basic Principles
• 1. Not a standalone, complete development methodology, but rather an approach to handling selected portions of a
larger, more traditional development methodology (i.e., Incremental, Spiral, or Rapid Application Development
(RAD)).

• 2. Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-
change during the development process.

• 3. User is involved throughout the process, which increases the likelihood of user acceptance of the final
implementation.

• 4. Small-scale mock-ups of the system are developed following an iterative modification process until the prototype
evolves to meet the users‘ requirements.

• 5. While most prototypes are developed with the expectation that they will be discarded, it is possible in some cases
to evolve from prototype to working system.

• 6. A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem.
 The Prototyping Model

• One main idea behind prototyping is for the development of fast

prototypes and customer availability for feedback.
• Often prototyping tools are used to help Developers respond to
feedback and add additional parts as application evolves into an
acceptable product.
• Recognize this process can be inserted into the SDLC or other
models.
The prototyping model
REQUI REMENTS
DETERMI NATI ON
BY CUSTOMER

PROTOTYPE
DESI GM

PROTOTYPE
I MPLEMENTATI ON

PROTOTYPE
EVALUATI ON
BY CUSTOMER

NO REQUI REMENTS FOR

REQUI REMENTS CORRECTI ONS, CHANGES
FULFI LLED ? AND ADDI TI ONS
YES
SYSTEM TESTS AND A good approach for small to
ACCEPTANCE TESTS
medium-sized projects.
SYSTEM CONVERSI ON Very important: customer involvement.
SYSTEM OPERATI ON
AND MAI NTENANCE
 Prototyping Model - more
• Advantages
• Shorter development process
• Substantial savings in development resources (time)
• Better fit to customer requirements and reduced risk of
project failure
• Easier and faster user comprehension of new system
• Disadvantages
• Less flexibility and adaptability to changes and additions
• Reduced preparation for unexpected instances of failure
Strengths:
• 1. ―Addresses the inability of many users to specify their information needs, and the difficulty of
• systems analysts to understand the user‘s environment, by providing the user with a tentative
• system for experimental purposes at the earliest possible time.‖ (Janson and Smith, 1985)
• 2. ―Can be used to realistically model important aspects of a system during each phase of the
• traditional life cycle.‖
• 3. Improves both user participation in system development and communication among project
• stakeholders.
• 4. Especially useful for resolving unclear objectives; developing and validating user
• requirements; experimenting with or comparing various design solutions; or investigating both
• performance and the human computer interface.
• 5. Potential exists for exploiting knowledge gained in an early iteration as later iterations are
• developed.
• 6. Helps to easily identify confusing or difficult functions and missing functionality.
• 7. May generate specifications for a production application.
• 8. Encourages innovation and flexible designs.
• 9. Provides quick implementation of an incomplete, but functional, application.
Weaknesses:
• 1. Approval process and control is not strict.

• 2. Incomplete or inadequate problem analysis may occur whereby only the most obvious and
superficial needs will be addressed, resulting in current inefficient practices being easily built into the
new system.

• 3. Requirements may frequently change significantly.

• 4. Identification of non-functional elements is difficult to document.

• 5. Designers may prototype too quickly, without sufficient up-front user needs analysis, resulting in an
inflexible design with narrow focus that limits future system potential.

• 6. Designers may neglect documentation, resulting in insufficient justification for the final product
and inadequate records for the future.
Weaknesses:
• 7. Can lead to poorly designed systems. Unskilled designers may substitute prototyping for sound design,
which can lead to a ―quick and dirty system‖ without global consideration of the integration of all other
components. While initial software development is often built to be a

• ―throwaway‖, attempting to retroactively produce a solid system design can sometimes be problematic.

• 8. Can lead to false expectations, where the customer mistakenly believes that the system is ―finished‖
when in fact it is not; the system looks good and has adequate user interfaces but is not truly functional.

• 9. Iterations add to project budgets and schedules; thus the added costs must be weighed against the
potential benefits. Very small projects may not be able to justify the added time and money, while only the
high-risk portions of very large, complex projects may gain benefit from prototyping.

• 10. Prototype may not have sufficient checks and balances incorporated.
Situations where most appropriate:
• 1. Project is for development of an online system requiring extensive user dialog, or for a less
• well-defined expert and decision support system.
• 2. Project is large with many users, interrelationships, and functions, where project risk relating
• to requirements definition needs to be reduced.
• 3. Project objectives are unclear.
• 4. Pressure exists for immediate implementation of something.
• 5. Functional requirements may change frequently and significantly.
• 6. User is not fully knowledgeable.
• 7. Team members are experienced (particularly if the prototype is not a throw-away).
• 8. Team composition is stable.
• 9. Project manager is experienced.
• 10. No need exists to absolutely minimize resource consumption.
• 11. No strict requirement exists for approvals at designated milestones.
• 12. Analysts/users appreciate the business problems involved, before they begin the project.
• 13. Innovative, flexible designs that will accommodate future changes are not critical.
Situations where least appropriate:

• 1. Mainframe-based or transaction-oriented batch systems.

• 2. Web-enabled e-business systems.

• 3. Project team composition is unstable.

• 4. Future scalability of design is critical.

• 5. Project objectives are very clear; project risk regarding requirements definition
is low.
Incremental - Basic Principles
Various methods are acceptable for combining linear and iterative system development methodologies, with the
primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and
providing more ease-of-change during the development process:

• 1. A series of mini-Waterfalls are performed, where all phases of the Waterfall development model are
completed for a small part of the system, before proceeding to the next increment; OR

• 2. Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of

individual increments of the system, OR

• 3. The initial software concept, requirements analysis, and design of architecture and system core are defined
using the Waterfall approach, followed by iterative Prototyping, which culminates in installation of the final
prototype (i.e., working system).
Strengths:
• 1. Potential exists for exploiting knowledge gained in an early increment as later increments are
developed.

• 2. Moderate control is maintained over the life of the project through the use of written documentation
and the formal review and approval/signoff by the user and information technology management at
designated major milestones.

• 3. Stakeholders can be given concrete evidence of project status throughout the life cycle.

• 4. Helps to mitigate integration and architectural risks earlier in the project.

• 5. Allows delivery of a series of implementations that are gradually more complete and can go into
production more quickly as incremental releases.

• 6. Gradual implementation provides the ability to monitor the effect of incremental changes, isolate
issues and make adjustments before the organization is negatively impacted.
 Weaknesses:
• 1. When utilizing a series of mini-Waterfalls for a small part of the system before moving on to the
next increment, there is usually a lack of overall consideration of the business problem and technical
requirements for the overall system.

• 2. Since some modules will be completed much earlier than others, well-defined interfaces are
required.

• 3. Difficult problems tend to be pushed to the future to demonstrate early success to management.
Situations where most appropriate:

• 1. Large projects where requirements are not well understood or are changing due to external
changes, changing expectations, budget changes or rapidly changing technology.

• 2. Web Information Systems (WIS) and event-driven systems.

• 3. Leading-edge applications.
Situations where least appropriate:

• 1. Very small projects of very short duration.

• 2. Integration and architectural risks are very low.

• 3. Highly interactive applications where the data for the project already exists
(completely or in part), and the project largely comprises analysis or reporting of
the data.
Spiral - Basic Principles:
• 1. Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and
providing more ease-of-change during the development process, as well as providing the opportunity to
evaluate risks and weigh consideration of project continuation throughout the life cycle.

• 2. ―Each cycle involves a progression through the same sequence of steps, for each portion of the product
and for each of its levels of elaboration, from an overall concept-of-operation document down to the coding of
each individual program.‖ (Boehm, 1986)

• 3. Each trip around the spiral traverses four basic quadrants: (1) determine objectives, alternatives, and
constraints of the iteration; (2) evaluate alternatives; identify and resolve risks; (3) develop and verify
deliverables from the iteration; and (4) plan the next iteration.(Boehm, 1986 and 1988)

• 4. Begin each cycle with an identification of stakeholders and their win conditions and end each cycle with
review and commitment. (Boehm, 2000)
The Spiral Model
• A heavy-weight, plan-driven, highly-structured
approach for large projects.
• Especially designed for those with higher chances
of failure.
• Combines iterative model, emphasizes risk
assessment, customer participation, prototyping,
and more
• Definitely an iterative process.
The Spiral Model
Can see each spiral
includes:

Planning

Risk Analysis / Resolution

Engineering activities
(design, code, test…)

Customer Evaluation
(errors, changes, new
requirements…)
Source: After Boehm 1988 (© 1988 IEEE)
 The Advanced
Spiral model The Win-Win Model
Revised Spiral Model provides
customer with improved chances
for changes;
developer better chances to stay
within budget and time.

Done by increased emphasis on

customer participation and
on engineering activities.

Extra sections in spiral

dedicated to customer actions
and developer engineering
Source: After Boehm 1998 (© 1988 IEEE)
Strengths:
• 1. Enhances risk avoidance.

• 2. Useful in helping to select the best methodology to follow for development of a given software
iteration, based on project risk.

• 3. Can incorporate Waterfall, Prototyping, and Incremental methodologies as special cases in the
framework, and provide guidance as to which combination of these models best fits a given
software iteration, based upon the type of project risk. For example, a project with low risk of not
meeting user requirements, but high risk of missing budget or schedule targets would essentially
follow a linear Waterfall approach for a given software iteration. Conversely, if the risk factors
were reversed, the Spiral methodology could yield an iterative Prototyping approach.
Weaknesses:
• 1. Challenging to determine the exact composition of development methodologies to use for each

• iteration around the Spiral.

• 2. Highly customized to each project, and thus is quite complex, limiting reusability.

• 3. A skilled and experienced project manager is required to determine how to apply it to any

• given project.

• 4. There are no established controls for moving from one cycle to another cycle. Without

• controls, each cycle may generate more work for the next cycle.

• 5. There are no firm deadlines. Cycles continue with no clear termination condition, so there is an

• inherent risk of not meeting budget or schedule.

• 6. Possibility exists that project ends up implemented following a Waterfall framework.

Situations where most appropriate:
• 1. Real-time or safety-critical systems.

• 2. Risk avoidance is a high priority.

• 3. Minimizing resource consumption is not an absolute priority.

• 4. Project manager is highly skilled and experienced.

• 5. Requirement exists for strong approval and documentation control.

• 6. Project might benefit from a mix of other development methodologies.

• 7. A high degree of accuracy is essential.

• 8. Implementation has priority over functionality, which can be added in later versions.
Situations where least appropriate:

• 1. Risk avoidance is a low priority.

• 2. A high degree of accuracy is not essential.
• 3. Functionality has priority over implementation.
• 4. Minimizing resource consumption is an absolute priority.
Rapid Application Development (RAD)
Basic Principles
• 1. Key objective is for fast development and delivery of a high quality • 5. Project control involves prioritizing development and defining

system at a relatively low investment cost. delivery deadlines or ―time boxes‖. If the project starts to slip,
emphasis is on reducing requirements to fit the time box, not in
• 2. Attempts to reduce inherent project risk by breaking a project into
increasing the deadline.
smaller segments and providing more ease-of-change during the
• 6. Generally includes Joint Application Development (JAD), where
development process.
users are intensely involved in system design, either through
• 3. Aims to produce high quality systems quickly, primarily through the consensus building in structured workshops, or through
use of iterative Prototyping (at any stage of development), active user electronically facilitated interaction.
involvement, and computerized development tools. These tools may
• 7. Active user involvement is imperative.
include Graphical User Interface (GUI) builders, Computer Aided
Software Engineering (CASE) tools, Database Management Systems • 8. Iteratively produces production software, as opposed to a
throwaway prototype.
(DBMS), fourth-generation programming languages, code generators,
and object-oriented techniques. • 9. Produces documentation necessary to facilitate future
development and maintenance.
• 4. Key emphasis is on fulfilling the business need, while technological
or engineering excellence is of lesser importance. • 10. Standard systems analysis and design techniques can be fitted
into this framework.
RAPID APPLICATIONS DEVELOPMENT
 Strengths:
• 1. The operational version of an application is available much earlier than with Waterfall, Incremental, or
Spiral frameworks.

• 2. Because RAD produces systems more quickly and to a business focus, this approach tends to produce
systems at a lower cost.

• 3. Engenders a greater level of commitment from stakeholders, both business and technical, than Waterfall,
Incremental, or Spiral frameworks. Users are seen as gaining more of a sense of ownership of a system, while
developers are seen as gaining more satisfaction from producing successful systems quickly.

• 4. Concentrates on essential system elements from user viewpoint.

• 5. Provides the ability to rapidly change system design as demanded by users.

• 6. Produces a tighter fit between user requirements and system specifications.

• 7. Generally produces a dramatic savings in time, money, and human effort.

Weaknesses:
• 1. More speed and lower cost may lead to lower overall system quality.

• 2. Danger of misalignment of developed system with the business due to missing information.

• 3. Project may end up with more requirements than needed (gold-plating).

• 4. Potential for feature creep where more and more features are added to the system over the course of development.

• 4. Potential for inconsistent designs within and across systems.

• 5. Potential for violation of programming standards related to inconsistent naming conventions and inconsistent documentation.

• 6. Difficulty with module reuse for future systems.

• 7. Potential for designed system to lack scalability.

• 8. Potential for lack of attention to later system administration needs built into system.

• 9. High cost of commitment on the part of key user personnel.

• 10. Formal reviews and audits are more difficult to implement than for a complete system.

• 11. Tendency for difficult problems to be pushed to the future to demonstrate early success to management.
 Situations where most appropriate:
• 1. Project is of small-to-medium scale and of short duration (no more than 6 man-years of development effort).
• 2. Project scope is focused, such that the business objectives are well defined and narrow.
• 3. Application is highly interactive, has a clearly defined user group, and is not computationally complex.
• 4. Functionality of the system is clearly visible at the user interface.
• 5. Users possess detailed knowledge of the application area.
• 6. Senior management commitment exists to ensure end-user involvement.
• 7. Requirements of the system are unknown or uncertain.
• 8. It is not possible to define requirements accurately ahead of time because the situation is new or the system being employed is
highly innovative.
• 9. Team members are skilled both socially and in terms of business.
• 10. Team composition is stable; continuity of core development team can be maintained.
• 11. Effective project control is definitely available.
• 12. Developers are skilled in the use of advanced tools.
• 13. Data for the project already exists (completely or in part), and the project largely comprises analysis or reporting of the data.
• 14. Technical architecture is clearly defined.
• 15. Key technical components are in place and tested.
• 16. Technical requirements (e.g., response times, throughput, database sizes, etc.) are reasonable and well within the capabilities of
the technology being used. Targeted performance should be less than 70% of the published limits of the technology.
• 17. Development team is empowered to make design decisions on a day-to-day basis without the need for consultation with their
superiors, and decisions can be made by a small number of people who are available and preferably co-located.
 Situations where least appropriate:
• 1. Very large, infrastructure projects; particularly large, distributed information systems such as corporate-wide databases.

• 2. Real-time or safety-critical systems.

• 3. Computationally complex systems, where complex and voluminous data must be analyzed, designed, and created within
the scope of the project.

• 4. Project scope is broad and the business objectives are obscure.

• 5. Applications in which the functional requirements have to be fully specified before any programs are written.

• 6. Many people must be involved in the decisions on the project, and the decision makers are not available on a timely basis
or they are geographically dispersed.

• 7. The project team is large or there are multiple teams whose work needs to be coordinated.

• 8. When user resource and/or commitment is lacking.

• 9. There is no project champion at the required level to make things happen.

• 10. Many new technologies are to be introduced within the scope of the project, or the technical architecture is unclear and
much of the technology will be used for the first time within the project.
 The Object-Oriented Model
• Easy integration of existing software modules (objects /
components) into newly developed software systems.
• Process begins with OOA and OOD
• Then, acquire suitable components from reusable
software component libraries (or purchase them).
• Otherwise, develop as needed.
• Can involve adding to repertoire of library components.
• Economy: integrating reusable components; much
lower cost than developing
• Improved quality – using tested components
• Shorter development times: integration of reusable
software components.
 Object Oriented
Development Model
CASE Tools

• CASE tools stand for Computer Aided Software Engineering tools As the name implies they are
computer based programs to increase the productivity of analysts They permit effective
communication with users as well as other members of the development team. They integrate the
development done during each phase of a system life cycle. They assist in correctly assessing the
effects and cost of changes so that maintenance cost can be estimated.
Available CASE tools
• Commercially available systems provide tools for each phase of the system development life cycle. A typical package is Visual
Analyst which has several tools integrated together.

• Tools are also in the open domain which can be downloaded and used. They do not usually have very good user interfaces.

• System requirements specification documentation tool

• Data flow diagramming tool

• System flow chart generation tool

• Data dictionary creation

• Formatting and checking structured English process logic

• Decision table checking

• Screen design for data inputting
• Form design for outputs.
• E-R diagramming
• Data base normalization given the dependency information
USES
DISADVANTAGES
ADVANTAGES
SYSTEM FLOW CHART

• System flowcharts are a way of displaying how data flows in a system

and how decisions are made to control events.

• To illustrate this, symbols are used. They are connected together to

show what happens to data and where it goes.
Symbols used in flow charts

• Note that system flow charts are very similar to data flow charts.
• Data flow charts do not include decisions, they just show the path that data takes, where it is held, processed, and
then output.
• Using system flowchart ideas in this system flowchart is a diagram for a 'cruise control' for a car.
• The cruise control keeps the car at a steady speed that has been set by the driver.
• The flowchart shows what the outcome is if the car is going too fast or too slow.
• The system is designed to add fuel, or take it away and so keep the car's speed constant. The output (the car's new
• speed) is then fed back into the system via the speed sensor.
• Other examples of uses for system diagrams include:
• • aircraft control
• • central heating
• • automatic washing machines
• • booking systems for airlines
INPUT AND OUT PUT
Decision Trees and Decision Tables

• Often our problem solutions require decisions to be made

according to two or more conditions or combinations of
conditions
• Decision trees represent such decision as a sequence of steps
• Decision tables describe all possible combinations of
conditions and the decision appropriate to each combination
• Levels of uncertainty can also be built into decision trees to
account for the relative probabilities of the various outcomes

66
Decision Tree Showing Possible Outcomes Projected
Sales
Results
Outcomes

A.1 Sales Up 10%

Outcome A
A.2 Sales Up 15%

Decision Made
B.1 Sales Up 5%

Outcome B
B.2 Sales Even

67
 Decision Tree of Outcomes -- Quantifying Uncertainties
Projected
Sales
Results

80%
A.1 Sales Up 10% 32%

Outcome A
40% 20% A.2 Sales Up 15% 8%

Decision Made
70% B.1 Sales Up 5% 42%

60%
Outcome B
30% B.2 Sales Even 18%

68
Example of Using a Decision Tree or
Table to Capture Complex Business
Logic
Consider the following excerpt from an actual business
document:

If the customer account is billed using a fixed rate method, a minimum

monthly charge is assessed for consumption of less than 100 kwh. Otherwise,
apply a schedule A rate structure. However, if the account is billed using a
variable rate method, a schedule A rate structure will apply to consumption
below 100 kwh, with additional consumption billed according to schedule B.

69
Articulating Complex Business Rules

◼ Complex business/logic rules, such as our example, can

become rather confusing
◼ Capturing such rules in text form alone can lead to ambiguity
and misinterpretation
◼ As an alternative, it is often wise to capture such rules in
decision tress or decision tables
◼ The examples on the following slides will illustrate this
technique
Decision Tree for this Example
< 100 kwh minimum charge
fixed
rate
billing >= 100 kwh schedule A

< 100 kwh schedule A

variable
rate
billing >= 100 kwh
?
71
Decision Tree for this Example
< 100 kwh minimum charge
fixed
rate
billing >= 100 kwh schedule A

< 100 kwh schedule A

variable
rate schedule A on
billing first 99 kwh
>= 100 kwh schedule B on
kwh 100 and above

72
DECISION TABLE
THREE PARTS
USES OF DECISION TABLE
DECISION TABLE METHODOLOGY
Decision Tree for this Example
< 100 kwh minimum charge
fixed
rate
billing >= 100 kwh schedule A

< 100 kwh schedule A

variable
rate schedule A on
billing first 99 kwh
>= 100 kwh schedule B on
kwh 100 and above

83
Decision Table for Example – Version 1
Is this a
Rules valid
business
Conditions 1 2 3 4 5 case? Did
we miss
Fixed rate acct T T F F F something?
Variable rate acct F F T T F
Consumption < 100 kwh T F T F
Consumption >= 100 kwh F T F T
Actions
Minimum charge X
Schedule A X X
Schedule A on first 99 kwh, X
Schedule B on kwh 100 +

84
Decision Table for Example – Version 2
Rules
Conditions 1 2 3 4
Account type fixed fixed variable variable
Consumption < 100 >=100 <100 >= 100

Actions
Minimum charge X
Schedule A X X
Schedule A on first 99 kwh, X
Schedule B on kwh 100 +

85
 Developing More Complex Decision
Tables
In the 1950's General Electric, the Sutherland
Corporation, and the United States Air Force worked
on a complex file maintenance project, using
flowcharts and traditional narratives, they spent six
labor-years of effort but failed to define the problem.

It was not until 1958, when four analysts using

decision tables, successfully defined the problem in
less than four weeks 1.

_____________________________________
1Ta ke n fro m “A H is t o ry o f D e c is io n Ta b le s ” lo c a t e d a t
http://www.catalyst.com/products/logicgem/overview.html
Steps to create a decision table
1. List all the conditions which determine which action to take.
2. Calculate the number of rules required.
• Multiple the number of values for each condition by each other.
• Example: Condition 1 has 2 values, Condition 2 has 2 values, Condition
3 has 2 values. Thus 2 X 2 X 2 = 8 rules
3. Fill all combinations in the table.
4. Define the action for each rule
5. Analyze column by column to determine which actions are
appropriate for each rule.
6. Reduce the table by eliminating redundant columns.
 All possible combinations

<cond-1> F T F T F T F T … T

<cond-2> F F T T F F T T … T

Conditions <cond-3> F F F F T T T T … T

… …

<cond-n> F F F F F F F F … T

<action-1> X X X X

<action-2> X X X X

Actions <action-3> X X X X

… …

<action-m> X X X

Actions per combination

(each column represents a different state of affairs)
Example
• Policy for charging charter flight costumers for certain
in-flight services:2
If the flight is more than half-full and costs more than $350 per
seat, we serve free cocktails unless it is a domestic flight. We
charge for cocktails on all domestic flights; that is, for all the ones
where we serve cocktails. (Cocktails are only served on flights that
are more than half-full.)

_____________________________________
2 Example taken form: Structured Analysis and System Specification, Tom de Marco,

Yourdon inc., New York,

List all the conditions that
determine which action to take.

Conditions Values
The flight more than half-full? Yes (Y), No (N)

Cost is more than $350? Y, N

Is it a domestic flight? Y, N
Calculate the space of combinations

Conditions Number of Possible Combinations/ Rules

Combinations
1 2 Y N
2 4 Y N Y N
Y Y N N
3 8 Y N Y N Y N Y N
Y Y N N Y Y N N
Y Y Y Y N N N N
… …
n 2n
Calculate the Number of Rules in Table

• Conditions in the example are 3 and all are two-valued

ones, hence we have:

All combinations are 23 = 8 rules OR

2 X 2 X 2 = 8 rules
Fill all rules in the table.
POSSIBLE RULES

more than half-full N N N N Y Y Y Y

CONDITONS more than $350 per

N N Y Y N N Y Y
seat

domestic flight N Y N Y N Y N Y
ACTIONS
Analyze column by column to determine which
actions are appropriate for each combination
POSSIBLE RULES

more than half-full N N N N Y Y Y Y

CONDITONS

more than $350 per seat N N Y Y N N Y Y

domestic flight N Y N Y N Y N Y
ACTIONS

serve cocktails X X X X

free X
Reduce the table by eliminating
redundant columns.

POSSIBLE COMBINATIONS
more than half-
full
N N N N Y Y Y Y Note that some
columns are identical
CONDITONS

more than $350 except for one condition.

N N Y Y N N Y Y
per seat

domestic flight N Y N Y N Y N Y
ACTIONS

serve cocktails X X X X

free X
Reduce the table by eliminating
redundant columns.

POSSIBLE RULES
more than half- Note that some
N N N N Y Y Y Y
full columns are identical
CONDITONS

except for one condition.

more than $350
N N Y Y N N Y Y
per seat
Which means that
actions are
domestic flight N Y N Y N Y N Y independent from
the value of that
ACTIONS

serve cocktails X X X X particular condition.

free X
Reduce the table by eliminating
redundant columns.

POSSIBLE RULES Note that some

more than half- columns are identical
N N N N Y Y Y Y except for one
full
condition.
CONDITONS

more than $350

N N Y Y N N Y Y
per seat
Which means that
actions are
domestic flight N Y N Y N Y N Y independent from
the value of that
ACTIONS

serve cocktails X X X X particular condition.

free X
Hence, the table
can be simplified.
Reduce the table by eliminating
redundant columns.

POSSIBLE RULES First we combine

more than half- the yellow ones
N N N Y Y Y Y nullifying the condition.
full
CONDITONS

more than $350

N Y Y N N Y Y
per seat

domestic flight - N Y N Y N Y
ACTIONS

serve cocktails X X X X

free X
Reduce the table by eliminating
redundant columns.

POSSIBLE RULES First we combine the yellow

more than half- ones nullifying the condition.
N N Y Y Y Y
full
Then the red ones.
CONDITONS

more than $350

N Y N N Y Y
per seat

domestic flight - - N Y N Y
ACTIONS

serve cocktails X X X X

free X
Reduce the table by eliminating
redundant columns.

POSSIBLE RULES First we combine the yellow

more than half- ones nullifying the condition.
N N Y Y Y Y
full
Then the red ones.
CONDITONS

more than $350

N Y N N Y Y
per seat
Notice that yellow and red
columns are identical but by
domestic flight - - N Y N Y one condition.
ACTIONS

serve cocktails X X X X

free X
Reduce the table by eliminating
redundant columns.

POSSIBLE RULES First we combine the yellow

more than half- ones nullifying the condition.
N Y Y Y Y
full
Then the red ones.
CONDITONS

more than $350

- N N Y Y
per seat
Notice that yellow and red
columns are identical but by one
domestic flight - N Y N Y condition.
ACTIONS

serve cocktails X X X X So, we combine them.

free X
Reduce the table by eliminating
redundant columns.

POSSIBLE RULES First we combine the yellow

more than half- ones nullifying the condition.
N Y Y Y
full
Then the red ones.
CONDITONS

more than $350

- N Y Y
per seat
Notice that yellow and red
columns are identical but by one
domestic flight - - N Y condition.
ACTIONS

serve cocktails X X X So, we combine them.

free X
Then we combine the violet
colored ones.
Reduce the table by eliminating
redundant columns.

POSSIBLE RULES Notice that even when we observe that

more than half- the green columns are identical except
N Y Y Y for one condition we do not combine
full
them:
CONDITONS

more than $350

- N Y Y A “NULLIFIED” condition is not the
per seat
same as a valued one.

domestic flight - - N Y

What about this rule? Have we

ACTIONS

serve cocktails X X X
over looked something?
free X
Final Solution

Rules

more than half-full N Y Y Y

CONDITONS
more than $350 per seat - N Y Y

domestic flight - - N Y

serve cocktails X X X
ACTIONS

free X
 Example:
“A marketing company wishes to construct a decision
table to decide how to treat clients according to three
characteristics:
Gender, City Dweller, and age group: A (under 30), B
(between 30 and 60), C (over 60).
The company has four products (W, X, Y and Z) to test
market.
Product W will appeal to female city dwellers.
Product X will appeal to young females.
Product Y will appeal to Male middle aged shoppers who
do not live in cities.
Product Z will appeal to all but older females.”
The process used to create this decision table is the following:
1. Identify conditions and their alternative values.
There are 3 conditions: gender, city dweller, and age group. Put these into table as 3
rows in upper left side.
Gender’s alternative values are: F and M.
City dweller’s alternative values are: Y and N
Age group’s alternative values are: A, B, and C
2. Compute max. number of rules.
Determine the product of number of alternative values for each condition.
2 x 2 x 3 = 12.
Fill table on upper right side with one column for each unique combination of these
alternative values. Label each column using increasing numbers 1-12 corresponding to
the 12 rules. For example, the first column (rule 1) corresponds to F, Y, and A. Rule 2
corresponds to M, Y, and A. Rule 3 corresponds to F, N, and A. Rule 4 corresponds to M,
N, and A. Rule 5 corresponds to F, Y, and B. Rule 6 corresponds to M, Y, and B and so on.
3. Identify possible actions
Market product W, X, Y, or Z. Put these into table as 4 rows in lower left side.
4. Define each of the actions to take given each rule.
For example, for rule 1 where it is F, Y, and A; we see from the above example scenario
that products W, X, and Z will appeal. Therefore, we put an ‘X’ into the table’s
intersection of column 1 and the rows that correspond to the actions: market product W,
market product X, and market product Z.
 1 2 3 4 5 6 7 8 9 10 11 12
Gender F M F M F M F M F M F M

City Y Y N N Y Y N N Y Y N N
Age A A A A B B B B C C C C
Market X X X
W

MarketX X X

MarketY X

MarketZ X X X X X X X X X X
5. Verify that the actions given to each rule are correct.
6. Simplify the table.
Determine if there are rules (columns) that represent impossible situations.
If so, remove those columns. There are no impossible situations in this
example.
Determine if there are rules (columns) that have the same actions. If so,
determine if these are rules that are identical except for one condition and
for that one condition, all possible values of this condition are present in the
rules in these columns. In the example scenario, columns 2, 4, 6, 7, 10, and
12 have the same action. Of these columns: 2, 6, and 10 are identical except
for one condition: age group. The gender is M and they are city dwellers. The
age group is A for rule 2, B for rule 6, and C for rule 10. Therefore, all possible
values of condition ‘age group’ are present. For rules 2, 6, and 10; the age
group is a “don’t care”. These 3 columns can be collapsed into one column
and a hyphen is put into the age group location to signify that we don’t care
what the value of the age group is, we will treat all male city dwellers the
same: market product Z.
Final Decision Table
1 2 3 4 5 6 7 8 9 10
Gender F M F M F M F M F M

City Y Y N N Y N N Y N N
Age A A A B B B C C C
MarketW X X X

MarketX X X

MarketY X

MarketZ X X X X X X X X