决方法和其他信息。通过这些分析就能得到一份软件需求规格说明。而这份软件需求规格说明便在研发人员和客户之间针对要研发的产品内容达成了协议。软件需求规格说明书能用一种你认为易于翻阅和理解的方式组织编写。要评审编写出的规格说明以确保他们准确而完整地表达了你的需求。一份高质量的软件需求规格说明能有助于研发人员研发出真正需要的产品。
4：需求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性软件需求规格说明的补充。因为如工作流程图那样的图表能非常清晰地描述出系统行为的某些方面。所以需求说明中的各种图表有着极高的价值。虽然他们不太难于理解，不过你非常可能对此并不熟悉。因此能需求分析人员解释说明每张图表的作用或其他的需求研发工作结果和符号的意义，及怎样检查图表有无错误及不一致等。
5：需求研发人员尊重你的意见
如果用户和研发人员之间不能相互理解，那关于需求的讨论将会有障碍，一起合作能使大家“兼听则明”。参和需求研发过程的客户有权需求研发人员尊重他们并珍惜他们为项目成功所付出的时间。同样，客户也应对研发人员为项目成功这一一起目标所作出的努力表示尊重和感激。
6：需求研发人员对需求及产品实施提供建议，拿出主意
通常，客户所说的“需求”已是一种实际可能的实施解决方案，分析人员将尽力从这些解决方法中了解真正的业务及其需求，同时还应找出已有系统不适合当前业务之处，以确保产品不会无效或低效。在完全弄清业务领域内的事情后，分析人员有时就能提出相当好的改进方法。有经验且富有创造力的分析人员还能提出增加一些用户并未发现的非常有价值的系统特性。
7：描述产品易使用的特性
你能需求分析人员在实现功能需求的同时还要注重软件的易用性。因为这些易用特性或质量属性能使你更准确、高效地完成任务。例如，客户有时需求产品要“用户友好”或“健壮”或“高效率”，但这对于研发人员来说，太主观了并无实用价值。正确的应是：分析人员通过询问和调查了解客户所要的友好、健壮、高效所包含的具体特性。
8：调整需求，允许重用已有的软件组件
需求通常要有一定的灵活性。分析人员可能发现已有的某个软件组件和你描述的需求非常相符。在这种情况下，分析人员应提供一些修改需求的选择以便研发人员能够在新系统研发中重用一些已有的软件。如果有可重用的机会出现，同时你又能调整你的需求说明，那就能降低成本和节省时间，而不必严格按原有的需求说明研发。所以说，如果想在产品中使用一些已有的商业常用组件，而他们并不完全适合你所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9：获得满足客户功能和质量需求的系统
每个人都希望项目获得成功。但这不仅需求你要清晰地告知研发人员关于系统“做什么”所需的所有信息，而且还需求研发人员能通过交流了解清晰取舍和限制。一定要明确说明你的假设和潜在的期望。否则，研发人员研发出的产品非常可能无法让你满意。
客户有下列义务：
1：给分析人员讲解你的业务
分析人员要依靠你给他们讲解的业务概念及术语。但你不能指望分析人员会成为该领域的专家，而只能让他们真正明白你的问题和目标。不要期望分析人员能把握你们业务的细微和潜在之处，他们非常可能并不知道那些对于你和你的同事来说理所当然的“常识”。
2：抽出时间清晰地说明并完善需求
客户非常忙，经常在最忙的时候还得参和需求研发。但无论怎么，你有义务抽出时间参和“头脑风暴”会议的讨论，接受采访或其他获取需求的活动。有时分析人员可能先以为明白了你的观点，而过后发现还需