Home/ Questions/Q 121033
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T03:54:21+00:00

I work for a CMMI level 5 certified company and one thing I hate

  • 0

I work for a CMMI level 5 certified company and one thing I hate about is the amount of documents we prepare (As a programmer I already hate documents). We have lots and lots of documents like PID(project initiation doc), Business requirements, System requirements,tech spec, Code review checklist, issue logs, Defect logs, Configuration management plan, Configuration management check list(s), Release documents and lots…

Almost 90% of these docs are just done for the sake of QA audit 🙂 .. What do you think are the most important documents for a project? What documents can be used in the long run by another developer?

Please share your good practices here. I would like to use them for my own projects or the company I am planning to start in the long run.

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. The key document is a good functional spec. There should be one and only one reference document for a system.

    Overdoing documentation proliferates a large number of small requirements and spec documents every time someone changes a system or interface. For a system of any complexity, before long you have your spec distributed around several hundred assorted word, excel, visio and even powerpoint files. When this happens you lose clarity about what is current or even whether you have located and identified all pertinent documentation.

    The BRD-SRD-Tech spec progression is based on an assumption that the business signs off the BRD, a business analyst signs off the SRD against requirements documented in the BRD and the technical specification is signed off against the SRD. This generates a web of sign-offs, multiple documents with redundant information and makes it difficult and clumsy to keep the spec documents up to date.

    Because of this, subsequent requirements documentatation tends to take the form of a series of change request and supplemental requirement and spec docs, each with their own sign-off and audit process. You gain CYA and audit trail (or at least the appearance of an audit trail), but you lose clarity. There is now no definitive reference document for the system and it is difficult to establish what is current or relevant to any particular activity. The net result is that your business analysis process gets bogged down in forensic research, which adds overheads and latency to delivery schedules.

    A spec document should be built in such a way that there is one definitive reference for any given system or subsystem. The document should be kept up to date and versioned. Get a good technical documentation tool like Framemaker, so your process can scale, and the document has some structural integrity of the sort lacking on Word.

    • 0