TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
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 http://www.hotmail.com
