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.
RE: I've been wrong all along...more pictures less words
Subject:RE: I've been wrong all along...more pictures less words From:"Lauren" <lt34 -at- csus -dot- edu> To:<techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 10 Aug 2007 12:59:47 -0700
I have a problem with the concept "as-is." In this case, it is too vague.
For Richard, it is the current state of a business process. For John, it is
the (probably packaged) state of a software program and it cannot exist for
new software. For sales, it means that there is no warranty. So I don't
like the term because of its multiple and easily interchanged meanings.
In a couple of my jobs, I would document the current state of the business
process and, in dead time, program applications to automate many of the
processes. There was an "as-is" state for the collection of processes and
there was not an "as-is" state for the collection of applications until the
applications were developed. The documentation that I produced supported
both, but with different version numbers of the documentation. Technically,
the documentation supported two as-is states; one was the state of the
processes without the applications, version 1, and the other was the state
of the processes with the applications, version 2. The end result of the
processes performed with either version of the documentation produced the
same result, so this was the same process with two different as-is states.
Now my little process applications are not exactly at the same level as
large software applications, but documenting the process without the
application and then with application required documenting the same business
and functional requirements. I documented requirements when I documented
the processes and I built the applications consistent with the requirements.
So the applications were an optional tool, but the requirements, which were
the critical piece of the documentation were based on the current, or as-is,
processes and not the, at the time, undeveloped applications.
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
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-