Usable Specs=DFDs

Subject: Usable Specs=DFDs
From: "Anthony Markatos" <tonymar -at- hotmail -dot- com>
To: billdb -at- ile -dot- com, techwr-l -at- lists -dot- raycomm -dot- com
Date: Mon, 25 Oct 1999 15:52:04 PDT

Bill Burns said:

..I don't have a problem with Yourdon's idea [using data flow diagrams and other structured systems analysis (SSA) techniques to create highly task-oriented requirements specs]. I've just never seen it [done] in practice, and I haven't seen an environment conducive to that level of software specification by SW developers.

Tony Markatos responds:

I have worked with graduate-degree software developers who said that Data Flow Diagrams (DFDs) are just too hard to understand. I have also, very successfully, walked-through DFDs (of the same level of complexity that the graduate developers found 'too difficult') with end users having only a high school education. The real issue in using them is not complexity but politics (i.e., turf wars and egos).

Yourdon used to say that DFDs without a (complete) data dictionary and entity relationship diagrams are "merely rough sketches". He has since changed his mind: he now acknowleges the political dangers in creating a detailed "As-Is" model.

However, even within organizations in which many are resistive of SSA techniques, I have found that (as long as upper management is not resistive) utilizing them, to the degree that they can be, results in specs that are much more task-oriented than otherwise possible. The following is a "real world" (politics considered) scenario:

1.) You are only allowed a couple of end user walk-throughs per data flow diagram. (For a variety of reasons, often many more iterations are needed.)

2.) You are only allowed time to rigorously define major data relationships and data flows.

3.) You have a strong sense that, if you ask any more questions, you will be attacked.

Having done, the above, you are still way short of the Yourdon ideal. However, reality is that you have completed an analysis more rigorous than 98% of all formal requirements specs efforts; the "real world" specification process is that primative. Additionally, your analysis will be much more end user focused than typically occurs. I have always found such to be the case.

Tony Markatos
(tonymar -at- hotmail -dot- com)

Get Your Private, Free Email at

Previous by Author: Re: Any ideas for a presentation on the documentation process?
Next by Author: Re: RE: Are best practices standards?
Previous by Thread: RE: Adding styles to the right mouse button
Next by Thread: Are best practices standards?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads