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.
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. 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-
