What requirements gathering technique should you use?

What requirements gathering technique should you use?

When gathering requirements, various techniques are available -- prototyping, modeling, storyboards, use cases, etc. Is one technique better than the other?

    Requires Free Membership to View

    Login

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Each technique has advantages and disadvantages. I would not say one technique is better than another. In fact, any project should probably use several of the techniques.

Methods that involve visualization of the requirements, such as prototypes, storyboards, scenarios, and to a certain extent use cases are beneficial when you have a business user who may not be concerned with the ins and outs of the technical solution or have a very long attention span for validating the requirements in a long-winded document. Using visual methods to gather and eventually validate the requirements with the user allows the analyst to drive the discovery more effectively than simply reading through a document with a prospective user.

Software requirements resources:
Software requirements gathering techniques

Using models to understand users' needs

Software requirements gathering process models

A combination of methods will almost always be required. Certain types of requirements lend themselves to a textual representation. It is difficult to storyboard that the system must respond in less than 1 second, but it's fairly easy to write a textual requirement stating that a certain type of transaction has an expected performance requirement. In that very same project, a storyboard might be very useful for drawing out (eliciting) a desired usage scenario from a customer service representative who will use the system every day to accept orders for your company.

Think about your audience and who will be validating that you have the correct requirements, then select the method that will provide the highest level of clarity for that audience.

This was first published in October 2007

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top