是可验证的(Verifiable)。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。
1.9 确定优先级
需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。
1.10 阐述“做什么”而不是“怎么做”
开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。他们经常在整理需求的时候习惯性将如何实现的信息涵盖在需求中，导致需求可读性、可验证性无法保证。
2、需求管理过程域 [部分定义摘录于网络]
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
2.1需求跟踪
需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性，确保所有的工作成果符合用户需求。 需求跟踪有两种方式：
正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵(即表格)。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
我们就曾经出现大家埋头于开发，最后才发现项目协议书中的一个小基本功能没有开发的事故。
2.2 变更管理
需求变更通常会对项目的进度、人力资源、经费产生很大的影响。
如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，会导致产品的部分内容需要重新开发。这是要坚决避免的。
如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。
其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题的一个办法是事先建立规则：如开发方与客户方达成“事不过三”的约定，即允许客户变更三次需求;如果客户第四此变更需求，开发方有权提请客户补偿开发投入。
3、深入理解需求
需求的开发和管理有一些规律或经验可以参考，核心是沟通确认、沟通控制。
3.1认清谁才是"上帝"
我们说客户是上帝，是