我们应当怎样做需求确认：评审与签字确认会

时间过得真快，经过一系列需求研讨、需求分析和整理确认，我们整理出了需求列表，编写出了需求规格说明书，一切似乎该到结束需求分析阶段的时候了。但是，敏捷大师的一句话让我们彻底心凉到了骨头里。敏捷大师说了，我们不可能在需求分析阶段完成所有的需求分析工作，它将延续到设计、开发，甚至测试阶段。

一直以来，我对这句话非常困惑。既然需求分析阶段不能完成所有的需求分析工作，那么完成多少才算结束呢？80%？60%？或者更少？大师没有给出一个标准。大师就是大师，生活在太空里的，我们慢慢理解吧。经过多年的实践，我慢慢理解了。我们说这种需求分析工作不可能完全完成，或者说日后用户的需求会变，其实并不是毫无规律可循的。通常，用户对需求的变更只发生在某些固定的范围内，弄清楚了这些范围，我们的问题就迎刃而解了。

1. 整体需求不变，具体细节变化。我们说需求是分层次的，整体框架、功能模块、每个操作的细节。如果用户变更到了将整个框架都推翻了，这个项目就别做了。所以整体框架是必须在需求分析阶段完成的，是日后不可能改变的。功能模块可能要变，但通常是某个部分在变，而更多的是那些具体操作的细节在变。

2.  界面风格与操作易用性是最容易发生变更的。我们说用户看到软件以后不满意，其实主要是对界面风格与操作性不满意，而不是软件功能。界面不够美观，操作不方便，不符合用户的操作习惯，都是造成用户不满意的地方。

3.  增加其它功能。软件是对现实的模拟，而现实也是复杂多变的。我们与用户在进行业务流程分析时，也许一些流程没有考虑到，或者还有特殊情况需要处理。这些是客户要求增加功能的主要动因。

经过以上分析，需求分析阶段要做到什么程度就可以清楚了：整体框架与功能模块必须确定下来，至于各个功能模块下的具体操作，尽量做，能到什么程度先到什么程度。至于界面风格与操作性，我们可以在日后迭代开发的每个迭代期，拿出样品以后再与用户确认。

OK，万事俱备只欠东风，当所有工作都完备以后，我们的需求分析工作开始进入最后收尾的阶段。我们说，需求分析阶段的产出物是需求列表与需求规格说明书，而最终结束的里程碑无疑就是需求评审会了，或者说与用户的签字确认会。

需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。从理论上说，需求评审会应当由用户代表，与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理，还有公司相关领导参加。但实际上，让如此多不同角色的人聚集在一起开会是不现实的。因此，我们可以将需求评审会分为内部评审会与外部评审会两部分来开比较现实。

处理外部问题，必先要从内部统一思想。先召开一个内部评审会，听听系统架构师、设计人员、测试人员、QA经理对需求分析工作的意见，然后由领导讲讲话，布置一下后面的工作，是十分有必要的。按照我的经验，系统架构师这时的作用相当重要，他应当仔细阅读需求，仔细思考技术是否可行，以及预测该系统是否能够达到用户方领导对该项目制订的目标。如果答案是否定，立即进行调整。

最后就是与用户的外部需求评审会了。外部需求评审会，也可称为签字确认会议，就是与用户就需求规格说明书进行评审，最后签字确认。用户签过字的东西，不可能完全抑制住用户的变更，但至少从很大程度上抑制住了用户的大改。然而，在召开外部需求评审会之前，我们建议大家就需求规格说明书，先与各个单位或部门的用户代表讨论并确定下来，避免在最终的签字确认会上出现分歧，影响工作进度。毕竟大家都不容易，工作一大堆，聚在一起不容易。

经过数月的分析讨论，最终在一片和谐的气氛中，双方领导在需求规格说明书上签字，项目开始进入一个新的轮回。在这个轮回中，是焦头烂额、不胜其苦，还是如履薄冰、最终顺利交付，是与许多因素有关的。但我想说，一份高质量的需求分析必定起到决定性的作用，必定为日后的软件开发扫清了许多许多的地雷。

