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