Software Engineering

LECTURE 2
 System Development Life Cycle (SDLC)

The SDLC is the process of understanding how

an information system can support business
needs, designing the system, building it, and
delivering it to users.
The key person in the SDLC is the systems analyst .

Duties of the System Analyst

• analyzes the business situation
• identifies opportunities for improvements
• designs an information system to implement them.
Note
• the primary objective of the systems analyst is not
to create a wonderful system.

• The primary goal is to create value for the

organization, which for most companies means
increasing profits (government agencies and not-
for-profit organizations measure value differently).
Many failed systems were abandoned
because the analysts tried to build a
wonderful system without clearly
understanding how the system would fit with
the organization’s goals, current business
processes, and other information systems to
provide value.
• Each of the phases include a set of steps,
which rely on techniques that produce
specific document files that provide
understanding about the project
(deliverables).
• To Understand the SDLC:

– Each phase consists of steps that lead to

specific deliverables
– The system evolves through gradual
refinement
Project Phases
• Planning (Why build the system?)

• Analysis (Who, what when, where will the system

be?)

• Design (How will the system work?)

• Implementation (System delivery)

Planning

• Identifying business value

• Analyze feasibility

• Develop work plan

• Staff the project

• Control and direct project

Analysis

• Analysis

• Information gathering

• Process modeling

• Data modeling
Design
• Physical design
• Architectural design
• Interface design
• Database and file design
• Program design
Implementation
• Construction
• Installation
Processes and Deliverables
Process Product

Planning Project Plan

Analysis System Proposal

Design System
Specification

Implementation New System and

Maintenance Plan
 • Feasibility Study or Planning

• Define the problem and scope of existing system.

• Overview the new system and determine its objectives.
• Confirm project feasibility and produce the project Schedule.
• During this phase, threats, constraints, integration and security of
system are also considered.
• A feasibility report for the entire project is created at the end of this
phase
 Analysis and Specification

• Gather, analyze, and validate the information.

• Define the requirements and prototypes for new system.
• Evaluate the alternatives and prioritize the requirements.
• Examine the information needs of end-user and enhances the system
goal.
• A Software Requirement Specification (SRS) document, which
specifies the software, hardware, functional, and network
requirements of the system is prepared at the end of this phase.
 System Design

• Includes the design of application, network, databases, user

interfaces, and system interfaces.
• Transform the SRS document into logical structure, which contains
detailed and complete set of specifications that can be implemented
in a programming language.
• Create a contingency, training, maintenance, and operation plan.
• Review the proposed design. Ensure that the final design must meet
the requirements stated in SRS document.
• Finally, prepare a design document which will be used during next
phases.
 Implementation

• Implement the design into source code through coding.

• Combine all the modules together into training environment that detects
errors and defects.
• A test report which contains errors is prepared through test plan that
includes test related tasks such as test case generation, testing criteria,
and resource allocation for testing.
• Integrate the information system into its environment and install the new
system.
 Maintenance/Support

• Include all the activities such as phone support or physical on-site

support for users that is required once the system is installing.
• Implement the changes that software might undergo over a period of
time, or implement any new requirements after the software is deployed
at the customer location.
• It also includes handling the residual errors and resolve any issues that
may exist in the system even after the testing phase.
• Maintenance and support may be needed for a longer time for large
systems and for a short time for smaller systems.
Key Individuals Involved in Systems Analysis

• Systems analyst – performs analysis and design

• May perform some programming as well

• Client – the person or organization contracting to have

the work done

• User – the people who will have contact with the

system
 System Development Methodologies

- a formalized approach to the systems development process;

- a standardized development process that defines a set of

activities, methods, best practices, deliverables, and
automated tools that system developers and project
managers are to use to develop and continuously improve
information systems and software.
Popular Methodologies

• The Waterfall Methodology

• The RAD or Agile Methodology

• Big Bang Model

 The Waterfall Methodology
