INSE - Lecture 4a

Requirements Elicitation

Requirements Elicitation vs Specification

[Many people in the industry confuse Requirements Elicitation with Specification: we will carefully separate them.]

Requirements Elicitation is the process of discovering what the customer needs.

Specification is the process of proposing a product that fits those needs.

That is: problem versus solution.

Requirements Elicitation in S.E.

… mainly a matter of applying common sense and prior experience

while seeking to discover the client’s needs

– not what he thinks his needs are;– not what he says his needs are;– not what you think his needs are (or ought to be);– not how you would satisfy his needs.

After Requirements Elicitation you should know…

the functional requirements; the non-functional requirements; the non-requirements (often overlooked); acceptable limitations.

I.e. what problem the product is to solve – not what product (=specification) or how the product works (=design)

[Is there really a problem? Does it merit a computer-based solution?]

Don’t be too hopeful with the requirements…

A multi-purpose transport engine Is the need for a bicycle? A skateboard?

More on Requirements …

… is well-covered in the Systems Analysis units…

Little point in duplicating what they say.

INSE - Lecture 4b

Specification

Overview of Specification Introduction to Formal Specification

Specification is…

… the process of deciding what the proposed product should “look like”, as viewed externally

[Internal views should be a matter for the design process]

Specification yields…

…a document describing an outside view of the proposed product

completely; unambiguously.

[We also often use the word “specification” to describe the document, as well as the process leading to the document.]

The specification document…

… has at least two audiences: the user (for validation) and the designer/programmer (for implementation):=> the spec is ideally in 2 forms: non-technical (for the user); technical (for the implementer)=> a problem guaranteeing consistency between the

two=> technical first, “back-translate” into non-technical

form?

Forms of the 2 versions

What form should the non-technical spec take?– non-jargonized English + diagrams

What form should the technical spec take? Two major possibilities –– jargonized English + diagrams?– a symbolic notation? = a Formal

Specification Language

A spec might have other audiences:

Higher management deciding if they want the proposed product, or can afford it;

Sales staff as the basis of their sales pitch;

The Courts if (when?) things go wrong; …

Formal Specification -

Introduction

Why Formal Specs?

Errors in specification or overall design of software are usually very expensive;

The alternative “usual” methods are based on intuition & guesswork;

Traditional Engineering disciplines avoid the risks by using maths-based designs;

So shouldn’t we be looking towards methods that have maths-like strength?

Engineer’s Council for Professional Development

“Engineering is the profession in which a knowledge of the mathematical and natural sciences, gained by study experience and practice, is applied with judgement to develop ways to utilise economically the materials and forces of nature for the benefit of mankind”

Simple example

“Calculate Square Roots” Q “What is a square root?” A “The number which, when multiplied

by itself, yields the input value” Q “What kind of numbers – integers,

fractions, reals? Positive, negative? A “Input and output are both positive

reals (or zero)

First attempt:

SQRT : R -> R

{A partial function on the Reals}

Before SQRT(s): s > 0

{Requirements on the input}

After r := SQRT(s): r >0 and r*r=s

{Requirements on the output}

That lacks some detail…

Q “What is the result is not finitely representable? – e.g. SQRT(2.0)

A “An approximate solution will do” Q “How approximate?” «pause for thought» “How do I determine the allowable error?”

A “The square of the result should differ from the input by no more than some small positive (non-zero) value.”

Second attempt

SQRT : RxR -> R

{Now we have two inputs}

Before SQRT(s,e): s > 0, e>0, and

e is small

After r := SQRT(s,e): r >0 and

(s-e) < r*r < (s+e)

After this lecture think about your past programming

efforts – how well did you consider the requirements? did the spec meet them?

The next lecture looks at a “formal method” in a little detail

(The notes sketch a couple more FM methods)