What is requirements gathering? – Jama Software

Making Assumptions About What You’ve Heard

Beware of simple, broad requirements. Don’t assume you know exactly what they mean. Above all, don’t assume all your stakeholders interpret those requirements in the same way.

Broad statements like, “The site shall have a blog” can mask a host of underlying assumptions. Scrutinize such requirements. Ask lots of questions. How will posts be displayed? How should authors be managed? How about comments, categories, tagging? Should there be an RSS feed?… and so forth.

Cross-check the answers you receive. Then come up with a set of more specific, verifiable requirements that everyone can agree upon.

Focusing on HOW Instead of WHAT

Requirements address two things. The first is WHAT the product must do (the functional requirements). The second is the necessary constraints on how the product does what it does (the non-functional requirements).

Requirements should not address HOW the product does what it has to do. In other words, your specification should be as implementation-agnostic as possible, within the constraints of the non-functional requirements.

During requirements elicitation, try not to think about how you’re going to implement the product. Forget about the latest technology your engineering department is obsessed with, your software team’s tool du jour, the features you feel are missing from the product baseline. Focus instead on your stakeholders’ needs.

Listen to what your stakeholders are saying first. Then gather, review and refine your requirements. Finally, once you’ve done all that, find the gaps in your baseline, and determine which technologies will deliver what your customers and stakeholders really want.

Insufficient Consultation With Stakeholders

Perhaps the biggest mistake systems engineers and product managers make in gathering requirements is failing to adequately consult with their stakeholders. Stakeholder consultation has several facets.

First, it is critically important that you drill down (and follow up) with each stakeholder group to fully understand their needs. Failure to do so is one of the leading causes of requirements failures.

A second important facet is transparency. Clean up your notes and share them after every interview, meeting, and survey. The easiest way to do this is through a modern RM tool to which all team members have access. Tools like Jama Connect allow you to attach notes to the requirements themselves for traceability purposes. This greatly increases the speed of the process and simplifies the review task.

The third potential pitfall in this area is insufficient review. Be sure to hold reviews where stakeholders can review the requirements, provide feedback, voice objections, and defend their positions. Open discussions involving all concerned stakeholders can help uncover and correct requirements flaws and achieve consensus.

Finally, get all your stakeholders to sign-off on the requirements to acknowledge that they understand them and that the requirements are sufficient for them to do their jobs. Be sure to make it clear to the stakeholder what his or her signature means.