软件需求分析文档

1、软件需求分析文档编写概要与模式一、软件需求前期采集部分1、前期需求采集的方法1.1市场调研：了解客户需求，竞争状况及市场力量，其最终目标是发现创新或改进产品的 潜在机会客户需求：通过市场信息反馈，得到一个总体的软件需求信息，进而对该项要求进行市 场调查与信息采集用户访谈：针对部分对需求功能点有意向的客户进行重点访谈，增加对功能需求的全面 了解，并且可将客户的一些基本需求及内容进行收集与直接面对客户的一线同时如销售，客服，技术支持等人员交流研究市场分析报告及文档试用竞争产品2、前期需求采集存在的问题区分用户需求与产品需求：用户需求是用户自以为的需求，并且经常是为了解决他们自身目前无法实现或较麻烦

2、实现的解决方案，而产品需求，是为了适应更多的客户， 找到真正的解决方案。所以，需求分析是从用户的需求出发，找到真正解决问题的方案，再转化为软 件需求的过程不完整的需求：想让用户代表能够更好的参与到完整性评价中来，就必须采用“业务导 向”的组织结构，而不是让用户将一大堆技术动作翻译到自己的业务场景中去。除此之外， 在实际的操作过程中还有一个要点，那就是利用树形层次结构将空管信息与微观信息进行有 效的剥离树形测试结构应该面向不同层面，决策者（高层） ，事物管理层（中层），操作层（基层）， 将需求分成不同的部分，让合适的人验证合适的部分，然后在汇总起来才是解决之道 需求规格说明书应该采用业务导向的树

3、形层次结构来组织缺乏用户参与主动参与意思是与获得的利益成正比的，对于需求分析员而言， 真正的专业主义是基于业务利益（解决问题，创造问题机会，提高管控力等）的沟通不切实际的用户期望软件的悟性和成本的不透明，简单的说，做不到是无效的，要说明为什么做不到才能解决问题需求变更频繁信息沟通失真客户需求放大需求分析人员是有必要对需求进行有效的控制的，问题出在控制的策略和方向上，如何才能缓解这一现象，应该以业务线索来组织需求，基于“Why”的层面对需求建立高层次的认识。业务场景是需求之魂3、前期需求的分类新增功能，功能改进，体验提升，软件bug,内部需求需求层次：基础，扩展（期望需求），增值（兴奋需求）4、

4、分析需求的商业价值重要性：重要程度，该软件功能在市场的需求量，实用性及功能卖点，是否涉及代理商的协议约定紧急度：紧急程度，分析该软件功能需求的急迫性，是否涉及合同要求，BOSS的销售及宣传点，持续时间： 持续时间，分析该软件功能的增值空间，带来的商业前景及开发成本等商业价值： 商业优先级，不考虑实现难度，群体决策5、分析需求的实现难度绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做性价比=商业价值/实现难度（简化为开发量），用于决定先做哪个6、1、业务需求业务需求S股反应企业/组织对软件系统的高层次目标要求，换句话说，就是软件系统的建设目标，而这种目标通常

5、体现在两个方面问题：解决企业/组织运作过程中遇到的问题，例如物资供应脱节，用户投诉量大，客户流失率较高等机会：抓住外部环境变化所带来的机会，以便为企业带来新的发展，例如电子商务，网上银行，基于即时通信工作协同系统等。因此业务需求的提出人通常是企业/组织的高层管理人员，它是彻底从业务角度描述的，是指导软件开发的高层需求。明确地定义出业务需求，将给整个团队指出努力的方向，这对整个开发活动将有积极的意义 2、用户需求用户需求是指描述的是用户使用软件需要完成什么任务，怎么完成的需求，通常是在业务需求定义的基础上进行用户访谈， 调查，对用户使用的场景进行整理， 从而建立用户角度的需 求。换句话说，用户需

6、求是需求捕获的产物，它具有以下几个方面的特点零散：用户会提出不同角度，不同层面，不同粒度的需求，而且通常是以一句话的形式提出的。存在矛盾：由于用户处于企业 /组织的不同层面，因此难免出现盲人摸象的现象，从而导致需求的片面性，甚至在不同用户之间会持有不同的观点。正因为如此，我们还需要对用户需求（也叫做原始需求）进行分析，整理，从而整理出更加 精确的需求说明。3、软件需求正如前面所说的，用户需求具有零散，存在矛盾的特点，因此需求分析人员还需要对其进行 分析，提炼，整理，从而生成指导开发的，更精确的软件需求。换句话说，软件需求是需求 分析与建模的产物。SERU诫语1业务需求是需求定义的产物，用户需求

7、是需求捕获的产物，软件需求是需求分析与建模的产物。需求的三种类型：功能需求，非功能需求，设计约束（非技术因素决定的技术选型，预期的软硬件环境，预期 的使用环境）SERU诫语2功能需求的要点在于如何组织SERU诫语3非功能需求要点在于保证信息的有效传递和注意其局部性。SERU诫语4设计约束包括非技术因素的技术选型，预期的软硬件环境和预期的使用环境三大类型软件需求编写部分需求文档一般有商业需求文档（BRD）,市场需求文档（MRD）,产品需求文档（PRD）,功能详细说明（FSD）等，最主要的是这三份， 其中商业需求文档一般包括项目背景，商业脚趾，功能需求描述，资源评估，风险和对策产品需求文档（PRD

