When we deliver software products, we need to be able to tell our customers what they're getting. Not just product documentation, but specifically, every time we deliver a new release, what problems were fixed, and also what the new features are. If the software is subject to periodic audits, we need to tell them even more, especially the ability to trace a requirement or change request to what was changed.
We do that very well. We point to the build that the customer currently has and to the build that we're planning on shipping to the customer. We then ask for a list of problems fixed, a list of the new features, and any documentation available for the new features. In a few seconds we have our answer in a simple release notes document ready for the technical writer to spruce up.
This is good and useful. For many shops this might be a leap forward, but in the context of an ALM solution, it doesn't go far enough.
If my world is limited to taking a list of problems and features and fixing/implementing them and delivering builds with those implementations, the above release notes are helpful. However if, instead, my world deals with taking a requirements specification, which is changing over time, and then ensuring that a conforming product can be demonstrated to the customer, my world is a bit bigger. If those requirements also include a budget and delivery schedule, it's all the bigger. Then if I happen to have one of those management structures that want to know the status of development, including, whether or not we'll meet our requirements within budget and on time, it's bigger still. If I have to track what customers have which problems and feature requests outstanding with each delivery, it's even bigger.
Many customers ask for much more than release notes. They want to know about their outstanding requests. They want to know about the quality level of the software we're shipping them. They want to know about the risks involved. They want to review the product specs before development is complete so that they may have additional input on the functionality. They want to know if our delivery schedule will be on time. We need a virtual maze of data to track the information involved in the ALM process (see diagram) and to support the audit process.