Welcome to EMC Consulting Blogs

There are some activities where doing it is harder than planning it, climbing Everest, would be a good example. There are others where it is the reverse, and I believe that writing a good requirements spec is one of them

Planning takes time and when under pressure to show progress then the simplest irrefutable demonstration that a BA isn’t spending all day on Facebook is to present the PM with pages of written graft, indexed, cross referenced etc. However this approach of getting something down on paper as fast as possible comes with great risk. The risk is that the requirements we start to write are not actually the root requirements, but either the requirement of the loudest member of the user group, or actually a solution dreamt up by the users.

Users inventing solutions is a sure-fire way to disaster, it somewhat defeats the object of getting a highly skilled consultancy in, if you are going to design the application yourself. It is a common scenario to be given a predefined application then work out what is was designed to do, specify that as requirements then hand over to someone else to redesign it. If the output of this process is the same as the input then… well I have never seen that happen.

The real skill is being able to get right down to the key underlying requirements, and this takes time.

You need to understand all the users, what is motivating the user of the application to be using it, speed, price, convenience etc, taking the first user’s view only is a route to disaster.

It should be possible to write a summary of the requirements in a list, each one no more than a sentence that does not refer to any application, screens, hardware etc. In other words, scope must be nailed

Once the real requirements are understood then the next hurdle is to understand when to stop writing. In a functional spec there is a fine line between sufficiently detailed to gain confidence from the users but not so detailed as to step on the toes of the technical designers.

The purpose of this piece is to advise that if the BA cannot clearly describe the scope of the piece (which is system independent) then the BA is not in a position to start writing a functional spec.

If this is the case, then despite the howls of anguish from the users, the scope is not yet fully defined; and unless the project is being managed on a time and materials agreement, cost and time estimates should not be considered until this scoping phase is complete. Otherwise you are committing to build something of unknown complexity and size for a fixed fee, which is yet another route to disaster.

If anyone has any contrary thoughts, then I would love to hear them.

Phil

Last weekend I was entering the final phase of constructing a barn like shed for my garden, the kind of construction that skirts the planning permission rules.

After cutting a piece of flooring to be the mirror image of what I wanted my friend flippantly said “measure twice, cut once”. Other than prompting an obvious remark it did make me think about how such an adage could have been applied to my professional deliverables.

Every waterfall IT project is littered with documentation and every one has some kind of requirements epic, often split into volumes written by someone acting as a BA. These documents have infinite variation and style and lurk under the terms of BRD (Business Requirements Document) FRS (Functional Requirements Specification) TOR (Terms of Req….. the list goes on.

But which is the best. What really needs to go in it:

Should non functionals be present?

Should include a design or just the base requirements?

If it includes a design, should it include wireframes?

Should it include the data set up for configurable variables?

Whilst working in the consultancy arena I have discovered that you always need to establish what is expected before you start. In other words:

“Ask twice, Write the spec once!”

The other challenge I have encountered is identification of  who are you writing it for, offshore developers, Tech leads, Account managers, project sponsors, end users? Should I write a textbook or just a brief oveview! Now I made a bit of an error here, I wrote mine for the person that was going to use it, in this instance it was the Tech Lead. What I should have done is write it for the person with the least understanding of the project. Every single one of these people need to read it and the key group are the end users, as without their support the project sponsor won’t sign and nobody goes anywhere. And generally end users are the least technical and the least comfortable with the process.

So now before writing a spec I would ask everyone what they are expecting, this will probably mean that a compromise is reached but what is delivered meets expectations. There are some basic guidelines: A small summary for the Sponsor, the requirements numbered for the developers and testers but structured according to how the users will use the system not according to how it will be built. However every set of circumstances are different and it may transpire that not even this is required . Now I would suggest:

“Ask everyone Twice, Write the spec once!”

Considering a mistake learned from is one worth making,  I now intend to issue the requirement documentation template before its populated, so the user can see the structure and format. Then I’ll write a single section, with an example of the chosen medium of requirements capture such as user story, and ask again.

Had I done this previously my documents would have reached completion months earlier as I could have changed them on day 2 rather than day 200.

For many readers this is nothing new, and once reaching this point all you think is that I can’t be that good at my job if I feel that stating these obvious point is of any worth, well all I can say is how many of you have ever cut that piece of wood in the mirror image…

The postings on this site are my own and don’t necessarily represent Conchango’s positions, strategies or opinions.