Re: tech writer --> BA

Subject: Re: tech writer --> BA
From: Tony Markos <ajmarkos -at- yahoo -dot- com>
To: hokumhome -at- freehomepage -dot- com, techwr-l -at- lists -dot- techwr-l -dot- com
Date: Thu, 4 May 2006 10:12:53 -0700 (PDT)

--- Sean Hower <hokumhome -at- freehomepage -dot- com> wrote:

Hi all.

I've made the switch from technical writer to
business analyst. I was wondering if anyone out
there has any good book recommendations.

I've got UML for the IT Business Professional (a very
good read) Writing Effective Use Cases


I belong to the requirements engineering listserv. If
you want to be a top notch BA, know the tragic flaw
of Use Cases. Below is a copy of an exchange I
recently had on that listserv on the tragic flaw of
Use Cases.

Tony Markos


Tony Markos wrote:

Why did Use Cases fail in this larger-scale
requirements analysis effort? I have seen this
situation before. The problem is obvious: Use Cases
failed to make "holes" in [a business analyst's]
understanding of functional requirements glaringly

Davor responded:

I have had similar experiences with Use Cases with
respect to what you are mentioning, and what I'm
really interested in is identifying why they leave
these "holes" in!

Tony Markos responds:

That is, in my humble opinion, the the most essential
question in requirements engineering today! (Funny
though how few are even focused on this issue -

Some years ago, I took the Yourdon course in
Structured Systems Analysis. The very first thing the
instructor talked about was the fact that previous
functional analysis techniques utilized what I call
the old "connect-the-boxes" approach (this approach is
as old as systems analysis).

As that instructor explain, in the old
"connect-the-boxes" approach, the business analyst
FIRST draws functional boxes and THEN he/she tries to
figure out how all the boxes interconnect.

That instructor then further explained that what the
requirements analyst is actually doing in this
situation is putting his/her limited (flawed)
understanding down on paper and then is trying to
force fit really to match that flawed understanding.

Use Cases are classic example of the old
"connect-the-boxes" approach.

Result of a "connect-the-boxes-approach": Discovery
(i.e., requirements elicitation) is derailed - the
analyst sees what he/she wants to see (i.e, what
he/she already knows) and, in a major way, evades
looking for what he/she does not know (i.e., missing
essential functional requirements).

To better visualize the problem with the old
"connect-the-boxes" approach, compare that approach
with proper use of Data Flow Diagrams. (I must
emphasize the word "proper"; many DFD'rs actually try
to "connect the boxes" - largely negating the
effectiveness of their DFDs.)

With proper use of DFDs, within the scope of the
system, the analyst FIRST draws some data flows. When
those data flows naturally split or combine THEN
he/she identifies a function. The big difference:
The analysis technique itself actually prods the
analyst to identify functionality. With a Data Flow
Diagram approach, in the ideal, the analyst's (flawed)
understanding does not even "come into play".

Of course one can say that ideals and reality seldom
match. However, the differences between an (as Tom
DeMarco called it) "interview the data" approach and a
"connect-the-boxes" approach are so profound, that
even a half-hearted attempt to follow the data flows
results is a big improvement over a strictly
"connect-the-boxes" approach.

Davor wrote:

...The main reason I see for not being able to provide
this "big picture" is that use cases are providing
only "snapshots" .....

Tony Markos responds:

Exactly. As Tom DeMarco wrote: The data flows provide
the litmus test of [proper integration]. To the
degree that we move away from formal identification of
the data flows - and Use Cases do not ID data flows -
we move away from checking the completeness of our

Davor wrote:

As such they do not provide even complete description
of each system process. This lack of integration
is what I feel leaves all these "holes" in - you do
not see any issues that arise when all of these use
cases get *integrated* to provide a full specification
of the system (minus all the stuff that has to be
filled in that does not exist in the UCs due to the
invisibility to the actors, at least when we are
working with Cockburn's UCs). So, I strongly feel that
UCs are an excellent *elicitation* technique, very
useful for customers and communication purposes, but
fail short when
it comes to providing necessary stuff for an
analyst/architect in term of providing a full,
integrated, picture of the system - i.e., clear
overall *specification* of the system. So, I feel much
more has to be done on top of just discovering and
specifying UCs before jumping into such activities as
OOA and similar, which are most often done exactly in
this fashion.

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!.

Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at

You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit

To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.

tech writer --> BA: From: Sean Hower

Previous by Author: Conducting Telephone Interviews
Next by Author: Re: tech writer --> BA
Previous by Thread: tech writer --> BA
Next by Thread: Re: tech writer --> BA

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

Sponsored Ads