Re: Life Cycle PLanning

Subject: Re: Life Cycle PLanning
From: Tony Markos <ajmarkos -at- yahoo -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Thu, 16 Dec 2004 17:27:47 -0800 (PST)

--- 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)

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

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.



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:

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 for more resources and info.


Re: Life Cycle PLanning: From: Ned Bedinger

Previous by Author: Re: Life Cycle PLanning
Next by Author: Agile Development And Data Flow Diagrams
Previous by Thread: Re: Life Cycle PLanning
Next by Thread: Re: Life Cycle PLanning

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

Sponsored Ads