软件需求分析文档
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件需求分析文档-编写概要与模式
一、软件需求前期采集部分
1、前期需求采集的方法
1.1
1.1 市场调研:了解客户需求,竞争状况及市场力量,其最终目标是发现创新或改进产品的潜在机会
1.2 客户需求:通过市场信息反馈,得到一个总体的软件需求信息,进而对该项要求进行市场调查与信息采集1.3 用户访谈:针对部分对需求功能点有意向的客户进行重点访谈,增加对功能需求的全面了解,并且可将客
户的一些基本需求及内容进行收集
1.4 与直接面对客户的一线同时如销售,客服,技术支持等人员交流
1.5 研究市场分析报告及文档
1.6 试用竞争产品
1.7
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涉及的角色,系统做出简单的说明