Collecting Requirements
Any stakeholder can specify requirements. Obviously the requests by users and project sponsors carry the most weight, however stakeholders such as developers, system administrators, and quality assurance personnel need to have a say since they usually have the best ability to manage the quality, cost, and time dimensions.
A requirement is usually a textual specification of the form “The system shall…” But beyond just documenting WHAT the system should do, you should also document WHY the system must conform to the requirement. This is helpful when developers interpret the requirements. It is also helpful when trade-offs need to occur between conflicting requirements.
Where possible, it helpful to express requirements in numerical terms, for example, the “The system shall return results to the users within 3 seconds, given a maximum of 100 records per result set and a maximum of 40 simultaneous users.” A requirement at this level of detail is helpful to developers, project sponsors, quality assurance personnel, database administrators, and system administrators. In that example, the technical stakeholders have some pretty concrete metrics to work with and the project sponsor has a reasonable way to verify the fulfillment of the requirement.
Warning. Stakeholders don’t always ask for what they really need. They make requests. It is your job to figure out what the real need is. You should ask yourself, “What is driving this request?” Requests provide context for needs. Is there a marketing reason for this request? Is there business process reason? Is there a compliance or legal reason? Is there a political reason?
Warning. Stakeholders quite often express their requirement in terms of features they have previous experience with. For example, “I would like a system that can handle email attachments”. In reality, what they want is a way to transfer files from one user to another, but if the only way they have ever done this is via email, they will explain their requirement in the only language they know. This represents a different form of thinking for the stakeholder. Instead of expressing WHAT they need, they are expressing HOW it should perform. Depending on the sophistication of the stakeholder, this may or may not be misleading. It is your job to translate “feature speak” back into needs, then recommend features that fulfill those needs.
