Software Requirements Analysis

and Specification
As per IEEE, a requirement is

• A condition or capability needed by a user

to solve a problem or achieve an objective.
• A condition or capability that must be met or
possessed by a system or system
component to satisfy a contract, standard,
specification, or other formally imposed
document.
Software requirement fall into five categories

• Functional Requirements
• Non-functional Requirements
• Interface Requirements
• Inverse Requirements
• Design and Constraints Requirements
Functional Requirements –

• Specifies actions that a system must be

able to perform, without taking physical
constraints into consideration.
• These are best described in a use-case
model and in use-cases.
• Thus specify the input and output behavior
of a system.
Non-Functional Requirements-

• Describe only attributes of the system or

attributes of the system environment.
• These are also called supplementary
requirements.
• These includes
 Performance Requirements
 Safety Requirements
 Security Requirements
 Software quality attributes
 Project Documentation
 User Support Documents
 Interface Requirements
This section describes how the software interfaces with
other software products or users for input or output.
It may be
• User Interfaces
•GUI
•CLI – Command line Interface
•Application Program Interface
• Communication Interfaces – Describes network
Interfaces.
• Software Interfaces – Describes any remaining software
interfaces not included above.
• Hardware Interface – Describe interface to hardware
devices.
Inverse Requirements
These are the requirements that specify what
the software system should not do.
 Design and Implementation Requirements

• Design constraints such as specifying specific

hardware and software or specific architecture
i.e client-server.

• Implementation constraints such as

implementing the product in c, Java or in Visual
Basic.
Requirements Engineering
Requirements Engineering

According to Pohl in 1993, “ it can be defined as

the process of developing requirements through an
interactive, co-operative process of analyzing the
problem, documenting the resulting observations in
a variety of representation formats, and checking
the accuracy of the understanding gained”.
 The requirements engineering process
Requir ements
Feasibility
elicitation and
stud y analysis
Requir ements
specification
Feasibility Requir ements
repor t validation

System
models

User and system

requirements

Requir ements
document
Requirements Engineering Activities

The Requirements Engineering Process involves

the following activities.
• Requirements Elicitations
• Requirements Analysis
• Requirements Specification
• Requirements Validation
• Requirements Management
 Requirements Elicitations
Requirements Elicitation is the activity during
which software requirements are discovered,
articulated (able to express one’s thought clearly)
and revealed from users or clients.
The general techniques used are
• On – site observation
• Review of written documents
• Interviewing
• Structured Meetings
• Questionnaires
• Brainstorming
 On-Site Observation

• It is the process of recognizing and noting

people, objects, and occurrences to obtain
information
• Participation with the user staff openly and
freely is required.
• The main objective of this is to get as
close as possible to the “real ” system
being studied.
 On-Site Observation…
• The following questions can serve as a guide for
on-site observations.
– What kind of system is it ? What does it do?
– Who runs the system? Who are the important people
in it?
– What is the history of the system? How did it get to its
present stage of development?
– Apart from its formal function, what kind of system is it
in comparison with other systems in the organization?
Is it a primary or secondary contributor to the
organization?
 On-Site Observation…
Rules for Analyst
 While making observations, he/she is more
likely to listen than talk and to listen with a
sympathetic and genuine interest when
information is conveyed.
 Do not give advice or pass moral judgment on
what is observed.
 Care is taken not to argue with the persons
being observed or to show hostility toward one
person and undue friendliness toward another.
 On-Site Observation…
Observation methods can be used
1.Natural or Contrived – A natural observation
occurs in a setting such as the employee’s place
of work; a contrived observation is set up by the
observer in a place like a laboratory.
2.Obtrusive or unobtrusive – An obtrusive
observation takes place when the respondent
knows he/she is being observed; an unobtrusive
observation takes place in a contrived way such
as behind a one-way mirror.
 On-Site Observation…
3. Direct or Indirect – A direct observation takes
place when the analyst actually observes the
subject or the system at work. In an indirect
observation, the analyst uses mechanical
devices such as cameras and videotapes to
capture information.
 Interviewing
The interview is a face-to-face interpersonal
role situation in which a person called the
interviewer asks a person being interviewed
questions designed to gather information
about a problem area.
This is the oldest and most often used device
for gathering information .
 Interviewing…
Advantages –
The flexibility makes interview a superior
technique for exploring areas where not
much is known about what questions to ask
or how to formulate questions.
It offers a better opportunity than the
questionnaire to evaluate the validity of the
information gathered. The interviewer can
observe not only what subjects say but also
how they say it.
 Interviewing…
Advantages –
It is an effective technique for eliciting
information about complex subjects and for
probing the sentiments underlying expressed
opinions.
Disadvantages-
Long preparation time is required.
Interviews also take a lot of time to conduct,
which means time and money.
 Interviewing…
Guides to a successful interview.

1.Set the stage for the interview.

2.Establish rapport; put the interviewee at
ease.
3.Asking the questions
4.Be a good listener; avoid arguments
5.Evaluate the outcome of the interview.
 Interviewing…
Guides to a successful interview…
1.Set the stage for the interview. – here the
analyst opens the interview by focusing on
1. The purpose of the interview.
2. Why the subject was selected.
3. The confidential nature of the interview.
The interviewer evaluates the cooperation of the
interviewee.
Both the content and tone of the responses are
evaluated.
 Interviewing…
Guides to a successful interview…
2. Establishing rapport – Some guidelines like
 Do not deliberately mislead the user staff about the
purpose of the study.
 Assure interviewees confidentiality that no information
they offer will be released to unauthorized personnel.
 Avoid personal involvement in the affairs of the user’s
department or identification with one faction at the
cost of other.
 Avoid showing off you knowledge or sharing
information received from other sources.
 Interviewing…
Guides to a successful interview…
2. Establishing rapport – Some guidelines like
 Avoid acting like an expert consultant or confidant.
This can reduce the objectivity of the approach and
discourage people from freely giving information.
 Respect the time schedules.
 Do not promise anything you cannot or should not
deliver, such as advice or feedback.
 Dress and behave appropriately for the setting and
the circumstances of the user contact.
 Do not interrupt the interviewee. Let him/her finish
talking.
 Interviewing…
Guides to a successful interview…
3. Asking the questions – Some guidelines
like
 Ask the questions as it is worded
 Ask the questions in the same order as they
appear on the interview schedule. Reversing
the sequence could destroy the comparability of
the interviews.
 Each question must be asked unless the
respondent, in answering a previous question,
has already answered the next one.
 Interviewing…
Guides to a successful interview…
4. Obtaining and recording responses –
Some guidelines like
 Be a good listener.
 Listen with interest.
 Understand what the respondent is trying to
say.
 The information received during the interview is
recorded for later analysis.
 Interviewing…
Guides to a successful interview…
5. Date recording and notebook –
 Interviewing
• In formal or informal interviewing, the RE
team puts questions to stakeholders about
the system that they use and the system
to be developed.
• There are two types of interview
– Closed interviews where a pre-defined set of
questions are answered.
– Open interviews where there is no pre-defined
agenda and a range of issues are explored
with stakeholders.
 Interviews in practice
• Normally a mix of closed and open-ended interviewing.
• Interviews are good for getting an overall understanding
of what stakeholders do and how they might interact with
the system.
• Interviews are not good for understanding domain
requirements
– Requirements engineers cannot understand specific domain
terminology;
– Some domain knowledge is so familiar that people find it hard to
articulate or think that it isn’t worth articulating.
 Effective interviewers
• Interviewers should be open-minded,
willing to listen to stakeholders and should
not have pre-conceived ideas about the
requirements.
• They should prompt the interviewee with a
question or a proposal and should not
simply expect them to respond to a
question such as ‘what do you want’.
 Questionnaires
• It is economical and requires less skill to administer than
the interview.
• Unlike the interview, which generally questions one
individual at a time, a questionnaire can be administered
to large number of individuals simultaneously.
• The standardized wording and order of the questions and
the standardized instructions for reporting responses
ensure uniformity of questions.
• The respondents feel greater confidence.
• The questionnaire places less pressure on subjects for
immediate response. Respondents have time to think the
questions over and do calculations to provide more
accurate data.
 Questionnaire Types
• Unstructured – In this type, there is no predefined categories.
It allows respondents to answer questions freely in their own
word. The responses are spontaneous rather than freely.
• Structured – The questions are presented with exactly the
same wording and in the same order to all subjects.
– Open Ended – question requires no response direction or specific
response. In a questionnaire it is written with space provided for the
response.
– Closed Ended - questions are those in which the responses are
presented as a set of alternatives. There are 5 varieties of closed
ended questions.
• Fill-in-the-blanks
• Dichotomous(yes/No Type)
• Ranking Scale Questions
• Multiple Choice Questions
• Rating Scale Questions
Requirements Analysis

