Compiled by: Mesfin Fikre (PhD) (mesfin.fikre@aau.edu.

et)

Addis Ababa University

Department of Management

Systems Analysis and Design (MGMT 461), Cr Hr: 3

Prerequisite: Management Information Systems

Course overview:

System Analysis and Design is a study of the systematic analysis, design, and implementation of software
systems with special emphasis on the processes and skills used in the System Development Life Cycle.

Course Objective:

The objective is to impart an understanding of the role of the system analyst in determining and
documenting user requirements, developing and documenting preliminary designs for systems that meet
those requirements, and assisting in project management for the implementation of the design.

A) Knowledge Outcomes
• Learn the concepts of System Development techniques
• Develop an understanding of all the steps of the System Development Life Cycle and the
procedures, skills and tools that comprise them

B) Skill Outcomes

• Practice and enhance team-based presentation skills through the demonstrating of

outcomes of their system development projects
• Improve analysis skill to model business processes and extract requirements for IT
projects
Delivery Methods:
- Class room lectures
Reading Materials:
- Systems Analysis and Design in a changing world 5th edition by John Satzinger, Robert Jackson,
and Stephen Burd,
Evaluation methods:
- Assignment (group)...............................................30 points
- Case Analysis (individual) ....................................20 points
- Final Exam..............................................................50 points

i
Compiled by: Mesfin Fikre (PhD) (mesfin.fikre@aau.edu.et)

Chapter 1: Fundamentals of Systems Analysis and Design........................................................................... 1

1.1. Understanding System Analysis and Design ................................................................................. 1

1.2. The Analyst as Problem Solver ...................................................................................................... 1

1.3. Systems that Solve Business Problems ......................................................................................... 2

1.4. Types of IS ..................................................................................................................................... 4

1.5. Required Skills for System Analysts .............................................................................................. 4

1.6. The Analyst’s Role in Strategic Planning ....................................................................................... 5

Chapter 2: System Development Approaches .............................................................................................. 6

2.1. The major phases of SDLC ............................................................................................................. 6

2.2. Methodologies: .................................................................................................................................. 7

2.3. IS Problem Identification ................................................................................................................. 12

2.4. IS development teams and roles ..................................................................................................... 12

Chapter 3: Analyst as Project Manager....................................................................................................... 13

3.1. IS Project Management (PMP certification) ............................................................................... 13

3.2. IS Project Cost estimations ......................................................................................................... 17

3.3. IS Project risks ............................................................................................................................. 18

3.4. Project Chart: .............................................................................................................................. 18

Chapter 4: IS Requirement Identification and Validation ........................................................................... 22

4.1. What are requirements? ............................................................................................................. 22

4.2. Fundamental types of requirements: ......................................................................................... 23

4.3. STAKEHOLDERS—THE SOURCE OF SYSTEM REQUIREMENTS ..................................................... 24

4.4. Techniques for Information Gathering ....................................................................................... 25

4.5. Requirements Analysis Template .................................................................................................... 26

4.6. Requirements Validation ............................................................................................................ 31

ii
 Chapter 1: Fundamentals of Systems Analysis
and Design
1.1. Understanding System Analysis and Design

Systems Analysis and Design (definition):

 It is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand
the structure, policies, and operations of an organization, and recommend solutions that enable the
organization to achieve its goals (IIBA, 2008).
 Systems analysis is really more about understanding the business and its goals and strategies, defining
requirements for information systems that support those goals and strategies, and supporting the
business. It’s not at all what most college students imagine it to be.

The key to successful system development is thorough systems analysis and design to understand what the
business requires from the information system.
 Systems analysis means understanding and specifying in detail what the information system should
accomplish.
 Systems design means specifying in detail how the many components of the information system should
be physically implemented.
This course is about systems analysis and design techniques used by a systems analyst, a business professional
who develops information systems.

1.2. The Analyst as Problem Solver

A systems analyst is often thought of as a problem solver rather than a programmer. So, what kinds of problems
does an analyst typically solve?
Example problems analysts solve includes:
• How to process customers order made during none working hrs.
• How to minimize inventories and stocks to avoid related costs and yet avoid or minimize
problem of stock outs.
• How to collect and analyze information on customer behavior that marketing can put to use.
• Employees demand more flexibility in their benefits programs, and management wants to build
loyalty and morale. So, the problem is how to process transactions for flexible health plans,
wellness programs, employee investment options, retirement accounts, and other benefit
programs offered to employees.
1
As you can understand from the above cases, solving each of these problems involves more than
programming.

Analysts Approach to problem solving

Example case???

- Utility bill payment

- Course scheduling and frequent changes

1.3. Systems that Solve Business Problems

We described the systems analyst as a business problem solver. We said that the solution to the problem is
usually an information system. Before we talk about how you learn to be a systems analyst, let’s quickly review
some information systems concepts.
System concepts
A system is an organized collection of people, machines, procedures, documents, data, or any other entities such
that they interact with each other as well as with the environment to reach a predefined goal.
Example of a system includes:
- Biological systems, physical systems, and organizational systems
Information System: The information system of an organization may be defined as a system that serves to

2
provide information within the organization when & where it is needed in any managerial level. It is a collection
of interrelated components that collect, process, store and provide as output the information needed to complete
business tasks (e.g. payroll system).Example(s):
 A payroll system, for example, collects information on employees and their work, processes and stores
that information, and then produces paychecks or cash and payroll reports (among other things) for the
organization.
 A sales management system collects information about customers, sales, products, and inventory levels.
It enables customers and sales personnel to create and modify sales orders, select payment methods, and
output sales information for tasks such as generating financial statements, computing bonuses, and
scheduling production.

A subsystem is a system which is an element of a larger system. The large system is called "Super System". One
super system can have many subsystems.
Example
- Finance systems can have subsystems like: A/R
system, A/P system, doubtful accounts system etc
- See the different sub systems of Customers
management System

Characteristics of Information System

All information Systems have the following characteristics
 Structure: a system must be organized in a way that gives it structure. The components of the system
must work together in some preplanned way, so the system can operate in an orderly manner.
Example: A department store's financial system is structured to reflect the interaction of the pricing,
purchasing, inventory, and billing activities.
 Interdependence: In order for a system to function, it must receive input from other systems. The system
processes the input to produce output, which is used as required input for still another system. In other
words, a system interacts with the environment in which it operates.

3
 Example: A purchasing department might receive requests for material from the factory and then
generate purchase orders to be routed to vendors.
 Functional decomposition: dividing a system into components based on subsystems (which are in turn
further divided into subsystems)
Example: A hospital may have separate subsystems for the pharmacy, the laboratory, and the patient
medical records. In addition, each of these subsystems may have subsystems of its own.

1.4. Types of IS

Because organizations perform many different types of activities, many types of information systems exist—all
of which can innovative and use the latest technologies. Example types of IS

1.5. Required Skills for System Analysts

1. Technical Knowledge/ skills

• Computers and how they work
• File, database, and storage hardware and software
• Input and output hardware and software
• Computer networks and protocols
• Programming languages, operating systems, and
utilities
• Communication and collaboration technology such
as digital telephones, videoconferencing,
and Web-based doct mgt systems

