软件需求的本质
软件需求的本质
在软件项目中，所有干系人的利益交接点主要集中在需求方面。
正是由于需求是软件开发和项目管理活动的基础，因此所有干系人都应该致力于需求实践活动，这是打造一流产品的前提。
需求的层次和种类
- 业务需求描述组织为什么要执行系统（组织希望获得的业务收益）。其关注点在于组织或者提出系统要求的客户有哪些业务目标
- 用户需求描述了用户使用产品必须完成的目标或者任务，并且这个产品要能有为人提供价值。用户需求表达的是用户通过系统完成那些具体的工作。
- 功能需求说的是在特定条件下所展示出来的行为 ，主要描述开发人员需要实现的功能以便用户能够完成自己的任务（用户需求），进而满足业务需求
- 系统需求描述了人们对某个产品的需求，而这个产品由多个组件或者系统子集组成
- 业务规则包括公司政策、政府法规、工业标准以及计算算法。业务规则有时又引申出具体的质量特性，这些特性有以功能的方式由开发人员实现。特定的功能需求可以追溯到具体的业务规则。
- 非功能需求描述系统必须展现的属性或者特性，或者必须遵循的约束。强调的并不是系统要做什么，其重点在于展现系统做的有多棒。包括系统的易用性、安全性、性能等特征。
- 特性单个或者多个用户提供价值的、有逻辑关系的系统性能，可以通过一个功能需求集合进行描述
图中所述的三种主要的需求交付物：愿景和范围文档、用户需求文档和软件需求规范说明（SRS）。无需为每个项目都创建三种独立的需求交付物。但这类需求信息融合在一起（特别是对于小型下项目），还是有必要的。
处理三种层次的需求
经理或者市场部门确定软件的业务需求->业务分析是通常与用户代表协同工作确定用户需求->产品经理决定产品中融入的特性->开发人员、测试人员根据功能和非功能需求进行开发和测试。
每个用户需求和特性必须向完成业务需求看齐。从用户需求角度开发，业务分析师或者产品经理引出能够使用户实现任务目标的功能。
需求开发和管理
需求开发
获取
需求获取涵盖需求发现的所有活动，例如访谈、研讨会、分档分析、原型等- 识别产品的预期客户群和其他干系人
- 理解客户任务、目标业绩这些任务相关的业务目标
- 了解新产品的应用环境
- 与每一类客户群的代表一起工作，理解他们对功能有哪些需要以及对质量有怎样的预期
在进行需求获取活动时，通常采取以用途或者产品为核心的方法。以用途为核心的策略强调的是对用户目标的理解和探求，以便提取必要的系统功能。以产品为核心的方法侧重于特性，目的是领先市场或者业务取得成功。
分析
- 分析来自用户的信息，将其任务目标与用能需求、质量预期、业务规则、建议解决方案和其他信息区别开
- 将概要需求进行适当的细分
- 从其他需求信息中引出功能需求
- 理解质量属性的相对重要性
- 将需求分配给系统架构所定义的软件组件
- 协商需求实现的优先级别
规范说明
需求规范说明以一种连贯并结构清晰的方式来表达和存储收集到的需求知识- 将收集到的用户需求转换为书面形式的需求和图表，供目标读者理解、检查和使用。
验证
需求验证是指确认需求信息是正确的，能使开发人员制定出能满足业务目标的解决方案- 检查记录下来的需求，在交给开发团队认可之前解决所有问题
- 开发验收测试和标准，保证产品的开发是建立在需求基础之上的，能够满足客户需要并达成业务目标
迭代是成功需求开发的关键
需求管理
需求管理活动：
- 及时确认需求基线，提交一个供当前时间段使用的参考，提出一套大家商定的、经过评审和标准的功能需求与非功能需求，通常针对具体的产品发布或者迭代开发
- 评估提议需求变更可能产生的影响，然后以可控方式将获准的变更融入项目
- 随着需求的演化，保持项目计划与需求同步
- 根据预估的需求变更可能带来的影响，商定新的承诺
- 定义各个需求之间存在的关系和依赖
- 跟踪每个需求到它们各自对应的设计、源代码和测试
- 在整个项目过程中跟踪需求状态和变更活动
需求管理的目标不是抑制变更或加大其难度，而是为了预测和协调不可避免且真实存在的变更，最终最小化变更对项目的破坏性影响
人对了，得出的需求却很糟糕
- 用户参与度不够
用户参与度不足会引发新的需求，造成返工并延误工期。
使延误分析师无法理解并准确几乎实际业务或者客户需要，特别实在检查和验证需求时 - 规划不够
软件成本估算不当的主要原因有：频繁的需求变更、需求依赖、与用户沟通不足、低质量的需求规范和不完善的需求分析 - 用户需求蔓延
为了管理范围蔓延，必须一开始就对项目的业务目标、战略愿景、范围、边界和成功标准给予明确说明。以此为参照，对所有的新特性或者需求变更进行评估。
随着新需求的涌现，我们可以将其植入到未完成的条目之中，然后根据优先级别分配到未来的迭代之中。变更也许决定着项目成败，但它总是有代价的。 - 需求模棱俩可
模棱两可的需求会使不同干系人产生不同的期望。
干系人应作为小组以工作坊的形式来讨论和解读需求，共同获取和验证需求。为需求写测试或者建原型也可以帮组我们找出歧义性需求 - 镀金
指开发人员增加的功能并不在需求规范之中（或者超出范围），但开发人员却自认为“用户肯定会喜欢”。如果客户对这个功能并不在意，那么实现这个功能就是再浪费时间
为了降低镀金的风险，就要对每一个功能单元追踪溯源，让大家了解为什么要有这些功能。确保规范和开发的东西都包含在项目范围之内。 - 忽视干系人
用户群不同，特性也不同，如果忽略特定的干系人，某些用户的需求可能就无法满足。
高质量需求过程带来的好处
- 需求中的缺陷和交付产品中的缺陷更少
- 开发的返工减少了
- 开发和交付更快
- 不必要和无用的特性更少
- 减少成本追加
- 信息错误传达的现象减少了
- 范围蔓延减少了
- 项目的混乱现象减少了
- 客户和团队成员的满意度更高了
- 产品按照人们当初的设想顺利运行
从客户的角度审视需求
越频繁的沟通，越容易让开发工作保持在正确的轨道上。
敏捷方法的一个指导性原则是开发人员要与客户保持持续沟通
谁是客户
干系人是指积极参与项目的某个人、群体和组织，它们可能会受项目过程和结果的影响或者影响项目的过程和结果
客户是能够直接或者间接从产品中获益的个人或组织。如上文所说，它们是实际业务需求的提出者，建立项目的指导框架以及启动项目的业务理念。
用户需求应该来自于直接或者间接使用产品的人，这些用户（通常称为“终端用户”）是客户的子集。用户通常能够描述他们需要产品执行的具体任务、他们需要的输出以及他们希望产品达到的质量标准。
提供业务需求的客户有时会试图替实际用户说话，然而这些内容常常和真是用户的需求相去甚远。如果为项目买单的人和最终用户之间有严重的脱节，肯定会出大问题
客户-开发的合作关系
卓越的软件产品来自基于卓越需求的卓越设计。卓越的需求则根基与开发人员与客户（特别是终端用户）高效协作的土壤中。
客户的权利：
- 期望业务分析师用自己的语言进行交流
- 期望业务分析师了解自己的业务和目标
- 希望业务分析师用了解合适的形式记录需求
- 收到需求实践和交付物的相关解释
- 变更需求
- 期望一个相互尊重的环境
- 聆听关于需求以及解决方案的建议和替代方案
- 描述能够提高产品易用性的特性
- 了解调整哪些需求可以实现复用，加速产品开发
- 收到满足自己功能需求和质量预期的系统
客户的责任
- 给业务分析师和开发人员传授你的业务知识
- 准备足够的时间用来澄清需求
- 提供具体而准确的需求
- 及时对需求进行确认
- 尊重开发人员针对需求可行性和成本的估算
- 和开发人员协作设置符合实际的需求优先级
- 评审需求和评估原型
- 设定验收条件
- 及时沟通需求变更
- 尊重需求开发流程
建立尊重需求的企业文化
如果想把开发人员、经理和客户拉在一起，就必须让每一个人都了解公司和客户之间曾经因为需求问题而经理的痛苦。
开发人员也是项目干系人，但他们的需求有时并没有得到任何考虑，使其成为被强加需求的受害者。开发人员应该提供关键信息以确保需求文档能够真正发挥作用。
质量保障人员和测试人员也是优秀需求的贡献者。
组织需要把高效业务分析和需求工程能力作为自己的战略性核心竞争力。
对需求达成一致
涉及的多个角色应形成如下共识：
- 客户承认需求描述了他们的需要
- 开发人员承认理解需求并且认为它们是可实现的
- 测试人员承认需求是可验证的
- 管理层承认需求可以达成他们的业务目标
不要把签字作为武器。把它当做一个里程碑，表示大家对签字活动的意义有清晰的共识，也包括理解未来有可能的变更。
需求基线
比签字仪式更重要的是确立一条需求基线，一个特定时间点的需求快照。需求基线是一组需求，在平生和确认后作为后续开发的基础。
“我同意当前这组需求代表我们对项目下一阶段需求最深入的理解，并且基于目前我们对问题的理解，这个解决方案能够满足我们的需求。我同意在未来使用项目定义好的变更流程基于这个基线对需求进行修改。我清除变更可能导致我们重新讨论项目的成本、涉及的资源以及对时间表的承诺。”
- 客户管理层或者市场营销人员相信项目不会超出可控范围,因为客户会为范围变化的决定负责。
- 用户代表相信开发团队会和他们一起工作,交付正确的解决方案,即使他们在开发开始之前没有考虑清楚所有的需求。
- 开发部门的信心建立在开发团队有业务伙伴保证项目始终聚焦于其目标上,同时业务伙伴也和开发团队一起平衡项目计划、成本、功能和质量。
- 业务分析师和项目经理有信心有效控制项目变更带来的风险,并使风险最小化。
- 质量保证和测试团队有信心开发测试脚本并且为自己在项目中的各种活动做好准备。
需求实践
在需求开发中，“逐步完善细节”是实施中的一个关键术语，指的是从一些原始的需求想法向更精确的理解和表述演进
