Ask the Expert

Four tips for gathering requirements for the new Business Analyst

Can you tell me the best way to gather requirements from users in such a way that the development team will adequately know how to design the software?

Requires Free Membership to View

Welcome to the wonderful world of business analysis! You're fortunate that the answer to this question can enable you from the start of your career to avoid falling prey to four common misconceptions that limit effectiveness of many business analysts (BAs).

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

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: