SOFTWARE ENGINEERING
Lecture 7
Requirements Representation:
Decision table + Usecases
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
DEFINITION
Decision tables are used to lay out in tabular form all possible situations which a
business decision may encounter.
A decision table lists causes and effects in a matrix.
Each column represents a unique combination.
Purpose is to structure logic
Combinations
Causes Values 1 2 3 4 5 6 7 8 Cause = condition
Cause 1 Y, N Y Y Y Y N N N N
Cause 2 Y, N Y Y N N Y Y N N Effect = action = expected
Cause 3 Y, N Y N Y results
N Y N Y N
Effects
Effect 1 X X X
Effect 2 X X X
WHAT IS A DECISION TABLE?
Table representing complete set of conditional expressions where expressions are
mutually exclusive in a predefined area
In a decision table, business logic is well divided into conditions, actions (decisions)
and rules for representing the various components that form the business logic.
The tables are composed of 4 parts: conditions, actions, condition alternatives (each
column is a rule), and actions for the rules.
Decision tables are used to remove inconsistencies in requirements
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.
A DECISION TABLE MAKES THE SAME REQUIREMENTS
CLEARER TO UNDERSTAND
IN A DECISION TABLE, CONDITIONS ARE USUALLY EXPRESSED
AS TRUE (T) OR FALSE (F)
Above table 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.
STEP 1: ANALYSE 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 COLUMN
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:
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.
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 THE ACTION
Enter [Link] 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
R1 R2 R3
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.
USE CASES
WHAT IS A USE CASE?
A use case is a typical sequence of actions that a user performs in order to complete
given task (Tells a story)
The objective of use case analysis is to model the system from the point of view of
how users interact with this system when trying to achieve their objectives.
Not the computations the system performs.
It is one of the key activities in requirements analysis
USE CASE
There are multiple paths to achieve the
A use case has:
goal:
Only one goal By mail
A single starting point In person
A single ending point by check
by cash, etc.
Multiple paths for getting from start to finish
A path that does not lead to the goal:
Credit card is declined
CHARACTERISTICS OF A USE CASE
A use case (or set of use cases) has these characteristics:
Organizes functional requirements
Models the goals of system/actor (user) interactions
Describes one main flow of events (main scenarios) and possibly other exceptional flows
(alternatives)
HOW DO WE DESCRIBE USE CASES?
Use case diagram
Fully Dressed use case
Descriptive Use case
USE CASE DIAGRAM
what is being described? (system)
who is using the system? (actors)
what do the actors want to achieve? (use cases)
Purpose
Specify the context of a system
Capture the requirements of a system
Drive implementation and generate test cases
USE CASE DIAGRAM ELEMENTS
Actors
- something with a behavior or role, e.g., a person, another system, organization.
Scenario
- a specific sequence of actions and interactions between actors and the system, a.k.a. a
use case instance
Use case
-a collection of related success and failure scenarios, describing actors using the system to
support a goal
Other Elements
-Associations, include, extend, System boundary
WHAT IS AN ACTOR?
Actor is someone interacting with use case (system function).
Named by noun
The actor can be a human or other external system.
Include system components only if they responsible for
initiating/triggering a use case. For example, a timer that
triggers sending of an e-mail reminder
Each Actor must be linked to a use case, while some use cases
may not be linked to actors.
KIND OF ACTORS
Primary - a user whose goals are fulfilled by the system
Secondary/supporting - provides a service (e.g., info) to the system
HOW TO IDENTIFY ACTORS?
Who uses the system?
Who installs the system?
Who starts up the system?
Who maintains the system?
Who shuts down the system?
What other systems use this system?
Who gets information from this system?
Who provides information to the system?
Does anything happen automatically at a present time?
USECASE
System function (process – automated or manual).
Named by verb
Represented by oval in Diagrams
Use cases are typically initiated by a user to fulfill goals
Login Account
HOW TO IDENTIFY USE CASES?
What functions will the actor want from the system?
Does the system store information? What actors will create, read, update or
delete this information?
SCENARIO
A scenario is an instance of a use case
A specific occurrence of the use case
a specific actor ...
at a specific time ...
with specific data.
OTHER ELEMENTS
Connection between Actor and Use
Boundary of system
<<include>> Include relationship between Use Cases (one UC must call another; e.g.,
Login UC includes User Authentication UC)
Extend relationship between Use Cases (one UC calls Another under certain
<<extend>> condition; think of if-then decision points)
RELATIONSHIPS
Association
Generalization
Inclusions
Extensions
GENERALIZATION
The child use case inherits the behavior and meaning of the parent use case.
The child may add to or override the behavior of its parent.
Much like super classes in a class diagram.
A generalized use case represents several similar use cases.
INCLUDE USE CASE /INCLUSIONS
Sometimes there is a common sequence of steps common to several use cases.
Those steps can be extracted to form a subcase.
Subcase can be called by a base use case.
INCLUDE
EXTEND USE CASE / EXTENSIONS
A use case can also be appended with an extension subcase that adds functionality to the end
of the use case.
An extending use case is, effectively, an alternate course of the base use case .
EXTEND
Register Course (standard use case) may have Register for Special Class (extend use case) – class
for non-standard students, in unusual time, with special topics, requiring extra fees…)
Register <<Extend>> Special
Course Class
<<Extend>> Authenticati
Login
on failed
EXAMPLE OF GENERALIZATION/EXCLUSION AND
INCLUSION
HOW TO CREATE USE CASE DIAGRAMS
List main system functions (use cases)
Draw system boundary
Draw actors and connect them with use cases
Specify include and extend relationships between use cases
FULLY DRESSED USE CASE OR USE CASE SPECIFICATION
FULLY DRESSED USE CASE OR USE CASE SPECIFICATION
Name: Give a short, descriptive name to the use case.
Actors: List the actors who can perform this use case.
Goals: Explain what the actor or actors are trying to achieve.
Preconditions: State of the system before the use case.
Post conditions: State of the system in following completion
Summary/Description: Give a short informal description.
Steps/Basic Flow
Alternative Flow
FULLY DRESSED USECASE
Secondary
actors:
DESCRIPTIVE USECASE
It is like user story
Description of scenario or events in the bulleted points
Answers 3 questions:
Who?
Does what?
And why?
ACTIVITY