上一篇主要说明了需求分析的内容，并强烈推荐了一篇非常好的文章，同时也根据笔者的经验简单的阐述了容易出现的一些问题。在此，笔者还想再次强调两点（也算是和大家沟通所得吧）：

1)       尊重实际的业务：尊重业务，不忽略任何细节，从而分析得出一致的系统模型。

2)       梳理规范的业务：此处的规范是为了管理而规范，不是系统规范。没有计算机，没有软件，照样会有规范的管理流程，有了计算机，有了软件，照样还会有不规范的操作。

1.       需求输出

如果说在需求分析过程中，没有偷工减料，成果的输出是一件很容易的事情。而且当前有很多的需求/软件规格的模版，借助模版，整理分析成果并不是一件难事。在具体动“笔”之前，强烈建议PM最好有一个比较完整的需求管理的思路。

在需求输出方面通常都会采用word文档，但如果可以有一个需求管理工具来辅助进行需求管理，也是非常有必要的，由于后期需求管理不善造成的问题数不胜数了，更为夸张的是软件和需求基本不会吻合，所以需求管理工具是非常有必要的，但据笔者了解，大部分公司一不会出钱，二不会承担使用盗版的“罪名”。所以，在此对PM的能力真的是一种无形的考验，而且是相当残酷。

尽管需求输出不是一件复杂的事情，也无需太多的技巧，但还是要注意几个问题，这个环节的重点是在于如何为后面的需求管理开一个好头。

1)       命名规范：包括文档命名、业务功能命名等等；最终要对这些内容实现跟踪管理，既然要跟踪管理，没有一个可识别的名称多少有些说不过去，就好像管理来管理去都不知道在管理什么。

2)       文档的拆分及合并原则：通常是一个需求团队共同完成一个系统的需求说明，所以，彼此的配合最终是体现在了需求的输出成果中，即需求文档。人和人之间的配合默契与否可以很容易看到，那文档呢？

3)       写需求文档不一定要像侦探小说一样有个推理过程，但最好可以把分析过程表达出来，因为有什么需求（可参见***调研报告或*****单据），所以，根据****方法得出，系统应该实现****功能，这些功能又根据******，所以应该按照****流程来进行。当然模版肯定不是这样，但内容不可少，目的就是为了可以追溯。当后续的环节发现错误之后，可以根据这个过程追溯到原始需求，从而在此进行结论的验证。

4)       尽管制作需求文档不是在写一篇高要求的说明文，但在此还是期望在写需求文档时一定要严谨，严谨的需求文档可以避免后期的很多误解。不要在需求阶段就无意有意的设置陷阱。

多说一句，需求文档是非常重要的，尽管很多时候技术人员未必会认真的看，但不能回避需求文档本身的质量问题（前后矛盾、功能不连贯、需求不严谨等等），更甚者会遗留很多模棱两可的内容，这是最致命的，遇到这种情况，如果技术人员可以得到很好的支持，也许这种模棱两可的内容可以进一步细化满足要求，如果技术人员得不到支持，再加之进度等其他压力，就会存在理解差异，且不去验证直接实现的可能。

2.       需求验证

需求验证实际就是对需求进行评审的过程，是对需求的质量最后把关的一道环节。在这个阶段会采用需求审查、评审甚至测试等方法来验证需求质量，确保可以达到预期目标，对于需求质量的衡量总结了几个方面，可供参考：

1)       需求的完整性；

2)       所有涉众对需求理解的一致性；

3)       需求的可追溯性；

4)       需求与合同（规划文档）的一致性，且满足了涉众的预期目标；

关于最后一点需要解释一下，这是笔者故意加上去的，需求是确定项目边界，所以如果边界发生变化了，要看看合同（规划文档）是否需要变更，如果需要就赶快变更。不要项目开始了才记起这个问题。满足涉众的预期目标很容易理解，就是满足大家的要求，记住不仅是用户，是涉众，是任何对系统可能产生影响的人。

需求验证可分为两个阶段：自我验证及集成验证。（笔者总结的，也许不正确，就好像单元测试和集成测试类似）

l  自我验证：根据获取的需求内容，根据分析的过程方法，进行需求验证。可借助一些分析工具，当前较好的建模工具通常都会有合法性的验证功能，如果需求分析过程中存在一些问题，通常情况下是可以通过工具来校验出来的。但这个环节是一个闭环，也就是如果做到正确，也只是可以保障从获取到的需求到需求输出是正确的，但这种“正确”的内容是否是用户想要的，是否在和其他内容整合在一起不出现问题，不得而知。

l  集成验证：第一步是将所有的需求文档整合在一起，按照自我验证的方式进行需求验证，第二步是将用户加入到这个过程中，取得对需求理解的一致性。

在与用户共同验证需求时，可采用的方法有：

1)       召开需求评审会，通过会议的形式解决这些问题。针对需求调研报告中的每一问题在需求输出中逐一对应，逐一解释。这样的会议通常要求技术人员参加。需求一旦确认，很难变更，所以技术人员务必参加这样的会议，提前确认需要确认的内容，降低后期风险。

2)       制作样例，通过可视内容进行需求验证。软件是抽象无形的，最好的方式就是作出来让用户亲自试用，但这样显然不现实，所以会通过界面样例让用户去感受这样的操作体验，实际通过制作样例解决的最主要的问题应该是潜在需求的验证。

针对于产品型（市场型）的项目而言，是没有明确的甲方的，此时的需求验证会相当的困难，在此如果有实力的话，可以通过一些市场手段进行验证，譬如调研，沟通见面会等等。如果公司不给于这些支持，建议对需求进行优先级划分，降低后期风险。

在这里隐含了一个问题，技术可行性，针对此，建议在需求评审过程中要求技术人员提前介入，甚至在需求分析过程中，技术人员就要提供支持，以避免由于技术问题带来的实现风险。

如果以上工作都已完成，OK，第一阶段大功告成，存入配置库，建立基线，开始进入需求管理工作。