我理解的需求规格说明书

内容导航：

我理解的需求规格说明书

需求 功能 规格 说明书 怎么理解的?

用户需求说明书 与 需求规格说明书 有什么本质区别？

用户需求说明书 与 需求规格说明书 有什么本质区别？ 求详解。谢谢

一、我理解的需求规格说明书

编辑导语：需求文档和需求规格说明书，二者都与产品有关，但是其所应用的场景又有所差异。产品经理可以利用需求规则说明书进行系统的校验或评判，使之更好地为实际场景所服务。本篇文章里，作者阐述了他所理解的需求规格说明书，一起来看一下。

一、前言

作为一个需求工作经验（ToB端）2年的小白，在没有大手子知道的情况下摸爬滚打磕磕绊绊，属实有点闭门造车，希望大家多指点指点，如何才能更好地完成需求工作。

另一方面，想让自己的胡思乱想可以记录下来，避免真的变成了胡思乱想。

二、编写需规的目的是什么？

为什么要将需规的编写目的放在第一位？

作为产品岗来说，发掘用户需求是我们的最终目标。针对这种思维结构，那么在探讨如何写好需规的前提，我们要想明白需规存在的含义是什么？为了什么而存在？我们不妨继续通过用户场景来分析，我们在什么场景下使用需规呢？

场景A：需求人员在需求传递环节，通过需规来与开发团队的成员讲述我们的系统要做功能A、功能B、功能C等等。场景B：开发同事发现业务A，有两种理解方式，不清楚该使用哪一种。场景C：项目进入需求验证阶段，需求同事要验证系统是否通过。场景D：测试同事提了一个BUG，但开发同事认为这不是BUG，认为需求如此。

针对以上四种场景，我们可感受到，我们需要利用需规去指导、去校验、去评判当前开发的系统是否是正确的。从场景中分析的需规作用，可以理解为一种解决方案。

我们再进一步地去思考，是否可以认为，需规的根本目的是“保证所开发的系统就是客户想使用的系统”。

三、需求文档和需求规格说明书有什么区别

一样又不一样。

说他俩一样。因为他使用的主要对象都有：开发、测试、项目经理；都是要描述核心业务、具体用例描述、功能&内容描述等。

说他俩不一样。因为需求文档是站在产品的角度去讲述。而需求是站在系统的角度去讲述的。

两者都有交集，但没有必要去划分的很清楚到底一不一样。在面对矛盾的时候我们要理解矛盾点在哪里。

一般来说，矛盾大多是由利益矛盾产生的。那么是谁的利益矛盾呢？

无非是阅读者与编写者的矛盾。阅读者想要快速地、简练地获取到自己想要的信息，因为懒！毕竟冗长的文档读起来对读者是精神与肉体的双重折磨。而编写者，总是想要把事情说的足够详细避免产生二义性，又或者还是懒！

所以我认为，需求文档更侧重于对产品的描述，产品的定位、目标市场、目标用户及其竞争产品。而需规更侧重于系统的描述，实现逻辑、约束、输入输出条件等。

四、从遇到的问题中反思

既然需规的目的是“保证所开发的系统就是客户想使用的系统”（我们先假定我们的需规内容与客户的想法一致）。我们先从可能存在的场景去分析需规应该有哪些内容。

1. 一定要有业务场景描述

其实关于业务场景的描述，更多地想要让文档读者更快地带入到系统中。由于公司资源调整，项目里很多同事换来换去的，直接参照着文档讲，容易给同事们讲的一脸懵逼。所以能够让团队成员更容易理解，更容易融入其中，对于业务场景的描述也是至关重要的。

我们在描述场景的时候，最好讲明“谁”（参与者），在“什么样的场景下”，为了完成某个“目的”，而做了“什么操作”。

通过上述的几个要素，个人觉得可以通俗易懂的讲述需求背景。

2. 尽量用用例的方式去划分功能点

“一千个读者一千个哈姆雷特”，关于需规的结构每个人的理解必然不一样，个人觉得要保持中心思想去做需规：用户可以通过系统完成什么事情。

即系统的用例，我们通过各种方式来梳理出系统的用例有哪些，这样就可以更直观地看出系统有哪些功能。

例如：在“场景A”的情况中，我们要来指导开发团队去开发功能，那么我们需要尽量描述清楚每一个功能，一定要保证功能不存在遗漏项。

那么怎样的逻辑才能让功能描述得全呢？我认为在项目做规划的时候，要把模块范围划分清楚，每一个模块的定义、目的、适用范围，然后再根据模块规划用例。这样就可以保证开发的内容保持功能全覆盖。读者在看的时候也可以很直观地看到，原来我们的系统可以完成这这这等等功能。

3. 复杂逻辑功能的流程图很重要

为什么要单独提出来重点功能这个概念呢？我们会发现场景B、C、D总结下来就是我们针对功能的理解都不一样。

文字描述总会有其弊端，断句、描述顺序、描述逻辑都存在偏向主观。所以我们可以通过画流程图来辅助对文字的描述。

同时，我们一定要确定好我们的流程图的范围，是针对业务流程进行的还是对这个用例进行描述的。因为我遇到过把业务场景跟用例画在一起的操作。这样很容易误导读者，使读者的迷惑。

