6．需求分析人员和用户的合作关系

　　的软件产品是建立在的需求基础之上的。而高质量的需求来源于客户和研发人员之间有效的交流和合作。通常，研发人员和客户或客户代理人，如市场人员间的关系反而会成为一种对立关系。双方的管理者都只想自己的利益而搁置用户提供的需求从而产生摩擦，在这种情况下，不会给双方带来一点益处。

　　只有当双方参和者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么时，才能建立起一种合作关系。由于项目压力和日渐增，所有风险承担者有着一个一起的目标这一点容易被遗忘。其实大家都想研发出一个既能实现商业价值，又能满足用户需要，还能使研发者感到满足的软件产品。

　　软件客户需求权利书列出了十条关于客户在项目需求工程实施中和分析人员、研发人员交流时的合法需求。每一项权利都对应着软件研发人员、分析人员的义务。而软件客户需求义务书也列出了十条关于客户在需求过程中应承担的义务。如果愿意，能将其作为研发人员的权利书。

　　客户有如下权利：

　　1：需求分析人员使用符合客户语言习惯的表达

　　需求讨论应集中于业务需要和任务，故要使用业务术语，你应将其教给分析人员，而你不一定要懂得计算机的行业术语。

　　2：需求分析人员了解客户的业务及目标

　　通过和用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要。这将有助于研发人员设计出真正满足你的需要并达到你期望的软件。为帮助研发人员和分析人员，能考虑邀请他们观察你或你的同事是怎样工作的。如果新研发系统是用来替代已有的系统，那么研发人员应使用一下目前的系统，这将有利于他们明白目前系统是怎样工作的，其工作流程的情况，及可供改进之处。

　　3：需求分析人员编写软件需求规格说明

　　分析人员要把从你和其他客户那里获得的所有信息进行整理，以区分开业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析能得到一份软件需求规格说明。而这份软件需求规格说明便在研发人员和客户之间针对要研发的产品内容达成了协议。软件需求规格说明书能用一种你认为易于翻阅和理解的方式组织编写。要评审编写出的规格说明以确保他们准确而完整地表达了你的需求。一份高质量的软件需求规格说明能有助于研发人员研发出真正需要的产品。

　　4：需求得到需求工作结果的解释说明

　　分析人员可能采用了多种图表作为文字性软件需求规格说明的补充。因为如工作流程图那样的图表能非常清晰地描述出系统行为的某些方面。所以需求说明中的各种图表有着极高的价值。虽然他们不太难于理解，不过你非常可能对此并不熟悉。因此能需求分析人员解释说明每张图表的作用或其他的需求研发工作结果和符号的意义，及怎样检查图表有无错误及不一致等。

　　5：需求研发人员尊重你的意见

　　如果用户和研发人员之间不能相互理解，那关于需求的讨论将会有障碍，一起合作能使大家“兼听则明”。参和需求研发过程的客户有权需求研发人员尊重他们并珍惜他们为项目成功所付出的时间。同样，客户也应对研发人员为项目成功这一一起目标所作出的努力表示尊重和感激。

　　6：需求研发人员对需求及产品实施提供建议，拿出主意

　　通常，客户所说的“需求”已是一种实际可能的实施解决方案，分析人员将尽力从这些解决方法中了解真正的业务及其需求，同时还应找出已有系统不适合当前业务之处，以确保产品不会无效或低效。在完全弄清业务领域内的事情后，分析人员有时能提出相当好的改进方法。有经验且富有创造力的分析人员还能提出增加一些用户并未发现的非常有价值的系统特性。

　　7：描述产品易使用的特性

　　你能需求分析人员在实现功能需求的同时还要注重软件的易用性。因为这些易用特性或质量属性能使你更准确、高效地完成任务。例如，客户有时需求产品要“用户友好”或“健壮”或“高效率”，但这对于研发人员来说，太主观了并无实用价值。正确的应是：分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性。

　　8：调整需求，允许重用已有的软件组件

　　需求通常要有一定的灵活性。分析人员可能发现已有的某个软件组件和你描述的需求非常相符。在这种情况下，分析人员应提供一些修改需求的选择以便研发人员能够在新系统研发中重用一些已有的软件。如果有可重用的机会出现，同时你又能调整你的需求说明，那能降低成本和节省时间，而不必严格按原有的需求说明研发。所以说，如果想在产品中使用一些已有的商业常用组件，而他们并不完全适合你所需的特性，这时一定程度上的需求灵活性显得极为重要了。