Requirements Analysis is the activity during which

the requirements gathered elicitation are analyzed
for conflicts, ambiguity, inconsistencies, missing
requirements or extra requirements.
An important part of the analysis effort is to
model the system to understand what you are
trying to understand.
 Analysis Issues

• Obtaining the necessary information

• Organizing the information, so that the
information can be effectively evaluated for
completeness and consistency.
• Resolving the contradictions that may exist in the
information from different parties.
 Requirements Specification
Requirements specification is the activity during which
requirements are recorded in one or more forms, usually in
a Software Requirement Specification Document (SRS)
The specification may be by using
Natural Language
Formal-Language
In a graphical form
The specification is used to communicate the requirements to
Customers
End-users
Managers
Designers
System Developers
The specification can be many things to many
people, such as,
• Describes what the system will be to the user
• Describes what kind of system the designers
need to build.
• Describes what kind of things need to be
tested for the testers.
• Establishes a contract between the customer
and the software developer.
Need For SRS

• An SRS establishes the basis for agreement

between the client and the developer on what
the software product will do.
• An SRS provides a reference for validation of
the final product.
• A high-quality SRS is a prerequisite to high-
quality software
• A high-quality SRS reduces the development
cost.
Characteristics of an SRS

Correct – An SRS is correct if every

requirement included in the SRS represents
something required in the final system.
Correctness ensures that what is specified
done correctly.
Complete – An SRS is complete if everything
the software is supposed to do and the
responses of the software to all classes of input
data are specified in the SRS. Completeness
ensures that everything is indeed specified
Unambiguous – An SRS is unambiguous if and
only if every requirement stated has one and only
one interpretation.
So instead of natural language some formal
languages can be used to reduce ambiguity.
Consistent – An SRS is consistent if there is no
requirement that conflicts with other.
Ex – Suppose a requirement states that an event e is
to occur before another event f. But then another
set of requirements states that event f should occur
before event e.
Ranked – An SRS is ranked for importance and /or
stability if for each requirement the importance and
the stability of the requirement is indicated.
Stability of a requirement reflects the chances of it
changing in future.
Modifiable - An SRS is modifiable if its structure
and style are such that any necessary change can
be made easily while preserving completeness
and consistency.
Traceable – Each requirement in SRS must be
uniquely identified to a source ( e.g. Use Case,
government requirement, Design, Industry Stanard
etc.)
SRS Format
1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience
1.4 Additional Information
1.5 Contact Information / SRS team members
1.6 References

2. Overall Description
2.1 Product Perspective
2.2 Product functions
2.3 User classes and characteristics
2.4 Operating Environment
2.5 User Environment
2.6 Design/Implementation Constraints
2.7 Assumptions and Dependencies
3. External Interface Requirements
3.1 User Interface
3.2 Hardware Interface
3.3 Software Interface
3.4 Communication Interface
4. System Features
4.1 System Feature A
4.1.1 Description and Priority
4.1.2 Action/Result
4.1.3 Functional Requirement
4.2 System feature B
4.3 System feature C
5. Other Non-Functional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
5.5 Project Documentation
5.6 User documentation
6. Other Requirements
Appendix A : Terminology/Glossary/Definitions list
Appendix B
 Requirements validation
• Concerned with demonstrating that the
requirements define the system that the
customer really wants.
• Requirements error costs are high so
validation is very important
– Fixing a requirements error after delivery may
cost up to 100 times the cost of fixing an
implementation error.
 Requirements checking
• Validity. Does the system provide the functions
which best support the customer’s needs?
• Consistency. Are there any requirements
conflicts?
• Completeness. Are all functions required by the
customer included?
• Realism. Can the requirements be implemented
given available budget and technology
• Verifiability. Can the requirements be checked?
Requirements validation techniques

• Requirements reviews
– Systematic manual analysis of the
requirements.
• Prototyping
– Using an executable model of the system to
check requirements.
• Test-case generation
– Developing tests for requirements to check
testability.
 Requirements reviews
• Regular reviews should be held while the
requirements definition is being formulated.
• Both client and contractor staff should be
involved in reviews.
• Reviews may be formal (with completed
documents) or informal. Good
communications between developers,
customers and users can resolve problems
at an early stage.
 Review checks
