Defining requirements by priority

Or how do you know where to start?

For a large number of my posts I have written guidelines to help you write better requirements. One thing that I have not covered is how you can tell which requirements you should concentrate on.

If you refer back to my post How do you know you are done? you will find a subtle hint. Recall that I suggested that you get a handle on the basic overview of what a project is trying to accomplish.

When using iterative or Agile development methodologies you group together smaller pieces of functionality into work packages or releases. The order in which items get into work packages is usually based on a combination of anticipated benefits (ROI with NPV) and dependencies.

Why not use this same methodology to prioritize the order in which different areas of the overall requirements' set will be examined? This is why I say you need to understand the 'big moving parts' (as mentioned in a previous post.) Each of these 'big moving parts' (e.g., capabilities) has a defined benefit to it. Each capability can then be decomposed into more discrete sections.

The picture below outlines the basic principles of this exercise.


Once again, each of these sections can be assigned a priority (based on natural dependencies and the section's contribution to the benefit of the capability) After this activity has been done, a business analyst (e.g., you) can then start exploring the sections based on their priority. This yields a few advantages:

1. You focus on the most important pieces (e.g., highest priority.)
2. You reduce the amount of time spent on unimportant pieces. I know this sounds like the first item but I want to emphasize something. You can use this reasoning to control your requirement gathering sessions. When your clients, because of their attention to detail and natural excitement, venture into areas outside of your area of focus you will have the ammunition to refocus them. You can politely state that you want to park their current ideas and refocus back on the pertinent requirements' section.
3. You will have an idea about how much is left to do.

You may think, you could implement this methodology to help prioritize everything as you delve deeper and deeper into the most atomic requirements. Would I suggest doing it?

My answer is a polite, "No." Understanding how much benefit an atomic low-level requirement contributes to the overall project may be useful information, but I feel the amount of effort needed to maintain this data far outweighs any benefits that can be gained. You need to find a happy medium otherwise eventually your productivity will hit the law of diminishing returns. Furthermore, for low-level requirements, it may be difficult to say how much benefit a specific feature is providing.

Other related thoughts

Think about how the previous picture would change if a waterfall-type of approach was used rather than an iterative one.