ObjectOriented Analysis and Design Lecture 1 Requirements Analysis

Object-Oriented Analysis and Design Lecture 1 Requirements Analysis

Overview n n 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? n n n Scope (extremely important!) System objectives Measurable criteria for success These might be found in a “systems plan” What about shrink-wrap?

The Final Document n n n 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 n n n n 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 n n n 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 n n n 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 n n n 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 Fact. Finder n n 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 Microdata Initial request Internet Filtered request External Server Results Filter processing External firewall Internal Server Results Query database Internal firewall

Example: Air Traffic Control System for North America n n How many pages is the requirements document? How many people understand the entire system?

Example: Symbolic Regression Accept input data (x 1 i, x 2 i, . . . , xmi, yi), i = 1, . . . , n n Produce a parsimonious, rational function f such that y = f(x) best fits the data, using “ Genetic Programming. ” n Graph the data. n Graph the solution. n Make sure it’s fast! n

Example: A Container Class Library n n 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 n n 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 n n n Interviews Joint Application Design Prototypes Questionnaires Observation Sampling

Interviews n First steps: n n n 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 n n n clerks and “trench workers” supervisors upper management

Interviews (cont. ) n n n 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 n n 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. ) n Collect all the “players” at once n Users (management, supervisors, clerks. . . ) n IS analyst n Session leader n Executive sponsor n Note-takers n Could we use groupware?

Rapid Prototyping n n n 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. ) n n n The goal is to reduce uncertainty A prototype is a kind of simulation Among other things, prototypes may be useful for n Process flow design n User interface design n Performance modeling

Prototypes (cont. ) n A prototype is not a complete specification. n n n 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 n n n 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? n “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? n We need a sorting routine, so we give a specification: n n n 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 Tricky. Sort.

How Hard is Requirements Specification? n n n 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 n 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. n n n 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 n n n 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 n n P. O. Flaatten, D. J. Mc. Cubbrey, P. D. O’Riordan, K. Burgess, Foundations of Business Systems, 2 nd ed. , The Dryden Press, 1992. S. Schach, “Object-Oriented and Classical Software Engineering”, Mc. Graw-Hill, 2002 J. Mc. Carthy, Dynamics of Software Development, Microsoft Press, 1995. F. P. Brooks, Jr. , The Mythical Man-Month, Addison Wesley, 1995.