One paper I attended opined that "requirements are developed by the end user of the software and not by the developer". The paper had a lot to commend it, but on this one point I strongly disagree.
Capturing requirements is a skill. It is not easy to gather all facets of the business requirements, and it is not easy to document them in a fashion that best serves all the needs of the development process (and beyond). Thus, it is unreasonable to expect users (or developers) to possess these skills unless they have been explicitly trained.
If training is required (e.g. in the absence of trained Analysts), does it not make more economic sense to train developers? They can be trained once and then use their skills (and growing experience) multiple times on subsequent projects. If you train a user, they are unlikely to re-use those skills (unless their application is in a constant state of change).
There are a variety of tools and techniques for performing analysis for requirements capture. One of the key skills is the ability to see beyond the current business process and to capture the true needs of the new business process. It is not apparent that users have a proper understanding of all aspects of their current business process; it is far from likely that they can accurately specify their target requirements. If requirements are to be of use, they must be documented in a form that facilitates their subsequent use by a) architects and designers, b) test case authors, and c) maintenance developers.
In my opinion, it is a developer's responsibility to help the user understand their current business process (particularly the processes for dealing with abnormal situations), and to guide them in the art of the possible for their target requirements. Developers need people-skills in addition to knowledge of tools and techniques for requirements capture.
The art of the possible is a key element of the requirements capture phase. We've all had experience of i) users asking for features that seem simple to them but are difficult/expensive for us to implement, and ii) users not asking for features that would be of high value to them but which they thought were too hard for us to deliver. I've seen countless examples of users telling me that they need the ability to:
a) email various reports to groups of people, and
b) write reports as spreadsheets.
Users typically express requirements in terms of things with which they are familiar, i.e. existing technology. We can advise them of the extended capabilities of:
a) portal and publish/subscribe capabilities that avoid the need to clog-up the email system with uncontrolled copies of report, and
b) web report studio and add-in for Microsoft office that give the user the ability to "interact" with the data, without the need for the data to leave the data centre.
If you're a developer, and you don't have professional Analysts to help you, take an interest in requirements capture; appreciate the skills, techniques and tools at your disposal, and (if possible) get some training to enhance your ability.
Delivering a successful project is a result of good teamwork. It is not the users' sole responsibility to produce good requirements; nor am I saying that it is the developers' sole responsibility. It's a question of what each party brings to the table. The users have to be committed and provide their time in addition to their knowledge and experience of the business; the developers must be willing and able to help the users express their requirements. You will succeed as a team.
Garbage in, garbage out. If all of the project's stakeholders are not clear on what is to be delivered, the chances of meeting everybody's expectations are much reduced. The capture of good quality requirements is crucial for ensuring the success of your projects. Play your part!
