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

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
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...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC