Topic: specification is infeasible

topics > computer science > programming > Group: requirement specification

formal methods and languages
limitations of formalism
problems with logic programming
program proving is infeasible
programming as mathematics
specification errors
user-centered design
Subtopic: model of reality up

Quote: a model of the real world is more robust than a set of functional requirements [»jackMA2_1984]
Quote: a functional specification must refer to an explicit model of reality; otherwise have confusion and misunderstandings [»jackMA2_1984]
Quote: program correctness is more than a calculable relation between its specification and its text [»tursWM10_2003]
Quote: program correctness includes the reality in which the need for a program emerged in the first place

Subtopic: unacceptable vs. acceptable up

Quote: it is much easier to recognize an unacceptable system than to define the requirements for an acceptable system [»neugW_1982]

Subtopic: misunderstanding client up

Quote: software development is not rational; do not know what is wanted; can not tell what is known [»parnDL2_1986]
Quote: systems analyst and client may understand specifications differently [»mccrDD_1981]
Quote: most specifications require verbal reinforcement to resolve ambiguities and questions [»joneTC4_1979]

Subtopic: missing specifications up

Quote: critical specification questions lie inherently outside of formal systems; e.g., Did we forget an event? Will the system act as we expect? [»bornA2_1987]
Quote: the most intractable problem in constructing complex software is specifying what it should do; what if an event is not anticipated? [»bornA2_1987]
Quote: the Ballistic Missile System Early Warning System failed because of the rising moon

Subtopic: implementation necessary up

Quote: only testing reveals discrepancies between a model and the real situation; also errors in proofs [»parnDL6_1990]
Quote: most requirements techniques incorrectly view software development as a contract; software is now a commodity [»pottC9_1993]
Quote: software developers usually have no, prior customer or set of requirements, evolve instead of create; domain knowledge important [»pottC9_1993]
Quote: specification without implementation is not possible because can't formalize requirements without user feedback from an implementation [»abboRJ3_1990]
Quote: during product development at Microsoft, the feature set may change 30% or more from the original specification [»cusuMA6_1997]
Quote: there's no sense being precise about something when you don't even know what you're talking about [»weinGM_1982]
Quote: a formal specification also requires user feedback from an implementation [»abboRJ3_1990]
Quote: can not state requirements in advance because the system development changes the user's perceptions and often changes the applications environment itself [»mccrDD4_1982]
Quote: a program is the only complete description of the program's behavior [»demiRA5_1979]
Quote: a program controls a computer's behavior, or it is a complete specification for the desired, observable behavior of a computer [»hehnEC2_1984]

Subtopic: specification is inflexible and premature up

Quote: the software life cycle rigidifies thinking and reduces a system's responsive to change [»mccrDD4_1982]
Quote: the software life cycle is like forcing supermarket customers to specify their shopping list at the door [»mccrDD4_1982]
Quote: a specification can shield programmers from user needs during development of a program [»millHD_1979]
Quote: structured analysis leads to premature design; hard to visualize overall behavior [»hsiaP11_1993]

Subtopic: specification too large and inadequate up

Quote: in practice, requirements engineering produces one large document that is seldom followed, and if followed, often unsuccessful; what is wrong? [»hsiaP11_1993]
Quote: in a large system, the formal specification is too bulky for practical use; instead design work switches to informal communications [»joneTC4_1979]
Quote: as a program increases in size, specifications stop increasing in size because they become too large to write and read [»joneTC4_1979]
Quote: like detailed flowcharts, formal specifications do not work; maybe useful in large jobs after a prototype is completed [»mccrDD_1981]
QuoteRef: kralTM5_1975 ;;6-10 problem with HIPO is "time consuming to produce and modify"

Subtopic: specification too obtuse up

Quote: the main drawback of formal specification languages is that specifications can be as opaque as source code; difficult to create [»krueCW6_1992]
Quote: in problem formulation shouldn't break thoughts into discrete units; form is vague, contradictory, and incomplete [»begeML10_1988]
Quote: abstract specification is difficult; e.g., specifying a simple table/list module led to non-intuitive problems [»bartW12_1977]

Subtopic: difficult to manage up

Quote: the specification phase is difficult to manage because progress is hard to measure

Subtopic: changing requirements up

Quote: need better ways to elicit and define requirements incrementally; not a language or structured analysis [»pottC9_1993]
Quote: specifications are a static representation of a dynamic process; does not make sense since change is the norm [»mccrDD_1981]
Quote: poor practice for requirements engineering due to changing, hard-to-uncover requirements, CASE, poor training and communication, insufficient time [»hsiaP11_1993]
Quote: requirement changes often cross-cut information hiding boundaries; should restructure the code, but restructuring is expensive without observable change [»berrDM10_2002]
Quote: in programming, discoveries and requirements grow faster than code; can not be systematic or keep up with documention [»berrDM10_2002]
Quote: while stepwise refinement works well for new development, it requires rewrite for changed requirements [»berrDM10_2002]
Quote: discourage change if want comprehensive requirements before coding starts [»berrDM10_2002]
Quote: refactoring takes time and may require throwing out perfectly good code; used for new requirements under extreme programming [»berrDM10_2002]
Quote: dealing with changed requirements is particularly painful for formal program development [»berrDM10_2002]
Quote: requirements and proofs are inherently global; a changed requirement may require redoing most of the proofs; verification gets dropped [»berrDM10_2002]

Subtopic: examples up

Quote: identification of specification errors in a published specification [»meyeB1_1985]

Subtopic: problems with object-oriented analysis up

Quote: object-oriented analysis has not been effective for specifying a system's black box behavior

Related Topics up

Topic: formal methods and languages (53 items)
Topic: limitations of formalism (93 items)
Topic: problems with logic programming (10 items)
Topic: program proving is infeasible (47 items)
Topic: programming as mathematics (27 items)
Topic: specification errors (10 items)
Topic: user-centered design
(65 items)

Updated barberCB 1/06
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.