What is the ‘right’ SDLC Doc Template? – some observations

We recently received the following question:

“I work for a small subsiduary. Can you recommend sources of documentation templates so I can build best practice to model for our parent company? Then I could recommend visible thread to propagate the standards.”

The question opens up the very interesting, highly subjective & contentious :-) topic of software process & the ‘best’ document template. I thought I’d blog on this and share an extract of my answer as it may be of some help to folks considering this whole area. Not a simple question, but here was my answer:

— A number of questions have a bearing on what type of documentation you use in the lifecycle. I like to consider these things:

  • Size, duration and distributed nature of projects? Larger projects require more controls, distributed projects also require more controls. Long duration projects also require more controls. (i.e. gates in your process and associated templates)
  • Size of projects, are these projects you work on mission critical or not, or a mix? The former require heavy oversight, whilst they can be ‘agile’ in very sophisticated organisations, they typically are waterfall if you look closely. Less mission critical projects require way less docs and can be far more flexible in the depth of content captured.
  • Style of projects, are these projects you work on waterfall in nature or iterative (or agile)? In reality, many organisations claiming to be iterative/agile tend to be ‘fakes’ when you dig to any extent under the covers, in other words whilst they may have that tag they will turn out to be waterfall. Either way, both approaches require change and need to be measured for change over time in terms of document content
  • Culture of your organisation, is your org open to adopting better practices, are they able to absorb change quickly? If your org culture is somewhat resistant, I would recommend getting some kind of buy in from management & gradually introduce revised templates over a period of say 2-4 months, addressing certain key areas initially, eg: get a decent func reqs spec in place along with an associated non-funcs spec template in place is always an excellent start.

Regarding templates here a few sources to get you going:

1.) A requirements template I always recommend is James and Suzanne Robertson’s Volere, which can be found at: http://www.volere.co.uk/template.htm This used to be a free download, although I see James and Suzanne are now charging a nominal fee. Worth it however as it is very strong and covers out a wide set of considerations in requirements analysis.

2.) Another good option is to search docstoc (or scribd) for templates. Here’s one that I like (and this ships as a sample set in VisibleThread) for non-functionals: http://www.docstoc.com/docs/287018/Non-Functional-Requirements-Document-Template

3.) There is an open source project at: http://readyset.tigris.org/ It attempts to compile and assemble a fairly complete collection of templates for the various states of the software lifecycle. Specifically the full list of templates is at: http://readyset.tigris.org/nonav/templates/frameset.html Whilst it is an interesting project it comes out of academia and is very light on the early stages of articulating requirements but better on later stage docs. Worth a look but I would be inclined to cherry pick and augment with better sources.

We tend to base our guidance on using VisibleThread as the way to help power your approach. VisibleThread does come with a number of very good Best Practices out of the box (based on our own experience and on service partners practices) but in fact any Best Practice template can be used and applied in VisibleThread within 5 minutes to form the basis of any quality and process improvement initiative.

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

VisibleThread for IT

2:48 minutes
This summary overview shows the business case for using VisibleThread for IT programs. It shows why up to 42% of IT project cost can be attributed to defective documentation and demonstrates how VisibleThread addresses this large business issue.

Red-flagging Bad Language

3:47 minutes
There are some words/phrases that you should avoid in a proposal. This short video shows how VisibleThread scans and red-flags 'bad language' in your RFP Responses.

Using Discovery to spot Gaps

2:28 minutes
Identification of key concepts in issued documents (RFP etc.) helps align the language of the response volumes. Discovery in VisibleThread can uncover mismatches and lack of alignment between issuer and response docs to support reviews and underpin a winning bid.

Validating Win Theme Language

4:43 minutes
Win themes articulate business differentiation. Too often, with multiple contributors and authors, it is hard to keep theme language consistent.

Here we see how VisibleThread validates response docs against win themes by:

Scanning for Compliance Requirements

4:30 minutes
Proposal Managers have to manually scan issued documents or pdfs to spot requirements prefaced with 'shall', 'must' etc. and track them in spreadsheets. This demo shows an 'obligation scan' run against a SOW. All instances of 'will', 'must', 'shall' are identified. It concludes by generating a first pass of an Excel Compliance Matrix.

Collaborations and Team Reviews with
Discussions

5:31 minutes
Managing inputs from multiple contributors and conducting efficient team reviews is critical to successful outcomes. This demo shows how VisibleThread supports collaboration using web based discussions.

Integrating with MS SharePoint

2:36 minutes
VisibleThread integrates seamlessly with MS SharePoint using an intuitive export/import capability. This short demo shows how the integration works in practical terms. We cover:

Plain Language Analysis

4:11 minutes
Plain Language Analysis drives clear documentation. This demo outlines how VisibleThread can identify long sentences, passive langauge and facilitate plain langauge audits.