软件需求分析文档.pdf
-软件需求分析文档编写概要与模式一、一、软件需求前期采集部分软件需求前期采集部分1、前期需求采集的方法111.1 市场调研： 了解客户需求,竞争状况及市场力量， 其最终目标是发现创新或改进产品的潜在机会1.2 客户需求:通过市场信息反馈,得到一个总体的软件需求信息,进而对该项要求进行市场调查与信息采集1.3 用户访谈： 针对部分对需求功能点有意向的客户进行重点访谈,增加对功能需求的全面了解，并且可将客户的一些基本需求及内容进行收集1.4 与直接面对客户的一线同时如销售,客服，技术支持等人员交流1.5 研究市场分析报告及文档1.6 试用竞争产品1.72、前期需求采集存在的问题21 区分用户需求与产品需求：用户需求是用户自以为的需求 ,并且经常是为了解决他们自身目前无法实现或较麻烦实现的解决方案,而产品需求，是为了适应更多的客户，找到真正的解决方案。所以， 需求分析是从用户的需求出发，找到真正解决问题的方案，再转化为软件需求的过程2.2 不完整的需求：想让用户代表能够更好的参与到完整性评价中来，就必须采用“业务导向”的组织结构，而不是让用户将一大堆技术动作翻译到自己的业务场景中去。除此之外，在实际的操作过程中还有一个要点， 那就是利用树形层次结构将空管信息与微观信息进行有效的剥离树形测试结构应该面向不同层面，决策者（高层)，事物管理层（中层）,操作层(基层)，将需求分成不同的部分，让合适的人验证合适的部分,然后在汇总起来才是解决之道需求规格说明书应该采用业务导向的树形层次结构来组织2.3 缺乏用户参与主动参与意思是与获得的利益成正比的,对于需求分析员而言，真正的专业主义是基于业务利益(解决问题,创造问题机会，提高管控力等）的沟通4 不切实际的用户期望软件的悟性和成本的不透明， 简单的说，做不到是无效的， 要说明为什么做不到才能解决问题2.5需求变更频繁2信息沟通失真.客户需求放大需求分析人员是有必要对需求进行有效的控制的,问题出在控制的策略和方向上,如何才能缓解这一现象,应该以业务线索来组织需求，基于“Why”的层面对需求建立高层次的认识。业务场景是需求之魂3、前期需求的分类31 新增功能,功能改进,体验提升，软件g,内部需求.2 需求层次:基础，扩展(期望需求）,增值（兴奋需求）、分析需求的商业价值4 重要性:重要程度，该软件功能在市场的需求量，实用性及功能卖点，是否涉及代理-商的协议约定4。2 紧急度:紧急程度，分析该软件功能需求的急迫性,是否涉及合同要求,OSS 的销售及宣传点,4.3持续时间: 持续时间，分析该软件功能的增值空间，带来的商业前景及开发成本等4.4 商业价值: 商业优先级，不考虑实现难度，群体决策、分析需求的实现难度绝对不能因为某个需求的商业价值很大就马上去做， 也不能因为另一个需求的商业价值不大就不做性价比=商业价值/实现难度(简化为开发量）,用于决定先做哪个6、业务需求业务需求 S 股反应企业/组织对软件系统的高层次目标要求，换句话说,就是软件系统的建设目标，而这种目标通常体现在两个方面问题：解决企业/组织运作过程中遇到的问题，例如物资供应脱节,用户投诉量大，客户流失率较高等机会： 抓住外部环境变化所带来的机会， 以便为企业带来新的发展,例如电子商务,网上银行，基于即时通信工作协同系统等。因此业务需求的提出人通常是企业/组织的高层管理人员，它是彻底从业务角度描述的，是指导软件开发的高层需求。明确地定义出业务需求,将给整个团队指出努力的方向,这对整个开发活动将有积极的意义、用户需求用户需求是指描述的是用户使用软件需要完成什么任务,怎么完成的需求，通常是在业务需求定义的基础上进行用户访谈， 调查,对用户使用的场景进行整理,从而建立用户角度的需求.换句话说，用户需求是需求捕获的产物，它具有以下几个方面的特点零散：用户会提出不同角度，不同层面,不同粒度的需求，而且通常是以一句话的形式提出的。存在矛盾:由于用户处于企业/组织的不同层面,因此难免出现盲人摸象的现象,从而导致需求的片面性，甚至在不同用户之间会持有不同的观点.正因为如此,我们还需要对用户需求(也叫做原始需求）进行分析，整理,从而整理出更加精确的需求说明.3、软件需求正如前面所说的,用户需求具有零散,存在矛盾的特点，因此需求分析人员还需要对其进行分析,提炼， 整理,从而生成指导开发的,更精确的软件需求。 换句话说,软件需求是需求分析与建模的产物。SRU诫语 业务需求是需求定义的产物，用户需求是需求捕获的产物,软件需求是需求分析与建模的产物。需求的三种类型：功能需求，非功能需求,设计约束（非技术因素决定的技术选型，预期的软硬件环境，预期的使用环境）SEU 诫语 2 功能需求的要点在于如何组织SRU 诫语 3 非功能需求要点在于保证信息的有效传递和注意其局部性.-SRU 诫语 4设计约束包括非技术因素的技术选型,预期的软硬件环境和预期的使用环境三大类型二、二、软件需求编写部分软件需求编写部分需求文档一般有商业需求文档（RD） ，市场需求文档(MR） ，产品需求文档(R） ，功能详细说明（S）等,最主要的是这三份，其中商业需求文档一般包括项目背景，商业脚趾，功能需求描述，资源评估，风险和对策产品需求文档（PRD)1、总体说明1.1 修订历史：写清楚每次修订的日期，版本号,说明和作者，便于以后追溯1.2 项目概述：简单描述项目的背景,意义，目标等，描述业务领域知识,让文档读者明白这个项目是为什么而做,如果此时 PR没有包含项目的全部需求，也应该相应说明这部分需求是什么,其他需求在哪里等1.3 功能范围：给出本RD 的业务逻辑范围,重点描述系统中角色的职责，与周边系统的关系,全局的商业规则等1.4 用户范围:对本 PRD 涉及的角色，系统做出简单的说明1.5 词汇表：对本RD 涉及的专有词汇，术语，缩写等做出说明1.6 非功能需求：如性能需求，数据监控需求等1.7 其他说明：其他任何需要说明的内容都可以写在这里（主要包含信息:产品的愿景，目标市场，竞争分析，产品功能的详细描述,产品功能的优先级，产品用例，系统需求,性能需求,销售及技术需求等）产品的五个层次：战略层:明确商业目标和用户需求，找准方向，重点是解决两者之间的冲突,找到平衡点范围层:明确“做多少,对于软件类产品，就是确定功能范围，对于网站类产品,就是确定内容范围结构层:考虑产品的各个部分互相之间是什么关系框架层:出现用户真正能看到的是什么东西，对于软件类产品磊说主要的工作是界面设计，而对于网站类产品则是导航设计，两者都有的是信息设计表现层:最后一步工作主要包含了视觉设计和内容的优化一个需求的 DNA需求属性需求属性编号编号提交人（提交人（) )提交时间提交时间模块（模块（*)*)名称（）名称（）描述描述(*)(*)提出者提出者提出时间提出时间BugBug 编号编号分类分类层次层次属性说明属性说明需求的顺序号需求的顺序号, ,唯一的标识唯一的标识需求的录入需求的录入D,D,负责解释需求负责解释需求需求的录入时间需求的录入时间, ,辅助信息辅助信息根据产品的模块划分根据产品的模块划分用简洁的短语描述需求用简洁的短语描述需求需求描述需求描述: :无歧义，完整性，一致性无歧义，完整性，一致性, ,可测试等可测试等即需求的原始提出者即需求的原始提出者, ,有疑惑时便于追溯有疑惑时便于追溯原始需求的获得时间，辅助信息原始需求的获得时间，辅助信息一些一些 BugBug 视为需求，统一管理视为需求，统一管理新增功能，功能改进，体验提升新增功能，功能改进，体验提升,Bug,Bug 修复修复, ,内部需求等内部需求等基础，扩展（期望需求）基础，扩展（期望需求） 、增值、增值( (兴奋需求兴奋需求) )-重要性重要性紧迫度紧迫度持续时间持续时间商业价值商业价值( (）开发量开发量( () )性价比（性价比（*)*)状态（状态（* *）负责负责D(D(）开发工程师开发工程师项目名称项目名称发布时间发布时间备注备注重要程度，辅助确定商业价值重要程度，辅助确定商业价值紧急程度，辅助确定商业价值紧急程度，辅助确定商业价值持续时间，辅助确定商业价值持续时间，辅助确定商业价值商业优先级，不考虑实现难度商业优先级，不考虑实现难度, ,群体决策群体决策需求的开发工作量需求的开发工作量, ,表征实现难度表征实现难度“商业价值“商业价值/ /开发量”开发量” ，用于决定先做哪个，用于决定先做哪个需求生命周期，待讨论，暂缓需求生命周期，待讨论，暂缓, ,拒绝，需求中，开发中，已发布拒绝，需求中，开发中，已发布状态进入“需求中”后确定状态进入“需求中”后确定状态进入“开发中”后确定状态进入“开发中”后确定需求的发布项目需求的发布项目需求的发布时间需求的发布时间其他任何信息，如其他任何信息，如1 1、 被拒绝的理由被拒绝的理由2 2、 被暂缓的理由和重启条件被暂缓的理由和重启条件3 3、 其他相关文档其他相关文档优秀需求的标准、完整性（）用户才是验证需求完整性的合适人选SRU 诫语 5业务导向的层次结构是保障完整性的关键-（）需求完整性存在不同的层面需求是有层次的，企业/组织中的高层管理人员,中层管理人员，操作人员所了解和掌握的信息是不一样的,换句话说,在验证需求完整性时需求需要采用分层评审的方式，不同层次的人员只负责评审与自己相关的那层、不失真需求的正确性和无歧义性是一组相关的要求，指的是确保需求在信息传递的过程中不失真。正确性：要使需求确保正确，就要找到正确的人来进行验证。这包含两层意思,一方面是不同层次的用户所能验证的需求层次是不相同的,应该按宏观,脉络， 细节分而治之,另一方面则是应该找到直接相关的人员来进行验证。 还有一点值得说明， 那就是有时还需要注意避免需求的片面性,具体的方法就通过用户调查来补充无歧义性： 歧义主要是不同背景的人在传递时加入不同理解而导致的， 因此光靠文档来传递需求是不充分的，文档是无法代替沟通的,而且还需要加入一些验证活动才能够尽可能缓解歧义问题总的来说，要确保需求不失真,加强需求的验证是关键手段,但在做需求验证时首先要认识到“验证是质量关”,尽可能多地暴露出问题才是关键3、有优先级想要更好的对项目进行管理,就需要有效的区分出优先级.在优秀需求的7大标准中,就明确的指出了有优先次序，而必要性则是对优先级的一种补充.(1）优先级有不同的角度ERU 诫语 6 需求有时会带上“高优先级”的面具,实际上就是担心你不去实现它我们还是需要引导用户对需求的优先级进行划分，因为业务角度的优先级划分是最为关键的.(2）必要性是优先级评价的盲区满意度：就是指当这个需求项被实现时,用户满意程度的量化值,它体现了需求的充分性不满意度：就是指当这个需求项没有实现时， 用户不满意程度的量化值， 它体现了需求的必要性。EU诫语 7 满意/不满意度模型是需求必要性评价的有效手段4、有技术早期介入与技术团队交流，探讨需求规格说明书在哪些方面存在不足，缺少什么信息,是改进需求规格说明书的有效方法,在优秀需求的 7 大标准中就有两条是和它相关的，可行性就是指需要让开发团队早期介入，对需求中描述的解决方案进行评价,可验证性则是需求规格说明书应该能够指导测试活动的,也提供了验证所需的信息.可行性:当然如果要求开发团队对整个需求规格说明书的内容都进行早期的可行性评价是很难操作的， 因此应该将这些的验证放在重点的需求项上， 以及一些实现技术较复杂的解决方案上。可验证性:现在许多测试团队都必须等到软件开发完成后,才能得到比较好的测试用例，而且经常采用从程序菜单的左上角一直测试到右下角的方式。 这也就体现出了需求规格说明书在组织上应该考虑到测试的需要，应该能够更便于推导出测试用例。三、三、软件需求执行部分软件需求执行部分情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子尽可能多的放弃：在收集阶段没有遗漏,才可能完整的看到事物的全貌，有了大局观，在放弃的时候才知道孰轻孰重，也便下得了手-需求获取基线管理需需需求分析求需求工程开编写规约发需求验证需求工程构成示意图需求工程构成示意图-求管变更管理理需求跟踪四、软件需求完成与问题处理部分
