第4章-需求获取

信息系统开发——方法、案例与实验

主讲：段智敏QQ：747885740系统需求概述需求获取过程案例分析需求获取方法本章主要内容学习目的与要求掌握怎样设计并执行访谈的选择，制定访谈计划掌握观察工作者方式和分析业务文档方式以确定系统需求的优缺点了解如何为需求获取提供支持了解怎样计划一个联合应用设计会议掌握在需求获取过程中使用原型了解确定需求的现代化方法掌握需求获取技术在网络应用开发中的应用考核知识点系统需求分类和获取系统需求获取方法需求获取技术的应用考核要求系统需求分类和获取识记：系统需求的分类简单应用：系统需求的获取过程系统需求获取方法简单应用：收集系统需求的方法综合应用：计划并执行访谈的选择，以及制订访谈计划以确定系统需求简单应用：观察工作者方式和分析业务文档方式以确定系统需求的优缺点简单应用：计算如何为需求获取提供支持综合应用：在需求获取过程中使用原型综合应用：确定需求的现代化方法需求获取技术的应用综合应用：需求获取技术应用于网络应用的开发需求获取是在问题及其最终解决方案之间架设桥梁的第一步，其实质是理解项目中描述的客户需求。需求获取是确定和理解不同用户类需要和限制的过程，它描述了用户利用系统需要完成的任务。需求获取主要涉及到系统分析员，他们同系统用户和所有者一起工作，在系统开发的早期阶段确定对信息系统的业务需求的详细理解。只有在全面确定了需求之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须进行大量的返工。如果仅仅将需求分析阶段的工作归结为编写需求规格说明书，这往往导致项目后期层出不穷的问题。需求获取是一个需要高度合作的活动，只有通过有效的客户—开发者的合作才能成功。作为系统分析员，必须透过客户所提出的表面需求理解他们的真正需求，而不是对客户所说需求的简单誊写。需求获取需求获取影响因素：客户方客户不明白他自己需要什么客户会不断更新所提出的需求客户与分析员之间缺乏有效沟通客户缺乏技术上的知识客户缺乏对软件开发的知识信息系统开发方他们习惯使用技术术语，而且在问题理解上与客户有偏差，有时他们以为互相之间完全达成协议，但是在展示最终结果时却发现并非如此此外，系统开发者往往喜欢将客户的需要改变，以使它们符合一个已存在的系统或模式，而不愿按照客户的需要来开发一个新的系统。有些情况下，需求分析往往是由程序员而不是系统分析员完成的。由于程序员往往缺乏对实际事物的运行过程和商业过程的理解，从而会导致需求获取存在问题。需求获取重要性☻问题的复杂性☻交流障碍（讲究技巧和原则）☻不完备性和不一致性☻需求易变性（动态性）派经验丰富的人去干！系统分析员需求获取重要性需求包含三个层次：业务需求、用户需求、功能需求及非功能需求业务需求反映了组织机构或客户对系统、产品的高层次目标要求，可以在项目视图和范围文档中进行说明。用户需求文档描述了用户使用产品必须完成的任务，在用例文档或者应用场景中予以说明。功能需求需求定义了系统必须实现的软件功能，使得用户可以完成他们的任务，从而满足业务需求。以图书管理系统为例，系统需要提供的基本功能包括：检验用户合法身份；用户注册和登记功能；图书借阅、归还功能；书库管理；读者管理等功能。非功能需求是指是衡量系统能否良好运行的定性指标。例如，可靠性、可扩充性、安全性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性系统需求分类系统需求分类

某日，面试前来应聘的高级程序员，问他“树上有十只鸟，开枪打死一只，还剩几只？”

他反问

"是无声手枪或别的无声的枪吗？"

"不是。"

"枪声有多大？"

"80-100分贝。"

"那就是说会震的耳朵疼？"

"是。"

"在这个城市里打鸟犯不犯法？"

"不犯。"

"您确定那只鸟真的被打死啦？"

"确定。拜托，你告诉我还剩几只就行了，OK？"

"OK，树上的鸟里有没有聋子？"

"没有。"

"有没有关在笼子里的？"

"没有。"

"有没有残疾的或饿的飞不动的鸟？"

"没有。"

"算不算怀孕肚子里的小鸟？"

"不算。"

"打鸟的人眼有没有花？保证是十只？"

"没有花，就十只。"

偶已经满脑门是汗，但他继续问："有没有傻的不怕死的？"

"都怕死。"

"会不会一枪打死两只？"

"不会。

"所有的鸟都可以自由活动吗？"

"完全可以。"

"如果您的回答没有骗人，"程序员满怀信心的说，"打死的鸟要是挂在树上没掉下来，那么就剩一只，如果掉下来，就一只不剩。“虽然是笑话,考虑全面啊

