In the world of software development, especially the Agile part of it, it is easy to live in the now and the current development effort. The Agile Manifesto values “Working software over comprehensive documentation.” Some people interpret this to mean that they do not need to worry about documentation as long as the software works. This is great for delivering software, but what happens after the software has been delivered and the project team is dispersed? What happens when the people that designed the software move on?
In my first software development project, we were working to modify some of the functionality of the current system. As we were having our elicitation sessions and learning about what the current system did and how it needed to change, I remember asking the lead on the project, “They should have all this information documented somewhere right?” The lead laughed a little and conceded that it Should be and in a perfectly efficient world it would have been, but in this world comprehensive documentation is not always practical.
In some circles, Business Analysts are thought of as note-takers, which would be drastically over-simplifying what we do, but a big part of the value that we provide involves documentation. Comprehensive documentation is like a retirement plan and I think most people understand the value of that. In order for it to work best, you must make regular contributions and build it up. Then when it is time to retire that software, you have everything you need for the next system.