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

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

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]

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

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]

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]

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"

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]

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

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]

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

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