RE: Business Requirements

Subject: RE: Business Requirements
From: "James Barrow" <vrfour -at- verizon -dot- net>
To: <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Fri, 06 Apr 2007 16:11:18 -0700

Hmmm...we're getting close to a point where I can't disclose any more
details (contractual agreement). But, on a very generic level, I'm talking
about 12 different government agencies. Each of these agencies receives
"elements" (physical and electronic), and creates a tracking record for

Each facility receives roughly the same types of elements, but they receive,
store and track them in very different ways. Add to this that the new app
must enable each facility to share information regarding elements.

Facility #1 might receive an element via courier, physically walk it to a
processing area, enter tracking data for it, then store it in one of a 100
storage areas.

Facility #2 might send their own van to a pick-up site, retrieve the
element, bring it back and create the tracking info and store in their own

The way the app is being developed, it would have a business requirement for
"Application must allow for the selection of a courier," but not "Elements
can be stored in the same facility".

-----Original Message-----
From: Gene Kim-Eng [mailto:techwr -at- genek -dot- com]

Not having seen any of the material you're discussing I'm having
a hard time seeing the distinction between your "business
requirements" and "functional requirements." I don't think I've
ever worked on a product development in which what we called
"business requirements" were so large that there could have been
something that was only 1/12 of the total. Ours were basically
what market the product was going to sell to, what its basic
function was, what projected price range we thought we could
sell it in and what its cost to deliver would have to be in order
for it to make an acceptable profit to justify its development.
What am I missing?

----- Original Message -----
From: "James Barrow" <vrfour -at- verizon -dot- net>

> I'm with the Architecture department. And, like you suggested, I included
> fairly clean matrix that listed the business requirements at the top of
> table, and the derived functional requirements at the bottom.
> The problem (see "convoluted" previously) is that the PMO gathered
> requirements and specs for one out of twelve facilities (user groups) and
> tried to pass these requirements off as all-encompassing. When I came on
> board I looked at all of the facilities and noted that the developers were
> going to start work with only 1/12th of the requirements. This is when
> firestorm started. And, like a room full of kindergartners, the PMO stood
> up and said, "The Architecture team is dumb. We're not playing with you
> more."
> On a personal level I have a difficult time with this. My brain wants to
> see the backwards traceability of the functional requirements to the
> business requirements, not FR to a project manager's whim.


Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more.

Now shipping: Help &amp; Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help &amp; Manual:

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -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 admin -at- techwr-l -dot- com -dot- Visit for more resources and info.


Re: Business Requirements: From: Gene Kim-Eng

Previous by Author: RE: Business Requirements
Next by Author: Replying to posts
Previous by Thread: Re: Business Requirements
Next by Thread: Re: Business Requirements

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

Sponsored Ads