Volere and requirements lifecycle

[Kim Abraham]

Hi,

I am currently working as a BA in a software development context. We
have been using Volere some time now and some practical questions
start popping up.

One thing I am particularly curious about is how other companies use /
maintain the documentation they produced during the requirements
gathering.

In my current work context (development of large, long lived software
applications), when working on a new software release, we sometimes
find functionality that was developed in a long gone past (developed
pre-Volere), for which it is no longer immediately obvious which
original requirement triggered its development.
As people (and therefore knowledge) continuously enter and leave the
company, it is not always possible to find the correct (i.e. a
knowledgeable) person to ask for clarifications.

Nevertheless, sometimes we *do* find unused functionality that was
once developed for a now obsolete requirement. Sometimes we only
*think* we found obsolete functionality and realize after deeper
investigation that there still was a need for it after all. :-)

Anyway, I would like to avoid these painful searches in the future and
I would like to know how other people manage the life and death of
their requirements. As far as I know, Volere does not really give an
answer to this problem or does it?
Do you use a requirements repository? How is it structured? Or do you
consider your requirements documentation to be "throw away after use"?

I would really appreciate your input / advice in this discussion!

Thanks & have a nice day!

Kim

[Robrecht David]

Kim

3 observations:
- Requirements documents are throw away project deliverables to me. Whatever solution is created, it will be a best effort, an acceptable or affordable solution. Sometimes we can deliver above expectations, but..... we are never sure what has really been created. I am bound to make an exception for projects where requirements are added to the backlog just in time and after talking it through with the deliver team(s). In traditional requirements engineering efforts where some of the work is done upfront, the requirements document does not always capture the full scope of the product. Especially since in long lived software product more than half of the product was created in "maintenance"

- So the solution is clear: keep the document updated. Somehow I am not convinced this is so easy to do. Another possibility would be to keep the rationale of all features documented together with the product documentation. I am convinced this can work if you make it someone's prime responsibility, a technical writer. Jim Coplien calls this the "Mercenary analyst pattern" http://users.rcn.com/jcoplien/Patterns/Process/section24.html .

- As much as would like the previous to be true, the only successful tracking I have seen was a product where in the code for each large chunk of functionality the code comment mentioned for whom it was made and who was using it.


Hope this helps to trigger a discussion.



Met vriendelijke groet

Robrecht David
robrech...@advalvas.be

Eenmeilaan 7
3010 Kessel-lo

[James Robertson]

Kim,

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
keeping it.

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
exist.

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.

Best regards,

James

___________________
James Robertson
the Atlantic Systems Guild
ja...@systemsguild.net
http://www.systemsguild.com
http://www.volere.co.uk

Our new book: 'Adrenaline Junkies and Template Zombies'
http://www.dorsethouse.com/books/ajtz.html
http://www.amazon.com/Adrenaline-Junkies-Template-Zombies-Robertson/dp/0932633676/ref=sr_1_6?ie=UTF8&s=books&qid=1196646341&sr=8-6

[gbcambridge]

Hi,

Kim... as you may suspect, this is a "length of string" question.. the
answer is "it depends". There are massively different types of
projects and organizations and these can massively affect the ground
rules for documentation. In lightweight projects ( I hesitate to use
the word Agile, because I am starting to feel that it really is just
"non-waterfall" in many organisations), heavy maintenance of old
documentation would be superfluous. Web page updates and design are a
possible candidate for "lightweight". There is not a lot of technical
challenge or choice (usually) and maintaining an English description
of what is essentially graphical is not advantageous. In fact it can
seriously affect productivity.
Conversely, a project implementing regulations may have to implement
total traceability of requirements. So, horses for courses is the
answer and I suspect that you need some principles to apply to sort
out these various horses. For me the main principle that I apply is
Risk. What is the risk to me (or the project) of NOT implementing
total traceability? Conversely what are the Benefits? What happened on
previous similar projects? If you address these questions openly, per
project, then you should get sensible answers from those involved.
For my own work I use a product TopTeam, from Technosolutions for
managing Requirements down into Use Cases and the associated tests.
There are many products that can be used but this seems to be light
enough and yet at the same time provide the depth needed for full
control as necessary. So there you have it... this piece of string
turns out to be quite elastic :-)

George