chris@hpcilzb.HP.COM (Chris Toomey) (06/02/88)
I'm doing structured analysis for the first time and am a little confused
about a few of its concepts.
I'm using an automated tool (HP Teamwork) to develop a set of leveled
data flow diagrams and the accompanying data dictionary; I want to use
these in place of a formal written requirements spec. I'm confused over
the identification of the net inputs/outputs of the system as specified
in the top-level DFD (the context diagram). I'll use a simple example
to illustrate my point.
Let's say I'm developing a very simple spelling program (similar to UNIX's
spell) which will repeatedly prompt the user for words, which are to be input
one at a time following the prompt. The program will check the spelling of the
words and place them accordingly into the files "correct" and "incorrect." This
will continue until the user enters ctrl-d at the prompt.
Now, for the context diagram:
------- ---------
---------- words / \ --------------> correct
| user | -------->| spell | ---------
---------- \ / --------------> incorrect
-------- ---------
As this DFD illustrates, the net input to the program is the words the user
enters, and the net output is the two files correct and incorrect. Is this the
right assessment of the system I've described? If so, then it seems to me that
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? Is my context diagram incorrect? Should the net input
be "keystrokes"?
Also, if the system was extended to display a menu to the user, would the
menu be considered net output to the user or merely "control information" (and
thus not shown on the DFD)?
Thanks for any insights.rha@bunker.UUCP (06/03/88)
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. Hi Chris - don't worry, the concepts ARE very confusing in the beginning. Now, let's see if we can sort this out. > I'm using an automated tool (HP Teamwork) to develop a set of leveled >data flow diagrams and the accompanying data dictionary; I want to use >these in place of a formal written requirements spec. I'm confused over >the identification of the net inputs/outputs of the system as specified >in the top-level DFD (the context diagram). I'll use a simple example >to illustrate my point. Let's get this clear up front. The System Dictionary (DFD's, Data Dictionary) alone IS NOT SUFFICIENT. This document must always accompany a formal, written Requirements Specification. The purpose of the System Dictionary is to better understand the current and proposed system from the perspective of data only. > Let's say I'm developing a very simple spelling program (similar to UNIX's >spell) which will repeatedly prompt the user for words, which are to be input >one at a time following the prompt. The program will check the spelling of the >words and place them accordingly into the files "correct" and "incorrect." This >will continue until the user enters ctrl-d at the prompt. > Now, for the context diagram: > ------- --------- > ---------- words / \ --------------> correct > | user | -------->| spell | --------- > ---------- \ / --------------> incorrect > -------- --------- > As this DFD illustrates, the net input to the program is the words the user >enters, and the net output is the two files correct and incorrect. Is this the >right assessment of the system I've described? If so, then it seems to me that >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? Is my context diagram incorrect? Should the net input >be "keystrokes"? Your Context Diagram is absolutely correct, my friend. The fact that the system prompts the user for a word does not constitute a flow of data in this context. Furthermore, your conclusion that the DFD's and Data Dictionary cannot be used *in place of* a formal, written Requirements Specification is also correct, as I stated above. The DFD is a logical view only...one should never be concerned with the manner of implementation (modules, keystrokes, etc.). > Also, if the system was extended to display a menu to the user, would the >menu be considered net output to the user or merely "control information" (and >thus not shown on the DFD)? In this regard, the menu is no different than a simple prompt. I hope that I was able to help you. Good luck on your project - E-mail me if you have any further questions. -- {yale!,decvax!,philabs!}bunker!rha Bob Averack Bunker Ramo, an Olivetti Company Two Enterprise Drive - Shelton, Connecticut 06484
hsd@uvacs.CS.VIRGINIA.EDU (Harry S. Delugach) (06/06/88)
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
rha@bunker.UUCP (Robert H. Averack) (06/09/88)
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? 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. Again, the essential point here is: WHAT before HOW. -- {yale!,decvax!,philabs!}bunker!rha Bob Averack Bunker Ramo, an Olivetti Company Two Enterprise Drive - Shelton, Connecticut 06484
embick@tetra.UUCP (06/09/88)
In article <3668@bunker.UUCP> rha@bunker.UUCP (Robert H. Averack) writes: >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) > >one needs to know WHAT a system is supposed to do BEFORE it is possible to >determine HOW to do it... Unfortunately, many developers seem to latch onto a harware/software capability that provides a "unique approach" to accomplishing an application, and build a system around it without regard to the using community's needs. "Gee, that's a neat idea! What kind of package can we wrap it in so we can sell it?" The design then dictates the requirements ;-) ------------------------------------------------------------------------------ Ed Embick (If God wanted me to write legibly, He wouldn't have invented email) Computer Sciences Corp. 4045 Hancock St. MILNET: embick@tetra.nosc.mil San Diego, CA 92110 (619) 225-8401 x287
daveb@geac.UUCP (David Collier-Brown) (06/15/88)
>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"