Two things:

[with] complete requirements, [...] you [can] analyze the impact of new changes
on the existing functionality

What do you mean by "analyze?" From requirements? From source code? All
angles?
What do you mean by "impact of new changes?" Cost? Risk? Estimated date?
All?

Do you have an example of how, with "complete requirements" in hand, you
(1) determined the changes that were new, and (2) analyzed the impact?
And how that would have not been possible without a document? (Maybe
nobody knows the actual system's features? Which would seem unlikely.)

most change requests [...] relate to existing functionality. Thus, business
analysts waste [...] [time re-]writing requirements from scratch for each new
release.

hmmm. so, even though the "enhancement request" may have been a small
bit of new functionality added on to the "Portfolio Summary" screen, a
disproportionately massive document gets generated? As if the BA has to
document the history of civilization just to describe a new feature
tweak to an existing feature?

So, you might be proposing that having this "complete" documentation
maintained over time would help preclude the scenario of
over-documenting a requirement?

Maybe the simpler answer could be:

1. the BAS could ask for feedback on the usefulness of the doc to its
recipients
* Quite often, lacking any feedback, the BA may simply think
that "more is better" when it comes to
excruciatingly-detailed documents.
* Unfortunately, more often than not, 90% of the doc goes
unread by the developers and the business.
* But, guess what, if you are paid to write docs, you get lots
of docs
2. the app already documents the features that it supplies to the
users just by "being"
3. teach the BA that too much documenting is ineffective, a waste of
time, and possibly even harmful
4. establish a culture where trying to achieve the near- and mid-term
business results for these enhancement requests should be done in
as quick of a turn-around time as possible
* instead of paying people to generate docs (or code)...
* pay people to generate features in the hands of users

just a thought...


jon


blog: TechnicalDebt.com <http://technicaldebt.com>
View Jon Kern's LinkedIn profileView Jon Kern's profile
<http://www.linkedin.com/in/jonkern>


Yuri Chernak said the following on 8/8/08 5:21 PM:
> [responding to Craig]
>
> There are a few benefits of having and maintaining complete requirements:
>
> when you analyze the impact of new changes on the existing functionality
> when you need to transfer knowledge to offshore resources
> when you need to develop requirements for a new release and most of changes
relate to the existing functionality (let’s discuss this point in more detail),
etc.
>
> Speaking from my own experience, most of change requests (60% - 85%) on Wall
Street projects relate to the existing functionality. Thus, business analysts
waste a lot of effort when they do not maintain requirements they developed in
previous releases and write requirements from scratch for each new release.
>
> Craig – I guess, you represent the developers’ community. What if I ask you
the same question – why would you want to maintain source code you developed in
previous releases, when you need to develop new features for the next release? I
am sure you will find this question silly.
>
> My point is that business analysts have the same benefit of documenting and
maintaining complete requirements, as developers have a good reason to maintain
their code base.
>
> Regards. Yuri
>
> --- On Fri, 8/8/08, craig_w_brown <craig.brown@...> wrote:
>
> From: craig_w_brown <craig.brown@...>
> Subject: [AM] Re: Means to Capture a System's Current and Historical
Functionality
> To: agilemodeling@yahoogroups.com
> Date: Friday, August 8, 2008, 7:51 AM
>
>
>
>
>
>
> --- In agilemodeling@ yahoogroups. com, "Paul Oldfield"
> <PaulOldfield1@ ...> wrote:
>
>
>> I have come across many systems where new requirements are
>> expressed in terms of changes to the existing system, and
>> the requirements for the existing system are either
>> forgotten or were never known. In almost all cases the
>> people looking after the requirements for these systems
>> say it would be nice to have a full set of the requirements
>> of the existing system. In almost all cases they decide
>> the cost of doing this is not worht the value.
>>
>>
>
> I ask why you want to document requirements.
>
> Don't you really want features? You care about what the system does,
> not what problems were solved in the past.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
> ------------------------------------
>
>
>
>
>