Path: utzoo!yunexus!geac!daveb
From: daveb@geac.UUCP (David Collier-Brown)
Newsgroups: comp.software-eng
Subject: Re: Structured Analysis ques.
Summary: Timewarp!
Message-ID: <2879@geac.UUCP>
Date: 15 Jun 88 13:07:44 GMT
Article-I.D.: geac.2879
References: <4150003@hpcilzb.HP.COM> <2449@uvacs.CS.VIRGINIA.EDU> <3668@bunker.UUCP>
Reply-To: daveb@geac.UUCP (David Collier-Brown)
Organization: The G. Yac Co. Ltd. Inc. Pty. Etc.
Lines: 56


>In article <2449@uvacs.CS.VIRGINIA.EDU> hsd@uvacs.cs.virginia.edu.UUCP (Harry S. Delugach) writes:
>>One doesn't have to separate the two phases (requirements and design)
>>as long as the designer keeps in mind the distinction between them --
>>which decisions which are fundamental to the system's purpose and which 
>>merely carry out the purpose?


In article <3668@bunker.UUCP> rha@bunker.UUCP (Robert H. Averack) writes:>     I think we need to be a little careful here.  It should be clear that
>one needs to know WHAT a system is supposed to do BEFORE it is possible to
>determine HOW to do it.  Therefore, even if the time gap between these
>decisions is one hour, one could consider them as separate phases.


    One thing to watch out for is managment misunderstanding of the
nature of specification and design.  Unless you're resolving a
well-understood problem, one often has to use an iterative algorithm
to build a tree of requirements and designs:

algorithm:
        think about problem set ("specification")
        specify solution set ("architectural design")

	for all possible solutions "S"
	        make "S" the new problem set
	        recurse ("specification" again)
	        on failure, backtrack

result:
                                topmost requirement
                                       |
                        +----------------------------+
                secondary requirement 1         secondary requirement 2
                        |
            +-----------------------------------+
secondary sub-requirement 1.1     secondary sub-requirement 1.2


  This raises the **nasty spectre** of having to "design" during the
specification stage.  Thus you get people defining an architectural
phase, etc, ad infinitum[1].

  It's a spectre, though.
  In fact, all you're doing is validating the requirements: no-one
can argue that impossible requirements are valid!

 --dave (I once got screamed at for asking if the database could
	 **do** something: that was "an optimization question") c-b

[1] The problem has about 20 variants, all trivially different. Half
    of them are discussed under "mixing design with implementation".
-- 
 David Collier-Brown.  {mnetor yunexus utgpu}!geac!daveb
 Geac Computers Ltd.,  | "His Majesty made you a major 
 350 Steelcase Road,   |  because he believed you would 
 Markham, Ontario.     |  know when not to obey his orders"