About 6.30 problem design discussion

Interpretation number 2. We all, as good students, literally followed specifications, while Dayton, as an “experienced and intelligent information systems developer” (using Satzinger & Orvik terminology), applied a fundamental information system design principle: a client will have not what s/he wants, but what s/he needs. More strictly:
“Typical problems with requirements information include:
- omissions: Very often the initial set of user-supplied requirements (and information) is incomplete. This means that, during the course of analysis, the software engineer will have to either locate, or generate, new information.”
Edward V. Berard. Creation of, and Conversion to, Object-Oriented Requirements (http://www.itmweb.com/essay551.htm)

Interpretation number 1. I should admit that my first reaction during the class (and next eight hours) was: Dayton suddenly and arbitrarily changed specifications, expanding them. I suspect that other students felt confused also, so I decided to post a more sophisticated interpretation (see interpr. # 2) to this conference.

Margarita