University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Lecture 2: Separate the problem from the solution

What are Requirements?
A separate problem Problem
description is useful:
Two basic principles of requirements engineering: Most obvious problem might
Situation
Separate the problem from the solution not the right one to solve
Problems and solutions intertwine with one another Problem statement can be
discussed with stakeholders

Describing problems:

Validation
Problem statement can be Problem

Correspondence
used to evaluate design

Verification
Statement

Correctness
Application Domains vs. Machine Domains choices
Verification vs. Validation Problem statement is a
source of good test cases

Systems Engineering Still need to check:

Systems vs. software Solution correctly solves the Implementation
stated problem Statement
Problem statement
corresponds to the needs of
the stakeholders

System

2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

But design changes the world Intertwining of problems and solutions

Independent Implementation Dependence Dependent

Problem
Situation General
change Path of expl
oration
System
Level
of
abstract Detail
model of world
implementation
statement
Problem Implementation
problem Statement Statement
statement
Detailed

2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4

1
 University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Some observations about RE A problem to describe

RE is not necessarily a sequential process: E.g. prevent unauthorized access to CSG machines
Dont have to write the problem statement before the solution statement
(Re-)writing a problem statement can be useful at any stage of development
RE activities continue throughout the development process
students encryption algorithms
The problem statement will be imperfect intruders T-cards
RE models are approximations of the world password files
will contain inaccuracies and inconsistencies sysadmins passwords
will omit some information.
analysis should reduce the risk that these will cause serious problems
password memory management
signed usernames
allocation
Perfecting a specification may not be cost-effective process forms
typing at
cache contents
Requirements analysis has a cost keyboard
stickies with secure sockets
For different projects, the cost-benefit balance will be different
passwords on
Problem statement should never be treated as fixed
Change is inevitable, and therefore must be planned for things the machine shared things private
There should be a way of incorporating changes periodically cannot observe things to the machine

2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

What are requirements? Fitness for purpose?

Application Domain Machine Domain
Two correctness (verification) criteria:
C - computers The Program running on a particular Computer satisfies the Specification
D - domain properties The Specification, in the context of the given domain properties, satisfies
R - requirements P - programs the requirements

Two completeness (validation) criteria:

We discovered all the important requirements
Domain Properties:
We discovered all the relevant domain properties
things in the application domain that are true whether or not we ever build the
proposed system
Example:
Requirements: Requirement R:
things in the application domain that we wish to be made true by delivering the Reverse thrust shall only be enabled when the aircraft is moving on the runway
proposed system
Domain Properties D:
Many of which will involve phenomena the machine has no access to
Wheel pulses on if and only if wheels turning
A Specification: Wheels turning if and only if moving on runway
is a description of the behaviours that the program must have in order to meet the Specification S:
requirements Reverse thrust enabled if and only if wheel pulses on
Can only be written in terms of shared phenomena!
Verification: S, D R
2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8

2
 University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Another Example But we can also move the boundaries

Requirement R: E.g. Elevator control system:
The database shall only be accessible by authorized personnel

Domain Properties D: people waiting

Authorized personnel have passwords Elevator call buttons Scheduling algorithm
people in the elevator
Passwords are never shared with non-authorized personnel Floor request buttons
people wanting to go to button lights
Specification S: a particular floor Current floor indicators Control program
Access to the database shall only be granted after the user types an Motor on/off
authorized password Elevator motors
Door open/close
S + D entail R Safety rules
But what if the domain assumptions are wrong?

We can shift things around:

E.g. Add some sensors to detect when people are waiting
This changes the nature of the problem to be solved

2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10

University of Toronto Department of Computer Science University of Toronto Department of Computer Science

Systems vs. Software Engineering Summary

Requirements Engineering is about describing problems
System
It is useful to separate the problem from the solution
Even though this cannot be achieved entirely
environ- Monitored input input output Controlled environ-
ment Variables software data output Problems evolve continuously:
devices data devices Variables ment Delivering a solution changes the problem
items items
Describing the problem changes the problem

Key distinctions:
Application Domains vs. Machine Domains
IN OUT Verification vs. Validation
(Properties of the input device) (properties of the output device)
SOFT Systems Engineering vs. Software Engineering
(properties of the software)

REQ (the requirements - relationships between monitored and controlled

variables that the system is required to establish or maintain)
NAT (natural relationships between monitored and controlled variables that
are part of the domain)

2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 11 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 12