First, rather than merely passively gathering requirements, an effective BA actively gathers data and then analyzes the data to discover the requirements.
Second, much of the data gathering actually involves digging—way beyond mere gathering--not only to find the frequently hidden data but more importantly to find out what data you need to collect. Far more commonly than recognized, BAs often unwittingly head down wrong paths gathering wrong data due to overly relying on (management's) inadvertently incorrect assumptions about what the project requires.
Third, users are only one of many sources of requirements. All users are customers, which can be internal or external; and there can be customers who are not users. All customers are stakeholders, and there can be stakeholders who are not customers. Contrary to another common misconception, users are not different from stakeholders-instead users are one of many types of stakeholders. Stakeholders, the all-inclusive category, are the source of requirements. You need to identify which stakeholders are likely to have data you need and then dig it out.
The most fundamental method for gathering data to aid in discovering requirements involves individually interviewing the various stakeholders. Techniques such as requirements workshops (also called Joint Application Development—or Design—JAD) and focus groups gather data from groups of stakeholders, which can be efficient to an extent but don't provide sufficient data to be relied upon as the only data gathering technique. Additional data can be gathered by reviewing relevant documents and researching literature, observing operations, and learning to do the work involved.
Fourth, there's one additional frequently-overlooked step between requirements and design of the software that will be developed. Software designs are not based directly on real, business requirements. Instead, software designs are based on creating a product that will satisfy the real business requirements. Therefore, after discovering the real, business requirements, the BA must define a product that presumably will meet them; and it's that product that software is designed and developed for.
This critical but frequently misunderstood distinction is made more confusing because what BAs and others commonly refer to as "requirements" actually are requirements of the product, system, or software they intend to create. For further description of the difference between real, business requirements and product/system/software requirements, see " Problem Pyramid discovering REAL software requirements."
Prototyping, visualization, user interface mock ups, walkthroughs, and most use cases are often touted as requirements definition techniques but in fact all are ways of examining the prospective product's ability to satisfy the (too-often-presumed rather than defined adequately) real, business requirements. Such methods indeed are helpful in the development process but do little to help discover the real business requirements the product must satisfy.
This was first published in August 2010