Map
Index
Random
Help
th

QuoteRef: parnDL2_1986

topics > all references > ThesaHelp: references p-r



ThesaHelp:
references p-r
Group:
program design
Topic:
specification is infeasible
Topic:
usability errors
Group:
psychology
Topic:
bugs
Group:
software maintenance
Group:
requirement specification
Topic:
importance of information hiding for requirement specification
Topic:
good requirement specifications
Topic:
design documentation
Topic:
requirement specification by function
Group:
program module
Topic:
separate a module's interface specification from its implementation
Topic:
data types in Thesa
Topic:
software review
Topic:
software documentation
Topic:
pseudocode design
Topic:
design for change
Topic:
writing
Topic:
information as facts

Reference

Parnas, D.L. , Clements, P.C. , "A rational design process: How and why to fake it ", IEEE Transactions on Software Engineering , SE-12 , 2 , pp. 251-257 , February 1986 . Google

Other Reference

356-367 [?] in Hoffman, D.M., Weiss, D.M. (eds.), Software Fundamentals. Collected Papers of David L. Parnas, Boston: Addison-Wesley, 2001

Quotations
251 ;;Quote: even though there is not a rational way to design software, we can fake one; i.e., present a system as if it were designed rationally
356 ;;Quote: software development is not rational; do not know what is wanted; can not tell what is known
251 ;;Quote: human errors are intrinsic to being human
252 ;;Quote: rational design requires a requirements document
253 ;;Quote: a requirements document should contain everything needed to write acceptable software and no more
359 ;;Quote: organize a requirements document as a reference document instead of an introductory narrative; worth the expense; easy lookup
253 ;;Quote: a requirements document is primarily a set of tabular, mathematical functions from external state variables to single output values
360 ;;Quote: a requirements document includes the host specification, interface specifications, a specification for each output value, timing and accuracy constraints, likely changes, and undesired event handling
253 ;;Quote: a module guide states the design decisions that will be encapsulated by each module
253+;;Quote: a module guide defines how work will be divided into work assignments
254 ;;Quote: a module interface specification is a formal description of each module as a black box; allows independent development
254 ;;Quote: a module design document records the major design decisions for design reviews and documentation
363 ;;Quote: use pseudocode in design documentation; keep both versions consistent; use different programmers
364 ;;Quote: keep design documents consistent with a system; if multiple versions are required, confine the differences to small modules
364 ;;Quote: in documentation, avoid stream of consciousness (write as think) and stream of execution (write as it happened); difficult to find information
365 ;;Quote: design a document by stating the questions, one per section; then write the document by answering the questions
365+;;Quote: define one and only one place for every fact
256 ;;Quote: include all design alternatives in the documentation along with why they were considered and why they were rejected

Related Topics up

ThesaHelp: references p-r (245 items)
Group: program design   (13 topics, 454 quotes)
Topic: specification is infeasible (46 items)
Topic: usability errors (6 items)
Group: psychology   (9 topics, 307 quotes)
Topic: bugs (66 items)
Group: software maintenance   (14 topics, 368 quotes)
Group: requirement specification   (11 topics, 307 quotes)
Topic: importance of information hiding for requirement specification (23 items)
Topic: good requirement specifications (36 items)
Topic: design documentation (43 items)
Topic: requirement specification by function (20 items)
Group: program module   (10 topics, 336 quotes)
Topic: separate a module's interface specification from its implementation (86 items)
Topic: data types in Thesa (92 items)
Topic: software review (80 items)
Topic: software documentation (64 items)
Topic: pseudocode design (43 items)
Topic: design for change (76 items)
Topic: writing (32 items)
Topic: information as facts (21 items)

Collected barberCB 4/87 12/04
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.