• The Waterfall Model was the first Process Model to be introduced. It
is also referred to as a linear sequential life cycle model. It is very
simple to understand and use. In the Waterfall model, each phase
must be completed before the next phase can begin and there is no
overlapping in the phases.
• This means that any phase in the development process begins only if
the previous phase is complete.
• The outcome of one phase acts as the input for the next phase
sequentially.
Advantages of the Waterfall
Methodology
• It allows for departmentalization and control. A schedule can be set with deadlines for
each stage of development and a product can proceed through the development
process model phases one by one.

• Development moves from concept, through design implementation, testing,

installation, troubleshooting, and ends up at operating and maintenance.

• Waterfall model works well for smaller projects where requirements are clearly defined
and very well understood.

• This model is simple and easy to understand and use.

Disadvantages of the Waterfall
Methodology
• It does not allow for much reflection or revision. Once an application is in the
testing stage, it is very difficult to go back and change something that was not
well documented or thought upon in the concept stage.

• No working software is produced until late during the life cycle.

• Not a good model for complex and object-oriented projects.

• Not suitable for the projects where requirements are at a moderate to high risk
of changing.
When to use the waterfall model
• This model is used only when the requirements are very well known,
clear and fixed.
• Product definition is stable.
• Technology is understood.
• There are no ambiguous requirements
• Ample resources with required expertise are available freely
• The project is short.
RAD Methodology
• Rad Model is a type of incremental model. In RAD model the components or
functions are developed in parallel as if they were mini projects. The
developments are time boxed, delivered and then assembled into a working
prototype. This can quickly give customers something to see and use and to
provide feedback regarding the delivery and their requirements.
• Phases in RAD
• Business modelling
• Data modelling
• Process modelling
• Application generation
• Testing and turnover
RAD Methodology Cont….
Rapid application development is a collection of
methodologies that emerged in response to the
weaknesses of waterfall development and its
variations. RAD incorporates special techniques and
computer tools to speed up the analysis, design, and
implementation phases in order to get some portion of
the system developed quickly and into the hands of the
users for evaluation and feedback.
The RAD may be conducted in a variety of
ways.
• Iterative Development
• System Prototyping
Iterative development breaks the overall project into a series of versions that are
developed sequentially. The most important and fundamental requirements are
bundled into the first version of the system. This version is developed quickly by a
mini-waterfall process, and once implemented, the users can provide valuable
feedback to be incorporated into the next version of the system.

Iterative development gets a preliminary version of the system to the users quickly
so that business value is provided. Since users are working with the system,
important additional requirements may be identified and incorporated into
subsequent versions. The chief disadvantage of iterative development is that users
begin to work with a system that is intentionally incomplete. Users must accept
that only the most critical requirements of the system will be available in the early
versions and must be patient with the repeated introduction of new system
versions.
System prototyping performs the analysis, design, and implementation phases
concurrently in order to quickly develop a simplified version of the proposed
system and give it to the users for evaluation and feedback. The system prototype
is a “quick and dirty” version of the system and provides minimal features.
Following reaction and comments from the users, the developers reanalyze,
redesign, and re implement a second prototype that corrects deficiencies and adds
more features. This cycle continues until the analysts, users, and sponsor agree that
the prototype provides enough functionality to be installed and used in the
organization. System prototyping very quickly provides a system for users to
evaluate and reassures users that progress is being made.
The approach is very useful when users have difficulty expressing requirements for
the system. A disadvantage, however, is the lack of careful, methodical analysis
prior to making design and implementation decisions. System prototypes may have
some fundamental design limitations that are a direct result of an inadequate
understanding of the system’s true requirements early in the project.
Advantages RAD Methodology
• Reduced development time
• Increases reusability of components
• Quick initial reviews occur
• Encourages customer feedback
 Disadvantages RAD
Methodology
• Depends on strong team and individual performances for identifying
business requirements.

• Only system that can be modularized can be built using RAD

• Requires high skilled developers/designers

• High dependency on modelling skills

• Inapplicable to cheaper projects as costs of modelling and automated

code generation is high.
When to use the RAD Model:
• When there is a need to create a system that can be modularized in 2-

3 months of time.

• If there is high availability of designers for modelling and the budget is

high enough to afford their cost along with the cost of automated

code generating tools.

Big Bang Model

• In this model, developers do not follow any specific process.

