Thanks to everyone for the comments on this article.  I thought I should respond to some of the points raised.

Firstly, it is true that I am "no Business Analyst".  However, it is also true that I am no "salesman" (and I’m not sure whether to be flattered or offended!)  I'm a Senior Consultant for a software quality management organisation - Experimentus (www.experimentus.com).  In my career, I've performed most roles in software testing and software quality, from work at the 'coal face' of writing and executing scripts, through to user negotiations, test management, configuration management, and various sorts of process assessment and improvement (including CMMi and TMMi).  I have worked in waterfall, V-model and RUP software methodology environments.  It could be said that I'm a 'techie' (for my sins).  Therefore, please don't make assumptions about myself or my background!

Secondly, to the level of the article itself.  This was developed from a previous piece of mine - "Ten Tips to reduce Software Development Life Cycle costs", which was published on various online sites including "StickyMinds.com" and "QAGuild.com" (and you can Google for it if you are interested).  That article was a brief spread on ten main issues that affect software companies – and was just a taster, really, with barely more than a paragraph on each issue.

I was then asked to expand upon each of the various tips listed in a series of new articles, and the first tip to be expanded upon was this one - "Focus on well documented functional requirements".

I must admit I had no idea which site this article would be published upon, once I had completed it - this is not unusual, as my work is published on a wide variety of websites.

It is clear that the ‘Requirements Networking Group’ website possesses a readership that is far more peopled with requirements professionals than the websites where my work has been published in the past.  Due to this, I do not doubt that the article seems very 'high level' (or even ‘basic’) and does not go into the depth perhaps associated with other articles published here.  This is not to say that I could not write an article to the appropriate level – it is merely the case that I was not asked to do so, in this instance.  I hope that this makes things clearer.

Thirdly, on ‘Agile’, and the note in my document stating that I was not dealing with this type of software project in the article.  To make myself clear, I did not mean that I do not like Agile, or do not respect Agile, or do not understand Agile, or that Agile is less important than ‘traditional’ software projects.  (I know that these have not been accusations, but I feel that clarity here is important.)  I am aware of the differences, as I am sure that many others are.  However, I did not feel that I could do justice to a discussion of requirements in both ‘Agile’ and ‘Traditional’ environments in a 1500-word paper.

I also feel reasonably sure that if I had merely left out the note stating that I was not dealing with ‘Agile’ software projects in this paper, there would have been some complaint about some aspect of what I said that did not fit with ‘Agile’ – indeed, this was a review comment I had before publication – so it is indeed true that there’s no pleasing all of the people all of the time!

Fourthly, thanks for the interesting comment about the “current” and “future” state of the business.  I totally agree with the sentiment.  However, I would also add that I believe that it is key that there is some kind of technical involvement in the requirements definition process.

Some businesses do this well, but I have seen many organisations where the Business Analyst agrees the requirements without any technical involvement, only for the agreed (between users and business) requirements to turn out to be near impossible to implement (at least, meeting budgetary / time / other constraints).

This can lead to either impossibilities being imposed upon the software development / test team (which leads to user dissatisfaction downstream) or a repeated and time-consuming review cycle whilst the developers / testers try to get something agreed that they are happy with implementing.

I can only speak from experience!  Of course, if the Business Analysts are technical enough to know whether or not certain things are possible, then this can suffice instead of direct development /test involvement.

In closing, I’d like to offer many thanks to everyone who has read this article, whether they have commented or not.  I hope that some people found it useful, or, if not, then at least found it interesting.  Sorry for the length of this response – I didn’t want anyone to think that I was ignoring their comment!

Kind regards

----------------------------

Nathan L. Weller

nathan [dot] wellerexperimentus [dot] com