From lechner Tue Mar 22 13:45:28 2005
Subject: [quasi-]Formal Methods in SW Requirements Specification (DFD's)
To: 05f523
RJLRef: $PH/06f522/dataflowdiagrams.plug

A message re: 06f522/asgnt2  hinted at Data Flow Diagrams, or DFDs
These were the focus of  'Structured Analysis' (not to be confused with 
'Structured Programming' :-).   Here is a 'shameless plug' for the DFD vote
(as former Pres. Wlm. Bulger liked to put it).
--------------------------------------------------------

You won't find 'Data Flow' in B&D:OOSE except p. 714 in the glossary.
It's from Structured Analysis for single-thread design, 
although some (e.g. 'SADT' by Doug Ross) enhanced it with 
asynchronous control/event flows as well.
SA complemented and advanced Structured Design, which used SCD's
(Structure Chart Diagrams) or call trees labeled with in/out parameters. 

This  email is about the psychology of using any semi-formal method.
Tom DeMarco was a great author in SA/SD.
Markos' shipping clerk was probably one of those 
'he can fix anything' types.:-)

DFD's and SCD's inspired the original BDE. 
The H in HN/HL etc. of BDE came from Horizontal Data Flow in DFD's;
a complmentary set VH, VL etc. was for Vertical Call Flow in SCD's.
BDE now combines these under a 'generic' Block Diagram abstraction
(Replacing the 'H'  by G' is anoher refactoring goal.)

Forwarded message:
> From owner-re-online@it.uts.edu.au  Tue Mar 22 07:21:45 2005
> From: Tony Markos <ajmarkos@yahoo.com>
> Subject: Re: [re-online] Application of Formal Methods in Software Requirements Specification
> To: re-online@it.uts.edu.au
> Debbie:

Good question.  A well partioned DFD is a great way to
communicate with end-users.  Reasons why most IT
people do not like to use them for functional analysis
(i.e., say they are too hard):

 *  DFDs, like nothing else, makes "holes" in the
analyst's understanding glaringly evident.  Many shy
away from having "holes" in their understanding being
made glaringly evident.

 *  They require working to a higher-level of
abstraction, which requires postoning detail to the
approprate time.  Many need the physcologial comfort
of being grounded in the detail and postponing detail
are often confused as being uninterested with the
details - and it is very dangerous in IT to be seen as
uninterested in the details!

Tony Markatos
--- Debbie Lawther <dlrl@onetel.com> wrote:
> That sounds remarkably like process modelling... and
> what is always excellent practice, checking with the users.
>
> Why do IT types find it too hard?
>
> D. Lawther
>
> Tony Markos wrote:
>
> >For functional requirements, I am a big Data Flow
> >Diagraming fan.  I have had people with a graduate
> >degree in computer science tell me they were too hard
> >to work with/understand - too hard not only for
> >end-users, but for them also.
> >
> >But I can not help but remember the time I was DFDing
> >shipping/recieving/inventory control at a distribution
> >company.  I showed my DFD on shipping operations to
> >the shipping clerk.  The guy worn blue jeans and a
> >torn T shirt with transmission fluid stains on it.

> >He looked at my DFD and said "Thats not how it is done;
> >let me show you how."  He then grabbed my DFD and with
> >his pencil made major modifications to it.
> >
> >So much for too hard!
> >
> >Tony Markatos