客户有下列义务：
1：给分析人员讲解你的业务
分析人员要依靠你给他们讲解的业务概念及术语。但你不能指望分析人员会成为该领域的专家，而只能让他们真正明白你的问题和目标。不要期望分析人员能把握你们业务的细微与潜在之处，他们很可能并不知道那些对于你和你的同事来说理所当然的“常识”。
2：抽出时间清楚地说明并完善需求
客户很忙，经常在最忙的时候还得参与需求开发。但无论如何，你有义务抽出时间参与“头脑风暴”会议的讨论，接受采访或其它获取需求的活动。有时分析人员可能先以为明白了你的观点，而过后发现还需要你的讲解。这时，请耐心一些对待需求和需求的精化工作过程中的反复，因为它是人们交流中的很自然的现象，何况这对软件产品的成功极为重要。
3：准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且又耗时，故很容易留下模糊不清的需求。但是，在开发过程中，必须得解决这种模糊性和不准确性。而你恰是为解决这些问题作出决定的最佳人选。不然的话，你就只好靠开发人员去正确猜测了。在需求规格说明中暂时加上待定（to be determined, TBD也可采用汉语拼音略写“DQD：待确定”）的标志是个不错的办法。用该标志可指明了哪些需要进一步探讨、分析或增加信息的地方。不过，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而注上TBD标志。尽量将每项需求的内容都阐述清楚，以便分析人员能准确的将其写进软件需求规格说明中。如果你一时不能准确表述，那就得允许获取必要的准确信息这样一个过程。通常使用所谓的原型技术。通过开发的原型，你可以同开发人员一起反复修改，不断完善需求定义。
4：及时地作出决定
正如一位建筑师为你修建房屋，分析人员将要求你做出一些选择和决定。这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权做出决定的客户必须积极地对待这一切，尽快做处理、做决定。因为开发人员通常只有等你做出了决定才能行动，而这种等待会延误项目的进展。
5：尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本价格，开发人员最适合预算这些成本（尽管许多开发人员并不擅长评估预测）。你所希望的某些产品特性可能在技术上行不通，或者实现它要付出极为高昂的代价。而某些需求试图在操作环境中要求不可能达到的性能或试图得到一些根本得不到的数据，开发人员会对此作出负面的评价意见，你应该尊重他们的意见。有时，你可以重新给出一个在技术上可行、实现上便宜的需求，例如，要求某个行为在“瞬间”发生是不可行的，但换种更具体的时间需求说法（“在50ms以内”,但若没有准确的技术分析不能轻易下结论），这就可以实现了。
6： 划分需求优先级别
大多数项目没有足够的时间或资源来实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，哪些是好的，是需求开发的主要部分。只能由你来负责设定需求优先级，因为开发者并不可能按你的观点决定需求优先级。开发者将为你确定优先级提供有关每个需求的花费和风险的信息。当你设定优先级时，你帮助开发者确保在适当的时间内用最小的开支取得最好的效果。在时间和资源限制下，关于所需特性能否完成或完成多少应该尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对这种现实的。业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
7：评审需求文档和原型
正如我们将在第1 4章讨论的，无论是正式的还是非正式的方式，对需求文档进行评审都会对软件质量提高有所帮助。让客户参与评审才能真正鉴别需求文档是否的确完整、正确说明了期望的必要特性。评审也给客户代表提供一个机会，给需求分析人员带来反馈信息以改进他们的工作。如果你认为编写的需求文档不够准确，就有义务尽早告诉分析人员并为改进提供建议。通过阅读需求规格说明，很难想象实际的软件是什么样子的。更好的方法是先为产品开发一个原型。这样你就能提供更有价值的反馈信息给开发人员，帮助他们更好地理解你的需求。必须认识到：原型并非是一个实际产品，但开发人员能将其转变、扩充成功能齐全的系统。
8：需求出现变更要马上联系
不断的需求变更会给在预定计划内完成高质量产品带来严重的负面影响。变更是不可避免的，但在开发周期中变更越在晚期出现，其影响越大。变更不仅会导致代价极高的返工，而且工期也会被迫延误，特别是在大体结构已完成后又需要增加新特性时。所以一旦你发现需要变更需求时，请一定立即通知分析人员。
9：应遵照开发组织处理需求变更的过程
为了将变更带来的负面影响减少到最低限度，所有的参与者必须遵照项目的变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后作出合适的决策以确定将某些变更引入项目中。
10：尊重开发人员采用的需求工程过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性。分析人员采用的方法有其合理性。也许你认为需求过程不太划算，但请相信花在需求开发上的时间是“很有价值”的。如果你理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。尽管去询问分析人员为什么他们要收集某些信息，或参与与需求有关的活动。
系统分析人员在开发过程中可能会遇到以下问题，一些很忙的客户可能不愿意积极参与需求过程，而缺少客户参与将很可能导致不理想的产品。故一定要确保需求开发中的主要参与者都了解并接受他们的义务。如果遇到分歧，通过协商以达成对各自义务的相互理解，这样能减少今后的摩擦。
7．需求文档
需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致协议。协议综合了业务需求、用户需求和软件功能需求。就像我们早先所看到的，项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求。你必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。只有以结构化和可读性方式编写这些文档，并由项目的风险承担者评审通过后，各方面人员才能确信他们所赞同的需求是可靠的。
你可以使用以下三种方法编写软件需求规格说明：
用好的结构化和自然语言编写文本型文档。
建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。
编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。
由于形式化规格说明具有很强的严密性和精确度，因此，所使用的形式化语言只有极少数软件开发人员才熟悉，更不用说客户了。虽然结构化的自然语言具有许多缺点，但在大多数软件工程中，它仍是编写需求文档最现实的方法。包含了功能和非功能需求的基于文本的软件需求规格说明已经为大多数项目所接受。图形化分析模型通过提供另一种需求视图，增强了软件需求规格说明。
软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。许多读者使用软件需求规格说明来达到不同的目的：
客户和营销部门依赖它来了解他们所能提供的产品。
项目经理根据包含在软件需求规格说明中描述的产品来制定规划并预测进度安排、工作量和资源。
软件开发小组依赖它来理解他们将要开发的产品。
测试小组使用软件需求规格说明中对产品行为的描述制定测试计划、测试用例和测试过程。
软件维护和支持人员根据需求规格说明了解产品的某部分是做什么的。
产品发布组在需求规格说明和用户界面设计的基础上编写客户文档，如用户手册和帮助屏幕等。
培训人员根据需求规格说明和用户文档编写培训材料。
软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明，那么它将不能作为协议的一部分并且不能在产品中出现。
我见过有一个项目突然接到测试人员发出的错误灾难的报告。结果是他们测试的是老版本的软件需求规格说明，而他们觉得错误的地方正是产品所独有的特性。他们的测试工作是徒劳的，因为他们一直在老版本的软件需求规格说明中寻找错误的系统行为。
在编写软件需求规格说明，希望读者牢记以下的建议：
对节、小节和单个需求的号码编排必须一致。
在右边部分留下文本注释区。
允许不加限制地使用空格。
正确使用各种可视化强调标志（例如，黑体、下划线、斜体和其它不同字体）。
创建目录表和索引表有助于读者寻找所需的信息。
对所有图和表指定号码和标识号，并且可按号码进行查阅。
使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。
为了满足软件需求规格说明的可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。这可以使你在变更请求、修改历史记录、交叉引用或需求的可跟踪矩阵中查阅特定的需求。由于要达到这一目的，用单一的项目列表是不够的，因此，我将描述几个不同的需求标识方法，并阐明它们的优点与缺点。可以选择最适合你的方法。
(1) 序列号最简单的方法是赋予每个需求一个唯一的序列号，例如SRS-13。当一个新的需求加入到商业需求管理工具的数据库之后，这些管理工具就会为其分配一个序列号（许多这样的工具也支持层次化编号）。序列号的前缀代表了需求类型，例如SRS代表“软件需求说明”。由于序列号不能重用，所以把需求从数据库中删除时，并不释放其所占据的序列号，而新的需求只能得到下一个可用的序列号。这种简单的编号方法并不能提供任何相关需求在逻辑上或层次上的区别，而且需求的标识不能提供任何有关每个需求内容的信息。
(2) 层次化编码这也许是最常用的方法。如果功能需求出现在软件需求规格说明中第3 . 2部分，那么它们将具有诸如3.2.4.3这样的标识号。标识号中的数字越多则表示该需求越详细，属于较低层次上的需求。即使在一个中型的软件需求规格说明中，这些标识号也会扩展到许多位数字，并且这些标识也不提供任何有关每个需求目的的信息。如果你要插入一个新的需求，那么该需求所在部分其后所有需求的序号将要增加。删除或移去一个需求，那么该需求所在部分其后所有需求的序号将要减少。但其他地方的引用将混乱，对于这种简单的层次化编号的一种改进方法是对需求中主要的部分进行层次化编号，然后对于每个部分中的单一功能需求用一个简短文字代码加上一个序列号来识别。例如，软件需求规格说明可能包含“第3.2.5部分—编辑功能”，并将此部分编写成子模块文档，然后配置管理。
有时，你觉得缺少特定需求的某些信息。在解决这个不确定性之前，可能必须与客户商议、检查与另一个系统的接口或者定义另一个需求。使用“待确定”（to be determined, TBD或采用汉语拼音略写DQD）符号作为标准指示器来强调软件需求规格说明中这些需求的缺陷。通过这种方法，你可以在软件需求规格说明中查找所要澄清需求的部分。记录谁将解决哪个问题、怎样解决及什么时候解决。把每个TBD编号并创建一个TBD列表，这有助于方便地跟踪每个项目。
在继续进行构造需求集合之前，必须解决所有的TBD问题，因为任何遗留下来的不确定问题将会增加出错的风险和需求返工。当开发人员遇到一个TBD问题或其它模糊之处时，他可能不会返回到原始需求来解决问题。多半开发者对它进行猜测，但并不总是正确的。如果有TBD问题尚未解决，而你又要继续进行开发工作，那么尽可能推迟实现这些需求，或者解决这些需求的开放式问题，把产品的这部分设计得易于更改。
编写优秀的需求文档没有现成固定的方法，最好是根据经验进行。从过去所遇到的问题中可使你受益匪浅。许多需求文档可以通过使用有效的技术编写风格和使用用户术语而不是计算机专业术语的方式得以改进。
你在编写优秀的需求文档时，希望读者还需牢记以下几点建议：
保持语句和段落的简短。
采用主动语态的表达方式。
编写具有正确的语法、拼写和标点的完整句子。
使用的术语与词汇表中所定义的应该一致。
需求陈述应该具有一致的样式，例如“系统必须..”或者“用户必须..”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的库存清单。”
为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、简单、有效、、最新技术、优越的、可接受的等。当用客说“用户友好”或者“快”时，你应该明确它们的真正含义并且在需求中阐明用户的意图。
避免使用比较性的词汇，定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。当客户说明系统应该“处理”、“支持”或“管理”某些事情时，你应该能理解客户的意图。由于需求的编写是层次化的，因此，可以把顶层不明确的需求向低层详细分解，直到消除不明确性为止。
文档的编写人员不应该把多个需求集中在一个冗长的叙述段落中。在需求中诸如“和”，“或”之类的连词就表明了该部分集中了多个需求。务必记住，不要在需求说明中使用“和/或”，“等等”之类的连词。
8．需求分析的过程
需求获取是在问题及其最终解决方案之间架设桥梁的第一步。获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。
需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息（需求获取）。同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系。然后，你可以使客户信息结构化，并编写成文档和示意图。下一步，就可以让客户代表评审文档并纠正存在的错误。这四个过程贯穿着需求开发的整个阶段。
由于软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。下面列出了1 4个步骤，你可以利用它们指导你的需求开发活动。对于需求的任何子集，一旦你完成了第十三步，那么你就可以很有信心地继续进行系统的每一部分的设计、构造，因为你将开发出一个好的产品:
1. 定义项目的视图和范围。
2. 确定用户类。
3. 在每个用户类中确定适当的代表。
4. 确定需求决策者和他们的决策过程。
5. 选择你所用的需求获取技术。
6. 运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级。
7. 从用户那里收集质量属性的信息和其它非功能需求。
8. 详细拟订使用实例使其融合到必要的功能需求中。
9. 评审使用实例的描述和功能需求。
10. 如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解。
11. 开发并评估用户界面原型以助想像还未理解的需求。
12. 从使用实例中开发出概念测试用例。
13. 用测试用例来论证使用实例、功能需求、分析模型和原型。
14. 在继续进行设计和构造系统每一部分之前，重复6~1 3步。
需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。需求获取只有通过有效的客户—开发者的合作才能成功。分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。确定用户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。
需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单拷贝。作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。询问一个可扩充的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。
需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式。与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。
在每一次座谈讨论之后，记下所讨论的条目，并请参与讨论的用户评论并更正。及早并经常进行座谈讨论是需求获取成功的一个关键途径，因为只有提供需求的人才能确定是否真正获取需求。进行深入收集和分析以消除任何冲突或不一致性。尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。
当进行需求获取时，应避免受不成熟的细节的影响。在对切合的客户任务取得共识之前，用户能很容易地在一个报表或对话框中列出每一项的精确设计。如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制。你可能要周期性地检查需求获取，以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。向他们保证在开发过程中，将会详尽阐述他们的需求。
在一个逐次详细描述过程中，重复地详述需求，以确定用户目标和任务，并作为使用实例。然后，把任务描述成功能需求，这些功能需求可以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解，但是你必须细化用户界面设计。
作者小传：
曹伟，南京易点网络软件公司技术总监。从ERP的系统开发，对整体系统有较强的认识欲望，现正在实施企业级软件系统构架，实施一个国际化企业电子化的解决方案。
文章来源于领测软件测试网 https://www.ltesting.net/
