需求分析师工作心得_软件开发管理

PPT 内容

1. 需求分析师工作心得
2. 概要信息系统基础理论需求的基本概念与原理需求工程需求定义最佳实践需求捕获最佳实践 1）了解我们将涉及的领域！ 2）从信息化的本质理解需求
3. 信息与信息系统基本概念信息：是指什么？信息系统（IS）：是人、数据、过程和接口的组合，它们之间相互作用，支持并改进企业日常的运作，并支持管理人员和用户解决问题和做出决策。
4. 信息系统的大致分类及特点事务处理系统：收集和处理企业事务，事务的响应时间、吞吐量、正确性、一致性等，BPR 管理信息系统：提供面向管理报告的信息系统应用决策支持系统：为用户提供决策信息，基于数据仓库专家系统：程序化的决策制定信息系统，人工智能(AI) 办公自动化和工作组系统：改进工作流和通信
5. 事务处理系统(TPS)概述每个组织都有手工和自动化的TPS，用来处理有关组织的基本业务记录更新所需的详细数据处理系统包括：订单录入、存货控制、工资单、应付帐款、应收帐款、总分类帐处理处理包括：数据收集、数据编辑、数据修改、数据操作、数据存储和文档生成事务：基本业务活动，如顾客订单、购货订单、时间卡和工资支票处理
6. 事务处理的机制批处理机制：将一段时间内的一批事务一次性处理的系统联机事务处理机制：该方法中每个事务即时进行处理，而不累积成批处理延迟的联机录入机制：前两者的折衷
7. 事务处理系统的目标处理由事务产生的及与事务相关的数据保持高准确度：输入和处理无错数据保证数据和信息的完整性及时生成文档和报告提高劳动效率有助于改善服务
8. 事务处理系统—要求一个组织的TPS必须支持业务正常工作过程中发生的常规的日常活动，这有助于公司对产品和服务增值数据应该在源处获得，以减少人工劳动，并且能准确、及时地记录送入计算机的方式事务处理的业务数据包括数据收集、数据编辑、数据修改、数据操作、数据存储和文档生成将一个公司的事务处理系统与其他公司连接起来是降低成本、加快信息流动的有效策略—例如SCM
9. 管理信息系统概述管理信息系统的主要目标是帮助管理者了解日常的业务以便进行既有效又高效的控制、组织、计划，最后达到组织的目标。--向管理者提供信息多数是通过不同的汇总分析报表来实现功能的；这些报表筛选、分析事务处理数据库中高度细化的数据，然后用一种有意义的方式将结果送给管理者在恰当的时机以恰当的方式向恰当的对象提交正确的信息，以改进工作效率
10. 管理信息系统特点制作进度、需求、异常、常规四类报表，有助于管理执行人员即时作出高质量决策报表具有固定和标准的格式生成硬拷贝和软拷贝报表使用存储在计算机系统内的内部数据报表由包括系统分析员和计算机程序员在内的信息系统人员开发和实施需要用户提交正式需求
11. 管理信息系统—四大类报表进度报表：周期生成或按日程生成，如日、周、月报关键指标报表是一种特殊类型的进度表，汇总前一日关键活动。需求报表：按管理者的要求提供相应的信息；如产品销售形势报表异常报表：当情况出现异常，需管理者加以注意而由系统自动生成的报表；如预算超支的项目列表常规报表：就某一情况为管理者提供更为详尽的数据
12. 管理信息系统—报表开发原则按用户要求定制每份报表：要求用户参与和输入时间与精力应只用于要使用的报表：一旦建立，即使没人使用，许多报表仍会一直不断生成注意报表的内容和格式：突出显示最为重要的信息，字词和术语力求清晰易懂利用例外报告实施管理：某些报告只应出现亟待解决问题或需要采取某动作时生成审核设定参数：如参数过低结果是报告过多，如参数过高则忽略有价值信息确保报告的时效：过期的报告无价值或价值极小
13. 管理信息系统小结MIS必须在恰当的时间以恰当的方式向恰当的人提供恰当的信息组织的MIS的最重要的内部信息来源是事务处理系统在大多数的情况下，公司最了解如何得到数据以及何时以何种形式向哪一位管理者提交报表可以为公司带来最大的利益不同信息系统的集成使数据和信息可以更简单地共享，从而降低公司的成本，提高报表的精确度、数据更安全，公司达到更高的效率
14. 决策支持系统基本概念决策是问题解答的一个组成部分决策阶段是问题解答的处理阶段，其包括情报、设计和选择三个时期。情报时期：认识和确定潜在的困难和(或者)机会设计时期：确定问题解答的可选择的方案选择时期：要求选择一种行动方案问题解答除了决策阶段外还包括实施时期和监控时期实施时期：确定的行动方案开始生效监控时期：决策者们评估问题解答方案实施效果
15. 决策支持系统基本概念程序化决策：使用一种规则、过程或量化方法所做的决策。例如：存货下降到一百单位时应该定货。--系统要素之间的关系通过规律、过程和数值关系的方式固定下来，通常可以通过MIS实现非程序化决策：处理不常见和异常的情况，很难量化。例如为雇员确定合适的培训计划、决定是否新建一条生产线。--决策支持系统将解决的问题最优化模型：找到最好解决方案的决策支持方法满意性模型：找出一个好的(但未必是最好)解决方案启发式方式：认为能找到一个较好解决方案的指导或过程
16. 决策支持系统的作用与特点用于支持专门问题决策的人力、过程、软件、数据库和设备的一个有组织的集合。用来解决非结构化或半结构化企业问题的决策。将处理不同来源的大量数据提供灵活的报告和展示以文本和图表格式提供信息支持深入的分析使用先进的软件包，完成错综复杂的分析和比较支持最优化的、满意性和启发式的方法执行What-if，模拟和目标求解分析
17. 决策支持系统的组成DSS的核心是数据库和模型库，还包括对话管理器(提供更友好的人机界面) 模型库：财务模型、统计分析模型、图表模型、项目管理模型……
18. 专家系统简介专家系统可以像某个特定领域的人类专家一样行动用来辅助设计新产品或新系统、决定木材的最佳使用、提高医疗卫生的质量、决定信用卡的信贷额度它能对它们的推理或提议的决策作出解释能显示“智能”行为能从复杂的关系间得出结论能提供“可移动”的知识能处理不确定性
19. 不同视角下的信息系统
20. 主流信息应用系统MRPMRP IIERP：制造业，成本、生产流程 CRM：客户关系管理 SCM：供应链管理 BI：商业智能 OA：办公自动化 E-Commerce：电子商务 ……
21. 信息应用系统分类内部：OA、MIS、BI、KM 外部：CRM、E-Commerce、Web Portal 协作：SCM、GroupWare、Assistant Tools
22. 信息系统需求的本质流程电子化> 利用信息化系统改进、固化流程> 事务处理系统尤其明显> 工作流定义、流程改进、再造> 工作流模型数据信息化> 业务术语，业务实体> 需要留存哪些数据？谁需要共享？> 需要什么报表？有哪些数据分析规则？
23. 信息系统常见技术计算模式：B/S、C/S 主要开发体系：.NET、J2EE、LAMP、Rail on Ruby 重要思想：SOA、Web Service、工作流引擎开发方法论：重方法论（RUP）、敏捷方法论建模技术：UML、E-R模型
24. 概要信息系统基础理论需求的基本概念与原理需求工程需求定义最佳实践需求捕获最佳实践 1）理论是实践的基础 2）解决概念性的误区
25. 需求—导致项目失败的罪魁祸首根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。也就是说，有近45%的项目最终因为需求的问题最终导致失败。对不知道航行目的地的人来说，没有顺风！
26. 我们在哪里重重摔了一跤在Standish Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：不完整的需求(13.1%)；缺乏用户的介入(12.4%)；不实际的客户期望(9.9%)；需求和规范的变更(8.7%)；提供了不再需要的(7.5%)缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%)
27. 项目成功的因素用户的参与：15.9% 管理层支持：13.9% 清晰的需求描述(13.0%)；合适的规划(9.6%)；现实的客户期望(8.2%)；较小的里程碑(7.7%)；有才能的员工(7.2%)
28. 软件需求曾经让我们如此狼狈
29. 参与各方都以自已角度讲述问题分布式 WebServices 三层对话框菜单条 DCOMB/S 数据交换……财务计算管理报表工作流自动库存控制库存报警业务线索管理业务经线索跟踪销售月报生成交易流数据
30. 问题的根源是什么？用户说的不是他想的：客户提供（陈述的需求）的需求并不是真实的需求，还需要作进一步的分析，以确定客户的真正需求和期望，接下来需要澄清并重新描述。可以这么说客户在理解基础业务过程和描述自己的需求方面有很大的差异。需求分析方法有问题：系统开发人员使用低效的需求分析和项目管理方法。共同责任强调不足：对客户和提供商在项目成功的共同责任方面强调不够。
31. 优秀的团队遇到糟糕的需求用户参与不足用户需求扩展有歧义的需求镀金问题过于抽象的需求忽略某种用户不准确的计划 ……
32. 我们应该怎么办？对“需求”建立正确的认识；客户和供应商—一根绳子上的两个蚂蚱；和客户一起建立起“共同的目标”；寻找并使用正确的、有效的需求捕获、描述（建模）、管理方法；动态、持续地适应需求的变化；
33. 需求是什么？
34. 业务需求业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。背景描述：XX保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。业务需求/目标：通过该系统的实施，将人工保费续缴、投保手续办理两项业务运转周期缩短10％以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。
35. 业务目标示例某船厂商业管理系统目标： A1.取代过时的系统 A2.集成订单文档及数据库 A3.使用经验数据进行报价A4.支持系统化的销售A5.快速捕获成本数据A6.加快发票的制作某医院管理系统目标： B1.降低IT成本人事部门： B2.实现一些任务的自动化 B3.消除出错源 B4.遵守最后期限B5.减少繁琐工作医院部门： B6.减少加班及工作量不足的情况B7.更快速的勤务规划B8.改进勤务表质量
36. 业务需求就是定义系统目标现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。目标！目标！还是目标！--系统开发应目标驱动！目标是团队唯一的行动纲领。目标的定义不能够流于形式，应该具有以下特征：业务导向、可度量、合理、可行。要注意目标太夸大会浪费资源，目标太缩小会影响士气。（城堡与小屋）目标通常就是业务需求！
37. 业务需求就是定义系统目标目标在哪里？业务需求是构建在“项目发起人”的脑子里的，也就是谁提出项目，谁就拥有对“业务需求”的最清晰的理解。引出宏观的目标：思考企业运作中存在什么问题？这些问题主要是体现在哪些方面？这些问题对企业造成了什么影响？认为可以怎么解决？希望达到什么样的效果？将大任务分解成为小目标，并且引导客户良好地定义，这也是我们形成“项目子目标描述”的关键基础。衡量这些目标的合理性与可行性。
38. 业务需求就是定义系统目标形成一个不超过50字的项目目标，并且列出5-9个主要子目标，并且将其制作成一页文档，作为“项目的行动纲领”，还应该得到“项目发起人”的认可。在此基础上，可以编写“项目的目标和范围文档”(或称项目综述，即POS，内容包括问题/机会、项目目标、项目目的、成功标准、假设/风险/障碍)，对于产品而言，我们还可以构建一个从市场角度分析的“愿景”文档。该部分工作是处于“需求过程”的金字塔尖，多花费一些时间和精力是值得的，也是必要的。
39. 业务需求就是定义系统目标有了清晰的目标之后，还应该对系统划定范围，最常用的方法是工作上下文范围图（结构化分析方法）：
40. 用户需求用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户有不同类型：> 管理型、事务型 > 信息系统、人> 决策层、使用层 > 常用者、偶用者组织方法：用例、用户故事、特性例子：对快到期的客户，系统将通过短信将续保信息发给该客户的代理人
41. 系统需求解释一：系统需求是相关联的硬件、软件系统对待开发系统的相关需求。解释二：从系统实现的角度描述的需求。开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。
42. 功能需求功能需求是需求的主体，是需求的本质功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作零散（需求项）整理（特性、用例）敏捷方法：用户故事
43. 质量属性产品必须具备的属性或品质可靠性：成熟性、容错性、易恢复性易使用性：易理解性、易学习性、易操作性效率：时间特性、资源特性可维护性：易分析性、易更改性、稳定性、易测试性可移植性：适应性、易安装性、一致性、易替换性 McCall体系：运行(正确性、可靠性、效率、完整性、使用性)、修正(维护性、测试性、灵活性)、转移(移植性、复用性、共运行性)
44. 设计约束也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。例如：必须采用国有自主知识版权的数据库系统… 再如：必须运行在UNIX操作系统之下
45. 正确理解需求—考虑系统的本质正确理解系统需求，就是理解系统的外围环境需求：使人能够将热的液体送到嘴里而液体不会溅出，人也不会烫伤杯体，组件，盛液体杯把，组件，方便拿和嘴的接口和手的接口和桌子的接口
46. 正确理解需求—考虑系统的本质考虑因素：> 杯子本身没有用，要依靠人胳膊的机械运动> 杯子的杯体部分要依靠重力的存在才能发挥作用> 杯子必须被正确使用，拿反了就会使液体倒出这个简单杯子要具备其用途的功能，最终取决于：> 从组件交互所表现出来的属性> 与外部组件的合适接口> 正确嵌入外围系统—由人手拿住，并用胳膊举起> 适当环境的存在—失重条件下需另一种解决方案
47. 两个世界三种设计
48. 问题域某需求分析师在一个“为货车运输公司开发软件”，该软件的目的是跟踪卡车、司机、货物及散布于全国各地的客户。如果一开始就描述客户所期望的尽可能详细的行为：屏幕的外观，每一版块的信息以及程序对鼠标的应答，那么—你就忽略了需求！！需求定义的是软件所要解决的问题，而不是描述软件如何解决它。即它是与问题域相关联的。例如：货运公司软件的一个需求可能是按要求把货物从一个地方送到另一个地方，软件通过调度卡车和委派司机来实现需求
49. 需求需求是通过计算机编程在问题域中施加的效果需求是确定客户需要得到什么的陈述：能在问题域中执行某种类型的活动，能使用问题域的部分信息，使问题域中的参数保持在一定的范围等货运公司软件需求中使用的术语应该是问题域中的对象，如“对于指定卡车，一个职员可以找出它正装载的货物是什么” 需求不包括像数据库、按钮、双向链表、文件等术语
50. 优秀的需求完整性：完整描述即将交付使用的功能，发现缺少某项信息，可以采用TBD来标注正确性：经过用户或用户信任的代理人审阅可行性：在已知能力和约束条件中实现必要性：每项需求记录的功能都应是用户真正需要的有优先次序：提供了实现优先级无歧义：对所有读者只有一种一致的解释可验证性：可以设计测试方法来检查
51. 概要信息系统基础理论需求的基本概念与原理需求工程需求定义最佳实践需求捕获最佳实践 1）掌握需求的相关工作 2）了解需求的相关人员
52. 需求错误的代价需求：1设计：5编码：10测度：20-50运行与维护：200
53. 需求开发与管理
54. 需求开发活动
55. 需求获取应收集什么信息：> 问题域的描述> 要求解决的问题列表（需求）> 用户对解系统的行为或结构施加的任何约束信息来源：> 客户（实际的和潜在的）> 任何原有解系统（已有系统）及其文档> 原有系统用户 / 新系统的潜在用户> 应用（问题）领域专家> 定义了任何接口系统的特片和行为的文档> 相关的技术标准和法规
56. 需求获取技术阅读背景资料头脑风暴讨论分析文档考古面谈（用户访谈）联合应用设计用户调查需求剥离现场观摩任务观察用例和场景
57. 需求获取的误区缺乏计划性：随意、走过场，预先没计划缺乏科学性：未从本质入手捕获对象不明确，甚至造成岐义过于迷信现有文档过于迷信“听”到的东西
58. 需求分析所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明分析方法：结构化分析法、面向对象分析法、面向问题域分析法任何分析法，均需描述以下几个方面:> 问题域的结构（子域，及子域间关系）> 问题域的数据> 问题子域的固有属性及行为> 问题域中的重要事件及现象> 需求：应产生的效果
59. 需求分析方法—结构化分析从基于文本分析和规格文档图形建模表示法结构化分析初期的模型：数据流图+E-R图数据流图：体现了流程，但是以数据为中心的流程 E-R图：体现了要存储的信息数据字典：对数据、数据流的描述
60. 需求分析方法—结构化分析对问题域的研究力度不够大分析和设计之间缺乏清晰的界限，将会导致不成熟的内部设计没有一个真正的功能规格说明需求实质上是根据满足该需求的某一特定系统的内部设计来加以说明的内部设计的开发使用的则是不可靠的内部设计技术，即功能分解 SA不适用于某些类型（绝非少数）的应用
61. 需求分析方法—面向对象分析与开发方法最为接近的分析方法主要模型：> 用例模型：系统的功能，场景化分析> 类模型：对象、数据> 活动图、状态图用例驱动的需求实践最佳实践
62. 需求分析方法—面向问题域分析是一种新的、返璞归真，较少强调建模搜集基本的信息并开发问题框架，以建立问题域的类型；在问题框架类型的指导下，进一步搜集详细信息并给出一个问题域相关特性的描述。
63. 需求分析—何时进行应该在“业务需求”充分理解，并且收集了最本质的“用户需求”之后就开始需求分析，但并不是等到需求捕获完全做完之后交替进行，先把握用户需求主要部分，然后在分析的基础上引入系统级的需求（系统的设计与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研的计划、问题、素材
64. 需求分析—何时结束需求捕获、分析与建模、规格说明书的编写、需求的验证这个需求开发的循环，是在整个软件开发生命周期中存在的每一次的循环，都将在需求开发的工作要点与份量上有所不同，它们应该遵循以下：> 从本质到边缘：本质、重要、次重要、一般、镶金> 细化阶段是需求开发最密集的阶段 > 构建阶段需求开发逐渐减少
65. 需求分析—内容与形式需求分析与建模不应该是孤立的行为，产生的结果也不一定非得是规范度很高的标准文档，而应该重在分析、重在方法、重在交流、重在解决问题团队聚在一起，利用白板甚至是纸张，在充分的合作下进行分析与初步建模是成本最低、效率最高、实用性最强的方法对于这些活动所产生的结果，可以利用数码相机、扫描仪进行文档化，“直到你一定要用时，再写文档” 对于比较重要、核心的内容，再采用Rose、Together这样的工具进行文档化
66. 编写规约规格说明书是对需求分析结果的文档化过程比较“正规”的开发组织都会重视这个活动，甚至可以说是“重视过度”，而且产生出来的文档经常是与实际的开发脱离，完成之后就束之高阁，再也不使用、不更新。这是一个需求崩溃的信号规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方法格式不同定义统一的格式是一个很重要的工作规约内容的严谨、正确、无岐义是很重要的
67. 需求验证这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的提高需求质量的重要手段：> 需求评审> 需求确认> 通过原型来验证需求
68. 需求开发与需求管理的分界
69. 需求基线管理频繁的需求变更会破坏开发的节奏，使整个项目开发的进度陷入混乱和失控的状态，而且会变成一个“救火队”式的工作，整天都在处理突发事件将所有现在的、将来的需求进行优先级评估，然后分解成为不同的组，每次迭代都选择其中优先级最高的部分进行开发，然后在迭代完成之前，开发工作不响应变更，这些划入的需求项就是需求基线的组成部分
70. 需求基线管理—操作思路我们应该在分析的基础上，将需求整合成为用例或功能项，然后对其进行优先级、依赖性进行综合性评估优先级判断：业务人员确定业务决定，技术人员确定技术决策；“满意度/不满意度”模型依赖性是指对于某些功能，在实现上有必须的依赖关系，即当某些功能没有实现时，另外的功能无法开始，这就需要对其进行调整
71. 需求变更管理需求变更是一定存在的，而需求变更管理并不是指逃避它，更不是说要避免它，它实际上是希望控制变更在基线内的需求不响应变更，为开发人员提供一个安静的工作时间状态专门的需求变更管理来对所有的需求变更进行响应，了解需求变更的关键意图、新产生的工作量，从而良好地进行重新计划，以便能够有效地解决其对整个开发带来的麻烦
72. 需求变更管理—变更的流程提出变更：正式的方式提交变更是很重要的，合约式的沟通平台变更评估：合理性评估，进一步了解其变更的主要原因，认清其是否是因为沟通上的误会与不理解而造成的不必要的变更；工作量评估则是评估其对进度的影响；影响面分析则是评估该变更会对哪些部分工作产生影响，具体地说会对哪些人的工作产生影响分级响应评估：不影响相关模块开发进度的，可直接响应；影响本模块开发进度但不影响项目总体进度的，可由项目经理协调后直接响应；影响项目进度的，则应该交与客户协商响应方式
73. 需求跟踪需求的跟踪是指对需求的完成情况、变更影响进行系统化的跟踪与处理 “需求是不是已经被实现？”、“需求的变化将需要修改哪些设计元素？会影响谁的工作？对已经完成的部分是否有影响？”
74. 需求管理的参与者
75. 需求分析师需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道典型活动：定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求必备技能：倾听、交谈和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力
76. 需求分析师必备知识：现代需求管理技术、各种软件开发生命周期、领域知识需求分析员的来源：用户转为分析员（软件工程知识欠缺）、开发人员转为分析员（领域知识、沟通能力）、主题专家（易按自己的偏好来构建系统）
77. 软件客户权利法案要求需求分析员使用客户的语言要求需求分析员熟悉客户的业务，了解客户的系统目标要求需求分析员把需求收集过程中客户提供的信息组织成书面的软件需求规格说明要求需求分析员解释需求过程生成的所有工作结果要求需求分析员和开发人员尊重客户，始终以合作和专业的态度与客户进行互动要求需求分析员和开发人员为需求和产品实现提供思路和备用方案
78. 软件客户权利法案要求开发人员实现能让产品使用起来更容易、更有趣的特性调整需求，便于重用已有的软件组件在提出需求变更时，获得对变更的成本、影响及二者权衡关系的真实评估获得满足功能和质量要求的系统，这些要求必须事先告知开发人员并征得其同意
79. 软件客户义务法案为需求分析员和开发人员讲解业务并定义业务术语提供需求，阐明需求，通过与开发人员的交互将需求充实完善对系统需求的描述必须详细、准确需要时，及时对需求做出决断尊重开发人员对需求成本和可行性的评估与开发人员协作，为功能需求、系统特性和用例设置优先级
80. 需求过程
81. 需求过程
82. 概要信息系统基础理论需求的基本概念与原理需求工程需求定义最佳实践需求捕获最佳实践对问题进行了正确的定义意味着成功解决了问题的一半
83. 信息系统立项前的分析方法GPOA方法：GoalProblemOptionAnswer G（目标）：要确定需要开发某个信息系统之前，应该分析其应该达到的目标：业务性、可度量 P（问题）：要达到该目标所需解决的问题！ O（选项）：针对这些问题可选的解决方案 A（答案）：针对各种Option进行分析、评估，最终确定答案。
84. 信息系统立项可行性分析确定目标：信息系统实现前，信息系统实现后提出解决方案：分析P，给出O，得出A 可行性分析：> 效益分析：经济可行性，投资回报> 社会可行性> 技术可行性
85. 信息系统立项时的常见误区目标：含混不清，过为宏观 Solution: 基于业务需求思考解决方案：思路过于受限 Solutions: > 只想What，别想How > 了解、理解IT技术期望值：脱离现实发起人、用户、使用者想法不一致
86. 框定问题的技巧问题的定义是需求工作的第一步，也是最重要的一步。问题是否能够解决，通常与是否能够更好、更准确地框定问题相关。
87. 框定问题的技巧软件需求第一和可能最重要的步骤是框定问题—把问题的特定部分，以及部分间特定的关系，放入一个特定的形式中。问题框定方法应使问题的细节适合一个简单连贯的框架同时，这也表现出，深入地理解问题域的知识，正确地抓住其本质特性，是十分重要的。
88. 框定问题的技巧问题：在风景旅游胜地的山脉中建成了一条很长的汽车隧道，为了防止停电时发生灾难，必须提醒司机进入隧道之前把车灯打开。解决方案一：“警告！前有隧道请打开车头灯” 新问题：隧道出口风景很美，返回时发现汽车没电—忘了关车头灯！！解决方案二：出口处立标牌“关掉车灯” 新问题：夜行车也会关掉车灯？解决方案三：建充电站新问题：维护开支大，充电站也会出故障
89. 框定问题的技巧解决方案四：授权私人经营充电站新问题：风景区商业化，政府与游客均不接受解决方案五：在隧道尽头，树立新标牌如果是白天，并且车灯开着，请熄灭车灯；如果天色已晚，并且车灯没开，请打开车灯；如果是白天，并且车灯没打，就别打开它；如果天色已晚，并且车灯开着，请别关掉它。新问题：谁能在行驶时读完？！终极解决方案：你的灯亮着吗？
90. 问题分析的五个步骤问题分析：理解真实世界中的问题和用户的需求并提出满足这些多方面要的解决方案的过程 ①在问题定义上达成共识 ②理解根本原因—问题背后的问题 ③确定风险承担人和用户 ④定义解决方案系统的界限 ⑤确定加在解决方案上的约束
91. 在问题定义上达成共识把问题写下来，看每个人是否都同意采用标准化格式：> 问题：描述问题> 影响：确定受问题影响的风险承担人> 结果：确定问题对风险承担人和商业活动的影响> 优点：指出解决方案并列出主要优点
92. 理解根本原因—问题背后的问题TQM的鱼骨图帕雷托图
93. 理解原因后对问题的陈述问题：不准确的订单影响：订单操作者、客户、生产者、销售者及客服结果：增加废品、额外处理成本、客户不满及收益降低优点：> 增加了输入点订单的准确性 > 增加了销售数据的报告以便进行管理 > 获得更好的效率
94. 确定风险承担人和用户系统的用户是谁？系统的客户是谁？还有哪些人会受系统输出的影响？系统完成并投入使用后，有谁会对它进行评估？还有没有其他系统内部或外部用户，他们的需要有没有必要被考虑到？系统将来由谁维护？还有其他人吗？
95. 定义解决方案系统的界限谁会对系统提供信息？谁会在系统中使用信息？谁会从系统中删除信息？谁将操作该系统？谁是系统的维护者？系统将会在哪儿被使用？系统从哪儿得到信息？哪些外部系统要和系统进行交互？
96. 确定加在解决方案上的约束经济约束：预算？行政约束：存在许可问题？潜在内外部政问题？部门间问题？技术约束：技术选择有何限制？限制在已有平台或技术上？禁止使用新技术？需要购买软件包？系统约束：建立在现有系统上？需要维护与原系统的兼容性？必须支付什么操作系统？环境约束：合法吗？安全性要求？其他标准限制？进度及资源：进度要求？已有资源？外部劳动力可用否？有无扩展资源？
97. 确定加在解决方案上的约束操作性：销售订单数据必须在数据库中备份一年，因为数据丢失风险太大，需并行运行至少一年的数据系统及操作系统：应用在服务器上占用不超过200M，因为服务器上存储空间有限设备预算：必须在已有服务器和主机上开发人员预算：固定的人力资源，没有外部资源技术要求：应用新的面向对象的方法
98. 项目定义—业务需求产品/项目的目的：对业务目标的简短、可度量的描述客户：为谁构建？顾客：谁会购买？风险承担者：哪些人在产品中拥有既得利益？用户：谁将操作它？他们的能力如何？限制条件：必须采用某设计方案？时间？经费？名称：该项目使用哪些术语？相关事实和假定：每个人都需要知道什么？工作的范围：什么是产品和项目的边界？估算的费用：需要花费多少工作量或资金风险：面临的主要风险
99. 项目定义—目标的六要素目标：精确预报道路结冰时间并分派除冰卡车业务优势：通过预报道路结冰情况来减少道路事故度量：因结冰而发生的事故数年将低于冬季发生的事故总数的15% 合理性：消除因结冰而发生的事故而减少的损失，与构建该系统所花费的成本和工作量相比，是否有价值？可行性：及时地除冰能否减少事故的发生？会降到总数的15%以下吗？可达成性：该目标能达到吗？
100. 项目定义—风险承担人与用户用户：与主题相关的经验、技术上的经验、智力能力、对工作的态度、对技术的态度、受教育程度、语言技能、年龄、性别风险承担者：用户、客户、顾客、管理者、业务主题相关者、开发人员、检查人员、市场力量、法律方面、反对者、专业团体、公众意见、政府、特殊利益团队、技术专家、文化利益、相邻系统
101. 项目定义文档—前景文档业务需求> 背景：新产品的来由与背景> 业务机遇> 业务目标与成功标准> 客户与市场需求> 业务风险解决方案的前景> 前景说明(目标客户、需求与机会、竞争对手与优势)> 主要特性> 假设与依赖
102. 项目定义文档—前景文档范围与限制> 第一个版本的范围> 各后续版本的范围> 限制与排除业务背景> 涉众简介> 项目优先级> 操作环境
103. 需求心理学—常见现象言过其实心理：说的流程是一种理想化流程，与实际情况严重不符越俎代疱心理：对非自己处理的流程津津热道，根据自己的理解、想像进行肯定的描述非正事心理：一直忙于工作，无瑕配合需求调研抗拒心理：新系统对其利益有损，故意不配合推卸责任心理：装不知，说没需求
104. 需求变化的预期流程变化：流程顺序变化，流程细节变化，流程负责人变化，流程输入变化，流程输出变化。数据变化：数据格式变化、数据规则变化、数据输出变化、数据项变化业务规则：规则增加、规则减少、规则变化系统表现形式变化：界面、风格、输入形式、展现方式、访问方法、网络环境目标变化
105. 概要信息系统基础理论需求的基本概念与原理需求工程需求定义最佳实践需求捕获最佳实践需求捕获是一个探索的过程是一个有计划、科学性的过程
106. 需求捕获的主要障碍大多数情况下，系统相关的人员无法陈述自己的需要许多用户难以解释所执行的任务，更难解释为什么执行这些任务相关人员经常指定解决方案而不是需求相关人员也难以构想出新的工作方法，或者想像出使用提供的方法执行熟悉的任务所能够得到的结果不同的相关人员可能持有相互矛盾的观点相关人员经常出于抵制变更而拒绝新系统需求可能过多—过度的需求需求随着时间而变化
107. 需求捕获的各方职责由需求分析师策划，由需求分析师、用户和其他风险承担者积极合作完成。用户、顾客和客户：有责任向需求分析师提供他们的工作知识需求分析师：理解用户所说的关于工作的事情，并将其解释成产品的需求规格说明> 观察和学习该项工作，从用户角度来理解它> 用户对某项工作的描述必须作为事实来对待，要发现工作的本质，而非表象> 发明完成该工作更好的方法> 以需求规格说明书和分析模型的方式记录
108. 用户在需求捕获过程中的角色作为设计组、专题讨论会的成员，参与设计用户界面作为知识来源，提供任务、商业过程的当前执行情况参与集策讨论会，提供构想、确定问题作为测试用户，在验收时测试系统检查能否正常工作作为审查者评估用户界面进行可用性测度，尝试使用新的用户界面执行任务作为项目管理委员会成员
109. 用户的各种需求意识到的需求：是指那些用户最先想到的需求，常常表明用户希望改进的一些事情无意识的需求：是指那些用户没有言明的事情，因为用户对它们知道得太多，以致于他们假定其他任何人都具备同样的知识未梦想过的需求：是指那些一旦用户认识到它们可能就会要求的事情
110. 系统化地组织需求捕获术语表、域建模、领域培训—这些都是因地制宜的业务建模的常见工具。（Wiki）与业务流程相关的系统，最重要的是：置身于流程之中，分析信息、工作流。从“组织结构与岗位设置图”所体现的管理层次与线条建立全局了解；--参与者的来源；针对业务流程，绘制出跨部门职能流程图，以帮助开发人员对客户方的业务流程建立宏观、清晰的认识，以便更加有的放矢地进行进一步的需求捕获工作。
111. 跨部门职责流程图
112. 系统化地组织需求捕获应该搜集什么信息？细化地研究流程图，看看是否已经对每个环节、每个步骤都清楚地认识了。我们应该根据自己的理解首先对每个流程的工作进行定义，写出事件流，并且标识出疑问点，这些都将使我们明白“应该收集什么信息”。从哪搜集这些信息？流程涉及到什么部门、岗位，答案就应该从谁身上找。（闲聊惹的祸）用什么机制来搜集？需求捕获技术有多种，重点在于因地制宜地使用不同的机制……
113. 主要需求捕获技术比较当前工作当前问题目标及关键问题未来系统构想切实的可能性结果及风险认可冲突决议最终需求优先级完整性相关人员分析BACCBBC用户访谈AABCC现场观摩ABCB任务示范AABCB文档考古ABCB用户调查BBCC集策讨论会A重点问题讨论会AAABCCA域专题讨论会AAABBBBBBB设计专题讨论会CABCBCA
114. 主要需求捕获技术比较当前工作当前问题目标及关键问题未来系统构想切实的可能性结果及风险认可冲突决议最终需求优先级完整性原型设计CABBAC小规模试验CAAABBB研究类似公司CBAAAB询问供应商CCBABB协商CBCCCAABA风险分析BBAC成本/效益分析BBCCACA目标-域分析BBBCABCBBA域-需求分析CBCABB
115. 用户访谈用户访谈：最基本、最常见的技术利：直接有效、形式灵活、交流深入，应该做为主要的需求捕获技术（宽带通信、固有灵活性、各类信息）弊：占用时间长（特别当客户忙时更显示出其不足）、面窄而容易造成信息的片面性。要点：首先要有准备：通常包括说明对流程的理解，并征得客户的意见；预先根据流程中的不明确点设计要询问的问题，并将客户的反馈记录下来；应留有一些即兴的空间，根据实际情况应变，以确保信息完善。第二是要有计划性：计划好时间、计划好人员、计划好策略。
116. 用户访谈：特点最传统的方法，单独使用并不有效，通常别期望用户知道并能够说出他们的需求应先草拟一份问卷，向要访谈的用户发出一份涉及访谈主题和时间安排的材料在访谈的过程中，及时用草图绘制模型（DFD、用例、思维图），从而得以及时反馈应以业务事件为谈话的中心，问问题，听取回答，然后反馈理解
117. 用户访谈：准备工作围绕目标制订一个计划，包括一组按逻辑方式分组和排序的问题在计划内应有时间在结束时检查是否已涵盖所有问题，并理解对所有问题的答复不要超过1小时，否则应安排下一次面谈地点选择：适当的不受干扰和避免打扰记录：自己做笔记（分神）、专门一同事做笔记（成本高）、录音（失去身体语言）/录像（难操作）自己做笔记+录音
118. 用户访谈：通用问卷建立客户或用户情况表> 姓名、职位等基本信息> 你的主要职责是什么？> 你们的主要输出是什么？> 为谁做的？> 如何测试成功?> 什么问题阻挠你们的成功?> 如果有，什么使你的工作更容易或更困难
119. 用户访谈：通用问卷评估问题> 你对哪种问题缺乏好的解决方案？> 它们是什么？（提示：不断问“还有吗？”）> 对每个问题，问： > 为什么存在这个问题？ > 现在你怎么解决它？ > 你打算怎么解决它？
120. 用户访谈：通用问卷理解用户环境> 谁是用户？> 他们的教育背景如何？> 他们的计算机背景如何？> 用户经历过这种类型的应用吗?> 使用的是哪一种平台？计划将来的平台是什么？> 有没有用其他和该应用有关的应用？如果有简单介绍 > 对产品可用性的预期是什么?> 你需要什么样的用户帮助（在线文档、纸介质？）
121. 用户访谈：通用问卷简要说明理解情况> 你刚才告诉我…（用自己的话列出客户所述问题）> 这是否足以表达你认为现在存在的问题？> 如果还有，那是什么问题？分析人员对客户问题的输入(有效或无效的假设)，如果有，问题与什么有关？对于每个建议，提问: > 这是一个实际的问题吗？产生的原因是什么？ > 你是怎么解决这个问题的？希望怎么解决？ > 和你提到的其他问题相比，这些问题的位置如何？
122. 用户访谈：通用问卷评估你的解决(总结你建议的解决方案的主要功能)如果你能够……对于这些的重要性，你是如何排序的？评估机会> 在你的单位中，谁需要这样的应用？> 使用这种应用的用户有多少?> 如何评价一个成功的解决方案?
123. 用户访谈：通用问卷评估可靠性、性能及支持的需要> 你对可靠性的预期是什么？> 你对性能的预期是什么？> 是你还是其他人来支持该系统？> 你对支持还有特别的要求吗？> 维护及服务如何?> 安全需求是什么？> 安装和配置需求是什么？> 有什么特殊的许可需求吗？
124. 用户访谈：通用问卷其他需求> 有必须支持的法律、法规、环境需求或标准吗？> 你还能想到其他我们应该知道的需求吗? 总结性提问> 我还有其他问题应该问你吗？> 如果我还问你其他问题的话，可以打电话给你吗？你愿意参加需求审阅吗？分析人员总结：面谈后，趁你记得时，总结出用户/客户确认的三条最高优先级的需求或问题
125. 用户访谈：操作法避免类似以下暗示：我的时间比你宝贵，我不知道我在做什么，你不知道你在讲什么用简单的语言清楚地表达问题，采用对方的术语和行话不要遗漏任何事情能够找到和探究异常现角，例如对未预料问题的反应不要搞错基本信息流要求的方向
126. 用户访谈：询问的问题问题类型：待解决的问题、开发解决方案的过程、需求获取本身需求获取本身的问题：> 我的问题看起来相关吗？你的回答正式吗？> 你是回答这些问题的最佳人选吗？> 我问了太多的问题吗？> 还有其他什么我该问你的？> 你想问我什么？> 我还应该见其他什么人？> 关于这个项目有什么人我们不需要？
127. 用户访谈：主要困难缺乏对所需要的人的访问（知道最多的人最忙）在面谈时记录信息很困难被访谈人会试图说他们认为你想要听的话访谈人用诱导性问题提问束缚关键职员的有关费用由不同领域知识和行话引起的交流困难隐蔽的动机和组织政策产生错误信息
128. 用户调查：概述用户调查：调查面最广的技术利：面广，能够获得更多的人的反馈。这点是对用户访谈技术不足之处的最好补充。弊：不够深入，容易形而上学。而这点是正是用户访谈技术所能够解决的。要点：结合用户访谈技术使用，具体来说：先设计问题，制作成为用户调查表，下发填写完后，进行仔细的分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作为补充。
129. 用户调查：主要用途搜索某项假设的统计依据：设计一些封闭的问题，例如“从现有系统中取得客户统计资料的难易程度：非常困难、相当困难、容易、非常容易” 搜索意见、建议：询问与用户访谈类似的开放性问题，例如“日常工作中的三个最大问题是什么？”，“你对能够更好地支持日常工作的IT系统有什么建议”。--误解你的问题，你误解他的回答
130. 用户调查：主要困难相关的问题不能事先决定问题背后的假设对答案会造成偏颇> 例如：这功能符合你的期望吗？> 假设：你有期望，所以这是一个有意义的提问难以探索一些新的领域，也没有探索新的需要被探索的领域的交互难以继续用户的模糊响应
131. 现场观摩：概述现场观摩：最生动的技术利：百闻不如一见，能够对需求与业务流程建立直观的认识。弊：消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真。适用性：要对于复杂流程的更加深入的理解时。要点：悄悄地进行，明确要强化理解的具体流程环节。
132. 现场观摩：常用变体任务示范：要求用户示范如何执行特定的任务利：可用于发现异常的、关键性的任务弊： “示范”失真、耗时做学徒：和用户坐在一起，通过观察、问问题、并在用户指导下完成一些工作来学习适用性：用户无法详细解释清楚他们在做什么时 “人们正在做一件事时，最能解释他们在做什么，为什么要这么做” 需求分析员可以通过学徒关系试验他的需求和设计思想
133. 文档考古：概述文档考古：最贴近实现的技术利：能详细、直观地对数据流细节进行了解与分析。弊：易陷入文山书海之中不可自拔，甚至常引起误导。要点：应该尽量让客户提供写有真实数据的文档。特点：从旧的工作材料中挖掘新的需求检查收集的文档，从中找出名词，或“东西”，包括列标题、命名的表格区域涉及内容：文档、打印输出、清单、手册、屏幕等
134. 文档考古：常用思考点此物的目的是什么？怎么用它？为什么用它？用它做什么？系统都利用它来做些什么？哪些业务事件用到或引用了此物？此物会有一个值吗？是数字、代码、数量？如果是这样的话，它属于哪些东西的组成体？此物的用途是什么？文档中是否包含了一组重复的事物？如果是这样的话，这些事物的集合称为什么？
135. 文档考古：常用思考点我能找到事物之间的联系吗？什么过程建立了它们之间的联系？每件事物附加的规则是什么？换句话说，哪部分业务策略涉及该事物？什么过程确保了这些规则会被遵守？什么文档给用户最多问题？建议：做为数据建模方法的一部分
136. 文档考古：优缺点优：获取信息相对比较直接，获得系统所有输入、输出及内部文档（但不应假定已获得全部描述）；有助于数据模型分析。缺：文档说明的系统与实际系统可能是不匹配的；文档考古的传统分析方式（如开发文档流图）可能导致产生现有系统的结构模型，从而带入新系统
137. 联合开发：概述联合开发：最理想的技术利：客户、开发人员直接的头脑风暴，是击破需求盲点的关键手段。弊：成本高，如果缺乏控制会变成一次闲扯大会。要点：需要有一个经验丰富、能够把控大局的主持人。
138. 联合开发：优点协助建立一支高效的团队，围绕一个目的：项目成功所有风险承担人都畅所欲言，没人被落下正如应用项目所必须做的，它促进风险承担人和开发团队之间达成共识它能够揭露和解决那些妨碍项目上成功的行政问题能够产生一个在特征级别上的初步系统定义
139. 联合开发：准备工作推销概念：充分的准备是联合开发的关键，推销联合开发（需求专题讨论会）的好处确保真正的风险承担人参与后勤保障热身材料：在开会前散发资料> 项目专有信息：需求文件草案、已排序的特性…> 摆脱束缚思想的：提供创新方法、自由讨论规则…> 2天~1周内散发，太早会使人忘记！
140. 联合开发：准备工作备忘录收件人：XXX项目的风险承担人主题：即将召开的需求专题讨论会我是XX产品（项目）的管理者。这个项目已经（或即将）于开始并截止于完成。（我们了解它，我们是认真的，我们想要按时完成它）正如大多数的项目一样，获得关于应用项目的新特征的共识并定义一个最初的基本系统来满足不同风险承担人的需要是十分困难的。（它甚至比在这个组达成任何其他共识更，因此我们将尝试一些不同的方法…）为了使这个过程更加容易，我们将召开一次关于的需求专题讨论会。专题讨论会的目标是：为产品的下一个基线版本确定新特性。为了做到这些，听取每一个风险承担人的意见就极为重要。专题讨论会将由来主持，他是一位经验丰富的需求管理联络员。（作为风险承担人，我们可能也有偏见，从外面聘请主持人可以使其更公平）专题讨论会将很快得出结果，并在第二天将结果分发给开发部。我们热忱地邀请您参加专题讨论会并提出代表你的（团队、部门、用户）需求的意见。如果您无法参加，我们热切地希望你能够授权一名代表您的需求的成员参加。（会后第一天我们将开始工作；如果你希望对项目提出什么意见，请到这里来，或授权一名代表来。换句话说，要么现在说，要么永远别说。）备忘录中有一个关于当前产品期望特征的简短说明，以及其他关于专题讨论会和自由讨论进程的资料。专题讨论会将于上午8:30开始，下午5:30结束。（这个专题讨论会以及该项目将按专业要求运作，需要你们来建议，使项目更顺利）热切期盼在会场上见到您。 [项目领导人]
141. 联合开发：联络员联络员：熟悉该过程，有风度受尊重，团队外成员主要职责> 在会议中建立一种专业、客观的基调> 按时开始、结束会议> 建立并维持会议“规则”> 为会议订立目标和议程> 管理会议进程并保持在“正确轨道”> 提供一种决策和达成共识的机制> 管理设施和后勤保障事务> 确定所有风险承担人都在参加> 控制混乱或没有意义的行为
142. 联合开发：安排日程 08:00~08:30 介绍议程、设备、规则 08:30~10:00 情况简介现状、需要、面谈结果 10:00~12:00 自由讨论应用特性 12:00~13:00 午餐 13:00~14:00 自由讨论继续 14:00~15:00 特征定义写出2~3句话的特征定义 15:00~16:00 意见精简与优先级排序 16:00~17:00 总结和操作议项
143. 联合开发：组织技巧中间休息迟到规则：每人先发一张，允许迟到一次而后向罚款箱投入xx元目的：保持会议的动向5分钟发言好主意！1次自由廉价攻击规则：每人先发一张，允许自由攻击或批评任何个人或部门，而后再出现就向罚款箱投入xx元目的：逗趣并提醒人们注意发言规则：每人先发两张，送给提出好建议的人，要尽快给出目的：刺激与会者并奖励提出创新者规则：每人可以在任何时候使用，让出讲台给他并计时，不得打断目的：允许结构化的即席发言
144. 联合开发：自由讨论与意见精简每人发25张索引卡片，按以下规则进行自由讨论意见精简> 修剪：去掉不值得进一步集体讨论的意见> 归类：把意见归类> 特征定义：用一句话描述未被删除的意见> 确定优先次序：累积投票(百元测试)、关键/重要/有用不允许批评或争吵允许发挥你的想像力产生尽可能多的意见转换和组合想法
145. 情节串联板制作：概述情节串联板制作：最互动的技术利：用户友好、交互性、对用户界面提供早期评审，易于创建和修改。弊：需求捕获速度慢。
146. 情节串联板制作：类型
147. 联合开发：做什么及要点谁是扮演者他们发生了什么事是怎样发生的不要在情节串联板上投入太多精力如果什么都不变，就什么都学不到不要做得太好—误以为已完成只要可能，就制作交互折
148. 需求捕获的最佳实践评估系统可行性：进行需求捕获之前，应先进行一个可行性研究，评估现有技术下系统是否能够实现目的> 主要效益：提示是否真正需要一个系统> 引入成本：低 > 应用成本：低-中注意组织和行政方面的因素：需求捕获时，必须注意影响需求源和可能会对你隐藏真正系统需求的组织和行政因素> 主要效益：有助于理解一些需求被建议的原因> 引入成本：低 > 应用成本：很低> 实施要点：注意不一致的目标、责任的丧失或转移、组织文化、组织的管理态度和士气、部门差异
149. 需求捕获的最佳实践识别和咨询系统的项目相关人员：即那些直接或间接从开发的系统中受益的人> 主要效益：发现所有可能的需求源> 引入成本：很低 > 应用成本：低记录需求源：即记录该需求所基于的信息的链接，可以是人员、文档、其他需求> 主要效益：来自于初始需求源的需求可跟踪性> 引入成本：低 > 应用成本：低定义系统的操作环境：主动、硬件和软件系统> 主要效益：交付系统没有安装问题> 引入成本：低 > 应用成本：低
150. 需求捕获的最佳实践使用业务关系来驱动需求捕获：业务关系是必须满足的高层目标，应识别、记录这些目标。> 主要效益：需求集中在核心业务需求上> 引入成本：低 > 应用成本：低寻找领域约束：即来自于系统应用领域的系统需求> 主要效益：领域约束经常会导致识别出关键需求> 引入成本：低 > 应用成本：中等记录需求理由：即关于提出某需求的原因，根据系统所需解决的问题来证明需求。是从需求源导出的。> 主要效益：提高对需求的理解> 引入成本：低 > 应用成本：低-中等
151. 需求捕获的最佳实践从多视点收集需求：对系统的需求有许多影响源，对系统应提供服务和提供服务的方式都有自己的视点> 主要效益：更好的需求覆盖率> 引入成本：中等-高 > 应用成本：中等原型化难以理解的需求：如果有不清楚或难以理解的需求，则应考虑开发一个原型系统。> 主要效益：更好地理解系统用户的真正需要> 引入成本：中等 > 应用成本：低-高使用场景来抽取需求：场景是最终用户和系统间某个交互类型有关的交互会话。> 主要效益：用户易于理解场景和描述的相关需求> 引入成本：相当高 > 应用成本：低
152. 需求捕获的最佳实践定义操作过程：应分析、理解和文档化各种业务过程，将其作为需求捕获的一部分。> 主要效益：揭示过程需求和需求约束> 引入成本：相当高 > 应用成本：中等复用需求：尽可能从在同一应用领域已经开发出来的其他系统中复用需求。> 主要效益：较低的需求成本、较快的需求捕获> 引入成本：中等-高 > 应用成本：中等

需求分析师工作心得

sky155782

贡献于2012-09-20

需求分析师工作心得

PPT 内容

PPT 图集

相关PPT