8、）1、总体说明修订历史：写清楚每次修订的日期，版本号，说明和作者，便于以后追溯项目概述：简单描述项目的背景，意义，目标等，描述业务领域知识，让文档读者明白 这个项目是为什么而做，如果此时PRD没有包含项目的全部需求，也应该相应说明这部 分需求是什么，其他需求在哪里等功能范围：给出本PRD的业务逻辑范围，重点描述系统中角色的职责，与周边系统的关系，全局的商业规则等用户范围：对本 PRD涉及的角色，系统做出简单的说明词汇表：对本PRD涉及的专有词汇，术语，缩写等做出说明非功能需求：如性能需求，数据监控需求等其他说明：其他任何需要说明的内容都可以写在这里（主要包含信息：产品的愿景，目标市场，竞争分析

9、，产品功能的详细描述，产品功能的优先级，产品用例，系统需求，性能需求，销售及技术需求等）产品的五个层次：战略层：明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突，找到平衡点范围层：明确“做多少”，对于软件类产品，就是确定功能范围，对于网站类产品，就是确定内容范围结构层：考虑产品的各个部分互相之间是什么关系框架层：出现用户真正能看到的是什么东西，对于软件类产品磊说主要的工作是界面设计，而对于网站类产品则是导航设计，两者都有的是信息设计表现层：最后一步工作主要包含了视觉设计和内容的优化一个需求的DNA需求属性属性说明编R需求的顺序号，唯一的标识提交人（*）需求的录入PD,负责解释需求提交

10、时间需求的录入时间，辅助信息模块（*）根据产品的模块划分名称（*）用简洁的短语描述需求描述（*）需求描述：无歧义，完整性，一致性，可测试等提WT即需求的原始提出者，有疑惑时便于追溯提出时间原始需求的获得时间，辅助信息Bug 编 p一些Bug视为需求，统一管理分类新增功能，功能改进，体验提升，Bug修复，内部需求等层次基础，扩展（期望需求）、增值（兴奋需求）重要性重要程度，辅助确定商业价值紧迫度紧急程度，辅助确定商业价值持续时间持续时间，辅助确定商业价值商业价值（*）商业优先级，不考虑实现难度，群体决策开发量（*）需求的开发工作量，表征实现难度性价比（*）“商业价值/开发量”，用于决定先做哪个状

11、态（*）需求生命周期，待讨论，暂缓，拒绝，需求中，开发中，已发布的 PD (*):状态进入“需求中”后确定开发工程师状态进入“开发中”后确定项目名称需求的发布项目发布时间需求的发布时间备注其他任何信息，如1、被拒绝的理由2、被暂缓的理由和重启条件3、其他相关文档优秀需求的标准1、完整性（1）用户才是验证需求完整性的合适人选SERU诫语5业务导向的层次结构是保障完整性的关键(2)需求完整性存在不同的层面需求是有层次的，企业/组织中的高层管理人员，中层管理人员，操作人员所了解和掌握的信息是不一样的，换句话说，在验证需求完整性时需求需要采用分层评审的方式，不同层次的人员只负责评审与自己相关的那层2、

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

13、段，但在做需求验证时首先要认识到“验证是质量关”，尽可能多地暴露出问题才是关键3、有优先级想要更好的对项目进行管理，就需要有效的区分出优先级。在优秀需求的7大标准中，就明确的指出了有优先次序，而必要性则是对优先级的一种补充。(1)优先级有不同的角度SERU诫语6需求有时会带上“高优先级”的面具，实际上就是担心你不去实现它我们还是需要引导用户对需求的优先级进行划分，因为业务角度的优先级划分是最为关键的。(2)必要性是优先级评价的盲区满意度：就是指当这个需求项被实现时，用户满意程度的量化值，它体现了需求的充分性不满意度：就是指当这个需求项没有实现时，用户不满意程度的量化值，它体现了需求的必要性。S

14、ERU诫语7满意/不满意度模型是需求必要性评价的有效手段 4、有技术早期介入与技术团队交流，探讨需求规格说明书在哪些方面存在不足，缺少什么信息，是改进需求规格说明书的有效方法， 在优秀需求的7大标准中就有两条是和它相关的，可行性就是指需要让开发团队早期介入， 对需求中描述的解决方案进行评价，可验证性则是需求规格说明书应该能够指导测试活动的，也提供了验证所需的信息。可行性：当然如果要求开发团队对整个需求规格说明书的内容都进行早期的可行性评价是很以及一些实现技术较复杂的解决方才能得到比较好的测试用例， 而 这也就体现出了需求规格说明书难操作的，因此应该将这些的验证放在重点的需求项上, 案上。以及一些实现技术较复杂的解决方才能得到比较好的测试用例， 而 这也就体现出了需求规格说明书可验证性：现在许多测试