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.
Monkey Business - (was, RE: I've been wrong all along...more pictures less words)
Subject:Monkey Business - (was, RE: I've been wrong all along...more pictures less words) From:"Lauren" <lt34 -at- csus -dot- edu> To:"'Richard Lewis'" <tech44writer -at- yahoo -dot- com>, "'Gene Kim-Eng'" <techwr -at- genek -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Sat, 11 Aug 2007 10:25:31 -0700
> From: Richard Lewis
>
> Gene Kim-Eng <techwr -at- genek -dot- com> wrote:
>
> However, do you agree that there has to be some specs in
> place before you start creating the actual banana peel calculator?
>
> Richard Lewis:
>
> The banana peels are only a mechanism of the As-Is. The
> As-Is is the primary input to creating the specs.
>
Richard,
Do you realize that not only did you not answer the question, you completely
circumvented the subject while using the same terms and allusions to the
same concepts in the question? That really takes talent. But it is only
talent if you intentionally used this squirrelly linguistic manueuver to
avoid the question. If avoidance of the question was not your intent, then
why not answer the question?
Maybe you don't understand the question, so perhaps you could instead
prioritize the items that follow in the order that they are documented, or
at least occur.
* Requirements and Specifications
* Software that supports a business process
* A business process
Before you do prioritize the list, let's apply this to your example so that
we are all following the same elements.
Richard Lewis' example, "I am referring to the software under development -
which may include automation of previously manual procedure. If we had a
monkey calculating sales tax using banana peels, and we are now developing a
software program to automatically calculate the sales tax, the monkey,
banana peels, and the monkey's thought process in using the banana peels
would be the As-Is for the application being developed."
Here we have a number of process supporting components.
* a monkey calculating sales tax using banana peels that I will call the
"monkey business process"
* a software program to automatically calculate the sales tax that I will
call the "monkey business calculator"
* the monkey, banana peels, and the monkey's thought process in using the
banana peels would be the As-Is that I will address now
To this list of ingredients we must add requirements because the monkey does
not work in a vacuum. There must be a business need that the monkey's
process satisfies and there must also be process needs that the software
satisfies. The third item in your laundry list, the "As-Is" description,
seems to relate to software requirements, although you do not seem to
discuss requirements. I will assume that they are software requirements
because, as I said, the monkey does not work in a vacuum and the third item
does not include business needs. You never address Functional
Specifications. So I will update the list of components to your software
documentation.
* Business Requirements that can presumably be derived from the monkey
business process and are probably "calculate sales tax"
* Software Requirements that can possibly be derived from your concept of
"As-Is"
* Functional Specifications
So now we have an updated list that generally occurs in the same order
across different, but well-organized development projects. Disorganized
projects occassionally get bizarre and random orders. What is important
here, is what is the most effective order for the list that follows given an
ideal set of circumstances?
* Monkey Business Process
* Monkey Business Calculator (software development)
* Business Requirements
* Software Requirements
* Functional Specifications
Everyone can play along if they want. There are, of course, more pieces to
effective documentation and development projects, like User Requirements,
but these five items appear to be the focus of contention. Actually, the
last item is the focus, but it keeps getting circumvented in the discussion,
while there is either allusion to or discussion of the other four.
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-