需求获取主要包括以下活动：发现和分析问题.了解用户需求。即通过与客户访谈或调研确定一些基本需求信息。分析用户需求。将客户需求与可能的系统功能或非功能需求相关联。编写需求文档。使客户需求信息结构化，编写成文档或者示意图。评审需求文档。选择客户代表评审文档并纠正存在的误解或者错误。需求管理。主要指需求变更以及需求跟踪。需求获取过程通过与用户对话或者观察用户收集的信息：访谈手稿、观察和分析文档的笔记、会议纪要等现有的书面信息：业务使命和战略陈述、业务表格、报告和计算机演示范例、规程手册、工作描述、培训手册、流程图和现有系统的文档、咨询报告基于计算机的信息：来自于联合应用设计会议的结果、组群支持系统会议的手稿或者文件、现有系统的CASE资料库内容和报告、从系统原型的显示和报告需求获取过程发现和分析问题鱼骨图感兴趣的问题原因分类根源了解用户需求识别系统用户。了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和工作范围。用户调研与访谈。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。访谈结果整理。对于用户提出的每个需求都要知道“为什么”，并判断用户对提出的需求是否有充足的理由；分析由用户需求衍生出的隐含需求，用户没有明确提出来的隐含需求，或者有可能是实现用户需求的前提条件。访谈结果呈现。需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求获取过程分析用户需求。将客户需求与可能的系统功能或非功能需求相关联。需求分析包括提炼、分析和仔细审查已经收集到的需求，以确保所有相关方都明白其中含义并找出其中错误、遗漏或不足之处。并对需求进行修改达成一致意见，使各类关联人员都能够对系统达成共识。这个过程主要排查以下方面的问题：是否遗漏了重要的需求；是否存在矛盾的需求；是否存在不可行的需求；是否存在重复的需求；是否存在模棱两可的需求；需求获取过程编写需求文档需求规格说明的主体由需求陈述构成，主要包含如下内容：系统应该提供的功能和服务系统的非功能需求，包括系统的特征、性能、属性等系统开发或者运行必须遵守的约束条件系统与其他系统之间的接口评审需求文档需求文档完成后，需要经过正式评审才能作为下一阶段工作的基础。一般的，评审分为用户评审和同行评审两类。用户和开发方对于软件项目内容的描述，是以需求规格说明书作为基础的；用户验收的标准则是依据需求规格说明书中的内容来制订，所以评审需求文档须重点考虑用户的意见。同行评审的目的是在软件项目初期发现那些潜在的缺陷或错误，避免这些错误和缺陷遗漏到项目的后续阶段。通过评审的需求文档称为需求基线（baseline），这说明这些需求已经确定下来，添加新的需求和修改原有的需求都必须通过需求变更流程来操作。需求获取过程评审指标正确性唯一性完整性可验证性一致性可理解性可修改性可追踪性需求获取过程评审内容系统定义的目标是否与用户的要求一致系统需求分析提供的文档资料是否齐全文档中的所有描述是否完整、清晰、准确与其他系统的接口是否描述数据流与数据结构是否确定图表是否清晰、易懂主要功能是否明确约束条件和限制条件是否符合实际开发风险是否可控是否考虑过软件需求的其他方案是否考虑了过系统可能有新的需求是否详细制定了检验标准，能否对系统定义的成败进行确认有没有遗漏、重复或不一致的地方用户是否审查了初步的用户手册软件开发计划中的估算是否受到了影响需求获取过程需求管理要保证需求分析各个活动都得到了充分的执行。需求管理主要涉及两方面的内容：需求变更以及需求跟踪。提出变更请求。对于影响需求基线的变更，例如业务规则的变化，用户需求的变化，或者技术条件的变化等，都需要采用书面的形式提出正式的需求变更请求。变更影响分析。由项目组有关人员汇同客户一起进行变更的合理性分析，变更替换方案分析，工作量的估算以及涉及模块、影响模块等分析。变更批准。根据变更影响分析的综合评估，确定是否执行变更。变更执行。根据经过审批的变更内容对系统进行相应的变更。变更测试。对变更进行验证测试，这时候特别要注意的是记录该变更的修改是否引起了该模块或其他模块产生缺陷。变更结束。变更验证后，测试人员关闭变更（状态：已关闭），项目经理告知客户已测试完毕，沟通发布时间并说明哪些模块可能有影响以及发现问题的反馈途径和方式。需求管理需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求，体系结构，源代码模块，测试，帮助文件等。需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。跟踪目标：进行设计时，保证需求没有遗漏地被实现。需求变更时，能找到设计中需要变更的地方。设计变更时，能找到受影响的需求。需求管理需求获取方法需求收集方法描述访谈访谈具有各种需求的单个人员或者团体，了解关于现有系统和未来系统需求的运行和问题，发现系统需求之间的关联与区别观察在选定的时间观察工作者如何处理数据，工作人员需要哪些信息名义团体技术研究业务文档，发现报告的问题、策略和方向，以及在组织中使用数据和信息的具体例子文档与报告通过研究现有文档、表和文件建立对系统的感性认识联合应用设计在联合应用设计（JAD）会议中把用户、发起人、分析员和其他人集中到一起讨论并审查系统需求原型通过显示系统工作原型等具体形式提炼对系统需求的理解需求获取策略了解现有文档、表格、报告、文件。观察工作中的系统。根据收集的事实，设计并发放调查表，澄清没有完全理解的事情。进行面谈。构造原型。追查到底，采用合适的调研技术验证事实。案例讨论：确定基于Web的客户关系管理系统的需求假设上海某家大型音像连锁店在本地区设有20个门店，主要开展销售和租赁视频、音乐和游戏给客户。现存和新出现的竞争者促使竞争的加剧，要求经常要考虑更好满足客户需求的方式。客户越来越多地希望得到信息服务，客户希望公司创建通信社区，与用户交换信息。由于业务发展需要，希望开发一个基于WEB的客户关系管理系统。希望所提议的系统将提供下列信息服务，如：（1）允许客户就他们所购买或者租赁的视频、音乐和游戏发表结构化或非结构化的评论；（2）提交要销售和租赁的新产品请求；（3）检查客户的突出租赁的到期时间；（4）商品项归还之后，在没有违章的情况下，可以付少量费用续借；（5）检查门店中的商品项的库存；（6）父母可以监视（看列表）孩子所购买或者租赁的商品项。该项目可以进行客户所期望这类的信息服务的详细分析，设计基于Web的系统来提供这个服务，并实施和检