• Verifiability -Is the requirement
realistically testable?
• Comprehensibility - Is the requirement
properly understood?
• Traceability - Is the origin of the
requirement clearly stated?
• Adaptability - Can the requirement be
changed without a large impact on other
requirements?
 Requirements management
• Requirements management is the process of
managing changing requirements during the
requirements engineering process and
system development.
• Requirements are inevitably incomplete and
inconsistent
– New requirements emerge during the process as
business needs change and a better
understanding of the system is developed;
– Different viewpoints have different requirements
and these are often contradictory.
 Requirements change
• The priority of requirements from different
viewpoints changes during the
development process.
• System customers may specify
requirements from a business perspective
that conflict with end-user requirements.
• The business and technical environment
of the system changes during its
development.
Requirements evolution

Initial Changed
understanding understanding
of pr ob lem of prob lem

Initial Changed
requir ements requir ements

Time
 Enduring and volatile requirements

• Enduring requirements
Stable requirements derived from the core
activity of the customer organisation. E.g. a
hospital will always have doctors, nurses, etc.
May be derived from domain models
• Volatile requirements.
Requirements which change during
development or when the system is in use. In
a hospital, requirements derived from health-
care policy
 Feasibility studies
• All new Information System (IS) should start
with a feasibility study, which
– Gathers information
– Proposes & evaluates alternatives for
computerisation
– Performs cost-benefit analysis
– Establishes priorities
– Presents conclusions
• A feasibility study should answer the
following questions:
 Feasibility study
• How does the proposed project contribute to the
overall objectives of the organisation? Does the
system contribute to the overall objectives
• Can the system be implemented using current
technology and within given cost and schedule
constraints?
• Can the system be integrated with other systems
which are already in place?
• What if the system wasn’t implemented?
• What are current process problems?
• Do technical resources exist?
• What is the risk associated with the technology?
 Feasibility study
• Is new technology needed? What skills?
• How will the proposed project help?
• Have the benefits identified with the system being
identified clearly?
• What will be the integration problems?
• What facilities must be supported by the system?
• What is the risk associated with cost and schedule?
• What are the potential disadvantages/advantages?
• Are there legal issues?
• Are there issues linked with the fact that this is an
offshore project?
 Feasibility studies
• After a feasibility study, management makes
a GO/NO GO decision
– The feasibility study is a management-oriented
activity
– Inputs
• Preliminary business requirements
• Outline description of how the system is intended to
support business processes
– Outputs
• A report that recommends whether or not it is worth
carrying on with the requirement engineering &
system development process.
 Four tests for feasibility
• There are four categories of feasibility tests
– Operational feasibility
• How well will solution work in organisation?
• How do people feel about it?
– Technical feasibility
• Practical?
• Expertise?
– Schedule feasibility
• Reasonable timetable?
– Economic feasibility
• Cost-effective?
 Operational feasibility: acceptability

• How do end-users & managers feel about

the solution? This is also called Behavioural
Feasibility Study.
– It's not only important to evaluate whether a
system can work but also evaluate whether a
system will work.
– A workable solution might fail due to end-user or
management resistance.
• Does management support the project?
• How do the end-users feel about their role in the new
system?
Operational feasibility: acceptability
• What end-users or managers may resist or not
use the system? People tend to resist change.
Can this problem be overcome? If so, how?
• How will the working environment of the end-
users change?
• Can or will end-users and management adapt to
the change?
– Internal issues – manpower problems, labour
objections, manager resistance, organisational
conflicts and policies;
– External issues – social acceptability, legal aspects
and government regulations.
 Technical feasibility
• Is the proposed technology or solution
practical?
– Do we currently possess the necessary
technology & expertise?
• Is the technology available “in-house”?
• If so, does it have the capacity to handle the
solution?
• If not, can it be acquired?
– Are the budget & schedule reasonable for the
team?
 Technical feasibility...
– Is the technology mature enough to be easily
applied to our problem?
• Some firms like to use state-of-the-art technology,
but most firms prefer to use mature and proven
technology
• A mature technology has a larger customer base
for obtaining advice concerning problems and
improvements
– Is it compatible with our other systems?
 Schedule feasibility
• Do we have the skills required to properly
apply the technology?
– True, all information systems professionals can
learn new technologies;
– However, that learning curve will impact the
technical feasibility;
– Specifically, it will impact the schedule.
 Schedule feasibility...
