- 软件需求的本质
>软件中的很多问题大多数来源于人们了解、记录、协商和修改产品需求的方法不当。
>在软件项目中，所有干系人的利益交接点主要集中在需求方面。
>这些干系人包括客户、用户、业务分析人员和开发人员等。正是由于需求是软件开发和项目管理活动的基础，因此所有干系人都应该致力于需求实践活动，这是打造一流产品的前提。
给自己的需求把把脉：
>从来没有清晰制定过项目的业务目标、愿景和范围。
>客户太忙，没有时间与分析师或开发人员共同处理需求。
>团队无法与用户代表直接互动，不理解他们的具体需要。
>客户认为所有的需求都很关键，因此没有对需求排定优先级。
>开发人员在写代码时遇到了模棱两可或者遗漏的信息，所以只能靠猜。
>开发人员与干系人沟通的重点集中于用户界面展示或者特性，并没有关注用户要使用软件完成的具体任务。
>需求从来没得到过客户的认可。
>客户认可了某个发布或者迭代的需求，但事后又不断更改。不断接受客户的需求变更请求，项目范围随之扩大，由于没有增加资源或者删减功能，进度最后完全被打乱。
>有人提出了变更请求，但被忽略，没人知道特定变更请求的具体状态。
>客户提出特定的功能要求，而且开发人员也建好了，但就是没有人用过。
>在项目接近尾声时，虽然满足规范说明，却不满足客户或业务的目标。
需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。
不要妄想项目中的所有干系人都能对需求达成统一的认识。提前确立定义，以便大家能够达成共识。
| 术语 | 定义 |
| 业务需求 | 开发产品的组织或者获取产品的客户所需的高层次业务目标 |
| 业务规则 | 策略、纲领、标准或者制度，能够定义或者约束某些方面的业务。虽然本身并不是软件需求，但它却是一些类型的软件需求的鼻祖 |
| 约束 | 对开发人员在产品设计和构建上的限制条件 |
| 外部界面需求 | 对软件系统和用户、其他软件系统或硬件设备间的关联进行说明 |
| 特性 | 单个或者多个为用户提供价值的、有逻辑关系的系统性能，可以通过一个功能需求集合进行描述 |
| 功能需求 | 描述系统在特定条件下展现的行为 |
| 非功能需求 | 描述系统必须展现的属性或者特性，或者必须遵守的约束 |
| 质量属性 | 一种非功能需求，描述的是服务或者一个产品的性能特征 |
| 系统需求 | 包含多个子系统的产品的顶层需求，子系统可以是软件，也可以是软硬件 |
| 用户需求 | 特定用户群必须能够用系统所完成的目标或任务，或者是用户期望有的产品属性 |
表 1 一些类型的需求信息
各类需求之间的关系。实线代表“被存储于”；虚线代表“起源”或“影响”
业务需求描述组织为什么要执行系统（组织希望获得的业务收益）。其关注点在于组织或者提出系统要求的客户有哪些业务目标。
用户需求描述了用户使用产品必须完成的目标或者任务，并且这个产品要能够为人提供价值。用户需求主要还包括对用户满意度最为关键的产品特性或特征的描述。
功能需求说的是产品在特定条件下所展示出来的行为，主要描述开发人员需要实现的功能以便用户能够完成自己的任务（用户需求），进而满足业务需求。
业务分析师（BA)将功能需求记录在软件需求规范说明（software requirements specification，SRS）之中，尽可能详尽地描述人们对软件系统的预期行为。SRS用于开发、测试、质量保障、项目管理和相关项目功能。
系统需求描述了人们对某个产品的需求，而这个产品由多个组件或者系统子集组成（ISOAECAEEE2011)。
业务规则包括公司政策、政府法规、工业标准以及计算算法。
一个特性包含一个或者多个逻辑上有关联的系统功能，能够为用户提供价值，这些由一组功能性需求来共同描述。
特性包含多种用户需求，每种需求都表示特定的功能需求必须实现，以便用户能完成用户需求中所描述的任务。
处理三种层次的需求↓
产品需求与项目需求
SRS包含产品需求，但不包括设计或执行细节（不同于已知的约束）、项目计划、测试计划或者类似信息。要将这类事项独立出去，使需求开发活动聚焦于理解团队要开发的内容。项目需求包括以下具体内容。
>开发团队的物质需求，比如工作站、专用硬件设备、测试实验室、测试工具和设备、团队办公室和视频会议设备。
>员工培训需求。
>用户文档，包括培训材料、教程、参考手册和发行说明。
>支持文件，例如帮助资源、硬件的现场维护和服务信息。
>操作环境中所需要的基础设施变更。
>需求和流程，用于发布产品，在实际操作环境中安装产品，对它进行配置和测试。
>针对从旧系统迁移到新系统所做的需求和规则，例如数据合并和转换、安全设置、产品切换以及为弥补技术空白而做的培训，我们有时称之为迁移需求（IIBA2009）
>产品认证和合规需求。
>修改的策略、过程、组织结构和类似文档。
>第三方软件和硬件组件的采购、收购和许可。
>Beta测试、生产、包装、市场和发行需求。
>客户服务等级协议。
需求开发管理
最好将需求工程分为需求开发和需求管理。
需求开发
获取、分析、规范说明、验证。
获取：
主要活动如下所示。
>识别产品的预期客户群和其他干系人。
>理解客户任务、目标以及与这些任务相关的业务目标。
>了解新产品的应用环境。
>与每一类客户群的代表一起工作，理解他们对功能有哪些需要以及对质量有怎样的预期。
分析：
下面是一些基本活动。
分析来自用户的信息，将其任务目标与功能需求、质量预期、业务规则、建议解决方案和其他信息区别开。
将概要需求进行适当的细分。
从其他需求信息中引出功能需求。理解质量属性的相对重要性。
将需求分配给系统架构所定义的软件组件。
协商需求实现的优先级别。
找出需求中的遗漏的或多余的、不必要的需求，以便定义范围。
规范说明：
需求规范说明以一种连贯并结构清晰的方式来表达和存储收集到的需求知识。主要活动如下。
将收集到的用户需求转换为书面形式的需求和图表，供目标读者理解、检查和使用。
验证：
需求验证是指确认需求信息是正确的，
>检查记录下来的需求，在交给开发团队认可之前解决所有问题。
>开发验收测试和标准，保证产品的开发是建立在需求基础之上的，能够满足客户需要并达成业务目标。
迭代是成功需求开发的关键。
需求管理
需求管理活动如下：
>及时确定需求基线，提交一个供当前时间段使用的参考，提出一套大家商定的、经过评审和批准的功能需求与非功能需求，通常针对具体的产品发布或者开发迭代。
>评估提议需求变更可能产生的影响，然后以可控方式将获准的变更融入项目。
>随着需求的演化，保持项目计划与需求同步。
>根据预估的需求变更可能带来的影响，商定新的承诺。
>定义各个需求之间存在的关系和依赖。
>跟踪每个需求到它们各自对应的设计、源代码和测试。
>在整个项目过程中跟踪需求状态和变更活动。
需求管理的目标不是抑制变更或加大其难度，而是为了预测和协调不可避免且实际存在的变更，最终最小化变更对项目的破坏性影响。
需求管理
需求开发和需求管理的界线
每个项目都有需求
软件涉及的相关系统都有对其依赖的干系人。花一些时间理解他们的需要，这对项目的成功是一种高杠杆投资。
人们有时不愿花时间写软件需求。但核心问题并不在于写需求，而在于判断需求。
需求很糟糕？
>用户参与度不够
用户参与度不足会引发新的需求，造成返工并延误工期。
>规划不当
软件成本估算不当的主要原因有：频繁的需求变更、需求遗漏、与用户沟通不足、低质量的需求规范和不完善的需求分析（Davis 1995）。
>用户需求蔓延
为了管理范围蔓延，必须一开始就对项目的业务目标、战略愿景、范围、边界和成功标准给予明确说明。
>需求模棱两可
需求模核两可的一大特征就是读的人可以用许多种方式来解读需求说明(Lawrence 1996）。另外一个信号是读的人不同，对需求的理解也各不相同。
>镀金
所谓镀金，是指开发人员增加的功能并不在需求规范说明之中（或者超出范围），但开发人员却自认为“用户肯定喜欢。”
>忽视干系人
如果无法在早期为产品确定主要的用户分类，某些用户的需要可能就无法满足.
除了显而易见的用户，还要考虑维护人员和现场支持人员，他们也有自身的需求，包括功能需求和非功能需求。
发表回复