4
 2. Business kge/ skill
• How are organizations structured?
• How are organizations managed?
• What type of work goes on in organizations
(finance, manufacturing, marketing, customer service,
and so on)?
3. People kge/ skill

1.6. The Analyst’s Role in Strategic Planning

Information systems strategic plan: The plan defining the technology and applications that the information
systems function needs to support the organization’s strategic plan. So System Analysts role is to help CEOs on:
1. Application architecture plan: a description of the integrated information systems that the
organization needs to carry out its business functions
2. Technology architecture plan: a description of the hardware, software, and communications
networks required to implement planned information systems

Review Questions

1. Give an example of a business problem that can be solved with IS

2. What are the main steps followed by system analysts when solving a problem?
3. Define system, and
4. Information system.
5. What types of information systems are found in most organizations?
6. What are some of the things an analyst needs to understand about businesses and organizations in general?
7. What are some of the things an analyst needs to understand about people?
8. How might an analyst become involved with executives and strategic planning relatively early in his career?

Think Critically

- Describe a business problem your university has that you would like to see solved. How can information
technology help solve it?
5
 - Explain why an analyst needs to understand how people think, how they learn, how they react to change,
how they communicate, and how they work.
- How might working for a consulting firm for a variety of companies make it difficult for the consultant to
understand the business problem a particular company faces? What might be easier for the consultant to
understand about a business problem?
- Explain why a strategic information systems planning project must involve people outside the
information systems department. Why would a consulting firm be called in to help organize the project?

Chapter 2: System Development Approaches

After reading this chapter, you should be able to:
- Explain the purpose and various phases of the traditional systems development life cycle (SDLC)

2.1. The major phases of SDLC

The initial activities of the SDLC, whose objective is to identify the scope of the new system
A.
Planning Phase and plan the project. Key deliverables under this stage includes:
1. Problem Statement/Objective
- Identify where you are now and where you want to get by performing this project.
- Ask many different questions to a variety of people in order to get a good idea of
what they have in mind.
2. Feasibility Study
- You look at whether to move on to the analysis phase or not.
- Here we have three aspects:-
A. Technically feasible :
 With the technology we have, can we get the project done?
Can we obtain equipment and personal to develop, install and operate the system?

6
 B. Economically feasible :
 Determine whether the time and money are available to develop the system
It includes the estimated cost to purchase Hardware & Software.
C. Operational Feasibility
 Determine if the human resources are available to operate the system once it has
been installed.
 Users that do not want a new system may prevent it from becoming operationally
feasible.
B The analyst studies the organization’s current procedures and the information systems used
Analysis to perform tasks such as payroll. Analysis has several sub phases:-
Phase 1. Determining the requirements of the system (it should be careful study)
2. Study these requirements and structure them according to their interrelationships and
eliminating any redundancies.
3. Generate alternative initial designs to match the requirements.
The output of the analysis phase is a description of the alternative solution recommended by
the analysis team

C. Design Activities D. Implementation and Operation

Design the user and system interfaces 1. Coding

Design and integrate the database 2. Testing
Designing forms and reports 3. Installation
4. Initial user training programs

2.2. Methodologies:
They are comprehensive guidelines to follow for completing every activity in the systems development life cycle,
including specific models, tools, and techniques. The most common methodologies are: Waterfall model, Spiral
model, Iterative development, and prototyping.

Waterfall Model: It is also referred to as a linear-sequential life cycle model. It is very simple to understand and
use. In a waterfall model, each phase must be completed before the next phase can begin and there is no
overlapping in the phases.
Advantages of Waterfall model Disadvantages of waterfall model When to use waterfall model
- Simple and easy to - You cannot go back a step, - Requirements are well
understand and use if the design phase has known, clear and fixed
- Easy to manage due to the gone wrong - Technology is well

7
 rigidity of the model
- Phases are processed and
completed one at a time
- High amount of risk and understood
uncertainty - There are no ambiguous
- Not good for complex requirements
projects - The project is short
- Not good for projects with
changing requirements

Prototyping model: It is a preliminary working model showing some aspect of a larger system
• 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.
• Ultimately, the product reaches a satisfactory completion.
• Developers respond to feedback and add additional parts as application evolves into an acceptable
product
• A good approach for small to medium-sized projects.
• Very important is customer involvement
Advantages Disadvantages
– Shorter development process – Less flexibility and adaptability to changes
– Save development time. and additions

8
 – Better fit to customer requirements and reduced – Reduced preparation for unexpected instances
risk of project failure of failure
– Easier and faster user comprehension of new
system

Spiral Model: An adaptive SDLC approach that cycles over and over again through development activities until
a project is complete
• Uses an iterative approach to address each phases in development by obtaining customer comments and
change, risk analysis, and resolution.
• Within a cycle, specific engineering (design, development, etc.) can take place using any other models,
like SDLC, prototyping,
• 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
• Especially designed for those with higher chances of failure.
• Is an iterative approach

Advantages Disadvantages

Iteration: system development process in which work activities—analysis, design, implementation—are done
once, then again, and yet again on different system components; they are repeated until the system is closer to
what is ultimately needed

9
 Advantage Disadvantage

Questions
1. What are the five phases of the traditional SDLC?
2. What characteristics of a project call for waterfall methodology to the SDLC?
3. What characteristics of a project call for Spiral methodology to the SDLC?
3. What is the objective of each phase of the SDLC? Describe briefly.

THINKING CRITICALLY
1. Write a one-page paper that distinguishes among the fundamental purposes of the analysis phase, the design
phase, and the implementation phase.
2. Describe a system project that might have three subsystems. Discuss how spiral methodology might be used
for the project.
2. Visit the Web sites for a few leading information systems consulting firms. Try to find information about the
approach they use to develop systems. Are their SDLCs described? Do their sites mention any tools?

CASE STUDIES:
10
 1. FACTORY SYSTEM DEVELOPMENT PROJECT
Sally Jones is assigned to manage a new system development project that will automate some of the work being
done in her company’s factory. It is fairly clear what is needed: to automate the tracking of the work in progress
and the finished goods inventory.

What is less clear is the impact of any automated system on the factory workers. Sally has several concerns: How
might a new system affect the workers? Will they need a lot of training? Will working with a new system slow
down their work or interfere with the way they now work? How receptive will the workers be? At the same time,
Sally recognizes that the factory workers themselves might have some good ideas about what will work and what
won’t, especially concerning (1) which technology is more likely to survive in the factory environment and (2)
what sort of user interface will work best for the workers. Sally doesn’t know much about factory operations,
although she does understand inventory accounting.

1. Is the proposed system an accounting system? A factory operations system? Or both?

2. Which life cycle variations might be appropriate for Sally to consider using?
3. Which activities of analysis and of design discussed in this chapter should

2. Comparing System development models

