sorry about the delay in responding.
The problem you refer to can be mostly solved by keeping the
documentation. However, documentation is unpopular - both to write
documentation, and with the agile folks who posture that documentation
is a diversion from the real work. I think that we should try and be
as agile as possible, but we should also not lose sight of what we are
trying to accomplish.
There is more to a system than just building it. Which means there are
several reasons for both writing a good requirements document and
The first of these is reuse. Most organisations build systems that
while not the same, have certain qualities and functions that are
close to one another. It is enormously efficient if you can search
previous requirements documents and find the similarities, and thus
potentially reuse the requirements. If the newly-needed requirement is
the same, then the design and code for that requirement should also
exist. Within reason this can be very efficient.
To do this you must have some kind of requirements document repository
that allows for semantic searching. You will be able to do it on
keyword searching if all the analysts have used the same or similar
terminology. This makes it cheap as you can use Google's search engine
on your PC.
The second reason is problem solving. If the documentation exists, and
it is up to date, then you can examine it to find needed/non-needed
functionality. However, my experience is that documentation is rarely
kept up to date at commercial sites. You may need to correlate the
documentation with changes to the code. A record of the latter should
To summarise: the documentation lives beyond the life of the
development. A searchable repository helps, and with today's tools and
open source software, this is fairly easy to achieve.
the Atlantic Systems Guild
Our new book: 'Adrenaline Junkies and Template Zombies'