• Given our technical expertise, is the project
deadline reasonable?
– Some projects are initiated with specific
deadlines;
– Whether the deadlines are mandatory or
desirable? What are the consequences of delay?
– If the deadlines are desirable rather than
mandatory, the analyst can propose alternative
schedules.
– Missed schedules are bad, but inadequate
systems are worse!
 Economic feasibility
• The bottom line in many projects is
economic feasibility.
– During the early phases of the project, economic
feasibility analysis amounts to little more than
judging whether the possible benefits of solving
the problem are worthwhile.
– As soon as specific requirements and solutions
have been identified, the analyst can weigh the
costs and benefits of each alternative.
– This is called a cost-benefit analysis…
 Feasibility Report
• The culmination of the feasibility study is a
feasibility report directed to management.
• The report is a formal document for
management use.
• The report contains the following sections
– Cover Letter – formally presents the report and
briefly indicates to management the nature,
general findings, and recommendations to be
considered.
– Table of contents – specifies the locations of
the various parts of the report for management’s
quick reference
 Feasibility Report
– Overview – is a narrative explanation of the
purpose and scope of the project, the reason for
taking the feasibility study. Also included are the
names of the persons who conducted the study,
when it began, and other information that
explains the circumstances surrounding the
study.
– Detailed findings – such as the method used in
the present system, it’s effectiveness and
efficiency as well as operating costs.
 Feasibility Report
– Economic Justification – details point-by-point
cost comparisons and return on investment(ROI)
analysis of the project is also included.
– Recommendations and Conclusions –
Suggest to management the most beneficial and
cost-effective system. They are written only as a
recommendation, not a command.
– Appendixes – document all memos and data
compiled during the investigation. They are
placed at the end of the report for reference.
 Information Modelling
• An information model is essential to provide the structure
for information that is transferred in a communication.
• An information model is a formal description of a portion of
interest of the real world and that provides explicit rules to
enable the data items that populate the model to be
interpreted without ambiguity.
• A quality information model should be complete, sharable,
stable, extensible, well-structured, precise, and
unambiguous.
• In general, the contents of an information model include
– Scope
– Information requirements
 Scope
• The scope specifies the domain of discourse and the processes
that are to be supported by the information model.
• It is a bounded collection of processes, information, and
constraints that satisfy some industry need.
• The scope statements include the purpose as well as viewpoints
of the model mentioned bellow:
– type of product,
– type of data requirements,
– supporting manufacturing scenario,
– supporting manufacturing activities,
– supporting stage in the product life cycle.
 Information Requirement
• After the scope is defined, the next phase is to conduct
a requirements analysis. There is no standard method
for collecting information requirements. However,
requirements analysis may be accomplished by:

– Literature surveys,
– Standards surveys,
– Domain experts’ interviews,
– Industrial data reviews,
– State-of-the-art assessments.
 Information Modeling
• Information modeling is a technique for specifying the
data requirements that are needed within the application
domain.

• There are different practices in developing an

information model:
– Data Flow Diagram
– Data Dictionary
– Structured English
– Decision Tables
– Decision Trees
 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
• Three methods
– Structured English
– Decision Tables
– Decision Tree
 Modeling Logic with Structured English
• Structured English is a technique used to
describe algorithmic procedures and is
sometimes considered an alternative to
flowcharts.
• Modified form of English used to specify the
logic of information processes
• Uses a subset of English
– Action verbs
– Noun phrases
– No adjectives or adverbs
• No specific standards
 Modeling Logic with Structured English

• Similar to programming language

– If conditions
– Case statements
• Figure 5-15 shows Structured English
representation for Hoosier Burger
 Modeling Logic with Decision Tables

• A matrix representation of the logic of a

decision
• Specifies the possible conditions and the
resulting actions
• Best used for complicated decision logic
 Decision Tables…

• A Decision table is a table of rows and

columns, separated into four quadrants
and is designed to illustrate complex
decision rules
– Condition Stub – upper left quadrant
– Rules Stub – upper right quadrant
– Action Stub – bottom left quadrant
– Entries Stub - bottom right quadrant
 Decision Table Layout

• Standard format used for presenting

decision tables.

Condition
Stub Rules
Stub

Action Entries
Stub Stub
 Decision Table
 For example: A bookstore get a trade discount of 25% for order more then 6 books; for
