how to filter 'must-have' requirements from 'nice-to-have' requirements [duplicate]

Question

This question already has answers here:

What is the benefit of the MoSCoW technique? (4 answers)

Closed 6 years ago.

In building a software from scratch, there is necessity to conduct detailed needs assessment and find out what the clients/stakeholders really need.

When interviewing the end-users, organizing workshops or directly participating in business process for which the software product is written, there are many requirements which are very important, they are 'must-to-have' requirements .

In the same process, the clients name some functionalities, which are related to software, but they do not seem do solve any problem, so say 'nice-to-have' features., e.g. have the possibility to change the interface color, or be able to manage some processes which the software could do without their interference.

There should be some pattern to manage this kind of requirements. How to distinguish between these 2 kind of featuures? How to estimate does an additional feature add value to the software or is just augments the scope of the project?

Besides, how to persuade the clients that 'nice-to-have' features are somehow useful, but not really necessary.

Answer 1

They're the client. They get to decide what they want and what they don't want. The way you get them to tell you what they don't really need is by attaching time and dollar estimates to the unnecessary features. They will quickly realize which features are really important to them.

Before signing a contract with a client involving money, you need to know the specific scope of the work and how much the client is going to pay for that work. Once the contract is signed, it is very difficult to get changes to the amount of money that the client is going to pay, so you either have to build something into the contract that allows them to add features for a price, or constrain the scope in such a way that they cannot add features once the price is agreed upon.

If you don't know the scope of the work, the way you find that out is to gather customer requirements, and then develop a Software Design Specification (or what you call your "needs analysis") so that you can map out how much time it is going to take to fulfill each requirement. Charge them for preparing the needs analysis, on an hourly basis. This must be done before a price is agreed upon.

Structure your requirements so that each requirement must pass an acceptance test specified by the client. If it passes their test, then you declare that requirement completed. This prevents them from coming back and saying "Well, I know that's what I said I wanted, but what I really wanted is this."