Assume that management of an organization has placed a high priority on developing a Web-based application to
connect clients with its branch offices. Before the Web component can be implemented, though, the organization
must automate more of the basic information it handles about patients, health-care facilities, and prescriptions.
Next, the organization must develop an initial informational Web site, which will ultimately evolve into an
extranet through which it will share information and link its processes closely with its clients and suppliers. One
significant requirement of the extranet is compliance with the regulatory frameworks, for security and privacy of
patient data/ information.

After basic processes are automated and the extranet Web site is in place, the system will enable clients to add
patient information and place orders through the Web. The system should streamline processes and should also
provide useful query and patient management capabilities to distinguish the company from its competitors.
o One approach to system development that the organization might take is to start one large project
that uses a waterfall model to the SDLC to thoroughly plan the project, analyze all requirements
in detail, design every component, and then implement the entire system, with all phases
completed sequentially. What are some of the risks of taking this approach? What planning and
management difficulties would this approach entail?
o Another approach to system development might be to start with the first required component and
get it working. Later, other projects could be undertaken to work on the other identified
11
 capabilities. What are some of the risks of taking this approach? What planning and management
difficulties would this approach entail?
o A third approach to system development might be to define one large project that will use an
iterative approach to the SDLC. Briefly describe what you would include in each iteration.
o Describe how incremental development might apply to this project. How would an iterative
approach decrease project risks compared with the first approach? How might it decrease risks
compared with the second approach? What are some risks the iterative approach might add to the
project?

2.3. IS Problem Identification

Information system problems can be identified in many ways. But there are two ways (based on ch/c of useful
information and Based on (PIECES framework). The following section describes these techniques.

Based on feature of Useful information

In order to detect IS problems, we can use the characteristic feature of useful information, like relevance,
completeness, correctness, efficiency, usability, security, timeliness, economy, and reliability.
Relevance problems: Look at the following symptoms:
- Many lengthy reports, Reports that are not used by persons receiving them
- Lack of user complaints, when reports are not produced and distributed
Completeness problem: Look at the following symptoms:
- When forms are incomplete
- Auditor analysis of data entry errors shows a high incidence of incomplete fields
Correctness problem: Look if there are many transactions with errors, and how many of the errors are critical
Security:
- When information is accessed by unauthorized person. Security problem is usually discovered after
security has been breached. Thus security audit must be made periodically but irregularly. So that
potential security problems are identified before they become a reality.
Timeliness: look at
- How quickly the information is updated
- How fast is the system to respond to users request
2.4. IS development teams
Efficiency: Look at
and roles
- throughput (the number of error free transactions processed through the system per unit of of time)
- Errorless transactions per hr - Users

Reliability: an important indicator of IS deterioration is lack of -reliability.

Managers So look at
- When computer is down most of the cases - System Analysts (roles and skill sets)

- When workstations response time is increasing - System Designers

Usability: When the system is difficult to use - Programmers

12
 - Long training hrs, High error rate
- Increased users complain
- Increased workers absenteeism, High turnover

Based on (PIECES framework)

- Problems related to performance of the system
- Problems related to Information (lack of relevant information and or data)
- Problem related to economics (cost vs benefits of the system)
- Problem related to control and security(too little or too much control)
- Problem related to efficiency (data is redundantly copied or entered)
Finally, prepare preliminary report about the problem (source of the problem, nature of the problem, detailed
analysis about the problem, and recommendation)

Chapter 3: Analyst as Project Manager

After reading this chapter, you should be able to:
- Explain the elements of project management and the responsibilities of a project manager
- Explain project initiation and the project planning activities of the SDLC
- Describe how the scope of the new system is determined
- Develop a project schedule using Gantt charts
- Develop a cost/benefit analysis and assess the feasibility of a proposed project
- Discuss how to staff and launch a project

3.1. IS Project Management (PMP certification)

This section focus to teach the specifics of how an information system is developed in an organization.

How IS projects are initiated (identified). There are different reasons, why new IS is initiated:
- To address some problems (IS problems discussed above and see if there are too many performance
errors, work is completed too slowly, work is done incompletely, work is not done at all), observe
behaviour of employees (high absenteeism, high job dissatisfaction, high job turnover),listen to external
feedbacks from vendors and service providers (complaints, suggestion for improvements), customers loss
of sales, and suppliers for lower sales
- To take advantage of some opportunities
- Government directives etc

Project management body of knowledge (as documented by PMI). The skill and kge sets needed for efficient
13
Project management are:
• Project Scope Management. Defining and controlling the functions that are to be included in the
system, as well as the scope of the work to be done by the project team
• Project Time Management. Building a detailed schedule of all project tasks and then monitoring the
progress of the project against defined milestones
• Project Cost Management. Calculating the initial cost/benefit analysis and its later updates and
monitoring expenditures as the project progresses
• Project Quality Management. Establishing a comprehensive plan for ensuring quality, which includes
quality-control activities for every phase of the project
• Project Human Resource Management. Recruiting and hiring project team members; training,
motivating, and team building; and implementing related activities to ensure a happy, productive team
• Project Communications Management. Identifying all stakeholders and the key communications to
each; also establishing all communications mechanisms and schedules
• Project Risk Management. Identifying and reviewing throughout the project all potential risks for
failure and developing plans to reduce these risks
• Project Procurement Management. Developing requests for proposals, evaluating bids, writing
contracts, and then monitoring vendor performance
• Project Integration Management. Integrating all the other knowledge areas into one seamless whole

Project planning and key activities (Activities required for project planning) includes:
Project planning Key Questions
Activities
Define the Do we understand what we are supposed to be working on?: Three issues:
problem Business benefits: If the target is ill defined, then all subsequent activities will lack
focus. As pointed out earlier, one of the primary causes of project failure is an unclear
objective. This can be done by reviewing the strategic plan, re-consulting departments
that requested, review government policy, re-evaluate business processes and identify the
business benefits of the new system etc.

System Scope documentation: Then identify, at a high level, the expected capabilities of
the new system. The objective is to define the scope of the problem in terms of the
requirements of the information system that can solve the problem

Proof of concept: New solutions, particularly those based on new technology, may not
be well accepted or well understood. In that situation, the project team can build a proof
of concept prototype to illustrate that a solution is possible and feasible.

14
 Typical system scope document need to show:
- Brief problem description
- Brief business benefits
- Brief system capabilities
Scope can also be indicated (communicated by using context DFD), see the following
diagram. Based on the diagram, one can easily understand the scope and capability of a
system called (customer support system)

Produce project Can the project be completed on time given available resources
Schedule During project planning, it may not be possible to schedule every task in the entire project
because it is too early to know all of the tasks that will be necessary. However, one of the
requirements of project planning is to provide estimates of the time to complete the
project and the total cost of the project.

The development of a project schedule is divided into three main steps:

• Develop a work breakdown structure. Often a project needs to be broken down into
smaller tasks or activities. These tasks together make up a work breakdown
structure (WBS)
- Each task or activity contains one deliverable, or tangible outcome, from the
activity
- Each task can be assigned to a single individual or a single group
- Each task has a responsible person monitoring and controlling performance.
For example: Work breakdown structure for planning activities can look like the

15
 following
1.Project planning
1.1 Define the problem
- Meet with users
- Determine scopes
- Write problem description
- Identify business benefits
- Identify system capabilities
- Develop context diagram
1.2 Produce the project schedule
- Develop WBS
- Estimate duration
- Determine sequences
- Develop Gantt charts
1.3 Confirm project feasibility
- Identify intangible costs/ benefits
- Estimate tangible benefits
- Calculate costs/ benefits
- Organizational feasibility
- Technical feasibility
- Evaluate resource availability
- Risk Analysis
1.4 Staff the project
- Develop resource plan
- Procure project team
- Conduct training
1.5 Launch the project
- Make executive presentations
Conduct kickoff meetings

• Build a schedule using a Gantt chart.

PERT/CPM chart: a technique for scheduling a project based on individual tasks or
activities
critical path: a sequence of tasks that cannot be delayed without causing the project to be
completed late
• Develop resource requirements and the staffing plan.
Confirm Project is Is it still feasible to begin working on this project
feasibility Information system projects do not have a very good track record. Even well-planned
projects sometimes go awry and get into trouble.
• Assess the risk to the project (risk management).
• Determine the organizational and cultural feasibility.
• Evaluate the technological feasibility
• Determine the schedule feasibility.
• Assess the resource feasibility.
• Determine the economic feasibility.
Staff the project Are resources available, trained, and ready to start? The staffing activity consists of five
tasks:
• Develop a resource plan for the project.
• Identify and request specific technical staff.

16
 • Identify and request specific user staff.
Launch the project Are we ready to start the project?

3.2. IS Project Cost estimations

(Estimate costs for each activity in the work breakdown structure)

- Causes for incorrect estimation
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.500&rep=rep1&type=pdf )

