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.
--- Ned Bedinger <doc -at- edwordsmith -dot- com> wrote:
You (Tony) seem to say that DFD is like a system of
equations that you can solve to "discover" what you
don't know about a system.
Tony Markos:
Yes that is what all the DFD gurus say - and I have
experienced. Many modeling techniques (Use Cases for
example) can used to capture what one already knows
about a system. DFDs are unique in that they guide
one in "flushing out" what one does not know about a
system. No other technique does such - and that is
what makes them a true analysis (i.e., discovery)
tool.
Ned Bedinger:
It isn't a DFD until it is complete....
Tony Markos:
Correct, and DFDs are designed to help us, through
multiple iterations, move from a flawed understanding
of requirements to a correct understanding.
Ned Bedinger:
A DFD would indeed tell you... how that top-level
function is decomposed into sub-functions, but without
the knowledge of those sub-functions, you
don't have a DFD, .
Tony Markos:
Your right, "The devil is in [knowledge of] the
details". While DFDs are meant to created in as top
down a fashion as possible, the method fully supports
the anlayst switching gears and going from top-down to
bottom-up, and then switching back again to proceed in
a top-down manner.
Ned Bedinger:
Functional decomposition: In Kovitz' P.11 sense,
you start off knowing at a high level what function
is needed. At that point, someone will need to break
it down, and find the best way to make that function
happen. That person breaks it down into sub-functions
and decides on what the sub-functional requirements
will be.
Tony Markos:
There are two kinds of DFDs: DFDs of the "As Is"
condition, and DFDs of the "To Be" condition (system).
It is not until we are working on the "To Be"
condition that we consider functions needed to make
the higher level functions happen.
In the "As Is" model, we strictly stick with what
currently is. Our main objective in creating the "As
Is" model is to uncover the essential logical
requirements. Essential logical requirements exist
irregarless of any implementation (i.e., make things
happen) considerations.
When I refer to DFDs, I generally mean "As Is" DFDs.
This is true with most DFDers as, generally, the
greatest part of the DFDing effort is in creating the
"As Is" model.
I think, Ned, that you (and Korvitz)are thinking "To
Be" DFDs. With "To Be" models we determine additional
requirements needed to implement our essential
requirements.
While "To Be" DFDs are very much needed, be aware that
a very common problem in projects is forgoing the "As
Is" and going directly to the "To Be". The problem
here is that discovery of the essential logical
requirement is cut short.
__________________________________
Do you Yahoo!?
Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com
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.
