Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!seismo!uunet!wuarchive!uwm.edu!src.honeywell.com!skyler.mavd.honeywell.com!djbailey From: djbailey@skyler.mavd.honeywell.com Newsgroups: comp.software-eng Subject: Re: Tolerance Message-ID: <1991Feb12.170456.115@skyler.mavd.honeywell.com> Date: 12 Feb 91 23:04:56 GMT References: <1401@ucl-cs.uucp> <27A9B451.48BF@tct.uucp> <2053@abvax.UUCP> Lines: 31 In article <2053@abvax.UUCP>, ejp@icd.ab.com (Ed Prochak) writes: > I think that the real point being missed is that the tolerance has nothing > to do with the result, be it numerical, alphabetic, or other. > [...] > Want a real life example? Consider a printer. it must locate the > characters and image them at the correct point size. there is little > or no tolerance there, but how fast the pages come out has a good > deal of tolerance. A customer expects simple pages to come out faster > than more complex pages. there are two measurements that may vary: > print speed and page complexity. Print speed is relatively easy to > define and can be measured precisely. Complexity of the text is > not so easily defined and may have a wide tolerance in the customer's > view. > Right, but tolerance in requirements is even harder to define. For example, customer A says, "Yes, I want to print things." Customer B says, "I want to print my 20 page listings in less than five minutes." Customer C says, "I need to print text and graphics at 1200 dpi, 10 pages per minute, on A, B, C, or D size paper, and I don't want to spend more than $10000." Customer D says, "I want to print reports." There is a lot more tolerance in Customer A's requirements than in Customer C's requirements. Customer D's requirements could mean anything depending on the definition of a "report." You need a way to measure the semantic content of requirements. Tolerance in requirements could be the number of design factors where your customer's response is "I don't care" or "I don't care as long as [...] is true." -- Don J. Bailey