object-oriented analysis and design lecture 1 requirements analysis
Post on 19-Dec-2015
235 views
TRANSCRIPT
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.