软件需求分析文档

1.1 市场调研：了解客户需求，竞争状况及市场力量，其最终目标是发现创新或改进产品的

潜在机会 1.2 客户需求：通过市场信息反馈,得到一个总体的软件需求信息，进而对该项要求进行市场

调查与信息采集 1.3 用户访谈：针对部分对需求功能点有意向的客户进行重点访谈,增加对功能需求的全面了

解，并且可将客户的一些基本需求及内容进行收集

1.4 与直接面对客户的一线同时如销售，客服，技术支持等人员交流 1.5 研究市场分析报告及文档 1.6 试用竞争产品

2、 前期需求采集存在的问题

2。1 区分用户需求与产品需求：用户需求是用户自以为的需求，并且经常是为了解决他们自身目前无法实现或较麻烦实现的解决方案，而产品需求,是为了适应更多的客户,找到真正的解决方案。所以,需求分析是从用户的需求出发，找到真正解决问题的方案，再转化为软件需求的过程

2.2 不完整的需求：想让用户代表能够更好的参与到完整性评价中来，就必须采用“业务导向”的组织结构，而不是让用户将一大堆技术动作翻译到自己的业务场景中去.除此之外，在实际的操作过程中还有一个要点，那就是利用树形层次结构将空管信息与微观信息进行有效的剥离

树形测试结构应该面向不同层面，决策者（高层）,事物管理层(中层），操作层(基层），将需求分成不同的部分，让合适的人验证合适的部分，然后在汇总起来才是解决之道 需求规格说明书应该采用业务导向的树形层次结构来组织 2.3 缺乏用户参与

主动参与意思是与获得的利益成正比的，对于需求分析员而言,真正的专业主义是基于业务利益（解决问题,创造问题机会，提高管控力等）的沟通 2。4 不切实际的用户期望

软件的悟性和成本的不透明，简单的说，做不到是无效的,要说明为什么做不到才能解决问题

2。5 需求变更频繁 2.6 信息沟通失真 2。7 客户需求放大

需求分析人员是有必要对需求进行有效的控制的，问题出在控制的策略和方向上，如何才能缓解这一现象，应该以业务线索来组织需求,基于“Why”的层面对需求建立高层次的认识。 业务场景是需求之魂 3、 前期需求的分类

3。1 新增功能,功能改进,体验提升，软件bug，内部需求 3。2 需求层次：基础,扩展（期望需求)，增值（兴奋需求) 4、分析需求的商业价值

4.1 重要性：重要程度,该软件功能在市场的需求量，实用性及功能卖点，是否涉及代理商的协议约定

4。2 紧急度:紧急程度，分析该软件功能需求的急迫性，是否涉及合同要求，BOSS的销售

及宣传点，

4.3 持续时间: 持续时间，分析该软件功能的增值空间，带来的商业前景及开发成本等 4。4 商业价值： 商业优先级，不考虑实现难度,群体决策 5、分析需求的实现难度

绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做

性价比=商业价值/实现难度（简化为开发量)，用于决定先做哪个 6、

1、业务需求

业务需求S股反应企业/组织对软件系统的高层次目标要求，换句话说，就是软件系统的建设目标，而这种目标通常体现在两个方面

问题:解决企业/组织运作过程中遇到的问题，例如物资供应脱节，用户投诉量大，客户流失率较高等

机会：抓住外部环境变化所带来的机会，以便为企业带来新的发展，例如电子商务,网上银行，基于即时通信工作协同系统等。

因此业务需求的提出人通常是企业/组织的高层管理人员，它是彻底从业务角度描述的，是指导软件开发的高层需求。明确地定义出业务需求，将给整个团队指出努力的方向，这对整个开发活动将有积极的意义 2、用户需求

用户需求是指描述的是用户使用软件需要完成什么任务，怎么完成的需求，通常是在业务需求定义的基础上进行用户访谈，调查，对用户使用的场景进行整理，从而建立用户角度的需求。换句话说,用户需求是需求捕获的产物，它具有以下几个方面的特点

