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.
>
> 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 archive -at- web -dot- techwr-l -dot- com -dot-
