Statistics: (2578 Views) (0 Comments) Print Posted: Thursday, September 20, 2007 Categories: Requirements Analysis (BABOK KA), Functional Specifications

A multitude of sins can be hidden behind the phrase “living document.” You can submit documents that are incomplete or inconsistent as long as you promise to fix it later. In this month’s issue of Strategic Software Engineering, I want to talk about the strategic importance of being realistic about the state of knowledge, plans and documents in a project.

When I first heard the term “living document” some years ago, I liked the concept. It signified an awareness that in an iterative, incremental development process we should be open to revisiting and revising designs, plans, and schedules. Markets become crowded, technologies emerge, and we learn. Updating strategies to reflect these new circumstances is a reasonable thing to do.

More recently I have encountered much abuse of the concept. “Don’t worry, it’s a living document. We can fix it later.” This indicates a misunderstanding of, or disregard for, the real intent of a living document. Releasing a document that is incomplete, inconsistent, or even incorrect is risky. Any document that is released will set expectations to a degree. Future releases will not have the same impact as the original and even if the document lives on the web where changes can be made centrally, some paper copies will undoubtedly confound the change process.

Author: John D. McGregor