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.
Tony "Focused on the Essential Like a Laser" Markos wrote:
> I also read [Kovitz's "Practical Software Requirements"] a ways
> back. He is con DFDs. To bad. All Requirements Engineering
> techniques - except DFDs - have the same tragic flaw: Reliance
> on a forced artificial partitioning ("chunking" to us TWs) of
> the system. Such techniques will, especially for larger scale
> efforts, always result in incomplete and disjointed
> requirements - to the point of causing big problems.
Hey, I'm not against DFDs! I'm against force-fitting software
requirements to data-flow diagrams when data flows are just not
what it's about.
For example, you *could* spec out the details of a communication
protocol using data-flow diagrams. That might be an interesting
exercise for a 3rd-year student in comp sci. But it's no way to
spec out a communication protocol so programmers can implement
it and testers can verify that it's implemented correctly. A
good way to do it is with a state-transition diagram and/or
table. See, for example, RFC 1661, describing the PPP protocol: http://www.ietf.org/rfc/rfc1661.txt.
I think we're on the same side on this, Tony. The book is
really a diatribe against artificial partitionings ("force-fits"
in the book) plus a bunch of ways to partition complicated
things naturally and without losing rigor. A lot of folks who
make software for a living got really really mad at having DFDs
shoved down our throats when they had nothing to do with the
project. Some of us threw the baby out with the bathwater. I
recommended keeping flow diagrams as a natural way to describe
situations where stuff gets pumped from one thing to another,
each time getting transformed in some way.
ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!
RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