- When to make the estimation (based on SDLC)

17
 3.3. IS Project risks

Project failures may be prevented by: Training, Experience, Learning why other projects have failed) OR
Fishbone diagram that systematically lists all of the possible problems that can occur. A fishbone diagram, also
called a cause and effect diagram or Ishikawa diagram, is a visualization tool for categorizing the potential
causes of a problem in order to identify its root causes.
Dr. Kaoru Ishikawa, a Japanese quality control expert, is credited with inventing the fishbone diagram to help
employees avoid solutions that merely address the symptoms of a much larger problem.

A fishbone diagram is useful in brainstorming sessions to focus conversation. After the group has brainstormed
all the possible causes for a problem, the facilitator helps the group to rate the potential causes according to their
level of importance and diagram a hierarchy. The design of the diagram looks much like a skeleton of a fish.
Fishbone diagrams are typically worked right to left, with each large "bone" of the fish branching out to include
smaller bones containing more detail.

You need to identify the root causes for issues that expose your project to a risk. Presenting a visual
representation of the risk of the project might help a lot. And then encourage your development team to organize
the risks into different categories and brainstorming different scenarios where the project may not be successful.
Key benefits of this tool (diagram) are:

 Visual risk analysis diagram,

 Identify root causes to the issue,

 Helps with brainstorming

 Break risks down into categories

3.4. Project Chart:

Describes in a written document what the expected results of the systems project are and the time frame for
18
delivery. It clarifies questions like:

• What does the user expect of the project? What is the scope of the project?
• What analysis methods will the analyst use to interact with users?
• Who are the key participants? What are the project deliverables?
• Who will evaluate the system and how will they evaluate it?
• What is the estimated project timeline? Who will train the users? Who will maintain the system?
Sample Project Chart (template chart)
1. Project Identification
- Organization….Addis Ababa University
- Name of the project…..Employee Management Information System
- Description……….Requirement gathering & validation, Analysis, Design, develop & implement the
system
- Sponsor……AAU
- Project Manager…..Mesfin

2. Business Reasons for Project

- Improve government’s ability to attract and recruit high quality candidates and compete regionally
- Respond to the poor employee management in the university
- Is an element of the universities strategic plan
- Is element of performance management
- Is element of national paperless plan and operation (green economy)

3. Project Objectives
– Overall, to create a conducive working environment that includes regular recognition and
feedback to employees
- To recognize employees for their high quality services and contributions
- To reinforce link between employee performance and departmental goals
- To do in such a way that reduces operational costs and increases efficiency

4. Project Scope
- To identify requirements for the system
- To validate requirements
- To design and develop the system
- To provide a system which allows managers to track and update employees’ recognition information,
educational achievement information, change in qualification status etc

19
 5. Key project deliverables
- Promotion and recognition framework
- Project plan
- Communication plan and
- Implementation plan
- Employee promotion and performance evaluation system
- User training
- Documentation about the system

6. Milestone dates
- Develop promotion or recognition framework…….Date??????
- Networking/information event for all departments….Date?????
- Develop the System……………………………………..date????
- User training…………………………………………..Date ??????
- Deployment of the system

7. Risks
- Availability of resources
- Public support and perceptions
- Implementation and timeliness

8. Success criteria
- Increase awareness and consistent use of the system
- Create a healthier and more supportive working environment
- Improve job satisfaction and employee engagement

9. Critical success factors

- Support from management, senior leaders, employees
- Effective communication
- Participation of system development team

10. Signoff
- Project Manager………………………………………Date……………….

Questions
20
 1. List and explain the activities of project planning.
2. List the major reasons projects fail.
3. What is meant by the critical path?
4. What is a project chart?
5. What is the purpose of a system context diagram?
6. Describe the major knowledge areas of project management.
Thinking Critically

Given the following narrative, make a list of expected business benefits:

Especially for You Jewelers is a small jewelry company in a college town. Over the last couple of years,
Especially for You have experienced a tremendous increase in its business. However, its financial performance
has not kept pace with its growth. The current system, which is partially manual and partially automated, does not
track accounts receivables sufficiently, and Especially for You is having difficulty determining why the
receivables are so high. In addition, Especially for You run frequent specials to attract customers. It has no idea
whether these specials are profitable or whether the benefit, if there is one, comes from associated sales.
Especially for You also wants to increase repeat sales to existing customers, and thus needs to develop a customer
database. The jewelry company wants to install a new direct sales and accounting system to help solve these
problems.

Given the following narrative, make a list of system capabilities:

The new direct sales and accounting system for Especially for You Jewelers is an important element in the future
growth and success of the jewelry company. The direct sales portion of the system needs to track every sale and
be able to link to the inventory system for cost data to provide a daily profit and loss report. The customer
database needs to be able to produce purchase histories to assist management in preparing special mailings and
special sales to existing customers. Detailed credit balances and aged accounts for each customer would help
solve the problem with the high balance of accounts receivables. Special notice letters and credit history reports
would help management reduce accounts receivable.

Suppose that you work in a dentist’s office and are asked to develop a system to track patient appointments. How
would you start? What would you do first? What kinds of things would you try to find out first? How does your
approach compare with what this chapter has described?

Using information from your organizational behaviour classes or other sources, write a one-page paper on what
kinds of team-building and training activities might be appropriate as the project team is expanded for the
analysis phase.

