This question already has an answer here:

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.

marked as duplicate by gnat, GlenH7, user40980, Martijn Pieters, amon Feb 19 '14 at 16:14

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
    In this question, people are discussing the use of specific method, its advantages and disadvantages. My question is how to determine if an additional feature adds value to the system, or it is just out of scope of the project. May be for client it is 'nice-to-have', but in reality it is very important – saakian Feb 15 '14 at 14:53
  • There's no way to quantify that. For example if a UI colorscheme setting is said to be absolutely necessary there could be a good reason. For example if it's a lighting control application like I'm working on then the ability to make the UI usable in the dark without blinding the operator is a key feature. If they're a client, then tell them how much the feature will cost and let them decide if they want it or not. – James Snell Feb 15 '14 at 16:53
  • @JamesSnell the problem is that we do not know the detailed requirements until signing the contract. After the contract is signed, we start the needs assessment and it is impossible to change the price if we have already agree on some 'approximate' one. That is why I cannot change the price, but I should keep the client in the project scope – saakian Feb 15 '14 at 18:02
  • 2
    @saakyan: This seems backwards. How can you give them a price if you don't even know the scope of the work? – Robert Harvey Feb 15 '14 at 18:11
  • @RobertHarvey yes, I know that is not a used practice. At first we know that the software is e.g. document management system, it will support windows authentication, should have some kind of user roles and permssions, etc, I mean some general requirements, not detailed enough in order to know all the features. After that, I conduct the needs assessment and that is why it is very difficult for me to keep them in scope – saakian Feb 15 '14 at 18:15

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

  • The following is a very good idea ''you either have to build something into the contract that allows them to add features for a price'', as these additional features are big problem for me. As for conducting needs assessment before price is agreed upon, that is impossible as there are number of companies who participate in bidding, and the client cannot conduct it with each bidder – saakian Feb 15 '14 at 18:31
  • 1
    Then hopefully you're experienced at making estimates without sufficient information, estimates that will give you enough money to deal with the inevitable aggravation that follows. You could tell the client that you intend to adjust your estimates if the needs analysis finds that the scope significantly varies from the client's original project description. – Robert Harvey Feb 15 '14 at 18:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.