一说起需求管理，很多人想到的就是需求跟踪。
可能是因为日常的需求管理活动，最直接相关的就是需求跟踪吧。
实际上，GJB5000A中非常明确地指出需求管理过程域有5个实践，需求跟踪不过是其中的一条实践而已。如果把需求管理等同于需求跟踪，那就相当于需求管理活动只完成了1/5。
这里不想再重复GJB5000A中的5条实践分别是什么，而是想讲一下实施需求管理过程要遵循的4项基本原则。了解了这4项基本原则，会帮助我们更好地实施需求管理活动。这4项基本原则如下：
1. 需求管理活动必须与需求工程的其他活动紧密整合
需求工程包括需求获取、需求分析、需求描述、需求验证和需求管理。顾名思义，需求管理是在已经有了需求就应该对需求进行管理的活动，所以，需求管理会从需求获取就开始，伴随着整个需求工程活动。
在需求获取阶段，我们需求识别合适的需求提供者，通过交流、演示等手段达成开发方与用户对需求的一致理解；随后，通过需求分析和需求描述做好需求定义，形成需求文档，进行需求评审，对需求进行确认以及由开发方做出对需求实现的承诺。并且以通过评审的需求文档作为基线，在后续的开发过程中进行需求跟踪。一旦发生需求变更，要做好变更影响分析，根据需求跟踪矩阵中的需求追溯关系，更改受影响的需求和工作产品。
这个过程一直到软件退役方才结束。
2. 需求必须是文档化的、正确的、最新的、可管理的、可理解的
需求必须是文档化的、正确的、可理解的，这些是需求管理活动的前提。很难想象，如果需求连这些条件都不满足，需求跟踪还有什么意义呢？
3. 只要需求变化了，就必须评估需求变更的影响，走正式的变更流程
对于需求变更，开发人员常常会有两个极端的看法：一方面没人愿意接受需求不断地变化，所以开发人员希望需求变更要有个正规的流程以对提出需求更改的一方进行约束；另一方面一些小的需求变化，开发人员也不愿意走正规的需求变更流程，他们会觉得又是申请，又是验证的，很是麻烦。
需求变更必须要走正式的变更流程。因为需求管理的意义就是要通过正规的流程对需求变更进行控制。不经申请就完成的变更，会使得软件状态不清楚；不经验证的变更，会使得引入新的缺陷而不自知。
4. 需求必须划分优先级
当你一提到需求优先级的时候，很多开发人员都很不以为然，总觉得软件的每个功能都是不可或缺的，都是同等重要的，可一旦工期吃紧，为了满足系统联试或者外场试验的要求，他们还是要面临先实现哪些需求的抉择。如果事先设定了需求的优先级，开发人员可以从容地实现这些需求并完成必要的验证，否则，眉毛胡子一把抓，该实现的没有实现，或者实现了的也没有进行验证，导致联试或试验过程中问题多多。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