Development begins with the necessary funds and efforts in the form
of inputs. And the result may or may not be as per the customer's
requirement, because in this model, even the customer requirements
are not defined.
• This model is ideal for small projects like academic projects or
practical projects. One or two developers can work together on this
model.
When to use Big Bang Model?

• As we discussed above, this model is required when

this project is small like an academic project or a
practical project. This method is also used when the
size of the developer team is small and when
requirements are not defined, and the release date is
not confirmed or given by the customer.
Advantage(Pros) of Big Bang Model:

• There is no planning required.

• Simple Model.
• Few resources required.
• Easy to manage.
• Flexible for developers.
Disadvantage(Cons) of Big Bang Model:

• There are high risk and uncertainty.

• Not acceptable for a large project.
• If requirements are not clear that can cause very expensive.
 Role of System Analyst

• The system analyst is a person who is thoroughly

aware of the system and guides the system
development project by giving proper directions.
He/She is an expert having technical and
interpersonal skills to carry out development tasks
required at each phase.
• He/She pursues to match the objectives of
information system with the organization goal.
Attributes of a Systems Analyst
The following figure shows the attributes a systems analyst should possess
 Interpersonal Skills
• Interface with users and programmer.
• Facilitate groups and lead smaller teams.
• Managing expectations.
• Good understanding, communication, selling and teaching abilities.
• Motivator having the confidence to solve queries.
Analytical Skills
• System study and organizational knowledge
• Problem identification, problem analysis, and problem solving
• Sound commonsense
• Curiosity to learn about new organization
 Management Skills

• Understand users jargon and practices.

• Resource & project management.
• Change & risk management.
• Understand the management functions thoroughly.
Technical Skills

• Knowledge of computers and software.

• Keep abreast of modern development.
• Know of system design tools.
• Breadth knowledge about new technologies.
Phase 1: Planning (Preliminary Investigation)

 A brief study of the problem to determine whether the

project should be pursued
 Also called the feasibility study or system survey
 Involves working with the users
 Defining the Problem

• Two points that must be agreed upon

• The nature of the problem
• The scope (boundaries) of the problem

• Agreeing on the problem helps define the objectives of the

system
Feasibility Study (TOES – R)
• Technical feasibility – Is the solution technically practical? Does our staff have the
technical expertise to design and build this solution?

• Operational feasibility – Will the solution fulfill the users’ requirements? To what degree?
How will the solution change the users’ work environment? How do users feel about such a
solution?

• Economic feasibility – Is the solution cost-effective?

• Schedule feasibility – Can the solution be designed and implemented within an

acceptable time?

• Risk feasibility – What is the probability of a successful implementation using the

technology and approach? (Risk Management)
SWIFT SPORT SHOES: PROBLEM DEFINITION
True Nature of the Problem
The nature of the problem is the existing manual inventory system. In particular;
 Products are frequently out of stock
 There is little interstore communication about stock item
 Store Managers have no information about stock levels on a day-to-day
basis
 Ordering is done haphazardly

Scope
The Scope of the project will be limited to the development of an inventory
system using appropriate computer technology

Objectives
The new automated inventory system should provide the following
 Adequate stock maintained in stores
 Automatic stock ordering
 Stock distribution among stores
 Management access to current inventory information
 Ease of Use
 Reduced operating costs of the inventory function
The most widely used tool
that is used to create the
Project Plan is the Gantt
Chart
 Phase 2: Analysis

It involves understanding the existing system

It is also called Requirement Determination/Specification
Two tasks are involved
 Data gathering
 Data analysis
 Introduction to Requirements Discovery

• Requirements discovery includes those techniques to be used

by systems analysts to identify or extract system problems and
solution requirements from the user community.

• A system requirement (also called a business requirement) is

a description of the needs and desires for an information
system.
• A requirement may describe functions, features (attributes), and
constraints.
 Types of Requirements

• A functional requirement is a function or feature that must be

included in an information system in order to satisfy the business
need and be acceptable to the users.

• A nonfunctional requirement is a description of the features,

characteristics, and attributes of the system as well as any
constraints that may limit the boundaries of the proposed solution.
These are the requirements that are not mention/specified by the
client.
Functional vs. Nonfunctional Requirements

