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

© 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

Lecture 2:Requirements and Projects

Two basic principles of requirements engineering: Separate the problem from the solution Problems and solutions intertwine with one another

Describing problems: Application Domains vs. Machine Domains Verification vs. Validation

Systems Engineering Systems vs. software

Patterns and Types of Problem Requirements patterns Problem Frames

Project Types & Context

Requirments Life-Cycle



Separate the problem from the solution

ProblemStatement

ImplementationStatement

System

Co

rres

po

nd

ence

Co

rrec

tnes

s

Val

idat

ion

Ver

ific

atio

n

A separate problem description is useful:

Most obvious problem might not be the right one to solve

Problem statement must be discussed with stakeholders

Problem statement can be used to evaluate design choices

Problem statement is a source of good test cases

Still need to check: Solution correctly

solves the stated problem

Problem statement corresponds to the needs of the stakeholders

ProblemSituation



ProblemSituation

P r o b l e mS i t u a t i o n

But design changes the world…

abstractmodel of world

implementationstatement

problemstatement

change

System



Intertwining of problems and solutions

Implementation Dependence

DependentIndependent

General

Detailed

Levelof

Detail

Implementation

Statement

ProblemStatement

Path of exploration



Some observations about RE

RE is not necessarily a sequential process: Don’t 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

The problem statement will be imperfect RE models are approximations of the world

will contain inaccuracies and inconsistencies will omit some information. analysis should reduce the risk that these will cause serious

problems…

Perfecting a specification may not be cost-effective

Requirements analysis has a cost For different projects, the cost-benefit balance will be

different Problem statement should never be treated

as fixed Change is inevitable, and therefore must be planned for There should be a way of incorporating changes periodically



A problem to describe…

E.g. “prevent unauthorized access to DSIC machines”

encryption algorithmsstudents

intruders

passwordallocationprocess

stickies withpasswords on

T-cards

sysadmins

signed forms

passwords

usernames

typing at keyboard

password files

memory management

cache contents

secure sockets

things the machinecannot observe

things private to the machine

sharedthings



Application DomainMachine Domain

D - domain properties

R - requirements

C - computers

P - programs

What are requirements?

Domain Properties: things in the application domain that are true whether or

not we ever build the proposed system Requirements:

things in the application domain that we wish to be made true by delivering the proposed system

Many of which will involve phenomena the machine has no access to

A Specification: is a description of the behaviours that the program must

have in order to meet the requirementsCan only be written in terms of shared phenomena!



Fitness for purpose? Two correctness (verification) criteria:

The Program running on a particular Computer satisfies the Specification

The Specification, in the context of the given domain properties, satisfies the requirements

Two completeness (validation) criteria: We discovered all the important requirements We discovered all the relevant domain properties

Example: Requirement R:

“Reverse thrust shall only be enabled when the aircraft is moving on the runway”

Domain Properties D: Wheel pulses on if and only if wheels turning Wheels turning if and only if moving on runway

Specification S: Reverse thrust enabled if and only if wheel pulses on

Verification: S, D R

S + D entail R But what if the domain assumptions are wrong?



Another Example

Requirement R: “The database shall only be accessible by authorized

personnel”

Domain Properties D: Authorized personnel have passwords Passwords are never shared with non-authorized

personnel

Specification S: Access to the database shall only be granted after the

user types an authorized password

S + D entail R But what if the domain assumptions are wrong?



But we can also move the boundaries…

E.g. Elevator control system:

people waiting

people in the elevator

people wanting to go toa particular floor

Elevator motors

Elevator call buttons

Floor request buttons

Current floor indicators

Scheduling algorithm

Safety rules

Motor on/off

Door open/close

Control programbutton lights

We can shift things around:E.g. Add some sensors to detect when people are waitingThis changes the nature of the problem to be solved



Example Problem Frames

Required behaviour Problem: build a machine to

control part of the world in accordance with a fixed set of control rules

Likely Solution: an automated control system

Commanded Behaviour Problem: build a machine that

allows part of the world to be controlled by an operator by issuing commands

Likely Solution: a “human-in-the-loop” control system.

Information Display Problem: provide information

about the current state of part of the world, in response to information requests

Likely Solution: an information system.

ControllerDesired

BehaviorControlled

Domain

ControllerDesired

BehaviorControlled

Domain

User

InformationRequests

Real World

Informationsystem

Informationfunction

InformationOutputs



More problem frames

Simple workpieces frame Problem: keep track of the

edits performed on some workpiece, e.g a text file or a graphical object

Likely Solution: application software (e.g. a word processor)

Transformation frame Problem: take input data in a

certain format, and provide a transformation according to a certain set of rules

Example Solutions: data processing applications; compilers, etc.

Connection frame Problem: maintain a

correspondence between domains that are otherwise not connected

Example Solutions: data entry system, sensor network, etc.

machineOperationproperties

workpiece

OperationRequests

machineMapping

RulesOutputData

InputData

SystemReal World

Connection

Achievablecorrespondence

SCCR



Project Types

Reasons for initiating a software development project

Problem-driven: competition, crisis,… Change-driven: new needs, growth, change in business

or environment,… Opportunity-driven: exploit a new technology,… Legacy-driven: part of a previous plan, unfinished work,

… Relationship with Customer(s):

Customer-specific - one customer with specific problem May be another company, with contractual arrangement May be a division within the same company

Market-based - system to be sold to a general market In some cases the product must generate customers Marketing team may act as substitute customer

Community-based - intended as a general benefit to some community

E.g. open source tools, tools for scientific research funder customer (if funder has no stake in the outcome)

Hybrid (a mix of the above)



Project Context

Existing System There is nearly always an existing system

May just be a set of ad hoc workarounds for the problem Studying it is important:

If we want to avoid the weaknesses of the old system… …while preserving what the stakeholders like about it

Pre-Existing Components Benefits:

Can dramatically reduce development cost Easier to decompose the problem if some subproblems are

already solved Tension:

Solving the real problem vs. solving a known problem (with ready solution)

Product Families Vertical families: e.g. ‘basic’, ‘deluxe’ and ‘pro’ versions

of a system Horizontal families: similar systems used in related

domains Need to define a common architecture that supports

anticipated variability



Is there a “Requirements Lifecycle”

Specification

Agreement

Representation

complete

fair

vague

personal view

common view

informal semi-formal formal

Source: Adapted from Pohl, CAISE 1993



Inquiry Cycle

Prior Knowledge(e.g. customer feedback)

Observe(what is wrong withthe current system?)

Model(describe/explain theobserved problems)

Design(invent a better system)

Intervene(replace the old system)

Note similarity withProcess of scientific

Investigation:Requirements models are theories about the

world; Designs are tests of those theories

Initial hypothesis

Look for anomalies - what can’tthe current theory explain?

Create/refinea better theory

Design experiments totest the new theory

Carry out the

experiments



Summary

Requirements Engineering is about describing problems

It is useful to separate the problem from the solution Even though this cannot be achieved entirely

Problems evolve continuously: Delivering a solution changes the problem Describing the problem changes the problem

Key distinctions: Application Domains vs. Machine Domains Verification vs. Validation Systems Engineering vs. Software Engineering

Basic Problem Frames Give us a starting point for understanding the problem Tell us what subdomains we need to describe



Summary

Project Lifecycles Useful for comparing projects in general terms Represent different philosophies in software

development Requirements evolve through their own lifecycles too!

Documents

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