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