Go to the CompTIA Web site (www.compTIA.org) and find the requirements for the project manager exam
(CompTIA Project+). Write a one-page summary of the expertise and knowledge required to pass the exam.
21
Assignment on the above questions

Chapter 4: IS Requirement Identification and

Validation
After reading this chapter, you should be able to:
- Describe the activities of systems analysis
- Explain the difference between functional and nonfunctional system requirements
- Identify and understand the different types of users who will be involved in investigating system
requirements
- Describe the kind of information that is required to model system requirements
- Determine system requirements through review of documentation, interviews, observation, prototypes,
questionnaires, joint application design sessions, and vendor research
- Discuss the need for validation of system requirements to ensure accuracy and completeness and the use
of a structured walkthrough

Requirement Gathering: This is the most challenging task in Systems analysis and design tasks. The single
biggest challenge in Systems Analysis and design is communicating what the customer wants in a manner that the
developer can deliver.

4.1. What are requirements?

22
Requirements are the foundation upon which information systems are built and, just like a building, if the
foundation is not solid, the building will not stand. Fundamentally, a requirement is how we communicate what
the builders (or buyers) of the solution need to build (or buy). This gets us fully into the world of human
communication with all of its misunderstandings, misinterpretations, and misrepresentations. Finally, what
requirements are depends to some degree on the Software Development Methodology (SDM) that your
organization uses and where in the development life cycle you are.

4.2. Fundamental types of requirements:

System requirements: are all of the capabilities and constraints that the new system must meet. Generally
analysts divide system requirements into two categories: functional and nonfunctional requirements.

Functional requirement: a system requirement that describes an activity or process that the system must
perform. For example, if you are developing a payroll system, the required business uses might include functions
such as ―write paychecks,‖ ―calculate commission amounts,‖ ―calculate payroll taxes,‖ ―maintain employee-
dependent information,‖ and ―report year-end tax deductions.
Nonfunctional requirement: characteristics of the system other than activities it must perform or support, such
as technology, performance, usability, reliability, and security. There are many different types of nonfunctional
requirements, including the following:
Technical requirements describe operational characteristics related to the environment, hardware, and software
of the organization. For example, the client components of a new system might be required to operate on portable
and desktop PCs running the Windows operating system and using Internet Explorer. The server components
might have to be written in Java.

Performance requirements describe operational characteristics related to measures of workload, such as

throughput and response time. For example, the client portion of a system might be required to have one-half-
second response time on all screens, and the server components might need to support 100 simultaneous client
sessions (with the same response time).

Usability requirements describe operational characteristics related to users, such as the user interface, related
work procedures, online help, and documentation. For example, a Web-based interface might be required to
follow organization-wide graphic design guidelines, such as menu placement and format, color schemes, use of
the organization’s logo, and required legal disclaimers.

Reliability requirements describe the dependability of a system—how often a system exhibits behaviors such as
service outages and incorrect processing and how it detects and recovers from those problems. Reliability
requirements are sometimes considered a subset of performance requirements.
23
Security requirements describe which users can perform what system functions under what conditions. For
example, access to certain system outputs might be limited to managers at a certain level or employees of a
specific department. Some access might be authorized from home and others only from within the organization’s
local network. Security requirements can also apply to areas such as network communications and data storage.
For example, an organization might require encryption of all data transmitted over the Internet and control of all
database server access through use of a username and password.

4.3. STAKEHOLDERS—THE SOURCE OF SYSTEM REQUIREMENTS

Your primary source of information for system requirements is the various stakeholders of the new system.
Stakeholders are all people who have an interest in the successful implementation of the system.
Business Users: Business users are the people who
use the system to perform the day-to-day operations
of an organization. We often call these operations
transactions. A transaction is a piece of work done
in an organization, such as ―enter an order.‖ Business
users provide information about the daily operations
of the business and ways the system must support
them.

Information Users: An information user is a person

who needs current information from the system. This
person might be an operational user or someone else.
In some cases, a business might want to make
Executive Users information directly available to customers. However,
The top executives of an organization are interested in an information user may not be allowed to enter
strategic issues, as well as the daily issues just information on business transactions, just to view
described. They typically want information from a specific information. An information user, then,
system so that they can compare overall provides an analyst with insight about what kinds of
improvements in resource utilization. They might information should be available daily, weekly,
want the system to interface with other systems to monthly, and annually, and about what format is most
provide strategic information on trends and directions convenient.
of the industry and the business.

24
Management Users
Managers are responsible for seeing that the company is performing its daily procedures efficiently and
effectively. Consequently, they need statistics and summary information from a system. Management will help an
analyst answer the following types of questions:
• What kinds of reports must the system produce?
• What kind of performance statistics must the system maintain?
• What kind of volume information must the system keep, and what volumes of transactions must the new system
support?
• Are the controls in the system adequate to prevent errors and fraud?
• How many requests for information will be made and how often?
External Users
More and more systems today allow external entities to have direct access to the system. Customers may access
the system directly through the Internet. Suppliers may have access to a system to check inventory levels and to
initiate billing transactions. These users are more difficult to identify and access because they are not regular
members of the organization. However, today they belong to an important group that must be considered in
system development.
Client Stakeholders: In many cases, the client is the same group as the executive users.

4.4. Techniques for Information Gathering

QUESTION THEMES
The first questions that new systems analysts ask are, ―What kind of information do I need to collect? What is a
requirement?‖ Basically, you want to obtain information that will enable you to build the logical model of the
25
new business system. Three major themes should guide you as you pursue your investigation.

Theme Questions to users

What are the business Operations and processes What do U do?
How should those operations be performed? How do u do it? What steps do you follow?
What information is needed to perform those What information do you use? What forms or reports
operations do you use?
We can also add prototyping and Joint application design into the above list.

4.5. Requirements Analysis Template

1.0 Purpose: Use this space to summarise the purpose of this document to its intended recipients.

Current system: This section, describes the current state of affairs. If the new system will replace an
existing system. It high lights the functionality and the problems of the current system.

Proposed System: This section highlights the proposed system functionality and how it solves problems of
existing system.

1.1 Intended Audience

Describe your intended audience here.

[Generally, the main intended audience for this document are the business owners of the
proposed system. This content should be tailored to their needs. They must be able to verify that
their business requirements have been documented here; completely, accurately and
unambiguously.]

1.2 Project Background

Describe the background and history of the project here.

[This sets the business requirements in context and may explain any scope limitations agreed at
business case approval stage].

1.3 Business Goals/Objectives to be achieved

Describe the major goals/objectives to be achieved with the implementation of the business

26
requirements.

[This should link in with the organisation’s strategic objectives as laid out in the strategic plan and
summarised in the business case].

1.4 Benefits/Rationale

Use this section to describe the desired benefits to be achieved and the justification for the project.

[What benefits will the new system offer, if implemented?]

1.5 Stakeholders

Adapt the table below to reflect your organisation and project.

[Stakeholders are the individuals or groups who have a vested interest in this project (system) and
whose interests need to be considered throughout. This section lists the Stakeholders of the Project
for which these Business requirements are documented.]

