写在前面
假设你明白清晰知道需求规格说明书是什么。则能够忽略此文章。假设你不清晰。建议还是阅读一下本文，不然或许早晚会碰钉子。
转载请标明出处：
http://blog.csdn.net/ouyida3/article/details/47683191
本文出自:【ouyida3的博客】
起因
近期在做项目时，依据项目计划，在用户输出了《需求书》后，须要我在2天编写出《需求规格说明书》。可是就这个说明书是什么，要编写什么我和用户产生了较大分歧。甚至对项目还产生了一些不好的影响，比方被领导臭骂。
需求书的定义
软件project里对于软件项目各个过程须要输出的文档都有明白的定义，可是每一个方法论又是不太一样，比方cmmi和敏捷的类似性就不大。当提到用户故事那应该是敏捷而不是cmmi，当说起需求规格说明书就应该不是敏捷的。
叫什么名字事实上我不太关注。抛开这些定义，一个真实的需求分析到软件设计的过程是如何呢？
cmmi的输出
cmmi在上述的第一步，会输出《用户需求规格说明书》，第二步会输出《软件需求规格说明书》，第三步会输出《软件概要设计说明书》。
当然，用户需求称为客户需求也行，软件需求规格说明叫做软件规格需求说明都能够。这些我不关注。
我想表达的是，《用户需求规格说明书》是业务人员写的。《软件需求规格说明书》是技术人员写的，假设是甲乙方的项目，那就是甲方的技术部写。而《软件概要设计说明书》是乙方输出。
因此。假设假设我并非甲方人员。让我写《需求规格说明书》，不管是用户需求还是软件需求，都是不合适的。回到主题。明显须要我写的仅仅能是《软件需求规格说明书》。可是项目计划里简简单单的写上需求规格说明书是不恰当的。
软件需求规格说明书有什么
先说说没有什么：一定不涉及技术元素，比方选择什么技术路线。选择什么编程语言等等。
也没有什么数据库的设计。
一定要技术人员和用户都看得懂。这样用户能够依据这个来验收，技术人员也能够依据它来进行概要设计。
当然。也要依据用户的需求书来验收，可是毕竟它和软件系统脱离的，有些关于系统操作类的精确事项无法描写叙述到。
举个样例，比方有四个不同的业务人员各自提出需求。他们之间的需求肯定有类似的地方，也有不同的地方。那么《软件需求规格》就须要把同样点归并，不同点如何体现编写出来，而且与四个业务人员确认，这样合并能否满足了这个需求。假设有一些现存的老系统，那么也须要说明对老系统进行什么样的改造（非技术类说明）。
谈谈时间
上面的样例，能否2天编写完毕？我觉得要看系统大小。假设是10人月以上的系统。2天是远远不足够的。
依据经验。我个人觉得是1人月的系统。大概须要2人天写这玩意。
谈谈敏捷
敏捷强调小步快跑。所以由用户写用户故事，完后直接就分析故事排计划，简单一些设计文档后就直接编码开干了，代码是最好的设计。通过不断的迭代完好。可是大项目、大系统，还是须要一些文档统筹设计的。
具体可看Mike Cohn大师写的书《用户故事与敏捷方法》
转载请标明出处：
本文出自:【ouyida3的博客】
2015.8.15