我们应当怎样做需求分析
我们应当怎样做需求调研：初识
我们应当怎样做需求调研：拜访
我们应当怎样做需求调研：研讨会
我们应当怎样做需求调研：需求研讨
我们应当怎样做需求调研：迭代
我们应当怎样做需求调研：需求捕获（上）
我们应当怎样做需求调研：需求捕获（下）
我们应当怎样做需求分析：功能角色分析与用例图
我们应当怎样做需求分析：业务流程分析（上）
我们应当怎样做需求分析：业务流程分析（下）
我们应当怎样做需求分析：用例说明
我们应当怎样做需求分析：查询报表分析
我们应当怎样做需求分析：子用例与扩展用例
我们应当怎样做需求分析：行动图和状态图
我们应当怎样做需求分析：业务领域分析
我们应当怎样做需求分析：原文分析法
我们应当怎样做需求分析：领域驱动设计
我们应当怎样做需求分析：非功能需求
我们应当怎样做需求确认：需求列表
我们应当怎样做需求确认：一个需求列表的实例
我们应当怎样做需求确认：快速原型法
我们应当怎样做需求确认：需求规格说明书
我们应当怎样做需求确认：评审与签字确认会

（全文终）

评论

12 楼 Junjing 2017-10-25  

非常感谢楼主的分享，受益匪浅！我是一位从业务规划和运营转需求分析的初级需求分析师，读了楼主您关于需求分析的系列文章，收获特别大，非常感谢楼主的无私分享！我由于没有技术背景，现转行做需求分析我深知自己需要学习和提升的地方有很多，楼主能否推荐几本书呢？另，还有个小请求，楼主能否分享一个《需求规格说明书》的实际案例，我希望能根据实际案例来好好学习一下，非常感谢！（邮箱：[e-mail]）

11 楼 kersky 2016-11-23  

感谢楼主的辛苦输出，半天看完了整个系列。对于一个转从开发转需求的工程师来说，对整个需求分析过程有了初步的了解，也边看边实践学习了用例图、活动图、状态图，了解了楼主的流程用例描述与查询报表用例描述。知道需求分析的最终输出产物是需求列表与需求规格说明书。知道了原文分析法与领域驱动的概念。
一下午的学习，算是需求的系统的入门吧。感谢楼主。
深知现在只是了解一点点“术”，“道”还得在实践与继续学习中摸索领悟，慢慢发现好需求的样子，好的需求分析的方法。
求软件需求列表、软件需求规格说明书实例文档。
若楼主看的参考书籍是电子版，同求。
邮箱：[e-mail] 不甚感激。

10 楼 dripstone 2016-08-25  

非常感谢楼主，用了大半天的时间，一口气读完了需求分析阶段。好多困惑的东西渐渐明朗起来，真的比读各种书籍都要管用，辛苦了，楼主。

9 楼 u012884883 2015-03-27  

楼主写的太好了，读罢，感觉自己对软件的整体认识又有提升了；如果能有具体的项目实例结合来阐述那就再好不过了。

8 楼 fangang 2014-03-24  

moshengtan 写道

楼主，可不可以发一个您写过的简单项目的需求规格说明书例子，给我学习学习。[e-mail] 谢谢了。

稍等，这两天我整理一个吧

7 楼 moshengtan 2014-03-21  

楼主，可不可以发一个您写过的简单项目的需求规格说明书例子，给我学习学习。[e-mail] 谢谢了。

6 楼 JoeyQin 2012-07-28  

一口气读完了楼主关于需求分析的所有文档，收获良多。文章结合了实际案例，丰富生动，专业的词汇不再晦涩难懂。
期待楼主能出一本书，我一定买。哈哈！

5 楼 fangang 2012-07-26  

参考资料
1.Brett D. McLaughlin, Gary Pollice & David West. Head First Object-Oriented Analysis & Design. O’Reilly Media, Inc. ISBN: 978-7-5641-0743-7
2.徐峰. 软件需求最佳实践：SERU过程框架原理与应用. 电子工业出版社. ISBN:9787121073953. 2008-10
3.Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison Wesley. August 20, 2003

我看的是英文版的，应该有中文版，你可以找找

4 楼 javalearning1014 2012-07-24  

收益匪浅，楼主辛苦了！实践试试去。
另外，请问楼主，有没有什么需求分析方面的书，请帮忙推荐几本，O(∩_∩)O谢谢！

3 楼 王乾志 2012-05-15  

收益匪浅，多谢楼主分享!

2 楼 lwqenter 2012-05-01  

楼主，可不可以发一个你写过的需求规格说明书的案例文档到我邮箱啊，让小弟学习与参考一下，因为案例更直接，更让人容易明白和理解。

1 楼 lwqenter 2012-05-01  

楼主，整体框架具体是指什么？整体流程和整体用例？