Stakeholder Group Role

Chief Executive Champions need for step change, Provides visible sponsorship

IT groups May be responsible for business intelligence but will also be concerned with
data availability, definition, control and accessibility as well as concerned re
software and hardware needs.

Data providers Projects need raw data and without support it may not be provided.

Performance Data needs to be interpreted and often the commentators are a separate group
commentators from the data providers.

Divisional or business Will want consistency between their own reporting and any consolidated
unit heads reporting.

Head office departments Often have interest in ensuring common data definitions, accounting
methodologies and software choices.

27
System end Users

System Project
Managers

1.6 Dependencies on existing systems

[Describe the dependencies between the new system project and existing applications/systems].

1.7 Assumptions

[Describe the major assumptions that were made prior to or during the business requirements
gathering and documentation].

2.0 Requirements scope

Outline what business functionality is in scope and out of scope for implementation.

In Scope

List the use cases/business functions that are in scope.

Provide a brief description (2-3 lines) for each of these use case/business functions.

Out of Scope

List requirements that are out of scope – this is a key aspect, particularly when using outside
parties to configure the software.

3.0 Functional requirements

[Describe the functional requirements of the project here].

[Functional requirements define how the new system should function from the end-user's
perspective. They describe the features and functions with which the end-user will interact directly.
When interpreting and recording requirements, it is important to clearly define and prioritise them,
analyse the impact of change, resolve conflicting issues and analyse feasibility.]

28
Functional requirements should include functions performed by specific screens, outlines of work-
flows performed by the system, and other business or compliance requirements the system must
meet. It also consists of different requirement categories:

Regulatory/Compliance Requirements

This involves specifying relevant applicable laws, regulations, policies, and standards that will
affect the operation and performance of the system, as well as any relevant external regulatory
requirements, or constraints imposed by normal business practices. Examples can include:

 The database will have a functional audit trail.

 The system will limit access to un authorized users.

 The spreadsheet can secure data with electronic signatures.

Security Requirements (example)

 Members of the Data Entry group can enter requests but cannot approve or delete requests.

 Members of the Managers group can enter or approve a request but cannot delete requests.

 Members of the Administrators group cannot enter or approve requests but can delete
requests.

4.0 Non-functional requirements

[Define the operations that must be carried out in the background to keep the product or process
functioning over a period of time and the required service standards].

Examples include:

Usability, Reliability, Performance, Supportability, Implementation, Interface, Packaging, Legal.

5.0 Technical requirements: Capacity and architecture requirements

5.1. Capacity requirements:

[Define the technical issues that must be considered to successfully implement the process or create
the product. This should include data requirements].

29
Specify the initial capacity requirements for the system. An initial estimation can be established using
current data amounts, planned number of users, and estimated number of transactions. Identifies the
highest and lowest estimated number of transactions and processing frequency expected usage
(including any seasonal peaks) for capacity planning for storage and memory requirements for the
application or project. Identifies the highest and lowest estimated number of transactions and
processing frequency expected usage (including any seasonal peaks) for capacity planning for storage
and memory requirements for the application or project.

Architecture requirements:

Specify the data platform, hardware, software, programming languages, tools and operating system
requirements for the application or project.
a. Identify any specialized hardware requirements that must be purchased or upgraded prior
to development, or in support of the implementation, of the application or project.
b. Identify any specialized software requirements that must be purchased or upgraded prior
to development, or in support of the implementation, of the application or project.
c. Identify any programming languages and tools selected for the development of the
application or project.
d. Identify any network/operating system or combination of network/operating systems that
will be used for the development of the application of project.

6.0 Transitional requirements

[Describe the steps needed to implement the new product or process smoothly].

7.0 Interface Requirements

Describe the User and System Interface requirements for the proposed system.

User Interface Requirements

Describe how the users will interact with the system, in particular any manual processes to be carried out
outside of the system.

Also describe the user interface requirements. Include or attach a screen prototype diagram here.

Good requirements are objective and testable. For example:

 Screen A accepts production information, including Lot, Product Number, and Date.

 System B produces the Lab Summary Report.

30
  Twenty users can use System C concurrently without noticeable system delays.

 Screen D can print on-screen data to the printer.

System Interface Requirements

Describe the other systems with which the BPM system will interact, both as inputs and outputs. Outline
any automated control and reconciliation requirements as well.

System User Characteristics

Identify each type of user of the system by function, location, and type of device. Specify the number of users
in each group and the nature of their use of the system

Example: - System must be available on the Internet

- System must be available 24 hours per day

- System must be accessible by mobile devices
- System must be able to accept electronic payments

List and describe what other external systems/business functions are required to be interfaced with the
proposed system from Business Requirements perspective. Example: This system needs to interface with
the CAS in order to receive some input data.

Example:

- System must interface with Commercial Bank of Ethiopia and mobile payment system
- Systems background development frameworks

8.0. System Acceptance Criteria

Specify the general system acceptance criteria specified and agreed upon by the project sponsor and key
stakeholders that will be used to accept the final end product. For example:

 New system must run in parallel with current production system for x months
 3 years of data must be in system (conversion implied) on day one

4.6. Requirements Validation

Now that you have learned about information-gathering techniques and ways to elicit requirements from the
users, you need to make sure that the information you gathered is correct. All too frequently, systems analysts
think they understand what the users need but have failed to capture some very important subtleties about the
business processes. Obviously, correcting such a mistake after the system has been programmed is very
31
expensive. In fact, various studies have indicated that fixing a requirements error later in the development cycle
can cost hundreds of times more than it would have cost to fix during the requirements definition. Requirements
validation is concerned to check the requirements document for consistency, completeness, and accuracy.
Requirements Verification and Validation Requirements Validation
Techniques – Check that the right product is being built
– Simple checks – Ensures that the software being developed (or
– Prototyping changed) will satisfy its stakeholders
– Functional test design – Checks the software requirements
– User manual development specification against stakeholders goals and
– Reviews and inspections requirements
– Model-based (formal) Verification and
Validation

Requirements Traceability Matrix: is a document that links requirements throughout the validation process.
The purpose of the Requirements Traceability Matrix is to ensure that all requirements defined for a system are
tested in the test protocols. The traceability matrix is a tool both for the validation team, to ensure that
requirements are not lost during the validation project, and for auditors, to review the validation documentation.

The requirements traceability matrix is usually developed in concurrence with the initial list of requirements. As
the Design Specifications and Test Protocols are developed, the traceability matrix is updated to include the
updated documents. Ideally, requirements should be traced to the specific test step in the testing protocol in which
they are tested.

The traceability matrix can either reference the requirement identifiers (unique numbers for each requirement) or
the actual requirement itself. In the example shown below, requirements are traced between a Functional
Requirements Specification, Design Specification, and Operational Qualification.

Requirements number(s) Design Specifications Test Cases

The program will have an auto save Each data entry form will prompt user to save data up Test 1,
function, up on exit. on the On Update event procedure. Test 2, ..etc.

