I may well regret throwing fuel on the fire that is keeping this
thread alive...


>>>> The problem was, we tried to document every detail, before
>>>> anything was built. A lot of assumptions had to be made.

>>> {When you have to make assumptions, you are /not/ "documenting"
>>> (what is), you are speculating (about what may be). }

>> Isn't that what all specs are about, and why they change? Unless
>> you're talking about documenting "after the fact", not during or
>> prior to the start of development.

> I have given examples before, one was a billing system for a company
> with complex billing procedures. There are many projects that include
> lots of requirements documentation that is not based on assumptions and
> that is created prior to the start of (and sometimes partly during)
> development. 

I'm uncomfortable that both sides keep arguing about the single word

    documentation

when it covers such a wide range of information from requirements &
specifications to user manuals.  Trying to write all of it, a priori,
and "casting it in stone" _is_ an impossible task.  But writing down
none of it in advance is a practical impossibility too.

But the vast majority of my clients over many years will _NOT_
sign off on a contract proposal until they know what it will cost
and I won't quote a fixed price until I know what I must deliver.
That mandates a requirements & specifications document up front.

Frequently it appears the business people who sign the checks are
more concerned with the final cost than what gets delivered (within
reasonable limits).  I expect I'd be laughed out of the room if I
proposed that they specify "just enough" to work for two weeks of
work -- and they pay my for that work -- with no up-front guarantee
of what the final product would look like.  That's the reality of
the marketplace that I work within.

And it doesn't have to be cast in stone.  In almost every project
that I have ever worked on, the requirements agreement was revised
one or more times during the construction process.  It does not
matter if it's software, cabling, or a building -- the change order
process (with fees for each change) is well know and understood.

I have had a couple clients who could live with the Agile purist
method -- but they are very rare and it took years to build a
relationship first.


>>> { Document the areas where you would have to make them as "TBD"
>>> or whatever, [...]

>> Then the whole document would have to be "TBD". You're saying that
>> once you document something, it is set in stone.

I've frequently had requirements documents where certain sections
are "TBD".  They get filled in during the project.  Sometimes on
an as needed basis; sometimes after certain milestones are met.

Nothing is "set in stone" until the final check is cashed and
the client doesn't sue you. :-)



In reference to Brook's Mythical Man-Month stating that the first
version of software will be thrown away...

>> I don't know, I end up refactoring most of my code at least once. :)

> That's easily possible. It doesn't affect, however, the fact that
> refactoring is expensive -- and an unnecessary cost if it could have
> been avoided by reasonable thinking ahead a few iterations.

It strikes me that an Agile purist's refactoring of code can be
considered to be "throwing away" the first version of software
in a piece-wise fashion.  At the end of the project, an Agile
program team has written the second version -- one bit at a time.

It's very difficult for any programmer to fully understand all the
application space constraints -- particulary the "unwritten rules"
or "corporate memory" that the workers develop over years/decades
through experience -- until the programmer(s) have been immersed in
the project for a while.  That alone makes it almost a given that
the requirements (as implemented in the software) will change even
if the "requirements spec" is never updated.

						Lee Jones


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist