TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Business Requirements From:hbacheler -at- aol -dot- com To:beth -at- bdel -dot- com, techwr-l -at- lists -dot- techwr-l -dot- com Date:Fri, 06 Apr 2007 00:54:38 -0400
This email addresses the 'software' business, bu can to a certain
extent be applied in any business environment.
When I took the SEI-CMM (SW-CMM) course in 2001 I got the following
advice/approach.
It was from Mark Paulk who is one of the primary authors/leads of the
Capability Maturity Model at Carnegie Mellon, at the Software
Engineering Institute (SEI). You will see his name on a great number of
the publications.
When talking about the 'processes' used in a 'mature' organization, the
documentation can be a small as a napkin with information on it.
As long as all know the process, and the documentation required for the
process it is OK. You might view the CMM as an outline for how to
ensure that all things get considered and 'documented'.
Whether it is an organization of 3-4 people, or a large organization
like Lockheed-Martin/CACI/TRW/CACI. the idea should be the same.
What is our mission, where are we going and how do we get there.
If the founders of the organization can't establish that for the
organization, why is there a business.
I have talked to several developers over the years. When I asked one of
them where his requirements were and what his design was, he said words
to the effect "I don't have any, I just know what they want." I
understand he got a position with another company for $85,000.00
shortly after that.
Another 'programmer' (hacker) toold me when he was redoing an
application (and not reusing any code "If they got the money, I got the
time to start from scratch, with all new code."
These are my thoughts, and are not the responsibility of anyone other
than myself.
Like a lot of us on this list, "Been there, done that, still got the
coffee cup".
Harry
-----Original Message-----
From: beth -at- bdel -dot- com
To: techwr-l -at- lists -dot- techwr-l -dot- com
Sent: Thu, 5 Apr 2007 5:09 PM
Subject: RE: Business Requirements
I work for a company that took the "we are too small to document this"
approach. The problem is now we have offices in three countries and
until I
started working here last year, they were still in that mode. I
continually
get flack from co-workers that "it has always worked fine they way we
use to
do it (without formal or semi-formal documentation)." Bad habits are
hard to
break.
-----Original Message-----
From: techwr-l-bounces+beth=bdel -dot- com -at- lists -dot- techwr-l -dot- com
[mailto:techwr-l-bounces+beth=bdel -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of
Jonathan West
Sent: Thursday, April 05, 2007 11:34 AM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: RE: Business Requirements
>
> If you don't know what your business requirements are, why are you in
> business?
>
> If there are no business requirements, why have
application/development
> requirements?
Of course a business that doesn't set requirements for what its
products are
supposed to achieve won't stay in business very long.
But so long as the requirements are *known* they don't necessarily need
to
be *formally documented*. A small company of just 3-4 people will
document
almost nothing for internal purposes, and can get away with that because
they are always talking to each other and know each others' minds.
The problems happen when an organisation starts growing. That kind of
word-of mouth may still work with 6 people, but will probably break
down by
the time the company grows to 20. At that point, a more formal
development
process starts to be needed.
At what point a particular kind of internal document starts being
needed is
difficult to define - it depends on many factors apart from the size of
the
company.
I've no idea whether in this case the absence of formally documented
business requirements is actually hurting the company. A relatively
simple
way of finding out is casually to ask two or three separate people who
ought
to know the business requirements for the product what those
requirements
are. Ask a question something like this: "By the way, just for my own
interest, what is the A2 intended to achieve that the legacy product
doesn't, and who do we hope will buy it?"
If you get diverging answers, then there is a potential problem. If you
get
consistent answers, then pushing for the business requirements to be
documented is probably a waste of time. Just get a braindump from
somebody
of the business requirements and use them for your own reference and
guidance.
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 & 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 & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as beth -at- bdel -dot- com -dot-
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 & 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 & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as hbacheler -at- aol -dot- com -dot-
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.
________________________________________________________________________
AOL now offers free email to everyone. Find out more about what's free
from AOL at AOL.com.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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 & 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 & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
