大家好，又见面了，我是你们的朋友全栈君。

写在前面

如果你明确清晰知道需求规格说明书是什么，则可以忽略此文章。如果你不清晰，建议还是阅读一下本文，不然也许早晚会碰钉子。

转载请标明出处：
http://blog.csdn.net/ouyida3/article/details/47683191
本文出自:【ouyida3的博客】

起因

最近在做项目时，根据项目计划，在用户输出了《需求书》后，需要我在2天编写出《需求规格说明书》，但是就这个说明书是什么，要编写什么我和用户产生了较大分歧，甚至对项目还产生了一些不好的影响，比如被领导臭骂。

需求书的定义

软件工程里对于软件项目各个过程需要输出的文档都有明确的定义，但是每个方法论又是不太一样，比如cmmi和敏捷的相似性就不大。当提到用户故事那应该是敏捷而不是cmmi，当说起需求规格说明书就应该不是敏捷的。

叫什么名字其实我不太关注，抛开这些定义，一个真实的需求分析到软件设计的过程是怎样呢？

cmmi的输出

cmmi在上述的第一步，会输出《用户需求规格说明书》，第二步会输出《软件需求规格说明书》，第三步会输出《软件概要设计说明书》。
当然，用户需求称为客户需求也行，软件需求规格说明叫做软件规格需求说明都可以，这些我不关注。

我想表达的是，《用户需求规格说明书》是业务人员写的，《软件需求规格说明书》是技术人员写的，如果是甲乙方的项目，那就是甲方的技术部写；而《软件概要设计说明书》是乙方输出。因此，假设如果我并不是甲方人员，让我写《需求规格说明书》，无论是用户需求还是软件需求，都是不合适的。回到主题，明显需要我写的只能是《软件需求规格说明书》。但是项目计划里简简单单的写上需求规格说明书是不恰当的。

软件需求规格说明书有什么

先说说没有什么：一定不涉及技术元素，比如选择什么技术路线，选择什么编程语言等等。也没有什么数据库的设计。
一定要技术人员和用户都看得懂。这样用户可以根据这个来验收，技术人员也可以根据它来进行概要设计。
当然，也要根据用户的需求书来验收，但是毕竟它和软件系统脱离的，有些关于系统操作类的精确事项无法描述到。

举个例子，比如有四个不同的业务人员各自提出需求，他们之间的需求肯定有相似的地方，也有不同的地方，那么《软件需求规格》就需要把相同点归并，不同点如何体现编写出来，并且与四个业务人员确认，这样合并是否能满足了这个需求。如果有一些现存的老系统，那么也需要说明对老系统进行什么样的改造（非技术类说明）。

谈谈时间

上面的例子，能否2天编写完成？我认为要看系统大小。如果是10人月以上的系统，2天是远远不足够的。根据经验，我个人认为是1人月的系统，大概需要2人天写这玩意。

谈谈敏捷

敏捷强调小步快跑，所以由用户写用户故事，完后直接就分析故事排计划，简单一些设计文档后就直接编码开干了，代码是最好的设计，通过不断的迭代完善。但是大项目、大系统，还是需要一些文档统筹设计的。详细可看Mike Cohn大师写的书《用户故事与敏捷方法》

转载请标明出处：
本文出自:【ouyida3的博客】
2015.8.15