RE: Business Requirements

Subject: RE: Business Requirements
From: "John Rosberg" <jrosberg -at- interwoven -dot- com>
To: "John Posada" <jposada01 -at- yahoo -dot- com>, <hokumhome -at- freehomepage -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Fri, 6 Apr 2007 08:27:02 -0500



-----Original Message-----
From: John Posada [mailto:jposada01 -at- yahoo -dot- com]
Sent: Thursday, April 05, 2007 9:50 AM
To: hokumhome -at- freehomepage -dot- com; techwr-l -at- lists -dot- techwr-l -dot- com
Subject: re: Business Requirements

> > At the moment I'm putting together a brief memo that details the
> > importance of establishing business requirements before starting
> > the A2 project, and establishing at least some business
> > requirements for the legacy app.
> > Do you agree? Disagree? Why?
>
> I totally agree that you need business requirements on your A2
> project. Not so sure about the legacy app unless you plan on doing
> some new development for it.

I don't consider Busness Requirements (BR) as important as Functional
Requirements (FS), except to write the FS, and if whoever is writing
the FS thinks they don't need the BR, maybe they do and maybe they
don't. It could be that the person writing the FS knows that business
and its requirements very well.

Once you have the FS, you are writing about the application that
conforms to those requrements.

John Posada
Senior Technical Writer

"They say everyone needs goals. Mine is to live forever.
So far, so good."


I'm not sure I'd agree that Business Requirements may be of less import
that Functional Requirements -- while the writing of the majority of the
documentation and help may be more directly driven by the FR (what the
product does), the context for these things should be found in the BR --


Without that information, it is very difficult to produce anything other
than "click submit, OK, and close."

Use cases are of great value to many customers, and typically FRs do not
contain much helpful data regarding them -- also, especially in
software, the folks that make the decision to purchase and deploy the
product are not the ones who actually wind up using it -- applications
appear on people's desktops, with little guidance as to how to use them.
Often, we produce docs and help that guide the user (or system admin)
through a series of steps (and FRs shine here), but often we do not
provide the why you would want to choose this menu option.

I think I've just described Mircosoft documentation, haven't I? ;-}

rosberg
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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.
http://www.DocToHelp.com/TechwrlList

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: http://www.helpandmanual.com

---
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 http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


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
http://www.techwr-l.com/ for more resources and info.


Follow-Ups:

References:
re: Business Requirements: From: John Posada

Previous by Author: RE: Happy to be a Tech Writer?
Next by Author: RE: Your thoughts on punctuation?
Previous by Thread: re: Business Requirements
Next by Thread: RE: Business Requirements


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


Sponsored Ads