9：获得满足客户功能和质量需求的系统

　　每个人都希望项目获得成功。但这不仅需求你要清晰地告知研发人员关于系统“做什么”所需的所有信息，而且还需求研发人员能通过交流了解清晰取舍和限制。一定要明确说明你的假设和潜在的期望。否则，研发人员研发出的产品非常可能无法让你满意。
客户有下列义务：

　　1：给分析人员讲解你的业务

　　分析人员要依靠你给他们讲解的业务概念及术语。但你不能指望分析人员会成为该领域的专家，而只能让他们真正明白你的问题和目标。不要期望分析人员能把握你们业务的细微和潜在之处，他们非常可能并不知道那些对于你和你的同事来说理所当然的“常识”。

　　2：抽出时间清晰地说明并完善需求

　　客户非常忙，经常在忙的时候还得参和需求研发。但无论怎么，你有义务抽出时间参和“头脑风暴”会议的讨论，接受采访或其他获取需求的活动。有时分析人员可能先以为明白了你的观点，而过后发现还需要你的讲解。这时，请耐心一些对待需求和需求的精化工作过程中的反复，因为他是人们交流中的非常自然的现象，何况这对软件产品的成功极为重要。

　　3：准确而周详地说明需求

　　编写一份清晰、准确的需求文件是非常困难的。由于处理细节问题不仅烦人而且又耗时，故非常容易留下模糊不清的需求。不过，在研发过程中，必须得解决这种模糊性和不准确性。而你恰是为解决这些问题作出决定的佳人选。不然的话，你只好靠研发人员去正确猜测了。在需求规格说明中暂时加上待定（tobedetermined，TBD也可采用汉语拼音略写“DQD：待确定”）的标志是个不错的办法。用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方。不过，有时也可能因为某个特别需求难以解决或没有人愿意处理他而注上TBD标志。尽量将每项需求的内容都阐述清晰，以便分析人员能准确的将其写进软件需求规格说明中。如果你一时不能准确表述，那得允许获取必要的准确信息这样一个过程。通常使用所谓的原型技术。通过研发的原型，你能同研发人员一起反复修改，不断完善需求定义。

　　4：及时地作出决定

　　正如一位建筑师为你修建房屋，分析人员将需求你做出一些选择和决定。这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权做出决定的客户必须积极地对待这一切，尽快做处理、做决定。因为研发人员通常只有等你做出了决定才能行动，而这种等待会延误项目的进展。

　　5：尊重研发人员的需求可行性及成本评估

　　所有的软件功能都有其成本价格，研发人员适合预算这些成本（尽管许多研发人员并不擅长评估预测）。你所希望的某些产品特性可能在技术上行不通，或实现他要付出极为高昂的代价。而某些需求试图在操作环境中需求不可能达到的性能或试图得到一些根本得不到的数据，研发人员会对此作出负面的评价意见，你应该尊重他们的意见。有时，你能重新给出一个在技术上可行、实现上便宜的需求，例如，需求某个行为在“瞬间”发生是不可行的，但换种更具体的时间需求说法（“在50ms以内”，但若没有准确的技术分析不能轻易下结论），这能实现了。

　　6：划分需求优先级别

　　大多数项目没有足够的时间或资源来实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，哪些是好的，是需求研发的主要部分。只能由你来负责设定需求优先级，因为研发者并不可能按你的观点决定需求优先级。研发者将为你确定优先级提供有关每个需求的花费和风险的信息。当你设定优先级时，你帮助研发者确保在适当的时间内用小的开支取得佳的效果。在时间和资源限制下，关于所需特性能否完成或完成多少应该尊重研发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对这种现实的。业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。

　　7：评审需求文件和原型

　　正如我们将在第14章讨论的，无论是正式的还是非正式的方式，对需求文件进行评审都会对软件质量提高有所帮助。让客户参和评审才能真正鉴别需求文件是否的确完整、正确说明了期望的必要特性。评审也给客户代表提供一个机会，给需求分析人员带来反馈信息以改进他们的工作。如果你认为编写的需求文件不够准确，有义务尽早告诉分析人员并为改进提供建议。通过阅读需求规格说明，非常难想象实际的软件是什么样子的。更好的方法是先为产品研发一个原型。这样你能提供更有价值的反馈信息给研发人员，帮助他们更好地理解你的需求。必须认识到：原型并非是个实际产品，但研发人员能将其转变、扩充成功能齐全的系统。

　　8：需求出现变更要马上联系

　　不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响。变更是不可避免的，但在研发周期中变更越在晚期出现，其影响越大。变更不仅会导致代价极高的返工，而且工期也会被迫延误，特别是在大体结构已完成后又需要增加新特性时。所以一旦你发现需要变更需求时，请一定即时通知分析人员。

　　9：应遵照研发组织处理需求变更的过程

　　为了将变更带来的负面影响减少到低限度，所有的参和者必须遵照项目的变更控制过程。这需求不放弃所有提出的变更，对每项需求的变更进行分析、综合考虑，后作出合适的决策以确定将某些变更引入项目中。

　　10：尊重研发人员采用的需求工程过程

　　软件研发中具挑战性的莫过于收集需求并确定其正确性。分析人员采用的方法有其合理性。也许你认为需求过程不太划算，但请相信花在需求研发上的时间是“非常有价值”的。如果你理解并支持分析人员为收集、编写需求文件和确保其质量所采用的技术，那么整个过程将会更为顺利。尽管去询问分析人员为什么他们要收集某些信息，或参和和需求有关的活动。

　　系统分析人员在研发过程中可能会遇见以下问题，一些非常忙的客户可能不愿意积极参和需求过程，而缺少客户参和将非常可能导致不佳的产品。故一定要确保需求研发中的主要参和者都了解并接受他们的义务。如果遇见分歧，通过协商以达成对各自义务的相互理解，这样能减少今后的摩擦。