要你的讲解。这时，请耐心一些对待需求和需求的精化工作过程中的反复，因为他是人们交流中的非常自然的现象，何况这对软件产品的成功极为重要。
3：准确而周详地说明需求
编写一份清晰、准确的需求文件是非常困难的。由于处理细节问题不仅烦人而且又耗时，故非常容易留下模糊不清的需求。不过，在研发过程中，必须得解决这种模糊性和不准确性。而你恰是为解决这些问题作出决定的最佳人选。不然的话，你就只好靠研发人员去正确猜测了。在需求规格说明中暂时加上待定(to be determined, TBD也可采用汉语拼音略写“DQD：待确定”)的标志是个不错的办法。用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方。不过，有时也可能因为某个特别需求难以解决或没有人愿意处理他而注上TBD标志。尽量将每项需求的内容都阐述清晰，以便分析人员能准确的将其写进软件需求规格说明中。如果你一时不能准确表述，那就得允许获取必要的准确信息这样一个过程。通常使用所谓的原型技术。通过研发的原型，你能同研发人员一起反复修改，不断完善需求定义。
4：及时地作出决定
正如一位建筑师为你修建房屋，分析人员将需求你做出一些选择和决定。这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权做出决定的客户必须积极地对待这一切，尽快做处理、做决定。因为研发人员通常只有等你做出了决定才能行动，而这种等待会延误项目的进展。
5：尊重研发人员的需求可行性及成本评估
所有的软件功能都有其成本价格，研发人员最适合预算这些成本(尽管许多研发人员并不擅长评估预测)。你所希望的某些产品特性可能在技术上行不通，或实现他要付出极为高昂的代价。而某些需求试图在操作环境中需求不可能达到的性能或试图得到一些根本得不到的数据，研发人员会对此作出负面的评价意见，你应该尊重他们的意见。有时，你能重新给出一个在技术上可行、实现上便宜的需求，例如，需求某个行为在“瞬间”发生是不可行的，但换种更具体的时间需求说法(“在50ms以内”,但若没有准确的技术分析不能轻易下结论)，这就能实现了。
6： 划分需求优先级别
大多数项目没有足够的时间或资源来实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，哪些是好的，是需求研发的主要部分。只能由你来负责设定需求优先级，因为研发者并不可能按你的观点决定需求优先级。研发者将为你确定优先级提供有关每个需求的花费和风险的信息。当你设定优先级时，你帮助研发者确保在适当的时间内用最小的开支取得最佳的效果。在时间和资源限制下，关于所需特性能否完成或完成多少应该尊重研发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对这种现实的。业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
7：评审需求文件和原型
正如我们将在第1 4章讨论的，无论是正式的还是非正式的方式，对需求文件进行评审都会对软件质量提高有所帮助。让客户参和评审才能真正鉴别需求文件是否的确完整、正确说明了期望的必要特性。评审也给客户代表提供一个机会，给需求分析人员带来反馈信息以改进他们的工作。如果你认为编写的需求文件不够准确，就有义务尽早告诉分析人员并为改进提供建议。通过阅读需求规格说明，非常难想象实际的软件是什么样子的。更好的方法是先为产品研发一个原型。这样你就能提供更有价值的反馈信息给研发人员，帮助他们更好地理解你的需求。必须认识到：原型并非是个实际产品，但研发人员能将其转变、扩充成功能齐全的系统。