Re: Life Cycle PLanning

Subject: Re: Life Cycle PLanning
From: Ned Bedinger <doc -at- edwordsmith -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Tue, 14 Dec 2004 20:00:40 +0000


Tony Markos wrote:


--- Ned Bedinger <doc -at- edwordsmith -dot- com> wrote:


Ben Kovitz explained this to you right here in this

group. You said you couldn't see such.


Tony Markos:

Ben posted that he was not con DFDs.

here's what he said:

--- Ben Kovitz <bkovitz -at- nethere -dot- com> wrote:

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

He's talking about a map that traces data and logic: Data goes in, gets manipulated, comes out. He says a flow diagram is good for describing that. Who would argue?

> Tony "Focused On The Essential" Markos responds to Ben Kovitz:

> ...Yet on page 11 of your book on software
> requirements you state the following:

"Functional decomposition [which entails proceeding
in a top-down fashion] doesn't work because there
are many ways to divide a high-level function into
subfunctions, and there is no way to tell which of
those possible divisions are good or bad until
you've gotten to the lowest level of design."


I do not see how
he can say such when he clearly states in his book
that top-down functional decomposition (i.e., Data
Flow Diagrams) do not work. See page 11 of his book.

What you're missing is that Ben uses DFD to diagram what he knows about a system. Again, he's talking about a map of what he knows, not a problem-solving technique.

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. I agree with this much:

A map that is incomplete might lead you to what is missing.

But then we diverge. I wouldn't call such a map a DFD. It isn't a DFD until it is complete. A DFD would indeed tell you, at an appropriate level of granularity, how that top-level function is decomposed into sub-functions, but without the knowledge of those sub-functions, you don't have a DFD, although it might be convenient to call what you have a DFD. To call an incomplete roadmap a DFD is to borrow elements from the well-defined concept of a DFD, to refer to things that are not DFDs.

You and Kovitz seem to diverge over the definition of a high-level function and what it means to decompose one. Its up to you to figure out where the disconnect is there--to me it seems pretty straight-forward:

High-level function: A description of a function. The High Level Function descriptor does not include any extended information about HOW the function does what it does. In this discussion, it hasn't seemed to matter whether the function is proposed or already exists--both apparently need to be analyzed and decomposed for DFD documentation. Example High-Level; Function: A new application needs to create a daily activity report. <--this is a high-level function *requirement*, but no matter, same difference.

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. These sub-functional requirements are, in Kovitz' P. 11 terms, the "lowest level of design". Examples would include all of the details of how to pull data for the required report, how to format the report, etc.

Pay attention now, here's the kicker:

*Unless you have the authority, on your project, to decide what the best way is to subdivide the high-level function,* then It doesn't matter if you can come up with a dozen different practical or theoretical ways to decompose that requirement into sub-functional requirements--you still can't diagram the DFD for that function (with any expectation of being right), until ...

...someone, who knows for sure how the function will be implemented, tells you how it is done (Kovitz' "lowest level of design"), and THEN you can diagram it as a DFD.



Ned Bedinger:


I think you need to clearly state what your job is,
and at what point in a project you are discovering requirements. Do you
already have a finished product?


Tony Markos:

I am a Technical Writer. I am highly experienced at
discovering requirements from the initial concept
phase all the ways forward.



Is your point that DFD is a formal concept that carries some weight in product development circles, and therefore lends authority as a good tool for illustrating bugs or design problems or analysis failures?

Are you sure that a sketch won't do just as well?

Ned Bedinger
doc -at- edwordsmith -dot- 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.



Follow-Ups:

References:
Re: Life Cycle PLanning: From: Tony Markos

Previous by Author: Re: Life Cycle PLanning
Next by Author: Re: Difficulties with Recruiter
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