需求承诺（Requirement Consent）
什么是需求承诺，是指开发方和客户方的责任人对通过了同行评审的需求阶段的工作产品，作出承诺，同时该承诺具有商业合同的同等效果。 需求承诺如下：
需求承诺
XXX项目需求文档_《XXX需求说明书》，版本号：X.X.X,是建立在XXX与XXX双方共同对需求理解的基础之上，同意后续的开发工作根据该工作产品开展。如果需求发生变化，双方将共同遵循项目定义的“变更控制规程”执行。需求的变更将导致双方重新协商成本、资源和进度等。
甲方签字
乙方签字
不少人会草率地对待需求承诺：不就是在一张纸的最后一行文字下面签字吗，反正已经评审过了，我就签吧。但他将来变更需求时可能会表示不瞒：“不错，我是签字了，但是我并没有阅读文档。是你们要我在文档上签字的，我是相信你们才这么做的。”为了避免发生此类纠纷，人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。
需求跟踪(Requirement Track)
为什么要进行需求跟踪？在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性。确保所有的实现是以用户需求为基础。对于需求实现是否全部的覆盖。同时确保所有的输出与用户需求的符合性。
需求跟踪有两种方式，正向跟踪与逆向跟踪：
正向跟踪：以用户需求为切入点，检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。
逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护《需求跟踪矩阵》。需求跟踪矩阵保存了需求与后续开发过程输出的对应关系。矩阵单元之间可能存在“一对一”、“一对多”或“多对多”的关系。见下表：简单的需求跟踪矩阵示例。
需求代号 需求规格说明书V1.0 设计文档V1.2 代码1.0 测试用例 测试记录
R001 标题或标识符 标题或标识符 代码文件名称 测试用例标识或名称
R002 … … … …
… … … … …
简单的需求跟踪矩阵示例1
使用需求跟踪矩阵的优点是很容易发现需求与后续工作产品之间的不一致，有助于开发人员及时纠正偏差，避免干冤枉活。
很多人有这样的误解：如果依照“需求开发－系统设计－编码－测试”这样的顺序开发产品，由于每一步的输出就是下一步的输入，所以不必担心设计、编程、测试会与需求不一致，因此可以省略需求跟踪。那么，需要指正的是，按照软件生命周期严格线性顺序的开发模型并不能保证各个开发阶段的工作产品与需求保持一致。因为开发者是人而不是机器。而且，大多数开发人员也都深有体会。
生活中“以讹传讹”的例子，想必大家都很熟悉。学生甲在精工实习时被机器弄破了手指，于是到医院包扎。同学乙路过医院时看到甲的手血迹斑斑，以为甲的手指被机器割断，于是将这个坏消息告诉同学丙。丙急忙转告同学丁，说甲的手被机器割断，正躺在医院里。丁十万火急地告诉全班同学，大家陷入悲痛之中，都以为“甲的胳膊被机器割断了，正躺在医院里，人快不行了。”
由于人们的表达能力、理解能力不可能完全相同，人与人之间的协作很难达到天衣无缝的境界。而使用需求追溯的本身也是一种传递的过程。
需求追溯本身并不是一件复杂的事，而是我们的本身一种理念在支配著我们。也许就有人认为这本身就是在浪费时间，主要麻烦是，当需求或工作产品发生变更时，开发人员要及时更新需求跟踪矩阵。然而没想到的事，如果后来再花时间来做同样的事的时候，将会付出更多。也时也就丢去了本身做这件事的意义。
需求变更控制(Requirement Change Control)
需求变更通常会对项目的进度、人力资源产生很大的影响，这是开发商非常畏惧的问题。也是必须面临与需要处理的问题。作为软件项目，特别在外地实施的工程软件项目而言，需求发生若干次变更似乎是不可避免的。需求发生变更的起因主要有：
随著项目生命周期的不断往前推进，人们（包括开发方和客户方）对需求的了解越来越深入。原先的提出的需求可能存在著一定的缺陷，因此要变更需求。
市场业务需求发生了变化，原先的需求可能跟不上当前的市场业务发展，因此要变更需求。由于市场变化而导致需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。
如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。
总的而言，人们提出需求变更，本就是出于能够是产品更加符合市场或客户需求，出发点本身是好的。但对于开发小组而言，需求的变更则意味着要需要重新进行估计，调整资源、重新分配任务、修改前期工作产品等，而作为开发商，需要增预算与投资，开发组要为此付出较重的代价。假定每次需求变更请求都被接受的话，那么这个项目将会成为一个连环式的工程。
需求变更控制的动机是：
如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。
如果需求变更带来的坏处大于好处，那么拒绝变更。
当然，好处与坏处并不是主观的，而是通过客观的分析与评价而得出的。
对于需求的变更，在某一个程度上来说，也就是项目的范围进行了变化。而需求同时又是项目进行的基础。是非常得要的基石。通常对于需求的变更需要客户与开发方共同参与，包括负责人及市场人员。当然，我们需要根据变更的内容来灵活运用。
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。客户会想当然地以为变更需求是他的权利，因为他付钱给开发方。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。怎么解决这个问题呢，通常情况下，每一类“游戏”都有一定的游戏规则，那么我们事先也需要建立“游戏规则”。
如果事先没有“游戏规则”的话，开发方的负责人需要一些社交技巧来减缓矛盾。例如首先承认客户提出的需求变更请求是合理的，再阐述己方的难处，最后建议在开发该产品新版本时修改需求。这种方式比直接拒绝有效得多，既不得罪客户，又为自己争取了余地。
另外还有一种方法，可以将变更需求先进行记录，并通知给客户，当其需求变化在开发组不能接受的范围时，可以通过市场进行相关的协调。
需求变更本是正常的，并不可怕，可怕的是需求的变更得不到控制。
