Researching Requirement Prioritisation

Currently I’m in the early stages of my Research and Design stages of my Final Year Project at University. I’m currently looking into Requirement Prioritisation and different techniques into splitting requirements up and prioritising them over other tasks. Below I’m going to attempt to discuss different prioritisation techniques to further reinforce my understanding of them.

MoSCow Requirement Prioritisation

MoSCoW Requirement Prioritisation ListFrom my understanding, MoSCow Prioritisation is one of most widely used techniques used. This technique is used by simply placing each requirement in a different category based upon how important the feature is. For example, a billing system for an online shop is placed in the ‘must have’ category. This is because it is required for the project to work end to end. There is four different categories used:

 

 

Must Have

Requirements are put into the ‘must have’ section of the list if the feature is critical to the project. If this requirement is not delivered the project is classed as a failure.

Should Have

Requirements that are put into the ‘should have’ category are still important for the projects success. However, These requirements are not as critical as must have requirements.

Could Have

Could have features are not required for the delivered project. They are desirable and could improve the overall quality of t he project. These would be the first features dropped if the project is starting to miss it’s deadline.

Won’t Have

Won’t have features are requirements that are agreed by stake holders that are not critical or not majorly beneficial to the system. These requirements are usually implemented if the project is ahead of schedule. These requirements will have minimal improvement to either the user experience or the overall quality of the project.

Needs-Based Analysis

Needs-Based Analysis is another commonly used requirement prioritisation technique. This method involves an analyst finding out with stake holders what is critical over what is just beneficial to the project. The one issue I have with this technique is that the analyst may not understand what is really critical to a system. This is more seen when the analyst may not directly be in the same job-role or industry as the day to day users of the system. Equally, stake holders may be blindfolded to what is actually critical to the system.

Crowd Sourcing

Crowd Sourcing is a convenient method of gathering requirements for a project that is used by the general public. A common example can be seen at Adobe’s Feature Request and Bug Form. Another way of gathering wishes from the community is by setting up a community on a open forum. On a forum you are able to have a section dedicated to feature requests that can then be prioritised using a combination of other prioritisation techniques.

Dot Voting

Dot-Voting is a technique where each Stakeholder is given a bunch of dots. Requirements are then listed, either on a board or on paper. Each stakeholder is then able to put their dots on each of the requirements they wish to see implemented in the project. They are able to put multiple dots on each requirement, increasing the chance of a requirement being highly prioritised however runs the risk of a more critical feature not being implemented.

I feel that this method of prioritisation has a small downside similar to Needs-Based Analysis whereby Stakeholders may get blindfolded to what they actually think is required and what is actually critical to the success of the project.

Buy a Feature

This method of prioritisation is similar to ‘Dot Voting’. Instead of dots, each stakeholder is given an amount of virtual currency.  Each requirement is then listed and then given a monetary value. Each stakeholder then buys their way into each requirement being prioritised. I believe this method of prioritisation has the same side affects as Dot Voting and Needs-Based Analysis.

Conclusion

Each method that I have discussed could be used for my project. I think that every method except from MoSCoW relies too heavily in having a large amount of stakeholders present at the meeting. Since I am the only one available to prioritise my project I think that I will be going with the MoSCoW method. Since I have contacts with people working in the industry that my project would be placed in, I feel that I am able to use this method easiest to get an idea about what is actually required.

You can find more information about prioritisation techniques at The Business Analyst’s Toolkit which is where I found most of my information.

Stay tuned – I’ll be posting more techie techie more stuff soon!