Questions
A. What is the difference between functional requirements and nonfunctional requirements?
B. List and describe the three fact-finding themes.
C. What categories of stakeholders should you include in fact-finding?
D. What technique is used to validate user requirements?

32
 E. List and describe the seven information-gathering techniques.
Thinking Critically
1. One of the toughest problems in investigating system requirements is to make sure that they are complete
and comprehensive. What things would you do to ensure that you get all of the right information during
an interview session?
2. What can you do to ensure that you have included all of the right stakeholders on your list of people to
interview? How can you double-check your list?
3. One of the problems you will encounter during your investigation is ―scope creep‖—that is, user requests
for additional features and functions. Scope creep happens because sometimes users have many unsolved
problems and the system investigation may be the first time anybody has listened to their needs. How do
you keep the system from growing and including new functions that should not be part of the system?
4. What would you do if you got conflicting answers for the same procedure from two different people you
interviewed? What would you do if one was a clerical person and the other was the department manager?
Case Studies
Reliable Pharmaceutical Service plans to develop an extranet that enables its client health-care facilities to order
drugs and supplies as if they were ordering from an internal pharmacy. The extranet should enable Reliable’s
suppliers to function as if they were part of Reliable’s internal organization. These views of the final system have
significant implications for defining system requirements and for gathering information about those requirements.
1. What information-gathering methods are most appropriate to learn about requirements from Reliable’s
own management staff and other employees? From client health-care organizations? From suppliers?
2. Should patients in client health-care facilities participate in the information-gathering process? If so, why,
and in what ways should they participate?
3. With respect to gathering information from suppliers and clients, how deeply within those organizations
should systems analysts look when defining requirements? How might Reliable deal with supplier and
client reluctance to provide detailed information about their internal operations?
4. For which user community or communities (internal, supplier, or client) are prototypes likely to be most
beneficial? Why?

Chapter 5: Structuring System Process Requirements

Learning Objectives
- Understand Process modeling of IS by studying examples of data flow diagrams (DFDs).
- Draw data flow diagrams following specific rules and guidelines that lead to accurate and well-
structured process models.
- Decompose data flow diagrams into lower-level diagrams.
- Balance higher-level and lower-level data flow diagrams.
33
- Use data flow diagrams as a tool to support the analysis of information systems.
1. Process Modelling is a graphically represent the processes that capture, manipulate, store, and distribute
data between a system and its environment and among system components.
- It utilize information gathered during requirements determination.
- Processes and data structures are modelled.
2. Deliverables and Outcomes
- Context data flow diagram (DFD).
- Level 0, level 1,…..level N DFDs, with many processes that show system functionalities and data stores.
Note: the lower the DFD level, the detailed it is
3. Definitions and Symbols

34
4. Developing DFDs
A. Context diagram is the first DFD that analysts draw. It is an overview of an organizational system
that shows:
- The system boundaries.
- External entities that interact with the system.
- Major information flows between the entities and the system.
- Note: only one process symbol, and no data stores are shown on context level DFD
Example 1: Context Diagram for restaurant system

Example 2: Context Diagram for student information system

35
 Example 3: Context Diagram for student information system

Example 4: context diagram for pharmacy information system

Insert sale mov. data

Insert sale mov. data
Insert incoming goods data 0
Pharmacy Get sale advice
Pharmacy Define new products Pharmacy
Management Define new products
Manager Get sale advice Employee
System
Define Employees data PMS Insert incoming goods data
statistics
alerts

Questions
- What are the different activities that pharmacy manager want to do with the system?
- What are the tasks/ activities that pharmacy employee wants to do with the system?

36
Other possible context DFD for pharmacy management system

Note: can be seen there is no one best way of drawing the diagram
B. Level-0 diagram is a data flow diagram that represents a system’s major processes, data flows, and
data stores at a high level of detail.
Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive (lower-level)
DFDs.
Example of Level-0 Diagram

37
DFD for Bank

38
Questions Student Management Information System
- Identify the different activities that the entities might want to do through the system
- Hint:
o Login to the system
o Add courses
o Add Teachers
o Add Students
o Search Report
o Add fees

39
 o Edit student details
Questions: Do the same for other context DFDs

5. Data Flow Diagramming Rules

- The following table summarizes the important DFD drawing rules

Completeness
- DFD must include all components necessary for system.
- Each component must be fully described in the project dictionary or CASE repository.
Consistency
- The extent to which information contained on one level of a set of nested DFDs is also included on
other levels

40
 Iterative Development
- Analyst should expect to redraw diagram several times before reaching the closest approximation to
the system being modeled.

Question
What is wrong with the following DFD?

6. Decomposition of DFDs
Functional decomposition is an iterative process of breaking a system description down into finer and
finer detail.
- Creates a set of charts in which one process on a given chart is explained in greater detail on another
chart.
- Continues until no sub process can logically be broken down any further.
- Primitive DFD is the lowest level of a DFD.

41
 - Level-1 diagram results from decomposition of Level-0 diagram.

- Level-n diagram is a DFD diagram that is the result of n nested decompositions from a process on a
level-0 diagram.
Primitive DFDs
- Lowest logical level of decomposition
- Decision has to be made when to stop decomposition
Rules for stopping decomposition
- When each process has been reduced to a single decision, calculation or database operation
- When each data store represents data about a single entity
- When the system user does not care to see any more detail
- When every data flow does not need to be split further to show that data are handled in various ways
7. Balancing DFDs
Conservation Principle: conserve inputs and outputs to a process at the next level of decomposition
Balancing: conservation of inputs and outputs to a data flow diagram process when that process is
decomposed to a lower level
Balanced means:
- Number of inputs to lower level DFD equals number of inputs to associated process of higher-level DFD
- Number of outputs to lower level DFD equals number of outputs to associated process of higher-level
DFD

42
8. Using DFDs as Analysis Tools
Gap Analysis is the process of discovering discrepancies between two or more sets of data flow diagrams
or discrepancies within a single DFD.
- Inefficiencies in a system can often be identified through DFDs.
- Using DFDs in BPR

43
 Chapter 6: Logic Modeling

Learning Objectives
• Use Structured English as a tool for representing steps in logical processes in data flow diagrams
• Use decision tables and decision trees to represent the logic of choice in conditional statements
• Select among Structured English, decision tables, and decision trees for representing processing logic
Logic Modeling
• Data flow diagrams do not show the logic inside the processes
• Logic modeling involves representing internal structure and functionality of processes depicted on a DFD
• Logic modeling can also be used to show when processes on a DFD occur
1. Structured English Modeling Logic
• Structured English is a language and syntax, based on the relative strengths of structured programming and natural
English, for specifying the underlying logic of elementary processes of information processes (on DFDs).
• No specific standards
• Uses a subset of English
• Used for simple logic situation
• Similar to programming language it uses If conditions Case statements Pseudocode

44
2. Decision Table
Policies and Decision Tables
• A policy is a set of rules that governs some process of the business.
• A decision table is a tabular form of presentation that specifies a set of conditions and their
corresponding actions (as required to implement a policy).
Modeling Logic with Decision Tables
• It is a matrix representation of the logic of a decision
• Specifies the possible conditions and the resulting actions
• Best used for complicated decision logic

