Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  What is difference between Want, Need and Expectaion?
Previous Previous
 
Next Next
New Post 12/18/2009 9:32 AM
User is offline Shawn Nikookar
2 posts
No Ranking


What is difference between Want, Need and Expectaion? 

Hi all,

I want to know that what difference is between Need, Want and Expectation when we want to collect business requrements. I will be thankful to answer with examples.

 
New Post 12/23/2009 11:49 PM
User is offline Newbert
5 posts
10th Level Poster


Re: What is difference between Want, Need and Expectaion? 

Hello Snikookar,

In specifying requirements you will encounter a number of categories by which requirements can be priortised to ensure that the most valuable / significant / mandatory items are focused on before the lesser wants and that expectations are only delivered if project time and budget allow.

In it's simplest form priority is typically: MUST have, SHOULD have and COULD have (which equate to your need, want and expect).

Take a look at MOsCoW

Hope this helps,

Joe

 
New Post 3/25/2010 12:28 PM
User is offline KIERANC
22 posts
9th Level Poster




Re: What is difference between Want, Need and Expectaion? 

Hi Snikookar,

I think MOSCOW categorisation can help you here. MoSCoW Rules is a technique used to prioritise a list of requirements based on the relative merits of each or their value to the business.Time and cost play a significant 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:

It 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.

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." 

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.

 

Regards,

K

 

 
New Post 3/30/2010 12:12 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: What is difference between Want, Need and Expectaion? 

 KIERANC wrote

Hi Snikookar,

I think MOSCOW categorisation can help you here. MoSCoW Rules is a technique used to prioritise a list of requirements based on the relative merits of each or their value to the business.Time and cost play a significant 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:

It 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.

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." 

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.

 

Regards,

K

 

Kieranc,

Agree with everything you said and wanted to get your views on the following...

Projects often die the death of a thousand cuts - we're running short of time and money so we'll just cut the scope a little bit here and rule that requirement out of scope and so on until the solution the project would deliver if allowed would be all but useless.

Does this mean then that once a requirement/scope statement is cut that the remaining should be reprioritised? The idea is that a requirement previously classified as Should Have may have become Must Have on the grounds that without it so much "significant value to the business" is lost that the solution is not worth the candle.

This reprioritiation is the only reprioritisation that could happen (no 'wants' can become 'coulds' , no 'coulds' can become 'shoulds' and no way for requirements to lose priority).

This raises the question of should the 'should have' been categorised as 'must have' to begin with or can it change priority?

It would be good to know your thoughts - and the thoughts of anyone else interested in this.

Guy

 
New Post 4/6/2010 9:40 AM
User is offline Anthony Chen
63 posts
8th Level Poster


Re: What is difference between Want, Need and Expectaion? 

 snikookar wrote

Hi all,

I want to know that what difference is between Need, Want and Expectation when we want to collect business requrements. I will be thankful to answer with examples.

 

what are you trying to get at? A need is something that can link back to the concrete business objectives, the reason the project was chartered in the first place. A want is something the users say they want, regardless of if it maps back to the business objectives. An expectation is what the users think they are going to get. Here are some interesting examples from a couple of recent projects.

1) The ROI was determined to be $20 million a year recurring by closing a revenue leakage hole in a client system. The client was basically handing out at least $20 million a year to their customers. Needs were any features that were directly required to close the revenue leak.

2) The finance team was based in malaysia. They were paid about $5/hour. They and their US managers wanted to add a significant number of usability features to improve the productivity of those resources. This was a want because it did not tie back to the core business objective. To save $50K/year they were willing to put at risk $20 million/year. These wants are not directly tied to the core business objectives. These wants are they key scope items that kill most projects

3) Expectations - on another project the business stakeholders left the company and new business stakeholders came on board in the last month of the project. When they started to do user acceptance testing they were very upset because the system was not what they expected. The system had a clear business case and every feature could be tied back to the business case. We are currently working with them to understand the value of the features that they would like instead and then walk them through the process of understanding the original business case. The original business stakeholders had discarded the features because the actual business value was miniscule - but the features do sound cool.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  What is difference between Want, Need and Expectaion?

Community Blog - Latest Posts

Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...
The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...

 






 

Copyright 2006-2021 by Modern Analyst Media LLC