• Functional requirement - something the information

system must do

• Nonfunctional requirement - a property or quality the

system must have
• Performance

• Security

• Costs
• A functional requirement is an action of the system
and usually is written using an action verb phrase. For
example:
• The system should process a checking account deposit
• The system should calculate the GPA for a student
• The system should capture the account holder
identification information
 Types of Nonfunctional Requirements
Requirement Type Explanation

Performance Performance requirements represent the performance the system is required

to exhibit to meet the needs of users.
· What is the acceptable throughput rate?
· What is the acceptable response time?
Information Information requirements represent the information that is pertinent to the
users in terms of content, timeliness, accuracy, and format.
· What are the necessary inputs and outputs? When must they
happen?
· What is the required data to be stored?
· How current must the information be?
· What are the interfaces to external systems?
Economy requirements represent the need for the system to reduce costs or
Costs increase profits.
· What are the areas of the system where costs must be reduced?
· How much should costs be reduced or profits be increased?
· What are the budgetary limits?
· What is the timetable for development?
Control Control requirements represent the environment in which the system must
(and Security) operate, as well as the type and degree of security that must be provided.
operate
· Must access to the system or information be controlled?
· What are the privacy requirements?
· Does the criticality of the data necessitate the need for special
handling (backups, offsite storage, etc.) of the data?
Types of Nonfunctional Requirements (concluded)
Requirement Type Explanation

Efficiency Efficiency requirements represent the systems ability to produce outputs

with minimal waste.
· Are there duplicate steps in the process that must be eliminated?
· Are there ways to reduce waste in the way the system uses it
resources?
Service Service requirements represent needs in order for the system to be
reliable, flexible, and expandable.
· Who will use the system and where are they located?
· Will there be different types of users?
· What are the appropriate human factors?
· What training devices and training materials are to be included in
the system?
· What training devices and training materials are to be developed
and maintained separately from the system, such as stand- alone
computer based training (CBT) programs or databases?
· What are the reliability/availability requirements?
· How should the system be packaged and distributed?
· What documentation is required?
An Ambiguous Requirements Statement
Requirement:
Create a means to transport a single
individual from home to place of work.

Management IT User
Interpretation Interpretation Interpretation
Results of Incorrect Requirements
The system may cost more than projected.

The system may be delivered later than promised.

The system may not meet the users’ expectations and they may not be
able to use it.

Once in production, costs of maintaining and enhancing system may be

excessively high.

The system may be unreliable and prone to errors and downtime.

Reputation of IT staff is tarnished as failure will be perceived as a mistake

by the team.
Criteria for System Requirements

• Consistent – not conflicting or ambiguous.

• Complete – describe all possible system inputs and responses.

• Feasible – can be satisfied based on the available resources and

constraints.

• Required – truly needed and fulfill the purpose of the system.

• Accurate – stated correctly.

• Traceable – directly map to functions and features of system.

• Verifiable – defined so can be demonstrated during testing.

Requirements Discovery

• Given an understanding of the problems, the systems analyst

can start to define requirements.

• Fact-finding – the formal process of using research,

meetings, interviews, questionnaires, sampling, and other
techniques to collect information about system problems,
requirements, and preferences.

• It is also called information gathering or data collection.

Fact-Finding Ethics
• Fact-Finding often brings systems analysts into contact with sensitive
information.
• Company plans

• Employee salaries or medical history

• Customer credit card, social security, or other information

• Ethical behavior
• Systems analysts must not misuse information.

• Systems analysts must protect information from people who would misuse it.

• Otherwise
• Systems analyst loses respect, credibility, and confidence of users and management,
impairing ability to do job
• Organization and systems analyst could have legal liability

• Systems analyst could lose job

Fact-Finding Methods
1. Sampling of existing documentation, forms, and
databases.

2. Research and site visits.

3. Observation of the work environment.

4. Questionnaires.

5. Interviews.

6. Prototyping.
Sampling Existing Documentation, Forms, & Files

Sampling –process of collecting a representative sample of

documents, forms, and records.
• Organization chart

• Memos and other documents that describe the problem

