业务分析与需求.pdf

业务分析与需求业务分析与需求 周金根周金根 2010-2-24 目录 业务分析与需求 . 1 前言 5 babok - 业务分析知识体系介绍 . 6 什么是 business analysis 7 谁是 ba . 7 范围(scope). 8 babok 结构 8 各组成部分在项目不同阶段大致工作量比例 . 11 cbap 认证发展阶段 . 12 babok - ba 计划和监控概要 . 13 描述 . 13 目的 . 13 任务列表 . 14 任务：涉众管理（conduct stakeholder analysis） . 14 任务：计划活动（plan business analysis activities） . 14 任务：计划沟通（plan business analysis communication） . 15 任务：计划需求管理流程（plan requirements management process） . 15 任务： 计划、 监控和报表业务分析绩效 （plan, monitor and report on business analysis performance） 15 babok 企业分析概要 . 17 描述 . 17 目的 . 17 任务列表 . 17 任务：标识业务需要（identify business need） 18 任务：确定方案步骤（determine solution approach） . 18 任务：定义方案范围（define solution scope） . 18 任务：开发业务案例（develop the business case） 19 babok - 需求获取（elicitation） . 20 描述 . 20 目的 . 20 任务列表 . 21 任务：准备工作（prepare for elicitation） 21 任务：开展获取（conduct elicitation） 21 任务：文档化获取结果（document elicitation results） . 21 任务：确认获取结果（confirm elicitation results） . 22 babok 需求分析概述 . 23 描述 . 23 目的 . 23 任务列表 . 24 任务：组织需求（organize requirements） . 24 任务：划分优先级（prioritize requirements） . 24 任务：详述需求和建模（specify and model requirements） . 24 任务：确定假定和约束（determine assumptions and constraints） 25 任务：确认需求（verify requirements） 25 任务：验证需求（validate requirements） 25 babok 方案评估和验证概述 . 26 描述 . 26 目的 . 26 任务列表 . 27 任务：评估需求覆盖率（assess requirements coverage） . 27 任务：分配需求（allocate requirements） 27 任务：确定组织意愿（determine organizational readiness） 28 任务：验证方案（validate solution） . 28 任务：评价方案（evaluate solution） . 28 babok 需求管理和沟通概要 . 30 描述 . 30 目的 . 30 任务列表 . 31 任务：管理方案和需求的范围（manage solution and requirements scope） 31 任务：管理需求追溯（manage requirements traceability） . 32 任务：管理需求重用（maintain requirements for re-use） 32 任务：准备需求包（prepare requirements package） . 32 任务：传递需求（communicate requirements） 33 babok 业务分析技术概要 . 34 软件需求的三个层次 . 36 业务需求 . 36 用户需求 . 38 功能需求 . 38 三个层次的开发关系 . 39 需求工程需求开发需求管理 . 42 需求开发 . 42 需求获取 . 44 需求分析 . 44 需求管理 . 46 用 kano 模型来确定需求优先级 . 48 客户满意度模型 kano 48 评估需求类型 . 48 kano 模型分析 49 原型开发. 51 为什么需要原型 . 51 水平和垂直的原型 . 51 抛弃型原型或进化型原型 . 51 低保真原型和高保真原型 . 52 原型工具 . 53 原型不仅仅是界面 . 54 openexpressapp 对原型的支持 55 获取需求方法：nine boxes . 56 三个方面 . 56 三种提问方式 . 57 用户故事 . 57 为客户着想 . 57 确定优先级的四个因素 . 58 用户经验曲线 . 59 用户经验曲线 . 59 大多数用户是大众（competent ）的用户 60 附一：业务流程梳理工具 sam . 62 业务流程五个层次 . 62 流程梳理工作方法 . 64 附二：原型工具 gui design studio . 65 前言前言 业务分析和需求对产品来说起到决定性作用，本文将会讲解一下业务分析知识体系 babok 以及一些与需求相关的一些知识 babok - 业务分析知识体系介绍业务分析知识体系介绍 当我们作项目时，下面这张图很多人都明白，从计划、构建、测试、部署实 施后发现提供的方案并不能真正解决用户的问题， 那么我们是不是少了什么步骤 或 者缺少对什么环节的重视呢？ 上图和下图对比就可以看出来，保证产品是客户想要的，那么必须有业务分 析这个重要环节 业务分 析这个重要环节，必须很好的描述和定义用户的需求并提供解 决方案。 scrum 方法中对开发团队提供了很多支持，但是对 po 如何得出 product backlog 并未提及，因为这已经属于另一范畴了。那我们有没有什么方法可以支 持 po 进行业务分析呢？秉承一贯偷的 作风，在年度总结和计划：去年 4 个 1， 今 年5个1中提及到引入babok知识体系， 本篇将作为这个系列的开篇， 对babok 进行总体的介绍。 什么是什么是 business analysis babok 对“what is business analysis“做了一个权威的定义： business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure,policies, and operations of an organization, and recommend solutions that enable the organization to achieve its goals. 翻译一下为： business analysis 就是一组任务和技能的集合，它是不同的利益 相关者之 间的桥梁，目的是为了让这些利益相关者更好的理解组织的 架构、政策和运作模 式，并且为了使得组织能够达到它们的目标，提 出相应的解决方案。 谁是谁是 ba babok 认为 ba 是任何人都可以是 ba，只要他做的是业务分析的工作，而不 区分岗位角色，他可能是系统分析师、流程分析师、项目（产品）管理 者、开 发人员、质量分析员、业务架构师或者咨询师等等。在不同的公司，对于 ba 有 不同的理解和职位描述，所以在 babok 中也没有定义明确的岗位职责。 对于 it 的 ba 而言，it 部门和业务部门会存在 gap，it 不懂业务，而业务 部门不懂技术，所以 it 的 ba 最好是既懂技术又懂业务。 范围范围(scope) 术语“scope”应用非常广泛，定义也非常之多，it 中有两个定义占主导： 方案范围（solution scope） ：是满足业务需 求而设计的一套方案 项目范围（project scope） ：实现和构造特定方案（solution）时的工作 在本系列介绍中，如果没有特别说明时，范围都指方案范 围，而项目范围 更多出现在项目管理范畴中。 babok 结构结构 babok 由以下几个部分组成： 1. 任务（任务（task） ：业务分析中的核心工作，每件任务都必须具有如下的特性： o 每件任务都是有价值价值的，并且大家都是认同的 o 每件任务是完整完整的，它的输出可以作为其它不同人的输入 o 每件任务都是知识体系中必须必须的组成部分 o 输入/输出 2. 技能 （技能 （technique） ： 技能描述在在某个特定的情况下如何执行任务。 每个任务可 以 没有或者有 1 至多个相关的技能， 但每个技能必须至少关联到一项任务中去。 babok 中包括了 ba 社区中大部分常用的技能。当我们在自己领域中实践时，可 以添加自 己的技能。 3. 知识点 （知识点 （knowledge area） ： 知识点是相关任务和技能的集合， 它由 7 大组 成部分： 各组成部分在项目不同阶段大致工作量比例各组成部分在项目不同阶段大致工作量比例 为了便于描述知识点的 7 个部分使用的技能，这里先约定一下简称， bap & m 业务流程计划和监控（business analysis planning and monitoring） ea 企业分析（enterprise analysis） e 需求获取（elicitation） ra 需求分析（requirements analysis） sa & v 方案评估和验证（solution assessment and validation） rm & c 需求管理和沟通（requirements management and communication） cbap 认证发展阶段认证发展阶段 参考： babok version 2 iiba 业务分析 师在敏捷项目中的作用 babok2 public draft 下载 babok - ba 计划和监控概要计划和监控概要 描述描述 业务分析计划是项目计划的主要输入， 项目管理包括组织和协调业务分析活 动。 ba 计划和监控描述如何确定在完成业务分析过程中需要哪些活动，它包括 涉众标识、业务分析技术的选择、管理需求的流程以及如何评估变更。 目的目的 计划业务分析任务 需要的话更新或更改业务分析方法 有效并持续改善业务分析实践 任务任务列表列表 涉众管理（conduct stakeholder analysis） 计划业务分析活动（plan business analysis activities） 计划沟通（plan business analysis communication） 计划需求管理流程（plan requirements management process） 计划、监控和报表业务分析绩效（plan, monitor and report on business analysis performance） 任务：涉众管理（任务：涉众管理（conduct stakeholder analysis） 目的 标识涉众，这个任务包括明确项目或项目不同阶段的涉众，涉众影响力分析， 参考：企业架企业架 构构 涉众管理（涉众管理（stakeholder management） 输入 o 组织规范（organizational standards） o 定义业务问题/机会（problem/opportunity） 输出 o 涉众列表 o 涉众角色以及职责 任务：计划活动（任务：计划活动（plan business analysis activities） 目的 确定在定义业务解决方案过程中需要哪有活动，这些活动如何被执行，有哪些 工作需要做，以及如何评估任务需要执行的时间 o 标识业务分析交付物交付物 o 确定业务分析工作范围工作范围 o 确定业务分析活动在知识域（enterprise analysis, elicitation, requirements analysis, solution assessment and validation）的任务任务 o 标识任务之间的依赖关系以及任务间的接口任务之间的依赖关系以及任务间的接口问题 o 开发 ba 工作评估指标评估指标（时间、技能要求级别、任务复杂性等） 输入 o 涉众列表 o 涉众角色以及职责 o 组织规范 输出 包含以下计划： o 业务分析和监控（business analysis planning and monitoring） o 企业分析（enterprise analysis） o 需求获取（elicitation） o 需求分析（requirements analysis） o 方案评估和验证（solution assessment and validation） o 需求管理和沟通（requirements management and communication） 任务：计划沟通（任务：计划沟通（plan business analysis communication） 目的 给涉众分组，确定不同涉众各自需要什么信息以及我们如何交流（口头、 文字等） 输入 o 涉众列表 o 涉众角色以及职责 o 业务分析计划 输出 业务分析沟通计划 任务：计划需求管理流程（任务：计划需求管理流程（plan requirements management process） 目的 描述如何确定合适的需求流程，包括确定是否以及为什么需求变更，涉众 是否同意变更， 以及需求追溯的方法。 需求管理定义可以参考需求入需求入 门：门： 需求工程需求开发需求管理需求工程需求开发需求管理 输入 o 组织规范 o 业务分析计划 输出 o 需求管理计划 任务：计划、监控和报表业务分析绩效（任务：计划、监控和报表业务分析绩效（plan, monitor and report on business analysis performance） 目的 确定在业务分析执行评估中使用哪些度量，包括我们如何跟踪、评估和报 告业务分析工作的质量以便我们采取措施改正我们的问题。 输入 o 组织绩效规范 o 实际的绩效度量 o 业务分析计划 o 需求管理计划 输出 o ba 绩效评估方法 o 学习文档（lessons learned） o 流程改进建议（process improvement recommendations） babok 企业分析概要企业分析概要 描述描述 企业分析描述我们如何捕捉、提炼并明晰业务需要，并定义一个可能实现这 些业务需要的一个方案范围， 它包括问题定义和分析， 业务案例开发， 可行性 研 究和方案范围定义 目的目的 明确业务战略需要和目标，并建议方案范围 任务任务列表列表 标识业务需要（identify business need） 确定方案步骤（determine solution approach） 定义方案范围（define solution scope） 开发业务案例（develop the business case） 任务：标识业务需要（任务：标识业务需要（identify business need） 目的 o 评估内部和外部环境： 内部： 定义和提炼当前和将来的业务架构 评估当前的技术（基础设施和应用）状态 外部： 基准分析（benchmark analysis） 竞争力分析（competitive studies） o 完整的定义业务问题和机会 输入 o 业务架构（business architecture） o 业务目标 输出 o 业务问题和机会（defined business problem/opportunity） 任务：确定方案步骤（任务：确定方案步骤（determine solution approach） 目的 o 找出潜在的方案（identify potential solutions） o 分析可行性（analyze feasibility of options） o 推荐可行的业务方案（recommend viable business solution） o 决策者验证（validate with decision makers） 输入 o 业务架构（business architecture） o 业务问题和机会（defined business problem/opportunity） 输出 o 方案步骤（solution approach） 任务：定义方案范围（任务：定义方案范围（define solution scope） 目的 o 上下文图（context diagram） o product breakdown structure 输入 o 业务架构（business architecture） o 业务问题和机会（defined business problem/opportunity） o 方案步骤（solution approach） 输出 o 方案范围（solution scope） 任务：开发业务案例（任务：开发业务案例（develop the business case） 目的 o 定义项目目的和期望的业务利益 o 开发项目范围 o 评估时间、费用和资源 o 分析费用 vs 获利 o 风险评估 输入 o 业务架构 o 业务目标 o 业务问题和机会（defined business problem/opportunity） o 方案范围（solution scope） 输出 o 业务案例 babok - 需求获取（需求获取（elicitation） 描述描述 需求获取描述我们如何与涉众一起协作来发现他们真正的需要， 并保证我们 正确并完整的理解他们的需要 目的目的 探索、标识并文档化涉众需求 任务任务列表列表 准备工作（prepare for elicitation） 开展获取（conduct elicitation） 文档化获取结果（document elicitation results） 确认获取结果（confirm elicitation results） 任务：准备工作（任务：准备工作（prepare for elicitation） 目的 为需求获取做好准备，确保所有可用的资源都已组织和计划好来进行需求获取 活动 输入 o 涉众列表 o 涉众角色和职责 o 业务问题/机会 或 业务案例和方案范围 o 获取机会 输出 o 计划好的资源（scheduled resources） o 提供支持的材料（supporting materials） 任务：开展获取（任务：开展获取（conduct elicitation） 目的 涉众调研，获取相关信息 输入 o 提供支持的材料（supporting materials） o 业务问题/机会 或 业务案例和方案范围 o 组织规范 输出 o 获取活动结果（elicitation activity results） o 假设、约束、风险、问题（assumptions, constraints, risks, issues） o 文档，如调研记录、研讨结果、调查反馈等（documentation based on technique e.g., interview notes, workshop results, survey responses, etc.) 任务：文档化获取结果（任务：文档化获取结果（document elicitation results） 目的 记录涉众的需求 输入 o 获取活动的结果（elicitation activity results） 输出 o 文档化的需求（stated requirements） 任务：确认获取结果（任务：确认获取结果（confirm elicitation results） 目的 o 验证涉众要求被正确并完整的理解 输入 o 陈述的需求（stated requirements） 输出 o 经过验证的文档化需求（validated stated requirements） babok 需求分析概述需求分析概述 描述描述 需求分析描述我们如何逐步详细的定义方案， 以便项目团队设计和构建出满 足业务和涉众需要的解决方案。 目的目的 逐步细化获取后的需求，在特定范围内更清晰的定义需求 验证需求是否满足业务需要 测试需求，确认需求高质量 任务任务列表列表 组织需求（organize requirements） 划分优先级（prioritize requirements） 详述需求和建模（specify and model requirements） 确定假定和约束（determine assumptions and constraints） 确认需求（verify requirements） 验证需求（validate requirements） 任务：组织需求（任务：组织需求（organize requirements） 目的 预计需求的级别，功能的分组等的功能，把需求组织成结构化的逻辑分组。 输入 o 业务案例 o 方案范围 o 需求 输出 结构化的需求 任务：划分优先级（任务：划分优先级（prioritize requirements） 目的 决定需求的优先级，标识需求之间的逻辑依赖性 输入 o 需求 o 业务案例 输出 经过划分优先级的需求（prioritized requirements） 任务：详述需求和建模（任务：详述需求和建模（specify and model requirements） 目的 o 捕获需求质量属性 o 使用文字描述需求和通过图形建模 输入 需求 输出 详细的或者建模后的需求 任 务 ： 确 定 假 定 和 约 束 （任 务 ： 确 定 假 定 和 约 束 （ determine assumptions and constraints） 目的 在分析涉众需求时， 我们会发现他们的期望不是需求， 例如经费限制、 开发期限、相关行业法律法规等。假设和约束最大的区别就是一个是确定 的，一个 是不确定的，约束是项目必须遵循的依据。 输入 涉众声明（stakeholder statements） 输出 假定和约束（assumptions and constraints） 任务：确认需求（任务：确认需求（verify requirements） 目的 检查需求被正确的、完整的定义出来 输入 详述或模型化的需求 输出 确认后的需求 任务：验证需求（任务：验证需求（validate requirements） 目的 验证需求满足业务需要 输入 确认后的需求 输出 验证后的需求 babok 方案评估和验证概述方案评估和验证概述 描述描述 方案评估和验证描述如何评估被提议的方案， 检查这个方法是否最合适满足 业务需要， 标识出不同方案间的区别和优先点， 并且决定必须的工作区或者需 要 更改的地方。 目的目的 评估方案，确保满足策略目标，涉众对需求满意 任务任务列表列表 评估需求覆盖率（assess requirements coverage） 分配需求（allocate requirements） 确定组织意愿（determine organizational readiness） 验证方案（validate solution） 评价方案（evaluate solution） 任务：评估需求覆盖率（任务：评估需求覆盖率（assess requirements coverage） 目的 检查可能的方案是否满足需求，评定结果应该包括推荐的方案、排除的方案或 者折衷的方案 输入 可选的设计方案 输出 设计方案评估 任务：分配需求（任务：分配需求（allocate requirements） 目的 把需求分派到发布或者方案组件中。这个任务确保可能的发布最大化的满足业 务价值，并且可以由设计部门来处理。感觉有点类似与我们做需求优先级划分的工 作。 o 把需求归类到硬件、软件或者人工处理流程等 o 推荐的产品发布策略 o 明白在不同实现方法间的折衷处理 输入 o 方案设计 o 验证的需求 输出 分配的需求 任务：确定组织意愿（任务：确定组织意愿（determine organizational readiness） 目的 确定组织对新方案执行的意愿 o 执行组织意愿评估 o 优化组织部署的推荐方法 输入 o 业务架构 o 方案设计 输出 o 组织意愿评定（organizational readiness assessment） o 组织变更建议（organizational change recommendations） 任务：验证方案（任务：验证方案（validate solution） 目的 验证被确定和部署的方案是否满足业务需要： o 定义验收准则 o 标识缺点 o 分析影响 o 定义校正动作 o 验证校正动作 输入 o 确认的或部署的方案 o 验证的需求 输出 o 验证的方案 o 缺点影响分析（defect impact analysis） o 验证的校正动作（validated corrective actions） 任务：评价方案（任务：评价方案（evaluate solution） 目的 评估方案对业务的价值，比较实际和希望的成本和收益 输入 部署的方案绩效度量 输出 成本收益分析 babok 需求管理和沟通概要需求管理和沟通概要 描述描述 需求管理和沟通描述我们如何管理冲突、问题、变更，并确保涉众和项目团 队在方案范围内保持一致。不同项目的复杂度和方法论支持都不一样，我们需要 管理正式评审、基线并跟踪需求文档的版本，还需要跟踪需求到实现的步骤 目的目的 认识在所有知识域（knowledge areas）中发生的沟通对于管理需求来说非常重要 管理批准的方案和需求范围 确保涉众可以获得业务分析工作交付物 准备好和涉众沟通需求 有效的重用需求，提高企业一致性 任务任务列表列表 管理方案和需求的范围（manage solution and requirements scope） 管理需求追溯（manage requirements traceability） 管理需求重用（maintain requirements for re-use） 准备需求包（prepare requirements package） 传递需求（communicate requirements） 任务：管理方案和需求的范围（任务：管理方案和需求的范围（manage solution and requirements scope） 目的 业务案例、方案和需求的基线和变更管理 o 对需求达成一致 o 基线需求 o 正式和非正式的需求变更管理 o 控制需求工件的版本 o 管理需求冲突和问题 输入 o 涉众角色和职责 o 需求 o 需求管理计划 输出 o 认可的需求（approved requirements） o 决策记录（decision record） 任务：管理需求追溯（任务：管理需求追溯（manage requirements traceability） 目的 o 需求跟踪 o 影响分析 o 支持方案评估和验证中的需求分配 输入 需求 输出 可跟踪的需求 任务：管理需求重用（任务：管理需求重用（maintain requirements for re-use） 目的 o 选择哪些需求在方案实现后还需要维护 o 确定谁负责维护需求 o 在影响分析和方案维护中更方便的使用需求 o 鼓励企业业务模型的一致性，在相关项目中更方便的重用需求 输入 可实现的需求 输出 被管理的可重用需求 任务：准备需求包（任务：准备需求包（prepare requirements package） 目的 o 确认适当的需求格式 o 生成一个需求包 输入 o 需求 o 业务分析沟通计划 输出 需求包（如 executive summary, formal documentation, rfi, rfp, etc.) 任务：传递需求（任务：传递需求（communicate requirements） 目的 o 在项目初期、中期和后期全过程与涉众交互 o 每个领域与沟通有关的将都在这里说明 o 与方案团队沟通，以确保需求被正常的理解和实现 输入 o 需求包 o 业务分析沟通计划 输出 沟通过的需求 babok 业务分析技术概要业务分析技术概要 在前面部分，针对业务分析知识领域的 7 个组成部分的任务进行了介绍,本 篇列出了各组成部分使用到的技术。这里不会对各种技术进行讲解，后面我将会 分别对每种技术进行介绍。 bap & m 业务流程计划和监控（business analysis planning and monitoring） ea 企业分析（enterprise analysis） e 需求获取（elicitation） ra 需求分析（requirements analysis） sa & v 方案评估和验证（solution assessment and validation） rm & c 需求管理和沟通（requirements management and communication） 软件需求的三个层次软件需求的三个层次 作为技术人员，我们以往更多的关注的是技术，但是在做个多年后，发现做 正确的事比正确的做事更重要，而软件中需求的好坏就很大程度决定了你这个 软件是否正确，需求确定后不管你如何实现，功能给客户直接带来的价值远远比 技术直接带来的价值要高。鉴于需求的重要性，所以后续我将陆续写一些需求相 关的 博文和大家一起学习探讨，扩充开发人员的需求知识，提高我们应用需求 到开发的技能。 本篇将从下图所示的软件需求的三个层次开始我们的需求之旅。 上图为需求的层次关系图，软件需求包括三个不同的层次： 业务需求业务需求 描述组织或客户的高层次目标组织或客户的高层次目标， 通常问题定义本身就是业务需求。 业务需求就是系统目标，它必须是业务导向、可度量、合理、可行的。这 类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的 管理者、市场营销部门或产 品策划部门。业务需求从总体上描述了为什 么要开发系统（whywhy）， 组织希望达到什么目标。一般使用前景和范围前景和范围 （vision and scopevision and scope）文档来记录业务需求，这份文档有时也被称作项目 轮廓图或市场需求（project charter 或 market requirement）文档。 组织愿景是一个组织对将使用的软件系 统所要达成的目标的预期期望。 比如“希望实施 crm 后公司的客户满意度达到 80以上”就是一条组织 愿景。这些最高级别的需求数量很少（25 条）。 以下为前前 景和范围景和范围文 档主要提纲： rup 的业务建模流 程（business modeling）就属于这个级别，有时 我们也叫这些为事理事理。在这个流程中，业务流程分 析员对企业目前的业 务流程进行评估，根据要进行的项目得到一个业务前景（business vision），描述项目成功后会的样子，并在涉众范围内达成一致。业务需 求层次需要投入的精力视具体项目而定， 而业务需求的确定对之后的用户 需求和功能 需求起了限定作用，任何用户和功能需求都必须符合业务需 求。 大 家可以使用免费的 sam 业务流程梳理建模工具软件来进行业务 梳理，坦白说我也没有实际真正的使用过这个工具，推荐它是因为它里面 提出了用企业价值增值链图(evc)和企业事件过程链图(epc)来进行梳理， 可能有人说这个工具不如 visio 好用，想怎么画就怎么画，其实业务建 模重在内容，并且图标需要统一规定。 用户需求用户需求 用户需求是指描述用户使用产品必须要完成什么任务， 怎么完成需求， 通常是在问题定 义的基础上进行用 户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需 求。用户需求必须能够体现软件系统将给用户带来的业务价值用户带来的业务价值 ，或用户要求系统必须能完 成的任务任务，也就是说用户需求描述了用户能使用系统来做些什么（what） ，这个层次的需求 是非常重要的。用例、用户故事、特性用例、用户故事、特性等都是 表达用户需求的有效途径。 用户需求层次上的重心转移到如何收集用户的需求上， 即确定角色和角色的用例， 需求 分析是很难的， 因为很多需求是隐性的，很难获取，更难保证需求完整，而需求又是易变 的。 功能需求功能需求 系统分析员系统分析员描述 开发人开发人员员在产品中实现的软件功能软件功能， 用户利用这些功能来完成任务， 满足业务需求。 功能需求是需求的主体， 它描述的是开发人员如何设计具体的解决方案来实 现这些需求（how） ，其数量往往比用户需求高一个数量级。 这些需求记录在软件需需 求规求规 格说明（格说明（software requirments specification）中。 srs 完整地描述了软件系统的预期特性。 srs 我们一般把它当作文档，其实，srs 还可以是包含需求信息的数据库或电子表格；或者 是存储在商业需求管理工 具中的信息； 而对于小型项目， 甚至可能是一叠索引卡片。 开发、 测试、质量保证、项目管理和其他相关的项目功能都要用到 srs。 产品特性（feature） ，是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使 业务 目标得以满足。对商业软件而言，特性则是一组能被客户识别，并 帮助他决定是否购 买的需求， 也就是产品说明书中用着重号标明的部分。 客户希望得到的产品特性和用户的任 务相关的需求不完全是一回事。一项特性可以包括多个 用例，每个用例又要求实现多项功 能需求，以便用户能够执行某项任务。 software requirements 举了一个字处理程序的例子来说明需求的这三种不同种类。业 务需求可能是：“用户能有效 地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标 明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并 通过一个提 供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需 求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范 围的 替换。 功能需求除了来自于用户需求，还来自于其它几方面需求： 1. 系统需求（系统需求（system requirement） 用于描 述包含多个子系统的产品(即系统)的顶级需求， 它是从系统实现的角 度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。 2. 业务规则业务规则 业务规划本身并非软件需求，因为它 们不属于任何特定软件系统的范围。 然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合 相关规则必须实现某些特定功能。 它包括企业方针、 政府条 例、 工业标准、 会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也 源于业务规则。所以，对某些功能需求进行追溯时，会 发现其来源正是一 条特定的业务规则。 3. 质量属性（质量属性（quality attribute） 产品 必须具备的属性或品质。 系统的质量属性包括可用性、 可修改、 性能、 安全性、可测试行、易用性和 mccall 体系等 4. 约束（约束（constraint） 约束也称为限制条件、补 充规约，通常是对解决方案的一些约束说明。 三个层次的开发关系三个层次的开发关系 这三个层次按照通俗一些的话来说，可以表示为下图： 在软件开发过程中，最为重要的“用户需求”往往和数量巨大的”功能需求“混淆 在一起，这会让太多没有直接提供业务价值的需求充斥在需求阶段，这 会导致没有 突出重点而忽视重要的业务特性,这对业务分析来说是非常有害的。所以在开发过程 中，很有必要加强认识并区分开来，有的开发平台（如普元）对三个层次的需求就 区分开来，如下图的构件种类对应关系： 需求工程需求开发需求管理需求工程需求开发需求管理 上图是需求工程的组成部分，从图中可以看出，需求工程需求工程划分为两个部分： 需求开发需求开发和需求管理需求管理。需需 求开发求开发又分为需求获取（需求获取（elicitationelicitation）、需求分析需求分析 （analysisanalysis）、编写规约编写规约 （specificationspecification）和需求验证（需求验证（validationvalidation）。需需 求管理求管理又分为基线管理基线管理、变变 更管理更管理、需求跟踪需求跟踪。 下面我将分别介绍一下上面各个主要组成部分主要的工作内容， 以便那些不 熟悉需求的人员读后能够从总体上把握需求所涉及的工作内容。 需求开发需求开发 需求开发活动包括以下几个方面： 1. 确定产品所期望的用户分类。 2. 获取每类用户的需求。 3. 了解实际用户任务和目标以及这些任务所支持的业务需求。 4. 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议 解决方法和附加信息。 5. 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 6. 了解相关质量属性的重要性。 7. 商讨实施优先级的划分。 8. 将所收集的用户需求编写成规格说明和模型。 9. 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接 受说明之前将问题都弄清楚。 实际工作中很难一次性得到完全正确的需求， 所以以上步骤并不是严格顺序 执行到底的， 它是一个不断反复的过程。 这些步骤也不是完全顺序的， 很可能 需 要迭代的进行。基于项目的产品需求开发过程可能如下图所示： 在软件开发过程中，当你想了解具体需求时，有些客户会说没有时间，这时需要 和客户建立一种合作关系，具体来说： 客户权利：客户权利： 1. 要求分析人员使用符合客户语言习惯的表达。 2. 要求分析人员了解客户系统的业务及目标。 3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。 4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。 5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。 6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。 7. 描述产品使其具有易用、好用的特性。 8. 可以调整需求，允许重用已有的软件组件。 9. 当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估。 10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。 客户义务：客户义务： 1. 给分析人员讲解业务及说明业务方面的术语等专业问题。 2. 抽出时间清楚地说明需求并不断完善。 3. 当说明系统需求时，力求准确详细。 4. 需要时要及时对需求做出决策。 5. 要尊重开发人员的成本估算和对需求的可行性分析。 6. 对单项需求、系统特性或使用实例划分优先级。 7. 评审需求文档和原型。 8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。 9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。 10. 尊重需求工程中开发人员采用的流程（过程）。 下面就需求开发每个活动进行简单介绍： 需求获取需求获取 在软件 需求的三个层次中介绍了三个层次的需求，在需求获取中，这 些需求都是我们需要获取的，我们需要收集问题域问题域的描述，要求解决的问题 列 表，以及了解系统的行为或约束。 信息来源信息来源 客户（实际的和潜在的） 用户（实际的和潜在的） 已有系统及其文档 领域专家 相关技术标准和法规 获取技术获取技术 阅读背景资料 用户访谈、调研 需求讨论会 现场观摩 需求分析需求分析 需求分析是指通过对需求获取中获得的问题域的研究， 获得对该领域特性及 存在其中的问题特性的透彻理解并用文档说明。 不需要等到需求完全捕获后开始，在“业务需求”充分理解下，并且收集了本质的“用 户需求”之后就可以开始进行需求分析 交替进行， 先把握“用户需求”主要部分， 然后在分析的基础上引入系统级的需求 （系 统的涉及与实现角度） ，并且分析模型，成为开发人员之间、开发人 员与客户之间 达成共识的一个平台 分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第 二次的需求调研计划、问题和素材 编写规约编写规约 规格说明书是对需求分析结果的文档化过程 需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离 为需求规约定义统一的格式是一个很重要的工作 规约内容必须严谨、正确、无歧义 需求验证需求验证 不重视需求验证工作会在系统交付时，客户发现不是这样的，导致不期望的需求变 更 提高需求质量的重要手段有：需求评审、需求确认和原型验证需求 方法之原型 开发 需求管理需求管理 需求管理活动包括： 1. 定义需求基线（迅速制定需求文档的主体） 。 2. 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。 3. 以一种可控制的方式将需求变更融入到项目中。 4. 使当前的项目计划与需求一致。 5. 估计变更需求所产生影响并在此基础上协商新的承诺（约定） 。 6. 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。 7. 在整个项目过程中跟踪需求状态及其变更情况。 用用 kano 模型来确定需求优先级模型来确定需求优先级 在敏捷估计和规划一书中，在确定合意性优先级确定合意性优先级一 章中专门介绍了这 个模型，这个模型可以作为我们确定需求优先级的一个参考。kano 模型定义了 三个层次的顾客需求：基本型需求、期望型需求和兴奋型需求。 这三种需求根 据绩效指标分类就是基本因素、绩效因素和激励因素。 客户满意度模型客户满意度模型