软件客户需求义务书
1. 给分析人员讲解业务及说明业务方面的术语等专业问题。
2. 抽出时间清楚地说明需求并不断完善。
3. 当说明系统需求时，力求准确详细。
4. 需要时要及时对需求做出决策。
6. 对单项需求、系统特性或使用实例划分优先级。
7. 评审需求文档和原型。
8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。
9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。
10. 尊重需求工程中开发人员采用的流程（过程）。
需求权利和义务规定了客户和开发者双方应该做些什么，双方共同出力，确保需求过程的有序进行。不过，大多数的软件公司一般都把“客户是上帝”这句话贯彻的很好，客户有什么样的要求，软件公司就做什么样的修改，最终损害的是客户和自己双方的利益。一次，我和一个小软件企业的技术总监聊起这方面的事情，请教他的做法。他在经历了几次销售人员随意答应客户要求的痛苦之后，决定亲自出动，在和客户接触的过程中掌握主动权，判断客户是不是一个“好”客户，再决定做不做这个软件。实施了一段时间后，发现效果非常的好，成本大幅度下降，客户也很满意。软件开发过程中软件企业和客户是一对合作者，一荣俱荣，一损俱损。要达到双方共赢的局面，只能靠充分的沟通。 需求分析和需求管理
需求的过程包括了两个过程，需求管理和需求分析。如同一个公司开展业务离不开管理一样，脱离了需求管理的需求过程很难做到顺利的完成需求过程。当然，并不是所有的软件公司都没有需求管理，例如安排需求的时间也是需求管理的一方面，大多数的软件公司都没有一个科学的、
任何活动都离不开管理，需求过程也不例外。需求过程的活动分为需求管理和需求分析两种。大多数人说不清楚需求管理和需求分析的差别，但是他们在进行需求过程的时候已经不知不觉的在开展需求管理和需求分析两种活动了。这种行为就有点像一些小企业主，缺乏科学的、系统的管理知识，但你却不能说他不懂管理，因为他有大量的实践经验。同样的，一些不够成熟的软件企业在进行需求分析的时候，主要还是靠经验，并没有一个经过验证的方法。 需求分析活动包括对一个软件项目需求的获取、分析、规格说明及验证。典型需求分析的结果是软件需求规格说明（System Requirements Specifications）及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线（baseline）。这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定（agreement）。工程项目可能会有其它的约定，例如可交付性、约束条件、进度安排、预算及合同约定等。但这些并不是需求过程主要考虑的因素。
需求约定是需求开发和需求管理之间的桥梁，需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动，如图所示。需求管理强调：
1、控制对需求基线的变动。
2、保持项目计划与需求一致。
3、控制单个需求和需求文档的版本情况。
4、管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关系。
5、跟踪基线中需求的状态。
和任何的管理活动一样，需求管理的目的也是为了确保需求分析活动按照既定方针执行。
文章来源于领测软件测试网 https://www.ltesting.net/
