Why this is in my collection

From the publisher:

John von Neumann once said, "There's no sense being exact about something if you don't even know what you're talking about." In a world that is growing increasingly dependent on highly complex, computer-based systems, the importance of defining what you want to make before making it—that is, knowing what you're talking about—cannot be stressed enough. Here's an innovative book that gives you the understanding you need to give people the solutions they want. The collaborative team of Gause and Weinberg tells how you can assure the requirements are right—before the product is designed. Written b

Highlights

  • Precision without shared meaning is fake rigor — the von Neumann framing that opens the book: being exact about something nobody understands yet is worthless; requirements work is building the model before the model, and MDDE inherits its quality ceiling from this stage.
  • Ambiguity is measurable — Gause and Weinberg's ambiguity poll (let a group estimate independently; the spread of answers quantifies how ill-defined the statement is) turns vagueness into a metric, which is structure-beats-magic applied to the fuzziest phase of any project.
  • Context-free questions as a reusable elicitation pattern — process questions that work before any domain content exists; a pattern-language for interviews, the same pattern-density instinct that makes data models generatable.
  • Every word hides alternative readings — their technique of stressing each word in a requirement in turn to expose the different interpretations it can carry; the linguistic root of why business rules must eventually be formalized, not just written down.
  • Defects are cheapest before design exists — the economic core of "quality before design": removing ambiguity at requirements time costs a conversation, removing it in production costs a rebuild — the same cost curve that justifies model-first over pipeline-first.
  • Requirements are negotiated between humans, not extracted from documents — meetings, conflicting expectations, and participation are the actual medium; a corrective to any purely tooling-driven view of model-driven work.
  • Even the project's name frames the solution space — naming decisions quietly constrain what gets built; an early lesson in how much structure hides in language.

Highlights on this page are generated with the help of AI.