16 Good Practices for Requirements Elicitation

Requirements don’t reveal themselves spontaneously. Apply these 16 practices for effective elicitation.

Image by freepik

The three major classes of software requirements — business, user, and solution — originate from numerous sources at different times during a project. The various types of information have different audiences and purposes and need to be documented in different ways. There’s more to requirements elicitation than simply “gathering requirements.”

Here are sixteen practices a business analyst (BA), product owner, product manager, or requirements engineer can use to discover the information the development team needs to build the right product. You won’t use all of these on every project, but they should all be in your tool kit so you can use the right one in each situation. I’m curious to know which of these practices — or others — you find the most important and most valuable. Please share your experience in the responses.

Actions

Define business requirements. A vision and scope document contains the product’s business requirements, including business objectives, constraints, and more. Business objectives keep the team aligned on achieving a useful outcome. A vision statement gives all stakeholders a common…