需求的基本概念与原理
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%)
项目成功的因素
用户的参与：15.9% 管理层支持：13.9% 清晰的需求描述(13.0%)； 合适的规划(9.6%)； 现实的客户期望(8.2%)； 较小的里程碑(7.7%)； 有才能的员工(7.2%)
业务需求就是定义系统目标
目标在哪里？业务需求是构建在“项目发起人”的脑 子里的，也就是谁提出项目，谁就拥有对“业务需求” 的最清晰的理解。 引出宏观的目标：思考企业运作中存在什么问题？这 些问题主要是体现在哪些方面？这些问题对企业造成 了什么影响？认为可以怎么解决？希望达到什么样的 效果？ 将大任务分解成为小目标，并且引导客户良好地定义， 这也是我们形成“项目子目标描述”的关键基础。 衡量这些目标的合理性与可行性。
业务需求就是定义系统目标
有了清晰的目标之 后，还应该对系统 划定范围，最常用 的方法是工作上下 文范围图（结构化 分析方法）：
用户需求
用户需求是指描述用户使用产品必须要完成什么任务， 怎么完成的需求，通常是在问题定义的基础上进用户 访谈、调查，对用户使用的场景进行整理，从而建立 从用户角度的需求。 用户有不同类型： > 管理型、事务型 > 信息系统、人 > 决策层、使用层 > 常用者、偶用者 组织方法：用例、用户故事、特性 例子：对快到期的客户，系统将通过短信 将续保信息发给该客户的代理人
设计约束
也称为限制条件、补充规约，这通常是对解决 方案的一些约束说明。 例如：必须采用国有自主知识版权的数据库系 统… 再如：必须运行在UNIX操作系统之下
两个世界三种设计
问题域 机器域
for(i=0;i=i+1;i++) { print i; }
需求
规格说明书
程序
优秀的需求
系统需求
解释一：系统需求是相关联的硬件、软件系统对待开 发系统的相关需求。 解释二：从系统实现的角度描述的需求。 开发人员（设计及分析人员）在业务需求、用户需求 的基础上生成的。
功能需求
功能需求是需求的主体，是需求的本质 功能需求定义了：系统必须完成的那些事，即为了向 它的用户提供有用的功能，产品必须执行的动作 零散（需求项）整理（特性、用例） 敏捷方法：用户故事
对不知道航行目的地的人来说， 没有顺风！
我们在哪里重重摔了一跤
在Standish Group的报告中总结了导致项目失 败的最重要的8大原因中，有5个与需求相关： 不完整的需求(13.1%)； 缺乏用户的介入(12.4%)； 不实际的客户期望(9.9%)； 需求和规范的变更(8.7%)； 提供了不再需要的(7.5%)
业务需求就是定义系统目标
现状：功能分解盛行的今天，常常会犯“盲人摸象” 的错误，这使得需求太过脆弱，难以经受考验。 目标！目标！还是目标！--系统开发应目标驱动！目 标是团队唯一的行动纲领。 目标的定义不能够流于形式，应该具有以下特征：业 务导向、可度量、合理、可行。要 注意目标太夸大会浪费资源，目标 太缩小会影响士气。（教堂与小屋） 目标通常就是业务需求！
讨论
你认为“什么是需求”？ 日常工作中，遇到与“需求”相关的问题有哪些？ 关于“需求”最大的困惑是什么？ 以下问题中，对你影响最大的是哪个？ > 不切实际的用户需求 > 很多需求最终是不需要的 > 用户介入太少 > 需求不完整 > 需求变更频繁
需求—导致项目失败的罪魁祸首
根据Standish Group对23000个项目进行的研究结果 表明，28%的项目彻底失败，46%的项目超出经费预 算或者超出工期，只有约26%的项目获得成功。 而在于这些高达74%的不成功项目中，有约60%的失 败是源于需求问题。 也就是说，有近45%的项目最终因为需求的问题最终 导致失败。
优秀的团队遇到糟糕的需求
用户参与不足 用户需求扩展 有歧义的需求 镀金问题 过于抽象的需求 忽略某种用户 不准确的计划 ……
我们应该怎么办？
对“需求”建立正确的认识； 客户和供应商—一根绳子上的两个蚂蚱； 和客户一起建立起“共同的目标”； 寻找并使用正确的、有效的需求捕获、描述 （建模）、管理方法； 动态、持续地适应需求的变化；
需求是什么？
业务需求
项目视 图/范围 文档 用户需求 质量属性 非功能需求 其它非功能 需求 设计约束 功能需求 SRS
用例文 档
系统需求
业务需求
业务需求是指反映组织机构或客户对系统、产品高层 次的目标要求，通常问题定义本身就是业务需求 。 背景描述：XX保险公司希望充分利用日益完善的移 动通信技术，在原有的办公系统的基础上进行扩展， 使得在外的业务人员能够及时地获得客户、业务相关 的动态信息，与此同时，实现企业内部的即时通信。 业务需求/目标 ：通过该系统的实施，将人 工保费续缴、投保手续办理两项业务运转 周期缩短10％以上，使企业内部沟通效率 大幅改善，以帮助企业运转效率得以提高。
业务需求就是定义系统目标
形成一个不超过50字的项目目标，并且列出5-9个主 要子目标，并且将其制作成一页文档，作为“项目的 行动纲领”，还应该得到“项目发起人”的认可。 在此基础上，可以编写“项目的目标和范围文档”( 或称项目综述，即POS，内容包括问题/机会、项目 目标、项目目的、成功标准、假设/风险/障碍)，对于 产品而言，我们还可以构建一个从市场角度分析的 “愿景”文档。 该部分工作是处于“需求过程”的金字塔尖，多花费 一些时间和精力是值得的，也是必要的。
完整性：完整描述即将交付使用的功能，发现缺少某 项信息，可以采用TBD来标注 正确性：经过用户或用户信任的代理人审阅 可行性：在已知能力和约束条件中实现 必要性：每项需求记录的功能都应是用户真正需要的 有优先次序：提供了实现优先级 无歧义：对所有读者只有一种一致的解释 可验证性：可以设计测试方法来检查
质量属性
产品必须具备的属性或品质 可靠性：成熟性、容错性、易恢复性 易使用性：易理解性、易学习性、易操作性 效率：时间特性、资源特性 可维护性：易分析性、易更改性、稳定性、易测试性 可移植性：适应性、易安装性、一致性、易替换性 McCall体系：运行(正确性、可靠性、效率、 完整性、使用性)、修正(维护性、测试性、 灵活性)、转移(移植性、复用性、共运行性)
软件需求曾经让我们如此狼狈
Байду номын сангаас与各方都以自已角度讲述问题
财务计算 管理报表 工作流 自动库存控制 库存报警 业务线索管理 业务经线索跟踪 销售月报生成 交易流数据 分布式 WebServices 三层 对话框 菜单条 DCOM B/S 数据交换……
问题的根源是什么？
用户说的不是他想的：客户提供（陈述的需求） 的需求并不是真实的需求，还需要作进一步的 分析，以确定客户的真正需求和期望，接下来 需要澄清并重新描述。可以这么说客户在理解 基础业务过程和描述自己的需求方面有很大的 差异。 需求分析方法有问题：系统开发人员 使用低效的需求分析和项目管理方法。 共同责任强调不足：对客户和提供商 在项目成功的共同责任方面强调不够。
业务目标示例
某船厂商业管理系统目标： A1.取代过时的系统 A2.集成订单文档及数据库 A3.使用经验数据进行报价 A4.支持系统化的销售 A5.快速捕获成本数据 A6.加快发票的制作
某医院管理系统目标： B1.降低IT成本 人事部门： B2.实现一些任务的自动化 B3.消除出错源 B4.遵守最后期限 B5.减少繁琐工作 医院部门： B6.减少加班及工作量不足的情况 B7.更快速的勤务规划 B8.改进勤务表质量
检查表示例
讨论
前面的描述中，最大的感触是什么？ 业务需求需求定义 用户需求需求捕获 软件需求需求分析与编写规约
项目成功的因素
用户的参与：15.9% 管理层支持：13.9% 清晰的需求描述(13.0%)； 合适的规划(9.6%)； 现实的客户期望(8.2%)； 较小的里程碑(7.7%)； 有才能的员工(7.2%)
业务需求就是定义系统目标
目标在哪里？业务需求是构建在“项目发起人”的脑 子里的，也就是谁提出项目，谁就拥有对“业务需求” 的最清晰的理解。 引出宏观的目标：思考企业运作中存在什么问题？这 些问题主要是体现在哪些方面？这些问题对企业造成 了什么影响？认为可以怎么解决？希望达到什么样的 效果？ 将大任务分解成为小目标，并且引导客户良好地定义， 这也是我们形成“项目子目标描述”的关键基础。 衡量这些目标的合理性与可行性。
业务需求就是定义系统目标
有了清晰的目标之 后，还应该对系统 划定范围，最常用 的方法是工作上下 文范围图（结构化 分析方法）：
用户需求
用户需求是指描述用户使用产品必须要完成什么任务， 怎么完成的需求，通常是在问题定义的基础上进用户 访谈、调查，对用户使用的场景进行整理，从而建立 从用户角度的需求。 用户有不同类型： > 管理型、事务型 > 信息系统、人 > 决策层、使用层 > 常用者、偶用者 组织方法：用例、用户故事、特性 例子：对快到期的客户，系统将通过短信 将续保信息发给该客户的代理人
设计约束
也称为限制条件、补充规约，这通常是对解决 方案的一些约束说明。 例如：必须采用国有自主知识版权的数据库系 统… 再如：必须运行在UNIX操作系统之下
两个世界三种设计
问题域 机器域
for(i=0;i=i+1;i++) { print i; }
需求
规格说明书
程序
优秀的需求
系统需求
解释一：系统需求是相关联的硬件、软件系统对待开 发系统的相关需求。 解释二：从系统实现的角度描述的需求。 开发人员（设计及分析人员）在业务需求、用户需求 的基础上生成的。
功能需求
功能需求是需求的主体，是需求的本质 功能需求定义了：系统必须完成的那些事，即为了向 它的用户提供有用的功能，产品必须执行的动作 零散（需求项）整理（特性、用例） 敏捷方法：用户故事
对不知道航行目的地的人来说， 没有顺风！
我们在哪里重重摔了一跤
在Standish Group的报告中总结了导致项目失 败的最重要的8大原因中，有5个与需求相关： 不完整的需求(13.1%)； 缺乏用户的介入(12.4%)； 不实际的客户期望(9.9%)； 需求和规范的变更(8.7%)； 提供了不再需要的(7.5%)
业务需求就是定义系统目标
现状：功能分解盛行的今天，常常会犯“盲人摸象” 的错误，这使得需求太过脆弱，难以经受考验。 目标！目标！还是目标！--系统开发应目标驱动！目 标是团队唯一的行动纲领。 目标的定义不能够流于形式，应该具有以下特征：业 务导向、可度量、合理、可行。要 注意目标太夸大会浪费资源，目标 太缩小会影响士气。（教堂与小屋） 目标通常就是业务需求！
讨论
你认为“什么是需求”？ 日常工作中，遇到与“需求”相关的问题有哪些？ 关于“需求”最大的困惑是什么？ 以下问题中，对你影响最大的是哪个？ > 不切实际的用户需求 > 很多需求最终是不需要的 > 用户介入太少 > 需求不完整 > 需求变更频繁
需求—导致项目失败的罪魁祸首
根据Standish Group对23000个项目进行的研究结果 表明，28%的项目彻底失败，46%的项目超出经费预 算或者超出工期，只有约26%的项目获得成功。 而在于这些高达74%的不成功项目中，有约60%的失 败是源于需求问题。 也就是说，有近45%的项目最终因为需求的问题最终 导致失败。
优秀的团队遇到糟糕的需求
用户参与不足 用户需求扩展 有歧义的需求 镀金问题 过于抽象的需求 忽略某种用户 不准确的计划 ……
我们应该怎么办？
对“需求”建立正确的认识； 客户和供应商—一根绳子上的两个蚂蚱； 和客户一起建立起“共同的目标”； 寻找并使用正确的、有效的需求捕获、描述 （建模）、管理方法； 动态、持续地适应需求的变化；
需求是什么？
业务需求
项目视 图/范围 文档 用户需求 质量属性 非功能需求 其它非功能 需求 设计约束 功能需求 SRS
用例文 档
系统需求
业务需求
业务需求是指反映组织机构或客户对系统、产品高层 次的目标要求，通常问题定义本身就是业务需求 。 背景描述：XX保险公司希望充分利用日益完善的移 动通信技术，在原有的办公系统的基础上进行扩展， 使得在外的业务人员能够及时地获得客户、业务相关 的动态信息，与此同时，实现企业内部的即时通信。 业务需求/目标 ：通过该系统的实施，将人 工保费续缴、投保手续办理两项业务运转 周期缩短10％以上，使企业内部沟通效率 大幅改善，以帮助企业运转效率得以提高。
业务需求就是定义系统目标
形成一个不超过50字的项目目标，并且列出5-9个主 要子目标，并且将其制作成一页文档，作为“项目的 行动纲领”，还应该得到“项目发起人”的认可。 在此基础上，可以编写“项目的目标和范围文档”( 或称项目综述，即POS，内容包括问题/机会、项目 目标、项目目的、成功标准、假设/风险/障碍)，对于 产品而言，我们还可以构建一个从市场角度分析的 “愿景”文档。 该部分工作是处于“需求过程”的金字塔尖，多花费 一些时间和精力是值得的，也是必要的。
完整性：完整描述即将交付使用的功能，发现缺少某 项信息，可以采用TBD来标注 正确性：经过用户或用户信任的代理人审阅 可行性：在已知能力和约束条件中实现 必要性：每项需求记录的功能都应是用户真正需要的 有优先次序：提供了实现优先级 无歧义：对所有读者只有一种一致的解释 可验证性：可以设计测试方法来检查
质量属性
产品必须具备的属性或品质 可靠性：成熟性、容错性、易恢复性 易使用性：易理解性、易学习性、易操作性 效率：时间特性、资源特性 可维护性：易分析性、易更改性、稳定性、易测试性 可移植性：适应性、易安装性、一致性、易替换性 McCall体系：运行(正确性、可靠性、效率、 完整性、使用性)、修正(维护性、测试性、 灵活性)、转移(移植性、复用性、共运行性)
软件需求曾经让我们如此狼狈
Байду номын сангаас与各方都以自已角度讲述问题
财务计算 管理报表 工作流 自动库存控制 库存报警 业务线索管理 业务经线索跟踪 销售月报生成 交易流数据 分布式 WebServices 三层 对话框 菜单条 DCOM B/S 数据交换……
问题的根源是什么？
用户说的不是他想的：客户提供（陈述的需求） 的需求并不是真实的需求，还需要作进一步的 分析，以确定客户的真正需求和期望，接下来 需要澄清并重新描述。可以这么说客户在理解 基础业务过程和描述自己的需求方面有很大的 差异。 需求分析方法有问题：系统开发人员 使用低效的需求分析和项目管理方法。 共同责任强调不足：对客户和提供商 在项目成功的共同责任方面强调不够。
业务目标示例
某船厂商业管理系统目标： A1.取代过时的系统 A2.集成订单文档及数据库 A3.使用经验数据进行报价 A4.支持系统化的销售 A5.快速捕获成本数据 A6.加快发票的制作
某医院管理系统目标： B1.降低IT成本 人事部门： B2.实现一些任务的自动化 B3.消除出错源 B4.遵守最后期限 B5.减少繁琐工作 医院部门： B6.减少加班及工作量不足的情况 B7.更快速的勤务规划 B8.改进勤务表质量
检查表示例
讨论
前面的描述中，最大的感触是什么？ 业务需求需求定义 用户需求需求捕获 软件需求需求分析与编写规约