• Standard operating procedures for current system

• Completed forms

• Manual and computerized screens and reports

• Samples of databases

• Flowcharts and other system documentation

• And more
Things to be Gleaned from Documents

• Symptoms and causes of problems

• Persons in organization who have understanding of problem

• Business functions that support the present system

• Type of data to be collected and reported by the system

• Questions that need to be covered in interviews

Sampling Techniques
Randomization– a sampling technique
characterized by having no predetermined
pattern or plan for selecting sample data.

Stratification – a systematic sampling technique that attempts

to reduce the variance of the estimates by spreading out the
sampling—for example, choosing documents or records by
formula—and by avoiding very high or low estimates.
Observation
Observation – a fact-finding technique wherein the systems
analyst either participates in or watches a person perform
activities to learn about the system.
• Advantages?

• Disadvantages?
 Observation
Advantages Disadvantages
1. Data gathered can be very 1. People may perform differently when being
observed
reliable
2. Work observed may not be representative of
2. Can see exactly what is being
normal conditions
done in complex tasks
3. Timing can be inconvenient
3. Relatively inexpensive compared 4. Interruptions
with other techniques 5. Some tasks not always performed the same way

4. Can do work measurements 6. May observe wrong way of doing things

Observation Guidelines
• Determine the who, what, where, when, why, and how of the observation.

• Obtain permission from appropriate supervisors.

• Inform those who will be observed of the purpose of the observation.

• Keep a low profile.

• Take notes.

• Review observation notes with appropriate individuals.

• Don't interrupt the individuals at work.

• Don't focus heavily on trivial activities.

• Don't make assumptions.

Questionnaires
Questionnaire – a special-purpose document that allows the
analyst to collect information and opinions from respondents.
• Open Ended Questions

• Closed Ended Questions

 Questionnaires
Advantages Disadvantages
1. Often can be answered quickly • Return rate is often low
2. People can complete at their
• No guarantee that an individual
convenience
will answer all questions
3. Relatively inexpensive way to
• No opportunity to reword or
gather data from a large
explain misunderstood
number
questions
4. Allow for anonymity
• Cannot observe body language
5. Responses can be tabulated
quickly • Difficult to prepare
Developing a Questionnaire
1.Determine what facts and opinions must be collected and from
whom you should get them.

2.Based on the facts and opinions sought, determine whether open or

closed questions will produce the best answers.

3.Write the questions.

4.Test the questions on a small sample of respondents.

5.Duplicate and distribute the questionnaire.

NB: ALWAYS INDICATE THE OBJECTIVE OF THE RESEARCH/PROJECT ON THE
QUESTIONNAIRE
Interviews
Interview - a fact-finding technique whereby the
systems analysts collect information from individuals
through face-to-face interaction.
• Find facts
The personal interview is
• Verify facts
generally recognized as the
• Clarify facts
most important and most
• Generate enthusiasm
often used fact-finding
• Get the end-user involved
technique.
• Identify requirements

• Solicit ideas and opinions

Types of Interviews and Questions

Unstructured interview –conducted with only a general goal or subject

in mind and with few, if any, specific questions. The interviewer counts
on the interviewee to provide a framework and direct the conversation.

Structured interview –interviewer has a specific set of questions to

ask of the interviewee.
Open-ended question – question that allows the interviewee to respond in any
way.

Closed-ended question – a question that restricts answers to either specific

choices or short, direct responses.
 Interviews
Advantages
Disadvantages
• Give analyst opportunity to
• Time-consuming
motivate interviewee to respond
freely and openly • Success highly dependent on

• Allow analyst to probe for more analyst's human relations skills

feedback • May be impractical due to
• Permit analyst to adapt or reword location of interviewees
questions for each individual

• Can observe nonverbal

communication
Procedure to Conduct an Interview
1.Select Interviewees
• End users

• Learn about individual prior to the interview

2.Prepare for the Interview

• interview guide

3.Conduct the Interview

• Summarize the problem

• Offer an incentive for participation

• Ask the interviewee for assistance

4.Follow Up on the Interview

• Memo that summarizes the interview
Conduct the Interview
• Dress to match interviewee