零散：用户会提出不同角度，不同层面，不同粒度的需求，而且通常是以一句话的形式提出的.

存在矛盾：由于用户处于企业/组织的不同层面，因此难免出现盲人摸象的现象，从而导致需求的片面性，甚至在不同用户之间会持有不同的观点。

正因为如此,我们还需要对用户需求（也叫做原始需求）进行分析，整理，从而整理出更加精确的需求说明。 3、软件需求

正如前面所说的，用户需求具有零散，存在矛盾的特点,因此需求分析人员还需要对其进行分析，提炼，整理,从而生成指导开发的，更精确的软件需求。换句话说,软件需求是需求分析与建模的产物。

SERU 诫语1 业务需求是需求定义的产物，用户需求是需求捕获的产物,软件需求是需求分析与建模的产物. 需求的三种类型:

功能需求，非功能需求,设计约束（非技术因素决定的技术选型，预期的软硬件环境，预期的使用环境）

SERU 诫语2 功能需求的要点在于如何组织

SERU 诫语3 非功能需求要点在于保证信息的有效传递和注意其局部性。 SERU 诫语4 设计约束包括非技术因素的技术选型，预期的软硬件环境和预期的使用环境三大类型

二、 软件需求编写部分

需求文档一般有商业需求文档（BRD)，市场需求文档（MRD)，产品需求文档(PRD）,功能详细说明（FSD）等，最主要的是这三份，其中商业需求文档一般包括项目背景，商业脚趾，

功能需求描述,资源评估，风险和对策 产品需求文档（PRD） 1、 总体说明

1.1 修订历史：写清楚每次修订的日期,版本号，说明和作者，便于以后追溯

1.2 项目概述:简单描述项目的背景，意义，目标等，描述业务领域知识，让文档读者明白这

个项目是为什么而做，如果此时PRD没有包含项目的全部需求，也应该相应说明这部分需求是什么，其他需求在哪里等

1.3 功能范围：给出本PRD的业务逻辑范围,重点描述系统中角色的职责，与周边系统的关

系，全局的商业规则等

1.4 用户范围:对本PRD涉及的角色，系统做出简单的说明 1.5 词汇表：对本PRD涉及的专有词汇,术语，缩写等做出说明 1.6 非功能需求：如性能需求，数据监控需求等

1.7 其他说明：其他任何需要说明的内容都可以写在这里

（主要包含信息：产品的愿景，目标市场，竞争分析，产品功能的详细描述,产品功能的优先级，产品用例，系统需求，性能需求，销售及技术需求等） 产品的五个层次:

战略层:明确商业目标和用户需求,找准方向，重点是解决两者之间的冲突,找到平衡点

范围层：明确“做多少\对于软件类产品，就是确定功能范围，对于网站类产品，就是确定内容范围

结构层：考虑产品的各个部分互相之间是什么关系

框架层:出现用户真正能看到的是什么东西，对于软件类产品磊说主要的工作是界面设计，而对于网站类产品则是导航设计，两者都有的是信息设计 表现层：最后一步工作主要包含了视觉设计和内容的优化 一个需求的DNA 需求属性 编号 提交人（＊） 提交时间 模块（＊） 名称（＊） 描述(*） 提出者 提出时间 Bug编号 分类 层次 重要性 紧迫度 持续时间 商业价值（*） 开发量（*) 性价比（*) 状态（＊） 负责PD(*） 属性说明 需求的顺序号,唯一的标识 需求的录入PD，负责解释需求 需求的录入时间，辅助信息 根据产品的模块划分 用简洁的短语描述需求 需求描述：无歧义，完整性，一致性，可测试等 即需求的原始提出者，有疑惑时便于追溯 原始需求的获得时间,辅助信息 一些Bug视为需求,统一管理 新增功能，功能改进，体验提升，Bug修复，内部需求等 基础，扩展（期望需求）、增值(兴奋需求) 重要程度，辅助确定商业价值 紧急程度，辅助确定商业价值 持续时间，辅助确定商业价值 商业优先级，不考虑实现难度，群体决策 需求的开发工作量，表征实现难度 “商业价值/开发量”,用于决定先做哪个 需求生命周期，待讨论，暂缓，拒绝,需求中,开发中,已发布 状态进入“需求中”后确定 开发工程师 项目名称 发布时间 备注 状态进入“开发中\"后确定 需求的发布项目 需求的发布时间 其他任何信息，如 1、 被拒绝的理由 2、 被暂缓的理由和重启条件 3、 其他相关文档 …… 优秀需求的标准 1、完整性

（1）用户才是验证需求完整性的合适人选

SERU 诫语5 业务导向的层次结构是保障完整性的关键 (2）需求完整性存在不同的层面

需求是有层次的，企业/组织中的高层管理人员，中层管理人员，操作人员所了解和掌握的信息是不一样的，换句话说，在验证需求完整性时需求需要采用分层评审的方式，不同层次的人员只负责评审与自己相关的那层 2、不失真

需求的正确性和无歧义性是一组相关的要求，指的是确保需求在信息传递的过程中不失真。 正确性：要使需求确保正确,就要找到正确的人来进行验证.这包含两层意思，一方面是不同层次的用户所能验证的需求层次是不相同的，应该按宏观，脉络,细节分而治之，另一方面则是应该找到直接相关的人员来进行验证。还有一点值得说明，那就是有时还需要注意避免需求的片面性,具体的方法就通过用户调查来补充 无歧义性：歧义主要是不同背景的人在传递时加入不同理解而导致的，因此光靠文档来传递需求是不充分的，文档是无法代替沟通的，而且还需要加入一些验证活动才能够尽可能缓解歧义问题

总的来说，要确保需求不失真,加强需求的验证是关键手段，但在做需求验证时首先要认识到“验证是质量关\"，尽可能多地暴露出问题才是关键 3、有优先级

想要更好的对项目进行管理，就需要有效的区分出优先级。在优秀需求的7大标准中，就明确的指出了有优先次序，而必要性则是对优先级的一种补充。 （1）优先级有不同的角度

SERU 诫语6 需求有时会带上“高优先级”的面具，实际上就是担心你不去实现它 我们还是需要引导用户对需求的优先级进行划分，因为业务角度的优先级划分是最为关键的。 （2）必要性是优先级评价的盲区

满意度：就是指当这个需求项被实现时，用户满意程度的量化值，它体现了需求的充分性 不满意度:就是指当这个需求项没有实现时，用户不满意程度的量化值，它体现了需求的必要性。

SERU 诫语7 满意/不满意度模型是需求必要性评价的有效手段 4、有技术早期介入

与技术团队交流,探讨需求规格说明书在哪些方面存在不足，缺少什么信息,是改进需求规格说明书的有效方法,在优秀需求的7大标准中就有两条是和它相关的，可行性就是指需要让开发团队早期介入，对需求中描述的解决方案进行评价，可验证性则是需求规格说明书应该能够指导测试活动的，也提供了验证所需的信息。 可行性：当然如果要求开发团队对整个需求规格说明书的内容都进行早期的可行性评价是很

难操作的，因此应该将这些的验证放在重点的需求项上,以及一些实现技术较复杂的解决方案上。

可验证性:现在许多测试团队都必须等到软件开发完成后，才能得到比较好的测试用例,而且经常采用从程序菜单的左上角一直测试到右下角的方式.这也就体现出了需求规格说明书在组织上应该考虑到测试的需要，应该能够更便于推导出测试用例. 三、 软件需求执行部分

情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子

尽可能多的放弃：在收集阶段没有遗漏，才可能完整的看到事物的全貌，有了大局观,在放弃的时候才知道孰轻孰重，也便下得了手

需求获取 基线管理 需求开发 需求管理 需求分析 需求工程 变更管理 编写规约 需求跟踪 需求验证

需求工程构成示意图

四、软件需求完成与问题处理部分