Modeling Logic with Decision Tables

• Consists of three parts
• Condition stubs: Lists condition relevant to decision
• Action stubs: Actions that result from a given set of conditions
• Rules: Specify which actions are to be followed for a given set of conditions
• Standard procedure for creating decision tables
– Name the condition and values each condition can assume
– Name all possible actions that can occur
– List all rules
– Define the actions for each rule
– Simplify the table: table compression
o Example of Decision Table

3. Decision Trees
• It is a graphical representation of a decision situation
• Decision situation points are connected together by arcs and terminate in ovals

45
 • Two main components
o Decision points represented by nodes
o Actions represented by ovals
o Example: Decision Tree Representation

What is a decision table?

A decision table is an excellent tool to use in both testing and requirements management.
Essentially it is a structured exercise to formulate requirements when dealing with complex
business rules. Decision tables are used to model complicated logic. They can make it easy to see
that all possible combinations of conditions have been considered and when conditions are
missed, it is easy to see this.
Decision Table Example:
Let’s take an example scenario for an ATM where a decision table would be of use.

A customer requests a cash withdrawal. One of the business rules for the ATM is that the ATM
machine pays out the amount if the customer has sufficient funds in their account or if the
customer has the credit granted. Already, this simple example of a business rule is quite
complicated to describe in text. A decision table makes the same requirements clearer to
understand:

In a decision table, conditions are usually expressed as true (T) or false (F). Each column in the
table corresponds to a rule in the business logic that describes the unique combination of
circumstances that will result in the actions. The table above contains three different business
rules, and one of them is the ―withdrawal is granted if the requested amount is covered by the
balance.‖ It is normal to create at least one test case per column, which results in full coverage of
all business rules.
One advantage of using decision tables is that they make it possible to detect combinations of
conditions that would otherwise not have been found and therefore not tested or developed. The

46
requirements become much clearer and you often realize that some requirements are illogical,
something that is hard to see when the requirements are only expressed in text.
A disadvantage of the technique is that a decision table is not equivalent to complete test
cases containing step-by-step instructions of what to do in what order. When this level of detail
is required, the decision table has to be further detailed into test cases.
Decision tables can be used in all situations where the outcome depends on the combinations of
different choices, and that is usually very often. In many systems there are tons of business rules
where decision tables add a lot of value.
Decision tables should best be constructed during system design, since they become useful to
both developers and testers. The requirements specialist also becomes more confident that
everything that is important is actually documented. If there are no decision tables, testers can
create them during test design to be able to write better test cases.
Now the question is how to create decision tables? Here are the steps that you need to use to
create decision tables.

Steps to create decision tables:

Step 1 – Analyze the requirement and create the first column

Requirement: ―Withdrawal is granted if requested amount is covered by the balance or if the
customer is granted credit to cover the withdrawal amount‖.
Express conditions and resulting actions in a list so that they are either TRUE or FALSE. In this
case there are two conditions, ―withdrawal amount ≤ balance‖ and ―credit granted‖. There is one
result, the withdrawal is granted.

Step 2: Add Columns

Calculate how many columns are needed in the table. The number of columns depends on the
number of conditions and the number of alternatives for each condition. If there are two
conditions and each condition can be either true or false, you need 4 columns. If there are three
conditions there will be 8 columns and so on.
Mathematically, the number of columns is 2 conditions. In this case 22 = 4 columns.
Number of columns that is needed:

47
The bottom line is that you should create smaller decision tables instead of fewer larger ones,
otherwise you run the risk of the decision tables being so large as to be unmanageable. Test the
technique by picking areas with fewer business rules.
Now is the time to fill in the T (TRUE) and F (FALSE) for the conditions. How do you do that?
The simplest is to say that it should look like this:
Row 1: TF
Row 2: TTFF
Row 3: TTTTFFFF
For each row, there is twice as many T and F as the previous line.
Repeat the pattern above from left to right for the entire row. In other words, for a table with 8
columns, the first row will read TFTFTFTF, the second row will read TTFFTTFF and the third
row will read TTTTFFFF.

Tip: There are Excel templates to fill in decision tables if you need help.

Step 3: Reduce the table

Mark insignificant values with ―-―. If the requested amount is less than or equal to the account
balance it does not matter if credit is granted. In the next step, you can delete the columns that
have become identical.

Check for invalid combinations. Invalid combinations are those that cannot happen, for example,
that someone is both an infant and senior. Mark them somehow, e.g. with ―X‖. In this example,
there are no invalid combinations.
Finish by removing duplicate columns. In this case, the first and third column are equal,
therefore one of them is removed.

Step 4: Determine actions

Enter actions for each column in the table. You will be able to find this information in the
requirement. Name the columns (the rules). They may be named R1/Rule 1, R2/Rule 2 and so
on, but you can also give them more descriptive names.

48
Step 5: Write test cases
Write test cases based on the table. At least one test case per column gives full coverage of all
business rules.
 Test case for R1: balance = 200, requested withdrawal = 200. Expected result:
withdrawal granted.
 Test case for R2: balance = 100, requested withdrawal = 200, credit granted.
Expected result: withdrawal granted.
 Test case for R3: balance = 100, requested withdrawal = 200, no credit.
Expected Result: withdrawal denied.
Summary
Decision tables are a good way to describe requirements when there are several business
rules that interact together. Using decision tables it becomes easier for the requirements specialist
to write requirements which cover all conditions. As to the tester, it becomes easier for them to
write complete test cases.
Write decision tables early, then they’ll become useful for requirements specialists, developers,
end-users and testers.

Decision Table - Jacket Weather

Determine whether you need to wear a light jacket, heavy jacket, or no jacket at all when you leave the
house. You need a heavy jacket if the temperature is below 50 degrees. You can make do with a light
jacket if the temperature is between 50 and 70. At 70 and above you only need a light jacket if there is
precipitation.

There will be 6 rules. The first condition (Is there precipitation?) has two possible outcomes, yes or no.
The second condition (temperature) has three possible outcomes. Two times three is 6.

Conditions 1 2 3 4 5 6
1. Precipitation? Y Y Y N N N
2. Temperature Less than 50 Between 50-70 More than 70 Less than 50 Between 50-70 More than 70
Actions
1. Heavy Jacket X X
2. Light Jacket X X X
3. No Jacket X

49
A technical support company writes a decision table to diagnose printer problems based upon
symptoms described to them over the phone from their clients.
The following is a balanced decision table.

Printer troubleshooter

Rules

Printer prints No No No No Yes Yes Yes Yes

Conditions A red light is flashing Yes Yes No No Yes Yes No No

Printer is recognized by computer No Yes No Yes No Yes No Yes

Check the power cable —

Check the printer-computer cable —

Actions Ensure printer software is installed —

Check/replace ink —

Check for paper jam —

Of course, this is just a simple example (and it does not necessarily correspond to the reality of
printer troubleshooting), but even so, it demonstrates how decision tables can scale to several
conditions with many possibilities.

50