• Arrive on time
• Or early if need to confirm room setup

• Open interview by thanking interviewee

• State purpose and length of interview and how data will be used

• Monitor the time

• Ask follow-up questions

• Probe until you understand

• Ask about exception conditions ("what if...")

 Interviewing Do’s and Don’ts
Do Don't
1. Dress appropriately
1. Assume an answer is finished or leading
2. Be courteous nowhere
3. Listen carefully 2. Reveal verbal and nonverbal clues
3. Use jargon
4. Maintain control of the interview
4. Reveal personal biases
5. Probe
5. Talk more than listen
6. Observe mannerisms and nonverbal 6. Assume anything about the topic or the
communication interviewee
7. Be patient 7. Tape record (take notes instead)
8. Keep interviewee at ease
9. Maintain self-control
10. Finish on time
 Structured Analysis

Analysts use various tools to

understand and describe the
information system. One of the
ways is using structured analysis.
 What is Structured Analysis?
• Structured Analysis is a development method that allows the analyst to
understand the system and its activities in a logical way.
• It is a systematic approach, which uses graphical tools that analyze and
refine the objectives of an existing system and develop a new system
specification which can be easily understandable by user.
• It has following attributes −
• It is graphic which specifies the presentation of application.
• It divides the processes so that it gives a clear picture of system flow.
• It is logical rather than physical i.e., the elements of system do not depend
on vendor or hardware.
• It is an approach that works from high-level overviews to lower-level details.
 Structured Analysis Tools
• During Structured Analysis, various tools and techniques are
used for system development. They are −

Data Flow Diagrams

Data Dictionary
Decision Trees
Decision Tables
Structured English
Flow Chart
 Data Flow Diagrams (DFD) or Bubble Chart

• It is a technique developed by Larry Constantine to express the

requirements of system in a graphical form.
• It shows the flow of data between various functions of system and
specifies how the current system is implemented.
• It is an initial stage of design phase that functionally divides the
requirement specifications down to the lowest level of detail.
• Its graphical nature makes it a good communication tool between user
and analyst or analyst and system designer.
• It gives an overview of what data a system processes, what
transformations are performed, what data are stored, what results are
produced and where they flow.
 Basic Elements of DFD

• DFD is easy to understand and quite effective when the required design is
not clear and the user wants a notational language for communication.
However, it requires a large number of iterations for obtaining the most
accurate and complete solution.
• The following table shows the symbols used in designing a DFD and their
significance
 Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store

DFD Rules and tips
• Each process should have at least one input and an output
• Each data store should have at least one data flow in and one data
flow out.
• Data stored in a system must go through a process
• All processes in a DFD go to another process or a data store.
DFD Levels
• A dataflow diagram can dive into progressively more detail by using
levels and layers, zeroing in on a particular piece. DFD levels are
numbered 0, 1 or 2 and occasionally go to even level 3 or beyond. The
necessary level of detail depends on the scope of what you are trying
to accomplish.
DFD Level 0 or Context Diagram

• DFD Level 0 is also called a Context Diagram. It’s a

basic overview of the whole system or process being
analyzed or modeled. It’s designed to be an at-a-
glance view, showing the system as a single high-level
process, with its relationship to external entities. It
should be easily understood by a wide audience,
including stakeholders, business analysts, data
analysts and developers.
Example 2 of a context diagram
DFD Level 1
• DFD Level 1 provides a more detailed breakout of
pieces of the Context Level Diagram. You will highlight
the main functions carried out by the system, as you
break down the high-level process of the Context
Diagram into its sub processes.
DFD Level 2

•DFD Level 2 then goes one step deeper

into parts of Level 1. It may require more
text to reach the necessary level of
detail about the system’s functioning.
 Types of DFD
Data flow diagrams (DFDs) are categorized as
either logical or physical. A logical DFD focuses on
the business and how the business operates. It
describes the business events that take place and
the data required and produced by each event.
On the other hand, a physical DFD shows how the
system will be implemented. Here are the main
differences between logical and physical DFD:
Logical DFD

• Logical DFD depicts how the business operates.