那么为什么要单指复杂逻辑功能呢？其实，我们完成了目的，讲明白需求就可以了，所有的功能都画的话，很浪费时间跟精力的，所以挑重点说就好。

本文由 @小钟也会胡思乱想 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自 Unsplash，基于 CC0协议。

一、需求 功能 规格 说明书 怎么理解的?

经济学中需求是在一定的时期，在一既定的价格水平下，消费者愿意并且能够购买的商品数量。在心理学中，需求是指人体内部一种不平衡的状态，对维持发展生命所必须的客观条件的反应。 营销学中，需求可以用一个公式来表示：需求=购买欲望+购买力，欲望是人类某种需要的具体体现，如你饿了你的需要是填饱肚子，那你的具体体现就是你要吃饭，而需要是一种天生的属性，因为天生的属性不能创造，所以需求也不能被创造。 在市场营销的概念中，营销是一个发现需求并且满足需求的过程，供需双方通过交换创造价值，而营销就是对这个过程的管理，从而让这个过程变得更有效、通过管理创造价值最大化。

功能的基本解释：1. [function]∶效能;功效 2. [ability]∶才能

规格：1.规范；格局。2.生产的成品或所使用的原材料等规定的质量标准。 3.指一般工业产品的物理形状，一般包括体积，长度，形状，重量等。 4.指动画分镜头台本里镜头的大小，用规格号表示。

说明书：顾名思义是以说明的表达方式，对事物加以解说和介绍，使人得到某种知识的书面材料。

二、用户需求说明书 与 需求规格说明书 有什么本质区别？

1、用户需求说明书是用户的需求，需要和用户确认的；需求规格说明书是系统需求主要是对内的。你考虑了一个对外一个对内。而且需求管理的时候也需要用到用户需求
2、
优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员的文档。
缺点：层次越多，信息损失的越多，误解的概率就越大。
权衡的结果：基本上是依据项目的规模而定。
3、这要看你们的项目管理采用的规范。
如果是cmmi就需要，敏捷就取消
4、如果你非要省掉一个的话，我倾向于写用户需求，因为搞系统的时候要始终明白用户在想什么，要解决什么问题
需求规格相对不是很重要，具体实现用户需求的时候，你可以有各种方案，这个是用户不关心的。要是用户需求就已经理解错了，软件规格让用户签字好哪里放什么文本框用什么布局有意义么？
最后还不是给你翻掉
5、一个是给用户看的
，一个给程序员看的
6、当然需要，需求管理不弄好，后期客户扯皮怎么办？
7、1、用户需求说明书是软件设计的根本，用户需要签字画押，详细设计基于这个写的，怎能不需要。
2、后期有扯皮的时候有依据，不至于什么都没有。
8、这个东西少不得，
做的详细点是对自己负责，
后期意义重大
需求阶段的工作主要分为两个方面，为“需求开发”和“需求管理”。
从我们的经验来讲
“需求管理”需要产出的文档大体上包含【需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件】
“需求开发”需要产出的文档大体上包含【需求规格说明书，需求规格说明书检查表，需求开发指南等】
需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点。
需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，cmmi中有标准的模板，重点是站在客户的角度讲产品功能。
需求规格说明书：是从业务规则讲起的，细一点偏向于软件的概要设计。是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。

三、用户需求说明书 与 需求规格说明书 有什么本质区别？ 求详解。谢谢

1、用户需求说明书是用户的需求，需要和用户确认的；需求规格说明书是系统需求主要是对内的。你考虑了一个对外一个对内。而且需求管理的时候也需要用到用户需求

2、
优点：用户的语言与设计人员的语言是不同的，所以需要有面向不同人员的文档。
缺点：层次越多，信息损失的越多，误解的概率就越大。
权衡的结果：基本上是依据项目的规模而定。

3、这要看你们的项目管理采用的规范。
如果是cmmi就需要，敏捷就取消

4、如果你非要省掉一个的话，我倾向于写用户需求，因为搞系统的时候要始终明白用户在想什么，要解决什么问题
需求规格相对不是很重要，具体实现用户需求的时候，你可以有各种方案，这个是用户不关心的。要是用户需求就已经理解错了，软件规格让用户签字好哪里放什么文本框用什么布局有意义么？ 最后还不是给你翻掉

5、一个是给用户看的 ，一个给程序员看的

6、当然需要，需求管理不弄好，后期客户扯皮怎么办？

7、1、用户需求说明书是软件设计的根本，用户需要签字画押，详细设计基于这个写的，怎能不需要。
2、后期有扯皮的时候有依据，不至于什么都没有。

8、这个东西少不得， 做的详细点是对自己负责， 后期意义重大

需求阶段的工作主要分为两个方面，为“需求开发”和“需求管理”。

从我们的经验来讲

“需求管理”需要产出的文档大体上包含【需求管理计划、需求检查表、需求跟踪表（包含矩阵图）、需求变更状态跟踪表，以及与其配套产出的指南型文件】
“需求开发”需要产出的文档大体上包含【需求规格说明书，需求规格说明书检查表，需求开发指南等】

需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点。
需求说明书：是根据与现场实际客户进行沟通，把客户的需求进行整理，CMMI中有标准的模板，重点是站在客户的角度讲产品功能。
需求规格说明书：是从业务规则讲起的，细一点偏向于软件的概要设计。是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口、活动图等。