On every project I've ever worked there seems to be a huge amount of effort undertaken to document requirements, create user manuals etc and at the same time someone else is writing a technical specification of the same system. I've seen how Quality Centre and Cucumber try to address this problem but I wondered how does your team document their software? Is it possible to have one place which product, test and development all use? And the biggest challenge, how do you keep it up-to-date?
Have you read Specification by Example by Gojko Azdic and the concept of 'living documentation' ?
I haven't but it sounds like I should :)
Looks like that might be the next book on my readng list
We try to follow a pretty standard waterfall SDLC process.
1. A Product Marketing Manager creates some form of Marketing Requirements doc.
2. A lead developer breaks this down into feature size pieces and creates a Development Spec, which marketing has to sign-off on. This goes to QE and Doc for high level test plans and doc planning.
3. When Dev completes the related work they update the Spec (we hope) with any relevant changes or information that came up during implementation. QE and Doc get the updates.
4. Defects filed during test may results in changes or clarification required in the spec. Test plans should cross-reference the dev spec.
Some points to note:
Your developers probably use some form of revision control or data management tool. You should also use that for all specs and test plans. Best to have a central repository so people know where to find the latest version of important documents.
The Dev Spec is kept up to date (theoretically) until release. QE and doc look to the Dev Spec. Until release. After release, we don't touch the dev specs anymore, but update test plans and end user docs as needed.
Defect fixes that require end user doc updates get tagged for tracking.
Addressing an earlier comment, our user docs are all online, and come from the same place as the context sensitive help, so we don't differentiate them.
This is definitely not an agile process - but I am really curious about newer methods of dealing with specs and documentation, which is why I just started reading Specification by Example. (How did my wife know to get me that book for Christmas?)