Four Questions You Should Ask Before Completing Your Requirements

When Push Comes to Shove

Gathering requirements seems like a straightforward process, but sometimes it's hard to figure out the relative importance of the requirements. If you're running an agile project, it's a little easier because you'll discover requirement priorities during the planning of a release or iteration. However, if you're taking a phased or waterfall approach, it's important to know which features or requirements must be in the solution, and which ones the users can live without. Of course you could just ask them to prioritize the requirements (for instance on a high, medium, and low scale); however, how many times do they prioritize everything as high? That's why I developed a simple, four-question set that makes it easier to communicate priorities.

The Full Spectrum of Needs and Wants

To make the conversation go smooth around requirements prioritization, ask your users these four questions:

• Which requirements must be done?
• Which requirements should be done?
• Which requirements might be done?
• Which requirements could be done?

You could ask the user to make the categorization each time a requirement is presented; however, I find it's best if you wait until all the requirements have been gathered. Once the initial requirements interview is done, you should have a neat list of requirements to discuss with the user. At this point, explain to them that, due to time and budget constraints, some requirements may not get done. Therefore, it's important that we focus our efforts early, on those requirements that absolutely must be done. For instance, the biggest value of your solution may be the integration of three systems: sales, order processing, and accounts receivable. Since it’s impossible to do this manually, this requirement is a must. Have the user highlight these deal-breakers, and then move on to the next question.

There are some requirements that really should be done, although the solution would still be useful if they’re missing. For example, there may be a reporting requirement that currently takes Mary several days to complete. Ideally, your solution would generate this report in seconds, saving Mary several days of work every month. However, Mary can continue to doing the report manually if this feature never makes it in. After musts and shoulds, we explore requirements on the wish list.

Requirements that might be done are nice-to-haves. In the high, medium, and low scale; they would end up with a low priority. There may be some user experience nuances like a “Save and Submit” button so the user can save a click here and there. I like the language of might versus low priority. It seems people have a hard time with anything that’s labeled as a low priority, which is why you never see them in your requirements documents. The final question allows your users to stretch their imagination a bit.

Requirements that could be done are usually over-the-top. Imagine an auto-complete function that can handle typos, misspellings, and even semantic proximity (e.g., it includes road whenever the user types street). Or a translator that automatically adjusts for local dialects. These are the things you might hear you user start off by saying, “In a perfect world…” Most likely, requirements like this won’t make your initial list, so it’s fine to explore them after the fact.

Conclusion

When brainstorming requirements with users, it's quite natural for them to communicate a wish as a need and vice versa. As a responsible business analyst, it's important for you to get these priorities straight. High, medium, and low scales don't work because everyone wants everything to be a high priority. Before completing your requirements, have a conversation with your users around for key questions, involving: must, should, might, and could. This simple conversation up front saves a huge amount of frustration and disappointment down the line.