object-oriented analysis and design lecture 1 requirements analysis

Object-OrientedAnalysis and Design

Lecture 1Requirements Analysis

Overview

Techniques for eliciting requirements

Functional requirements, and some ways of specifying them

Quality requirements, and some ways of specifying them

Several examples

What’s a Requirements Spec? Scope (extremely important!) System objectives Measurable criteria for success These might be found in a “systems

plan” What about shrink-wrap?

The Final Document

A requirements specification is a “logical” model of the system to be built.

It specifies what but not how. It should be understandable by both

the developer and the client. It is a kind of contract. It is the basis for design.

Typical Contents

Scope, goals, objectives Data flows and a data model An object model with interactions Queries and other user interactions (use

cases) Interfaces w/ other systems Sample reports and screen layouts Performance parameters Criteria for judging acceptable performance

Example: Chess Playing

Build a system to play chess with the user.

Provide a visual display of the chess board and the chess pieces.

Provide a simple means for the user to move her chess pieces.

Both the system and the user will be restricted to legal moves.

The system will recognize when a player has won.

Functional Requirements

Establish essential behaviors for any correct implementation (legal moves, etc.).

True for every implementation, on every machine, in every language, in any operating environment.

But there is more...

Nonfunctional Requirements Operational properties of the

delivered system. Response time, ease of use, “ilities.” Difficult to describe logically. Difficult to check in advance of an

implementation. Every bit as important as functional

requirements.

Example: American FactFinder U.S. Census Bureau microdata files. Allows users to request

“tabulations” over the Web. Big issues with confidentiality. Incorporates “disclosure limitation”

filters.

AFF Sample Query

Give me counts of households in Oakland,ordered by race of head of household, income, and indoor plumbing.

AFF Query Process

External firewall

Internet External Server

Initialrequest

Internal Server

Filteredrequest

Internal firewall

Filterprocessing

Query database

ResultsResults

Microdata

Example: Air Traffic Control System for North America How many pages is the

requirements document? How many people understand the

entire system?

Example: Symbolic Regression

Accept input data (x1i, x2

i,...,xmi, yi),

i = 1,...,n Produce a parsimonious, rational function f

such that y = f(x) best fits the data, using “ Genetic Programming.” Graph the data. Graph the solution. Make sure it’s fast!

Example: A Container Class Library Provide the most common data

structures and algorithms. Provide a common interface, so

easy to use, interchangeable. Make extensions as easy as

possible. Make it efficient.

Our Several Examples

The examples differ widely in their nature Procedure-driven vs data-driven We could write a prose description for

each, but danger lurks... Is their a formal modeling procedure that

can capture requirements unambiguously, across this variety of applications?

Eliciting Requirements

Interviews Joint Application Design Prototypes Questionnaires Observation Sampling

Interviews First steps:

Understand the “business” Understand the terms (glossary: brace,

beam, girder, strut)) Understand the operating environment

(plant tour) Understanding what can change

Select interviewees from a spectrum of users clerks and “trench workers” supervisors upper management

Interviews (cont.)

Prepare questions tailored to the interviewee.

Open-ended vs. close-ended questions Gather samples of documents and

reports. Have a known management sponsor. Stay out of power struggles! After, write a report, and give it to the

interviewee.

Joint Application Design

A better “interviewing technique” Designed to shorten the

requirements definition process Get involvement, commitment, and

hopefully “ownership” Developed by IBM, but Pushed by consleazants

JAD (cont.)

Collect all the “players” at once Users (management, supervisors,

clerks...) IS analyst Session leader Executive sponsor Note-takers

Could we use groupware?

Rapid Prototyping

Will our design reflect what we know how to build, rather than what the client needs?

“...even the most talented people require approximately a decade to reach top professional proficiency.” (Simon)

Prototypes yield much needed experience “Plan to throw one away; you will anyway”

(Brooks) Some projects are “first-of-a-kind”

Prototypes (cont.)

The goal is to reduce uncertainty A prototype is a kind of simulation Among other things, prototypes

may be useful for Process flow design User interface design Performance modeling

Prototypes (cont.)

A prototype is not a complete specification. Can’t be used as evidence in court… Maintenance and enhancements

would be difficult, since there is no clear current spec.

The end product is insight, not a computer program

Rapid Prototyping Dangers Prototypes are “smoke and mirrors” Big “changes” can be made quickly Management may think real changes to the

real system can be made just as easily. Relying on the prototype’s design will likely

make integration difficult. Management doesn’t like the idea of

building something just to be thrown away.

How Hard is Requirements Specification? “If the sales for the current month are

below the target sales, then a report is to be printed, unless the difference between target sales and actual sales is less than half the difference between the target sales and actual sales in the previous month or if the difference between target sales and actual sales for the current month is under 5 percent.”

How Hard is Requirements Specification? We need a sorting routine, so we

give a specification: Input specification: p: an array of n

integers, n > 0. Output specification: q: an array of n

integers such that q[0]q[1] … q[n-1]

The programmers oblige, giving us TrickySort.

How Hard is Requirements Specification? 1969, Naur described a procedure

for proving a code product correct. The idea: start with a specification,

then map lines in the spec to lines in the code

Here is his example problem:

Naur’s Problem Given a text consisting of words separated

by blank characters or by newline characters, convert it to line-by-line form in accordance with the following rules. Line breaks must be made only where the

given text contains a blank or newline; Each line is filled as far as possible, as long as No line contains more than maxpos characters.

Naur’s Problem Naur’s “product” was 25 lines of ALGOL

code. He “proved” informally that his code was

correct. Subsequent reviewers and authors found

several major spec ambiguities. A new spec was written, four times longer. Another author found 12 faults with the

new spec!

Sources For This Lecture

P.O. Flaatten, D.J. McCubbrey, P.D. O’Riordan, K. Burgess, Foundations of Business Systems, 2nd ed., The Dryden Press, 1992.

S. Schach, “Object-Oriented and Classical Software Engineering”, McGraw-Hill, 2002

J. McCarthy, Dynamics of Software Development, Microsoft Press, 1995.

F.P. Brooks, Jr., The Mythical Man-Month, Addison Wesley, 1995.