《uml课件》由会员分享，可在线阅读，更多相关《uml课件（45页珍藏版）》请在金锄头文库上搜索。
1、面向对象设计方法与统 一建模语言CH2-需求的获取与分析（1）需求l需求是关于系统将要完成什么工作(what)的一 段描述语句,是指用户或者客户对要开发的软 件系统的要求。l它们必须经过所有相关人员的认可,其目的是彻 底解决客户的问题。l需求的内容在“问题定义”中描述（可能是招标 文件）。需求分析l指开发人员为了准确地理解和表达用户要 求，进行细致的调查分析，将用户非形式 的需求陈述转化为完整的需求定义，再由 需求定义转换到相应的形式功能规约（需 求规格说明）的过程。l准确地回答“系统必须做什么？”软件需求分析的目标l确定系统的综合要求l确定系统功能、性能、运行等方面要求l对将来可能提出的要求
2、做准备l分析系统的数据要求l考虑数据、数据处理l导出系统逻辑模型l用例图、活动图、时序图l修正系统开发计划l对系统成本、进度有更精确的估算l总之，需求分析的任务就是借助于当前系 统的逻辑模型导出目标系统的逻辑模型， 解决目标系统的 “做什么” 的问题。获取需求前的准备工作l软件项目总是从了解问题领域开始的。l项目正式启动前要考察和评估委托方企业业务 模式，可借助如下工作完成：l项目背景调查l业务前景分析l业务可行性分析l技术可行性分析l等l根据对业务概况的了解来整理业务目标。电力营销系统l供电企业业务概况：l电厂发出电力发电l高压电网传输高压电送电l变电站将高压电转成低压电变电l低压电通过供电
3、线路传输到终端配电l各户安装电表，家电使用电力用电电力营销系统l关注于用电环节：1.新用户申请用电，供电局安装相关设备并 供电业扩2.记录用户用电量，并计费收费计费、帐 务3.管理和维修供电和计量设备计量4.保障用电安全用电检查整理业务目标l根据对业务概况的了解来整理业务目标。l此案例中得到的业务目标：见书本P197涉众分析l了解业务状况后分析员最先要做的事情不是去 了解业务细节，而是去发现与这个业务有关的 人和物涉众。l涉众：l与项目利益有关系的人和事，都可能对系统建 设造成影响。l通常在项目初期不能清楚获悉，随着需求的深 入而逐步明确。发现和定义涉众1.业主l指系统的需求提出者和使用者。l
4、是系统建设的出资方、投资者。l关心建设成本，建设周期以及建成后的效益。l成本、周期将影响到项目可采用的技术、架构、系统 范围。发现和定义涉众2.业务提出者：l是业务范围、业务模式和业务规则的制定者，l一般指业务方高层人物，制定业务规则、圈定 业务范围、规划业务目标。l关心系统建设带来的社会影响、效率提升、管 理改进、成本节约等宏观效果。l他们的期望是系统建设的最高纲领，同时也是 非常原则化和粗略的，有很大调整空间。发现和定义涉众3.业务管理者l实际管理和监督业务执行的人员，将业务提出 者的意志付诸实施，并监督底层员工工作。l关心系统将如何实现管理职能、如何方便得到 业务的执行情况，如何下达指令
5、、如何得到反 馈、如何评估结果。l他们是系统的主要用户之一，期望比较细节， 是需求调研中最重要的信息来源。l他们的期望也可以有所妥协，系统分析员可以 提供可替代的方法来规避高技术、高成本风险 。发现和定义涉众4.业务执行者l指底层的业务操作人员，最关心系统会给他们 带来什么样的方便，会怎样改变他们的工作模 式。l他们的需求最为细节，如系统运行效率、友好 性、界面风格、录入方式等。l人数较多，要求各种各样，系统分析员要从中 找出具有普遍意义，解决大部分人问题的期望 。发现和定义涉众5.第三方：l与业务有关的，但并非业务方的人或事。l对系统不会产生决定性影响，但会起到一些限 制作用。l如：项目监理
6、6.承建方：l通常关心通过这个项目能否挣钱，能否累积核 心竞争力、能否树立品牌，能否开拓市场。l通常会影响到项目所采用的架构方法，开发技 术。发现和定义涉众7.相关的法律法规8.用户涉众分析报告l通过上述大类，可以帮助发现项目涉众，进而 对涉众进行调查和访谈，得到涉众分析报告。l完整的涉众分析报告包括：l涉众概要l涉众简档l用户概要l用户简档l消费者统计l涉众概要l说明各种涉众的基本信息，在系统中的角色， 及其对系统建设的期望。l涉众简档l描述涉众在系统中承担的职责，以及涉众在系 统中成功的标准。l用户概要l描述用户的概况、特点、使用系统的方式，及 代表涉众。l用户简档l与涉众简档类似，用于对
7、一些典型的用户代表 进行描述。l消费者统计l说明系统预期使用人群和他们的特点，使用系 统的频率，及特殊要求l如下图：收集系统需求l在需求收集期间，分析员应从尽可能多的来源 收集与这个系统应该如何运转的信息。l收集系统需求就像进行一场调查，好的分析员 应具有如下特性：l鲁莽l公正l放宽限制l注意细节l再构造收集需的传统方法l信息收集是系统分析的核心，可采用的传统方 法是：1.访谈2.观察3.分析现有程序和文档访谈l与系统的涉众对话，并获取他们的需求。l访谈时可采用两种形式的问题:1.开放式问题 谈话的形式, 问题通常没有确定 的答案2.封闭式问题 问题通常被良好的组织, 通常会 提供这些问题的答
8、案范围，让受访者从中选择 。有效访谈的指导原则直接观察用户l观察用户是如何工作的。l目的：l为了获得用户与信息系统交互的更多的第一手 资料和客观度量；有时，这将比雇员自己的报 告更能准确地反映事实。l缺点：l观察可能使用户改变他们的日常行为; 另外有 限的观察时间也会成为获得丰富数据的一个限 制。分析程序和其他文档l分析系统历史文档，来收集当前和未来系 统的相关信息。l相关文档：l个人或者工作组的一个书面工作程序l业务表单l当前系统生成的报表确定系统需求的现代方法l联合应用程序设计（JAD）l原型法l敏捷方法联合应用程序设计 (JAD)l20世纪70年代末，始于IBM；l目的是从涉入系统的重要
9、用户那里收集系统需 求lJAD会议通常在一个距离人们投入正常工作很 远的地方举行。l高度专心于系统。JAD 的小组成员lJAD会议引导者coordinatorl用户 information sourcel管理人员 information sourcel主办者 championl系统分析人员listenersl抄写人员 recorderlIS 员工listenersJAD会议的结果l用报告记录JAD中的调查结果，其中详细描述 了当前系统的工作方式和新系统的特征。l分析员可以从中得到用户对于新系统的期望的 详细信息。原型法l是一个反复的过程，其中分析员和用户依 据用户的反馈构建一个信息系统的初步版
10、 本。l反复的过程: l构建, 使用, 评估何时使用原型方法？l用户需求不清楚或者不能很好的理解。l一个或者少数用户和其他利益相关者涉入了 系统。l可能的设计很复杂，需要用具体形式来充分 地评价。l用户和分析员之间的沟通存在问题，双方要 确信系统需求尽可能详细。l快速构建可运转的系统。原型法的缺陷l逃避创建正规系统需求文档的趋势，会使系统 更难以开发成为一个完全可运行的系统。l原型可能仅适合最初用户，难以传播或适合其 他的潜在客户。l原型通常作为独立系统构建，因而忽略了共享 数据和其他已有系统交互的问题。l忽视了SDC中的检查，可能忽略了其他重要的 系统需求。敏捷方法l是一种在系统分析过程中让
11、用户不断有效参与 需求确定过程的技术。l有两种方法:1.敏捷的以使用为中心的设计2.极限编程极限编程Extreme ProgramminglXP是敏捷软件工程开发方法的代表。l“XP是一种轻量、高效、低风险、柔性、可 预测。科学而充满乐趣的软件开发方式。”Kent Beck（美国软件工程专家）XPl最初人们认为XP过于激进，但XP用自己的实 践，在一定范围内打破了软件工程必须“重量” 才能成功的观念。lXP在提高软件质量、确保开发进度等方面取 得了显著效果。XP的做法lXP专家William C.Wake：1.客户寻求一个XP开发团队启动一个项目， 客户在开发过程中与他们在一起。2.项目的早期，团队重点进行探索和发布计划 ，客户编写故事1，程序员对此进行估算，客 户选择故事开发的顺序。3.重点在编写的代码上。团队反复进行迭代式 工作。4.如果需求改变，客户及时将变化情况通知团 队，并能成功的改变团队的方向。5.每隔两周提供一个可运行 的迭代式的软件版 本。XP的适用场合lKent Beck建议：lXP应用于规模小，进度紧，需求变化大，质量 要求比较严格的项目。lXP项目成员应该在10人以内，不是异地分布，
