A template for software requirements gathering techniques

Requirements gathering can be a difficult, exhaustive process. We've assembled information on the best methods for requirements engineering -- prototypes, storyboards, models, state transition diagrams and use cases -- in one guide.

Requirements gathering is an essential part of software development. However, the process can be difficult. To...

help you, we've assembled a detailed guide of the best methods for facilitating the requirements gathering process. Not merely a collection of links, our guide has detailed descriptions to help you maneuver. We value your input. As always, if you know of an article, tip, tool or successful method for requirements gathering that should be included, send us an email with the information.

Prototyping

Prototypes range from the simple to the elaborate. But whether it's a paper sketch or an interactive digital design, a prototype should aid stakeholders and developers in anticipating requirements for a product.

Storyboards

Storyboards help developers visualize the sequence and interconnectedness of their work. They allow for a "big picture" approach that may be very useful in requirements gathering.

Modeling

A model can be made according to Unified Modeling Language (UML) or according to domain-specific modeling. Or, models can consist of stick figures on a whiteboard. All of these methods have their advantages and disadvantages. Use these links to figure out what method is right for you.

Modeling in the agile methodology

While these links discuss modeling from an agile software development perspective, the lessons may still be valuable to those practicing other methodologies. At the very least, one can gather ideas for one's own modeling processes.

State transition diagrams

State transition diagrams allow developers and users to see how a program might behave. This anticipation of events is useful when discussing requirements.

  • What is a state diagram?
  • State-transition diagrams: This article explains what state transitions are and why they are important. Also included are a series of questions for testing state-transition diagrams.
  • Automating state transitions: The Microsoft Developer's Network state transitions within Visual Studio. Code examples aid the reader.
  • Visual Requirements: There is a section devoted to state transition diagrams in this article on diagrams in software development. The author provides a clear perspective on state diagrams and the necessary part they play among the other diagrams. (PDF)
  • Understand testing diagrams

Use cases

Use cases are created to capture functional requirements in the software development lifecycle.

  • Software requirements analysis: Five use case traps to avoid: Employing use cases during software requirements analysis helps you improve your chances of developing software that truly meets their needs. But there are traps you should avoid, says expert Karl E. Wiegers, Ph.D.
  • Planning requirements for multiple software product releases: Most software products evolve over time. The challenge is creating a release strategy that provides the maximum customer value consistent with budgets, schedules, resources and business objectives. This article written by Karl E. Wiegers describes two techniques for planning such release strategies.
  • Use-Case Model -- Writing Requirements in Context: A well-written use case is an excellent tool in the requirements gathering process. This chapter is a great primer on creating use cases. (PDF)
  • Listening to the customer's voice: Understanding the customer's needs is crucial in requirements gathering. This article explains how use cases can facilitate communication with users.
  • Functional requirements and use cases: The connection between functional requirements and use cases is clarified in this white paper. A use case template and diagram are very helpful visual resources, the template in particular. (PDF)

Tools

Here are some tools that may prove useful in the requirements gathering process.

Other useful resources

Send in your suggestions: Are there other topics you'd like to see learning guides on? Send an e-mail to editor@techtarget.com and let us know what they are.

Next Steps

Learn how to use a nonfunctional requirements template

Some IT pros are rethinking requirements and the tester's role

Advice for getting the Agile Scrum right

Avoid garbage in/garbage out in your Agile project

What role should business play in Agile development?

It's all hands on deck when it comes to Agile requirements

This was last published in February 2007

Dig Deeper on Software Requirements Gathering Techniques

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

9 comments

Send me notifications when other members comment.

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

Please create a username to comment.

What are some of your tried and true techniques for software requirements gathering?
Cancel
Every time someone asks for something, we should ask as many WHYs as needed to get to the real root of the problem, so we can find the best way to approach it.
Cancel
Great point, Carlos. It's also important to make sure that the user/business doesn't feel like their requests are being challenged, but that those questions are meant to create the best solution possible. 
Cancel

I totally agree, the Five Whys game is a
great tool for better defining requirements. Framing the questions as part of a
game helps keep everyone on the same team. Zach Nies explained how to use the
Five Whys to cut
through organizational blame games
.



I'd also like to point out the Jenn Lent offered 5
tips on capturing better requirements
which included actively eliciting
requirements, using LinkedIn to find the right people to ask about
requirements, mapping to business goals, and valuing developers' doubts.

Cancel
The primary factor for where I work, outside of direct interaction with customers and getting a direct feel for what they need, is to aggressively use our product ourselves. through that process, we all contribute to the discussion, and in that effort, I feel we get superior requirements clarification than when we do not. This also helps with carlosdl's comment; we're able to get to the WHY's much more quickly and effectively. We also get a better feel of our customer's pain points as well, which definitely informs our efforts, too.
Cancel
Hi Michael, 
That is a great way to get requirements as long as you and your dev team fit the target audience. For any sort of consumer application meant for wide consumption, you're spot on! It would also work really well for building better software dev/test tools. We know plenty about what we need in those tools and can use that knowledge to our advantage.
However, I think it might be a tough strategy to implement for software that supports a specialized role like doctors or lawyers, or even sales or accounting. Would you recommend that teams developing software for such specialized roles use their own products for better understanding? If so, how would you address concerns that our bias as novices (in the context the software will be used) would make the product less effective for the professionals who will use it every day?
Cancel
James, there's two levels to this. I should have mentioned that my current team works on software that i geared towards a general use market (collaborative tools that fills a variety of needs and niches). Prior to this, I worked with a much more specialized software company that focused on Immigration Law, and you are correct, no matter how hard I tried to be a domain knowledge expert, I was never going to be a practicing Immigration attorney (well, not without going to Law School ;) ). In that case, we had a unique relationship with a law firm that we communicated with very regularly. Again, we did our best to try to anticipate their needs and what other clients would want, but we'd often ask them specific questions to understand the workflows that were important, which areas were settled vs. which areas were more volatile, and to have us communicate with them on a regular basis.

If at all possible, I believe in trying to model personas as close to the environment and practices as I can, but of course, there's only so much of that domain I will be able to understand in my role as a developer or a tester. Having a liaison who really understands the business helps tremendously (and to that end, we ultimately did hire some Immigration Law attorneys to work with our company to help us with business and product development).
Cancel
That makes a lot of sense. Building that close working relationship with professionals in the specialty area is probably the way to go for a lot of teams. Especially if you're building tools specifically for corporate employees. Makes it easy to find a captive audience ;) But seriously, it shouldn't be too hard to find users willing to talk with you and help you make their tools work better. It's a big win-win.
Cancel
Initially, just talking about the concept and the goal is a good way to get started. No one ever thinks of everything in these early stages, though. So during the development process, make sure there is lots of communication with business users, back and forth, with rapid feedback. Whenever a new feature is in test, demonstrate that feature to the users. 
Cancel

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close