1.1前言
软件中的很多问题大多数来源于人们了解、记录、协商和修改产品需求的方法不当。现实生产环境中的软件产品发现的缺陷有40%~50%是在需求阶段埋下的“祸根”(Davis 2005)。在具体说明客户需求和管理客户需求过程中用户输入不足和有误,是造成项目失败的罪魁祸首。在软件项目中,所有干系人的利益交接点主要集中在需求方面。(更多干系人方面的内容参考本栏目后面章节)这些干系人主要包括客户、用户、业务分析人员和开发人员等。若处理得当,这种交接既让客户满意,又能鼓舞开发团队。若处理不当。则会引发误解和摩擦,最终降低产品质量和业务价值。
本章将学习:
- 理解软件需求领域所用的一些关键术语;
- 区分船票需求和项目需求;
- 区分需求开发和需求管理;
- 警惕可能出现的与需求相关的一些问题。
给自己的需求把把脉:
- 从来没有清晰制定过项目的业务目标、愿景和范围。
- 客户太忙,没有时间与分析师或开发人员共同处理需求。
- 团队无法与用户代表直接互动,不理解他们的具体需要。
- 客户认为所有的需求都很关键,因此没有对需求排定优先级。
- 开发人员在写代码时遇到了模棱两可或者遗漏的信息,所以只能靠猜。
- 开发人员与干系人沟通的重点集中于用户界面展示或者特性,并没有关注用户要使用软件完成的具体任务。
- 需求从来没得到过客户的认可。
- 客户认可了某个发布或者迭代的需求,但事后不断更改。
- 不断接受客户的需求变更请求,项目范围随之扩大,由于没有增加资源或者删减功能,进度最后完全被打乱。
- 有人提出了变更请求,但被忽略,没人知道特定变更请求的具体状态。
- 客户提出特定的功能要求,而且开发人员也建好了,但就是没有人使用过。
- 在项目接近尾声时,虽然满足规范说明,却不满足客户或业务的目标。
1.2软件需求的定义
对于开发人员来说,客户定义的需求听上去更像是一种高级产品的概念。
对于用户来说,开发人员所说的需求理念听上去更像是一种具体的用户界面设计。
这种理解上的偏差都是普遍存在的。
1.2.1关于“需求”的一些解释
顾问布莱恩劳伦斯认为需求是“任何能够驱动设计做出选择的东西”,需求的目的是要做出合适的设计选项,最终满足客户的需要。
Ian Sommerville and Pete Sawyer(1997)提出:需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性,可以是一种对系统开发进程的约束。
Tips:不要妄想项目中的所有干系人都能对需求达成统一的认识。提前确定定义,以便大家能够达成共识。
1.2.2字典中的“需求”
字典中对“需求”解释为:被命令或者强制性的东西;需要或者必要。这对软件界所使用的“需求”不是一个含义。人们有时会怀疑是否有必要对需求进行优先级排序,因为有的低优先级需求可能永远不会被实现。
需求包含一个时间维度,它们可能是描述目前系统性能的现在时。或者它们可能是近期(高优先级)、中期(中等优先级)或者想象中(低优先级)的未来。
1.3需求的层次和种类
1.3.1需求领域的常用术语
术语 | 定义 |
---|---|
业务需求 | 开发产品的组织或者获取产品的客户所需的高层次业务目标 |
业务规则 | 策略、纲领、标准或者制度,能够定义或者约束某些方面的业务。虽然本身不是软件需求,但它却是一些类型的软件需求的鼻祖 |
约束 | 对开发人员在产品设计和构建上的限制条件 |
外部界面需求 | 对软件系统和用户、其他软件系统或硬件设备间的关联进行说明 |
特性 | 单个或者多个为用户提供价值的、有逻辑关系的系统性能,可以通过一个功能需求集合进行描述 |
功能需求 | 描述系统在特定条件下展现的行为 |
非功能需求 | 描述系统必须展现的属性或者特性,或者必须遵守的约束 |
质量属性 | 一种非功能能需求,描述的是服务或者一个产品的性能特征,例如性能、安全性、易用性和可移植性 |
系统需求 | 包含多个子系统的产品的顶层需求,子系统可以是软件,也可以是软硬件 |
用户需求 | 特定用户群必须能够用系统所完成的目标任务,或者用户期望有的产品属性 |
1.3.2软件需求的三个层次
- 业务需求:描述组织为什么要执行系统(组织期望获得的业务收益),其关注点在于组织或者提出系统要求的客户有哪些业务目标。
- 用户需求 :描述了用户使用产品必须完成的目标或任务,并且这个产品要能够为人提供价值。用例、用户故事以及事件响应表都是用户需求的表达方式。用户需求表达的是用户通过系统来完成哪些具体工作。
- 功能需求:产品在特定条件下所展示出来的行为,主要描述开发人员需要实现的功能以便用户能够完成自己的任务(用户需求),进而满足业务需求。常将功能需求记录为传统意义上的“应当”句式:某某应当能进行什么动作。
数据需求贯穿于这三个层次的需求之中。
业务分析师(BA)将功能需求记录在软件需求规范说明(SRS)之中,尽可能详尽地描述人们对软件系统的预期行为。SRS用于开发、测试、质量保障、项目管理和相关项目功能。它还称作业务需求文件、功能规范说明、需求文件等。
1.3.3处理三种层次的需求
前面图1-1显示了三种主要的需求交付物:愿景、范围文档、用户需求文档和软件需求规范说明。无需为每个项目都创建这三种需求交付物。要注意这三种交付物包含不同的信息,要在项目的不同点进行开发,开发人员也可能不同,目的和目标受众也不相同。
前面图1-1展示了一个简单的自上而下的需求信息流。在现实中,我们见到的是以业务、用户和功能需求为中心的循环和迭代。只要提出某个新特性、用户需求或者一点点功能,分析师肯定会问“这在范围之内吗?”如果回答“是”,则将此需求纳入规范说明。若回答“不,但它支持业务目标,所以应该算是吧。”,这种情况下,项目发起方、项目经理或者产品负责人都必须当机立断,决定是否增加当前项目或者迭代范围以适应新的需求。这种业务决策对项目的计划和预算都有着很大的影响,可能要对其他功能做出妥协。
高效的变更过程包含“影响分析”以保证合适的人做出可靠的业务决策,确定哪些变更可以接受,解决时间、资源或特性权衡所关联的成本。
1.3.4产品需求与项目需求
到目前为止,讨论的需求主要描述软件系统的属性。我们将其称之为产品需求。项目还包含其他诉求和产出,不在团队执行的软件范围之内,但对项目整体成败尤为关键。这些都是项目需求而非产品需求。SRS包含产品需求,但不包括产品设计或执行细节、项目计划、测试计划等信息。要将这类事项独立出去,使需求开发活动聚焦于理解团队要开发的内容。
项目需求包括:
- 开发团队的物质需求,包括工作站、专用硬件设备、测试实验室、测试工具和设备、团队办公室和视频会议设备。
- 员工培训需求。
- 用户文档,包括培训材料、教程、参考手册和发行说明。
- 支持文件,例如帮助资源、硬件的现场维护和服务信息。
- 操作环境中所需要的基础设施变更。
- 需求和流程,用于发布产品,在实际操作环境中安装产品,对它进行配置和测试。
- 针对从旧系统迁移到新系统所做的需求和规则,例如数据合并和转换、安全设置、产品切换以及弥补技术空白而做的培训,我们又时也称为迁移需求。
- 产品认证和合规需求。
- 修改的策略、过程、组织结构和类似文档。
- 第三方软硬件组件的采购、收购和许可。
- Beta测试、生产、包装、市场和发行需求。
- 客户服务等级协议。
- 针对与软件相关的知识产权,为获取法律保护(专利、商标或者版权)所做的需求。
项目需求信息最好存储在项目管理计划中,详细列出全部预期项目活动和交付物。
特别是针对业务应用,人民有时认为“解决方案”包含产品需求(业务分析师的主要责任)和项目需求(项目经理主要责任)。在本次学习中,我们讨论产品需求,不管最终的交付物是某个商业软件产品、带嵌入式软件的硬件设备、企业信息系统、政府定制软件还是其他任何东西。