order from libraries and individuals, 5% allowed on orders of 6-19 copies per book
title; 10% on orders for 20-49 copies per book title; 15% on orders for 50 copies or
more per book title.
Complete decision table for payroll system example
 Developing Decision Tables
• Process requires the determination of the
number of conditions (inputs) that affect
the decision.
• The set of possible actions (outputs) must
likewise be determined
• The number of rules is computed
• Each rule must specify one or more
actions
 Number of Rules
• Each condition generally has two possible
alternatives (outcomes): Yes or No
– In more advanced tables, multiple outcomes for
each condition are permitted
• The total number of rules is equal to
2 no. of conditions
• Thus, if there are four conditions, there will
be sixteen possible rules
 Building the Table
• For each rule, select the appropriate
action and indicate with an ‘X’
• Identify rules that produce the same
actions and attempt to combine those
rules; for example:
– Condition 1 Y Y Condition 1 Y
Condition 2 Y N Condition 2 -

Action 1 X X Action 1 X
 Cleaning Things Up
• Check the table for any impossible
situations, contradictions, and
redundancies and eliminate such rules

• Rewrite the decision table with the most

reduced set of rules; rearranging the rule
order is permissible if it improves user
understanding
 Decision Table example:
combine and reduce

Conditions and Actions 1 2 3 4 5 6 7 8

     
Order from Fall Catalog Y Y Y Y N N N N
Order from Christmas Catalog Y Y N N Y Y N N
Order from Special Catalog Y N Y N Y N Y N
Mail Christmas Catalog X X X X
Mail Special Catalog X X
Mail Both Catalogs X X

The four gray columns can In addition, Rules 1&5 and

be combined into a single Rules 3&7 can be combined.
rule. Note that four each, Each pair produces the same
there was NO order placed action and each pair shares two
from the Special Catalog. common conditions.
Decision Table example ~ Final Version

Conditions and Actions 1 2 3

Order from Fall Catalog -- -- --

Order from Christmas Catalog Y -- N
Order from Special Catalog Y N Y
Mail Christmas Catalog X
Mail Special Catalog X
Mail Both Catalogs X

Eliminates the need to check for every possible case.

 Constructing a Decision Table
• PART 1. FRAME THE PROBLEM.
– Identify the conditions (decision criteria). These are the factors that will influence
the decision.
• E.g., We want to know the total cost of a student’s tuition. What factors are
important?
– Identify the range of values for each condition or criteria.
• E.g. What are they for each factor identified above?
– Identify all possible actions that can occur.
• E.g. What types of calculations would be necessary?

• PART 2. CREATE THE TABLE.

– Create a table with 4 quadrants.
• Put the conditions in the upper left quadrant. One row per condition.
• Put the actions in the lower left quadrant. One row per action.
– List all possible rules.
• Alternate values for first condition. Repeat for all values of second condition.
Keep repeating this process for all conditions.
• Put the rules in the upper right quadrant.
– Enter actions for each rule
• In the lower right quadrant, determine what, if any, appropriate actions should
be taken for each rule.
– Reduce table as necessary.
 Example
• If you are a new customer and you want to
open a credit card account then there are
three conditions first you will get a 15%
discount on all your purchases today,
second if you are an existing customer and
you hold a loyalty card, you get a 10%
discount and third if you have a coupon,
you can get 20% off today (but it can’t be
used with the ‘new customer’ discount).
Discount amounts are added, if applicable.
Conditions Rule 1 Rule 2 Rule 3 Rule 4 Rule 5 Rule 6
New Y Y N N N N
Customer
(15%)

Loyality N N Y Y N N
Card (10%)

Coupon Y N Y N Y N
(20%)

ACTIONS
NO X
DISCOUN
T
20% X
15% X
30% X
10% X
20% X
Importance of Decision Tables
• Aids in the analysis of structured
decisions
• Ensures completeness
• Checks for possible errors (impossible
situations, contradictions, and
redundancies, etc.)
• Reduces the amount of condition testing
that must be done
••if
if driver.age
driver.age << 20
20 and
and
driver.has
driver.has training
training
then
then driver.eligible
driver.eligible == true
true
••if
if driver.age
driver.age << 20
20 and
and
driver.has
driver.has training
training == false
false
then
then driver.eligible
driver.eligible == false
false
••if
if driver.age
driver.age >=>= 20
20
then
then driver.eligible
driver.eligible == true
true
(do
(do not
not care
care about
about training
training for
for this
this
case)
case)