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