Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!ncar!boulder!sunybcs!rutgers!gatech!mcnc!uvaarpa!virginia!uvacs!hsd
From: hsd@uvacs.CS.VIRGINIA.EDU (Harry S. Delugach)
Newsgroups: comp.software-eng
Subject: Re: Structured Analysis ques.
Message-ID: <2449@uvacs.CS.VIRGINIA.EDU>
Date: 6 Jun 88 14:25:57 GMT
References: <4150003@hpcilzb.HP.COM>
Reply-To: hsd@uvacs.cs.virginia.edu.UUCP (Harry S. Delugach)
Organization: U.Va. CS dept.  Charlottesville, VA
Lines: 30

In article <4150003@hpcilzb.HP.COM> chris@hpcilzb.HP.COM (Chris Toomey) writes:
>
>  I'm doing structured analysis for the first time and am a little confused
>about a few of its concepts.
>

Spelling checker example deleted....

>the system cannot be fully specified by this approach because it fails to 
>consider the module(s) which are responsible for prompting the user and reading
>words. In other words, how can DFDs and data dictionary entries be used in 
>place of a written requirements spec. if they don't encompass the entire 
>system being developed? 

But you are not just developing a specification (i.e., design) of the whole
system -- you are also trying to show its *requirements*. In this case, the
requirement (from the user's point of view) is to divide words into files,
although it needs constraints on what "correct" or "incorrect" spelling
means. Modules are not part of requirements -- I could come up with
an alternate module design which could also satisfy your requirements.

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?

-- 
Harry S. Delugach   University of Virginia, Dept. of Computer Science
                    INTERNET: hsd@cs.virginia.edu
                    UUCP: ..!uunet!virginia!uvacs!hsd
                    BITNET: hsd2x@virginia