• The processes represent the business activities.
• The data stores represent the collection of data regardless of how the
data are stored.
• It’s how business controls.
Physical DFD

• Physical DFD depicts how the system will be implemented (or how the
current system operates).
• The processes represent the programs, program modules, and manual
procedures.
• The data stores represent the physical files and databases, manual
files.
• It show controls for validating input data, for obtaining a record, for
ensuring successful completion of a process, and for system security.
An Example - Grocery Store System
• The example below shows a logical DFD and a physical DFD for a
grocery store cashier:
• The CUSTOMER brings the ITEMS to the register;
• PRICES for all ITEMS are LOOKED UP, and then totaled;
• Next, PAYMENT is given to the cashier finally, the CUSTOMER is given
a receipt.
 Data Dictionary

A data dictionary contains metadata i.e data about the

database. The data dictionary is very important as it contains
information such as what is in the database, who is allowed
to access it, where is the database physically stored etc. The
users of the database normally don't interact with the data
dictionary, it is only handled by the database administrators.
Example of Data Dictionary
 Decision Trees

• Decision trees are a method for defining complex relationships by

describing decisions and avoiding the problems in communication. A
decision tree is a diagram that shows alternative actions and conditions
within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.
• Decision trees depict the relationship of each condition and their
permissible actions. A square node indicates an action and a circle
indicates a condition. It forces analysts to consider the sequence of
decisions and identifies the actual decision that must be made.
• The major limitation of a decision tree is that it lacks
information in its format to describe what other
combinations of conditions you can take for testing. It
is a single representation of the relationships between
conditions and actions.
• For example, refer the following decision tree
 Decision Tables

• Decision tables are methods of describing the complex logical relationship

in a precise manner which is easily understandable.
• It is useful in situations where the resulting actions depend on the
occurrence of one or several combinations of independent conditions.
• It is a matrix containing row or columns for defining a problem and the
actions.
 Components of a Decision Table
• Condition Stub − It is in the upper left quadrant which lists all the condition to be
checked.
• Action Stub − It is in the lower left quadrant which outlines all the action to be carried
out to meet such condition.
• Condition Entry − It is in upper right quadrant which provides answers to questions
asked in condition stub quadrant.
• Action Entry − It is in lower right quadrant which indicates the appropriate action
resulting from the answers to the conditions in the condition entry quadrant.
• The entries in decision table are given by Decision Rules which define the relationships
between combinations of conditions and courses of action. In rules section,
• Y shows the existence of a condition.
• N represents the condition, which is not satisfied.
• A blank - against action states it is to be ignored.
• X (or a check mark will do) against action states it is to be carried out.
• For example, refer the following table
 CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

Advance payment
Y N N N
made

Purchase amount =
- Y Y N
Rs 10,000/-

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -

Give no discount - - X X
 Structured English

• Structure English is derived from structured programming language which

gives more understandable and precise description of process. It is based on
procedural logic that uses construction and imperative sentences designed to
perform operation for action.
• It is best used when sequences and loops in a program must be considered
and the problem needs sequences of actions with decisions.
• It does not have strict syntax rule. It expresses all logic in terms of sequential
decision structures and iterations.
• For example, see the following sequence of actions
if customer pays advance then Give 5% Discount
else if
purchase amount >=10,000
then
if
the customer is a regular customer then Give 5%
Discount
else No Discount
end if
else
No Discount end if
end if
Flow Chart
• A flowchart is a visual representation of the sequence of steps and
decisions needed to perform a process. Each step in the sequence is
noted within a diagram shape. Steps are linked by connecting lines
and directional arrows. This allows anyone to view the flowchart and
logically follow the process from beginning to end.
Flow Chart Symbols
An example
 Guidelines for Selecting Appropriate Tools

• Use the following guidelines for selecting the most appropriate tool that
would suit your requirements −
• Use DFD at high or low level analysis for providing good system
documentations.
• Use data dictionary to simplify the structure for meeting the data
requirement of the system.
• Use structured English if there are many loops and actions and if they are
complex.
• Use decision tables when there are a large number of conditions to check
and logic is complex.
• Use decision trees when sequencing of conditions is important and if there
are few conditions to be tested.
THANK YOU