Re: Business Requirements

Subject: Re: Business Requirements
From: "Pro TechWriter" <pro -dot- techwriter -at- gmail -dot- com>
To: "Jim Barrow" <vrfour -at- verizon -dot- net>
Date: Tue, 10 Apr 2007 11:53:01 -0400

This is a pretty long thread, so if someone else has suggested this, and I
missed it, please forgive me.

Have you thought about doing use cases (from the user perspective) as
requirements for your new application? The use cases would be the foundation
for the user guides and other documentation, and would also provide the
developers with real world information about how the user would interact
with the new system. This would not require getting "permission" either,
since you would be using them as a tool to base the user documentation on.

I created use cases as the foundation for development, user documentation,
and then for testing.

There are some great books out there that provide the how to. I don't have
them with me, but if you are interested, I will get the titles and send them
to you.

About the old system: if you are not attempting to discover and correct gaps
between the existing system (the As-Is) and the new system (the To-Be), you
probably don't need a complete set of requirements from the old system. Just
documenting the current functionality and any background activities should
be sufficient.

Good luck. If you find that use cases would work for you, please let me know
if you need any help. I'd be glad to do that.

On 4/5/07, Jim Barrow <vrfour -at- verizon -dot- net> wrote:
> Thanks, Mary.
> The situation is convoluted. A consulting firm came in over a year ago to
> develop the business and functional requirements for the A2 system. I don't
> know if there was a gas leak at the time, but the documents that I read were
> of little value. The "requirements" that the firm listed were not
> requirements at all and I was able to reduce the list of 680 down to
> 120. For political reasons, that list was thrown out and another firm was
> hired to start at square one (the developers are supposed to start working
> on 6/1).
> There are three items that I can clarify.
> First, I'm not a gun-slinger who decided that these requirements (for both
> the legacy app and A2) needed to be written. I was given that assignment.
> Second, the legacy app documentation is mostly for the stakeholders so
> that heads *don't* roll if they ask to see the current documentation. The
> emphasis was on generating this first.
> Third - and I say this with respect - John was incorrect when he said that
> I had been shot down once before regarding this. That incident/post
> referred to a completely different project. And again, I'm not playing
> Cowboy Bob shooting my way into board rooms trying to sell my agenda. My
> manager tells me what he'd like and I do it.
> --
> PT
> pro -dot- techwriter -at- gmail -dot- com
> I'm a Technical Technical Writer!

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: Jim Barrow

Previous by Author: Re: Aware of such a System
Next by Author: Re: Capitalization examples?
Previous by Thread: RE: Business Requirements
Next by Thread: re: Business Requirements

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

Sponsored Ads