管理人员在要求开发一个系统时并不会理解进行需求分析的重要性，他们只知道能不能尽快开发出相应的系统来方便使用，但是如果不做好需求分析，最终开发出的系统也不会有人用。
客户的需求认识并不像软件开发人员这样，了解的比较清楚，客户通常并不懂得从系统的实际用户处得到信息的重要性，然而从产品的实际用户处收集需求有着不可替代的必要性，所以导致项目最终失败的两个原因，一个是缺乏用户参与，另一个是不完整的需求规格说明。
在进行需求分析时，只有系统的实际使用者才能清楚的描述他们要用此系统必须完成的任务。
开发之前要清楚客户的概念。客户指直接或者间接从产品中获得利益的个人或者组织。项目的风险承担着有义务说明业务需求，即产品的高层次概念和产品的主要业务内容。业务需求只是高层次需求，还需要从产品的用户处收集用户需求，能够了解该产品要完成的任务，必须要去实际用户处收集用户需求才会有准确性。如果上述两种需求无法分析明白，除非需求极为简单，否则必须要消除需求中模糊不清的地方和一些使程序人员感到困惑的方面。
客户与开发人员之间要协调好关系，不能总是只想着自已一方的利益，还要为对方的利益着想。在开发过程中，软件客户既有相应的权利，也有对应的需求，要清楚自己一方的权利与义务，来为整个开发过程服务。
在权利方面，
要求分析人员懂得业务术语，软件的使用可能会用到这些业务术语；
分析人员一定要去了解业务和业务目标，必须要编写软件需求规格说明书，这在以后的开发过程中是至关重要的；
开发过程中使用的图表及流程图或符号之类，软件客户有权利知道每一个表示的意义，并且要求开发人员尊重客户的意见；
客户在描述产品性能时，很可能会用词非常主观，用词并不确切对于开发者来说，这样很可能会导致最后开发的产品不能让用户满意，所以描述的时候，分析人员要询问了解客户所要求的具体特性，要定量化的描述；
需求具有灵活性，是可稍微变更的，同客户分析之后，将需求变得灵活一点，这样就可以重用一些已有的软件组件，既能降低成本，也能节省开发时间，先同客户分析，再变更。
在变更需求时，会对软件开发的成本或者其他方面会有影响，这时客户可以要求开发人员分析给出真实可信的评估，开发人员不可以不想变更需求而主观随意夸大成本。
在义务方面，
在进行开发之前的需求分析阶段，客户需要给分析人员讲解业务概念和术语，因为分析人员需要使用这些术语来明白系统的问题和目标而开发出符合要求的系统。如果客户很忙，也需要客户抽出时间来进行详细的讲解。
需求规格说明书是一份很重要的说明，但是里面的内容不一定都能正确理解，所以必须要解决这个问题，可以在说明书中加上一些标记来方便日后的阐述。
在需要客户做出决定时，客户尽量根据当时条件，及时准确的做出决定，这样才不至于延误项目进展。
客户说明需求之后，开发人员会对这些需求进行可行性分析和成本的评估，客户要尊重分析人员进行的评价，从而来决定是否要调整需求。
分析人员了解需求之后，会提供每个需求的话费和风险的相关信息，这时客户应该根据这些信息来划分需求的优先级，从而使开发者在一定的时间内用最小的开支来取得最好的效果。
在书写完成需求规格说明书之后进行开发之前，需要让客户参与需求文档的评审，这样可以给分析人员带来反馈信息，尽早告知分析人员相关的建议，这样可以大大节省后期开发的时间，并且出错的概率也会大大降低。但是仅凭一份文档，用户很难知道软件是什么样子的，开发人员要做一个原型系统来提供更有价值的信息。
开发过程中，如果要变更需求，客户一定要马上联系开发人员，否则越是到开发后期，成本会越高，并且开发时间也会延长。
最后最重要的是，客户一定要理解分析人员在需求分析上花费的功夫，因为这个是非常必要的。
当需求规格说明书完成之后，客户需要在说明书上签字。这意味着客户同意终止需求开发过程，表明客户同意文档表述了目前项目需求的了解，如果以后要做变更，可以基于一定的准线来进行变更，虽然这有可能会影响到成本、资源、和项目工期等方面的问题。明白这些之后，就明白签约的意义了，并不只是签个名字的意义，这会在以后的开发工作以及提出需求变更时，仍能让双方满意。