Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Requirements  How to make users prioritise requirements usefully
Previous Previous
Next Next
New Post 8/10/2009 4:43 AM
User is offline thommeread
1 posts
No Ranking

How to make users prioritise requirements usefully 

 Hi everyone,

I have a question. I'm trying to get my users to properly prioritise their requirements so the PM has something to work with. My predecessor on this project tried printing out all of the requirements and getting the users to place them on a long table - one end being 'must haves', the other for 'nice to have' features. Of course, when she came back in the room, they had put every single bit of paper in a pile at the 'must have' end of the table (!).

So, in an effort to force the issue, I want to impose a percentage split of categories: e.g. only 50% can be p1, 30% p2, etc. However, I've got no clue what the percentage splits should be.

Any ideas? Anyone tried this approach before?



BA, London


New Post 8/12/2009 5:20 PM
User is offline Craig Brown
560 posts
4th Level Poster

Re: How to make users prioritise requirements usefully 
Modified By Craig Brown  on 8/12/2009 6:23:01 PM)

Rather than have them classify them into categories try getting your stakeholders to rank them from 1 to x.  1 is the most important and 2 is the second etc.


Either that or you as an analyst should do the work yourself and tell them what is most important.

New Post 8/13/2009 8:19 AM
User is offline Tony Markos
493 posts
5th Level Poster

Re: How to make users prioritise requirements usefully 


What is obvisous is that your users are lost.   Saying that everything is important is being done out of cover-your-behind fear.  What they are doing is crying out for leadership.

Chances are is that none of them have a comprehensive, integrated understanding of the essential business functionality.  Such an understanding is prerequiste to effective prioritization.  Simular to what Craig has said, come up with that understanding yourself; determine priorites from that understanding; get their OK on your priorities.






New Post 8/13/2009 10:32 PM
User is offline KJ
243 posts
6th Level Poster

Re: How to make users prioritise requirements usefully 



I sincerely hope that the BA does not independently set priorities. Asking the SME is a recipe for disaster; their priority is whatever makes their job easier. Therefore, its sometimes good to refocus on strategy. Why are we doing this? What are the benefits etc. Most of the time users and SMEs just do not have this strategic knowledge. That is when you ask the senior manager as well as check the project brief with the project sponsor. It is important to link the ESSENTIAL requirements to the CSF (Critical Success factors) of the strategy. I stress the ESSENTIAL requirement; not “the how we do things now” requirement.


So, if you have a proper traceability matrix that links requirements to strategy, you would know which requirement needs priority. You MoSCoW from the strategy and CSFs. Words the BA should never hear are: “thanks for the requirements. This is exactly what we wanted; but not what we need right now”. The BA’s job is to provide management with what they NEED right now to support the strategy! The rest is mere embroidery.


Warm regards,



New Post 9/1/2009 4:38 AM
User is offline KIERANC
22 posts
9th Level Poster

Re: How to make users prioritise requirements usefully 
Modified By KIERANC  on 9/1/2009 5:50:00 AM)



I would agree with that. The Traceability Matrix provides the key driver to link requirements to the strategy and assign priorities. Often we would use the MoSCow Rules Technique to prioritise a list of requirements based on the relative merits of each or their value to the business.

Time and cost play a key role in project delivery, so it is important to understand at the outset which features are essential to the delivery of benefits and the business needs most. "MoSCoW Rules" is a well established technique which is used to assign priority to requirements: This is complementary to Pareto's Law, often referred to in IT development as the "80/20 rule", which states that 80% of the objectives should be achievable with 20% of the resources. Once benefits have been identified and attributed to the requirements then time boxing can be exercised effectively. If a project has clearly prioritised its requirements it is better able to react to changing circumstances, e.g. a new "Must Have" requirement can replace a lesser priority one without affecting scope.

Using such a technique as MOSCOW will go a long way to producing an ordered list of requirements. With this technique in in conjunction with the users or business specialists assigned to your project assess each item on the list against the criteria set out below and allocate it to a category.  

Must have

These are requirements that are fundamental to the successful delivery of the project's objectives, i.e. the minimum usable subset. Without them the system or service is unusable. It is essential to be critical of all "Must Have" requirements and when assigning this priority the business should be told that the significance lies in the statement "Without them the system or service is unusable."

A good measure of the quality of the prioritisation process is manifested by the proportion of requirements in this category. Ideally no more than 40% and certainly no more than 60% of requirements should be classified as "Must Have".


Should have

This category covers important requirements that deliver significant value to the business but can be omitted if time constraints threaten delivery, i.e. the delivered solution will still be usable and meet its critical objectives without them.

Could have

These are requirements that enhance the capability of the required solution but can be left out of the current increment.

Want to have

but will not have this time round

"Wants" are those requirements of limited value or applicable to a limited group of users that can wait until later development takes place.

You will really need to guide them your users on this. Ideally no more than 40% and certainly no more than 60% of requirements should be classified as "Must Have.

Traceability in turn simplifies the process of reviewing the impact of proposed requirements changes. Projects must demonstrate the bi-directional traceability of their requirements as this is mandatory action to comply with both Sarbanes-Oxley (S-Ox) and CMMI (Capability Maturity Model Integration) and to ensure your Requirements are linked to the Business Strategy and can be prioritised effectively.


Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  How to make users prioritise requirements usefully

Community Blog - Latest Posts

Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...
I recently had the pleasure of chatting with Wolfgang Goebl, a visionary in the field of business architecture and enterprise design. His unique approach, which he refers to as "architectural thinking," and his work with the EDGY framework, offer valuable insights into the future of organizational structure and design. This tool covers th...
Our next speaker in our Blueprints for Success series is none other than Roger Burlton, a prominent leader in business architecture. As founder of Process Renewal Group, Roger has spent over three decades helping businesses worldwide translate strategy into execution. “Intention is everything.” – Roger Burlton Known for his ...



Copyright 2006-2024 by Modern Analyst Media LLC