[comp.software-eng] Soft-Eng Digest v5n14

nigam@pcsc-sun (Alok Nigam) (06/10/88)

Soft-Eng Digest             Fri, 10 May 88       V: Issue  14         

Today's Topics:
                  Structured Analysis ques. (3 msgs)
----------------------------------------------------------------------

Date: 1 Jun 88 23:26:02 GMT
From: hpda!hpcuhb!hpcilzb!chris@bloom-beacon.mit.edu  (Chris Toomey)
Subject: Structured Analysis ques.

  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)?

------------------------------

Date: 2 Jun 88 19:20:37 GMT
From: hpda!hpcuhb!hpsmtc1!byackle@bloom-beacon.mit.edu  (Brad Yackle)
Subject: Structured Analysis ques.

The context diagram defines what information the spell process needs
and what information it produces.  I would suggest the following changes:

             commands
          ---------\
          |         -> -------                   ---------
 ----------   words   /        \ --------------> correct
 | user   | -------->|  spell   |                ---------
 ----------<----------\        / --------------> incorrect
              display  --------                  ---------
                          ^
			  |
                      ------------
                      |spelling  |
		      |dictionary|
                      ------------

Commands can be defined as cntl-d and display can be defined prompts
and/or menus.  I also assume that the spelling program will need an
additional resource of dictionary of correctly spelled words.  The
details of how the prompts are displayed i.e. unix shells, dos etc.
are not needed on this diagram.  The dfd is meant to show "what"
the process does, the "how" is shown with structured design.

------------------------------

Date: 6 Jun 88 14:25:57 GMT
From: uvaarpa!virginia!uvacs!hsd@mcnc.org  (Harry S. Delugach)
Subject: Structured Analysis ques.

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?

------------------------------

End of Soft-Eng Digest
******************************