第3章需求类文档写作
3.1需求概述
作为技术人员,大家更多关注的是技术,但软件需求在很大程度上决定了软件是否正确,需求确定后不管如何实现,功能和质量给客户直接带来的价值远远比技术直接带来的价值要高。因此,做正确的事比正确地做事更重要。错误需求带来的问题一直是各个软件公司项目失败的首要原因,因为获得需求是个复杂的过程,要在实践中不断地学习,提高需求分析的能力。需求有以下三个层次。
1. 业务需求
描述客户的高层次目标,通常问题定义本身就是业务需求的表征。这种目标通常体现在两个方面。
(1) 问题: 解决企业/组织运作过程中遇到的问题,如设备管理混乱、用户投诉量大、客户流失率高等。
(2) 机遇: 抓住外部环境变化所带来的机会,以便为企业带来新的发展,例如电子商务、网上银行、物联网等。
业务需求就是系统目标,它是以业务为导向、指导软件开发的高层次需求。这类需求通常来自高层,例如项目投资人、购买产品的客户、实际用户、市场营销部门或产品策划部门。业务需求从总体上描述了为什么要开发系统(why),组织希望达到什么目标,一般在可行性研究报告中反映,也可使用前景和范围(vision and scope)文档来记录业务需求,这份文档有时也被称做项目章程(Project Charter)或市场需求(Market Requirement)文档。组织愿景是一个组织对将使用的软件系统所要达成的目标的预期期望,如“希望实施CRM后公司的客户满意度达到90%以上”就是一条组织愿景。
2. 用户需求
用户需求是指用户要使用产品完成什么任务,通常是在问题定义的基础上进行用户访谈、调查,对用户使用的场景进行整理,从而获得来自用户角度的需求。用户需求必须能够体现软件系统将给用户带来的业务价值,或用户要求系统必须完成的任务,也就是说用户需求描述了用户能使用系统来做些什么(what),这个层次的需求是非常重要的。
作为需求捕获阶段的主要产物,用户需求主要具有以下特点:
(1) 零散。用户会提出不同角度、不同层面、不同粒度的需求,而且常常是以一句话形式提出的,如通过电话、短信等非正式方式提出的需求。
(2) 相互矛盾。由于不同用户处于企业/组织的不同层面,可能会出现盲人摸象的情况,导致需求的片面性。
因此,还需要对原始需求进行分析和整理,从而得出更加精确的需求说明。用例是表达用户需求的一种有效途径。
3. 软件需求
由于用户需求具有零散、片面的特点,因此需求分析人员还需要对其进行分析、提炼、整理,从而生成可指导开发的、更准确的软件需求,软件需求是需求分析与建模的产物。
软件需求是需求的主体,它是设计具体解决方案的依据(how),其数量往往比用户需求高一个数量级。这些需求记录在软件需求规格说明(Software Requirements Specification,SRS)中。SRS完整地描述了软件系统的预期特性,SRS一般被当作文档保存,设计、实现、测试、质量保证、项目管理以及其他相关的项目过程都要用到SRS。
3.2软件需求的分类
软件需求可分为功能需求、质量需求、约束条件三种类型,质量需求和约束条件也叫非功能需求。
1. 功能需求
功能需求规定必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。
对于功能需求而言,最关键的是如何对其进行组织,否则一句话的描述就会十分分散,很难保证开发人员逐一理解和满足这些要求。
在传统的方法论中,会以系统→子系统→模块→子模块的层次结构来组织,和程序的结构相对应,但这样会割裂用户的使用场景。为了解决这个问题,现代需求理论更加强调需求分析人员从用户的角度将系统理解成一个黑盒子,从横向的使用视角来整理需求。
2. 质量需求
质量需求不同于产品的功能描述,它从不同方面描述产品的各种特性。这些特性包括可用性、可移植性、性能、安全等,它们对用户或开发人员都很重要。
质量需求描述有两个常见问题。
(1) 信息传递的无效性: 在很多需求规格说明书中,会通过一个名为性能需求的小节来说明非功能需求,列出诸如高可靠性、高可用性、高扩展性等要求。但是很多开发人员根本就不看这些内容,因为这样的定性描述缺乏判断标准,故这种信息传递方法是无效的。
(2) 忽略了质量需求的局部性: 经常会看到诸如“所有的查询响应时间都应该小于10s”的描述,但是当用户查询的是年度统计数据时,这样的需求是较难实现的,因此开发人员就会忽略和不理会这样的需求,最终的结果就是导致它成为了摆设。因此更科学的做法是利用具体的应用场景来描述。
……