Title: The Wall

Dear C Vu editor (aka. Francis Glassborow)

[Yes - I have only just got round to reading July's issue of C Vu. Life is very busy.]

Peter Goodliffe's article on specifications was a very good overview of this important topic and made all the right points. However it omitted one type of specification that can be very useful but is often overlooked. To be awkward we call it the 'requirements specification' but 'user problem/need statement' or 'user requirements specification' might be better.

This document specifies what the user wants done or solved (as opposed to PG's 'requirements specification' which specifies what one is going to do about it). The users or customers can write this document themselves. If one sells to many customers rather than working to contract for one, the marketing department might write it. However, one often ends up writing it oneself. Particularly if one has many users, or a collection of change requests it is very helpful to collate all the things asked for into one document. It makes a much better input into the process of setting priorities and then agreeing what should be done. If possible the document should target the problems that need to be solved rather than the perceived solutions. For example 'we need to get messages from London to Bristol in 3 hours' rather than 'we need email between London and Bristol' - that way you do not rule out alternative solutions (for example a phone call) too early. However it is not always possible to distinguish the real problem from a proposed solution so do not be too dogmatic over this.

'Requirements' is a slippery term. To continue the confusion of names already mentioned above we combine the role of PG's 'requirements specification' and his 'functional specification' into a single document called the 'functional specification'. These days, if I was starting a new set of process documents from scratch, I would not call anything a 'requirements specification' as it means too many different things to too many people.

Stephen Baynes

<<srb@thekeyboard.com>>