Re: Monkey Business - (was, RE: I've been wrong all along...more pictures less words)

[Richard Lewis <tech44writer -at- yahoo -dot- com>]

Hey, I thought Gene was joking.  There is plenty of joking around on this listserv.  And questions made jokingly are often not answered.
   
  My answe to Gene's question:  Yes specs are important.   I am a big proponent of specing before development.   But again, up to 98% of the required work in specing is coming up with a comprehensive, integrated As-Is document.
   
  Richard Lewis

Lauren <lt34 -at- csus -dot- edu> wrote:
  > From: Richard Lewis
> 
> Gene Kim-Eng 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.

Lauren





       
---------------------------------
Building a website is a piece of cake. 
Yahoo! Small Business gives you all the tools to get online.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


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.