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

 

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

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

 

通过与用户交流来获取用户需求、分析人员才能更好地了解你的业务任务和怎样才能使产品更好地满足你的需要。这将有助于开发人员设计出真正满足你的需要并达到你期望的优

秀软件。为帮助开发人员和分析人员，可以考虑邀请他们观察你或你的同事是怎样工作的。如果新开发系统是用来替代已有的系统，那么开发人员应使用一下目前的系统，这将有利于他们明白目前系统是怎样工作的，其工作流程的情况，以及可供改进之处。

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

 

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

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

 

分析人员可能采用了多种图表作为文字性软件需求规格说明的补充。因为如工作流程图那样的图表能很清楚地描述出系统行为的某些方面。所以需求说明中的各种图表有着极高的

价值。虽然它们不太难于理解，但是你很可能对此并不熟悉。因此可以要求分析人员解释说，每张图表的作用或其它的需求开发工作结果和符号的意义，及怎样检查图表有无错误及不一致等。

5：要求开发人员尊重你的意见

 

如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍，共同合作能使家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成

功所付出的时间。同样，客户也应对开发人员为项目成功这一共同目标所作出的努力表示尊重与感激。

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

 

通常，客户所说的“需求”已是一种实际可能的实施解决方案，分析人员将尽力从这些解决方法中了解真正的业务及其需求，同时还应找出已有系统不适合当前业务之处，以确保

产品不会无效或低效。在彻底弄清业务领域内的事情后，分析人员有时就能提出相当好的改进方法。有经验且富有创造力的分析人员还能提出增加一些用户并未发现的很有价值的系统特性。

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

 

你可以要求分析人员在实现功能需求的同时还要注重软件的易用性。因为这些易用特性或质量属性能使你更准确、高效地完成任务。例如，客户有时要求产品要“用户友好”或

“健壮”或“高效率”，但这对于开发人员来说，太主观了并无实用价值。正确的应是：分析人员通过询问和调查了解客户所要的友好、健壮、高效

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

 

需求通常要有一定的灵活性。分析人员可能发现已有的某个软件组件与你描述的需求很符。在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够在新系统开发

中重用一些已有的软件。如果有可重用的机会出现，同时你又能调整你的需求说明，那就能降低成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合你所需的特性，这时一定程度上的需求灵活性

就显得极为重要了。

9：要求对变更的代价提供真实可信的评估

 

有时人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的，所以，你有权利要求开发人员通过分

析给出一个的确真实可信的评估，包括影响、成本和得失等评估。开发人员不能由于不想实

施变更而随意夸大评估成本。

1 0：获得满足客户功能和质量要求的系统

 

每个人都希望项目获得成功。但这不仅要求你要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制。一定要明确说明你

的假设和潜在的期望。否则，开发人员开发出的产品很可能无法让你满意。