Changes in Software Systems and the documents
I'd like to know how changes are documented in your organization. It is getting more difficult to identify the 'correct' behavior of any component because of a phenomenon I call document fragmentation.
When new features are designed, new documents are born to specify the new features. Usually this include changes to the existing design. So after a few releases, there is not one document that describes the release in its entirety, just the latest features. Thus in order to create a test plan, or review the system in its entirety, one has to go through all these documents and try to correlate what is current and what is obsolete. Often there is conflicting information that leads to coding errors and/or bad test cases.
I believe it would be better to have one set of design documents and revise them, much the same hardware designs are managed. For instance, when you revise a circuit diagram or mechanical drawing, the entire design is updated. Designers don't create a new drawing with just the new info. Can and should the same be applied to software specifications and requirements?