Anyone who derives direct or indirect benefit from a product or service offered is a customer. It’s not necessary that the customer may be always right. However, the customer has a viewpoint and one must understand and respect customer’s viewpoints rather than forcing developers to determine among the customers who do not agree with conflicting project requirements.
As a software customer one would be primarily responsible for the following activities: Customers at times believe that the analyst or the member from the development team should already know what the customers need. Defining business requirements is not the ownership of the customer but the project team.
It would be ideal if the analyst is given the pulse of the current systems and processes coupled with existing documents to educate them about customer’s business concepts and terminology.
Customers usually don’t find it significant to invest time with the project team for requirements gathering or elicitation activities. Sometimes customers get so busy with the key responsible areas at work that they usually don’t give justice to the requirements gathering activity and the requirements gets captured just on assumptions.
Customer needs to prioritize what requirements are crucial and critical to the project. Requirements, which are vital, need to be delivered on priority whereas those that are good to have features can be delivered phase wise. Customers have to understand that not all requirements can be given at the same time. Phase wise delivery would be ideal.
Nilesh Raje works as Business Analyst with SYSTIME Computer Systems Ltd. based in Mumbai. He also has his articles published earlier with RQNG, International Institute of Business Analysis, ProjectTimes, Business Analyst Times and ManagementNext magazine. He's been a reader here for a while and has proposed this question;
Who decides a project’s requirements?