最新《高中地理》课件-区域自然资源综合开发利用教学讲义ppt课件 99页

《高中地理》课件-区域自然资源综合开发利用\n最早出现文明地区第二节河流的综合开发河流————孕育人类文明的摇篮黄河-长江流域印度河-恒河流域两河流域尼罗河流域\n一、河流1、流域和水系(1)流域又称供水区，指供给河流地表水源的地面集水区和地下水源的地下集水区总称，一般指地面的集水区。相邻流域间的山岭或河间高地，称为分水岭。分水岭最高点的连线，称为分水线或分水界。\n\n\n\n田纳西河\n二、田纳西河流域开发的自然背景1、田纳西河流域的基本情况：(1)位置位于美国东南部(2)流域范围发源于阿巴拉契亚山脉的西坡，在肯塔基市附近注入俄亥俄河。全长1450千米，流域面积10.6万平方千米。(3)支流分布状况(4)大坝和船闸及码头的分布看图\n\n2、自然背景(1)地形多山，地形起伏较大(上游地区为高低起伏的山地丘陵，中游地区为丘陵，下游地区为河谷平原）利：蕴藏着丰富的水力资源。弊：使得陆路交通不便，但河流航运对沟通上、下游地区之间的联系，作用十分突出。\n3632返回\n2、自然背景(2)气候亚热带地区，气候温暖湿润。降水丰富，冬末春初多降水，夏秋季降水相对较少。思考1．田纳西河水主要靠大气降水补给。根据流域的气候特征，田纳西河水量季节变化有什么特点?水量的变化随降水量的季节变化而变化，所以，冬春季相对较多，夏秋季水量相对较少。2.从农业发展角度看，夏季是作物的主要生长期，需水量较大，而冬季需量较少。田纳西河流域的气候条件对农业发展有什么影响?如何利用田纳西河的资源发展农业?第一问从灌溉不足、资源浪费等方面思考；第二问从修建水库等方式进行调整季节分配等方面考虑。\n2、自然背景(3)水系优点：水系发达，支流众多，水量丰富，大部分可通航，并通过密西西比河及其支流可通往全国大部分地区。缺点：①由于地形起伏大，河流落差较大。②水量很不稳定。思考:1、田纳西河水量的变化对航运有什么影响？2、如何改善？(答案)\n2、自然背景(4)矿产资源矿产资源丰富，主要有煤、铁、铜、磷、锌、云母等。\n\n\n位置发源注入所经地形气候水系水文状况矿产美国东南部阿巴拉契亚山地俄亥俄河山地为主亚热带湿润气候发达，支流众多水量不稳定，夏秋少，冬春多煤、铁、铜、磷、锌、云母水能丰富影响航运、农业落差水量影响知识点小结\n三、田纳西河流域的早期开发及其后果1、18世纪下半叶经济活动：有较为发达的农业，盛产棉花、马铃薯、蔬菜。影响：人口较少，人类活动对自然环境的影响不大，整个流域山青水秀，森林繁茂。2、19世纪后期流域内人口激增，开始对对其进行掠夺式开发，带来一系列生态环境与社会问题。\n流域19世纪后期的开发及其后果长期高强度种植棉花土地退化老棉花带衰落扩大耕地获取炼铜用的木炭矿山开产植被坡坏水土流失，生态环境恶化炼铜企业大量排放SO2，形成酸雨环境污染许多生物消失绝迹原因问题后果3、20世纪30年代初，成为美国最贫困的地区之一\n河流开发的自然背景决定河流的利用方式流域的开发方向小结:河流开发的自然背景的分析地形特征气候特征水文特征矿产资源的蕴藏状况\n试分析长江流域开发的自然背景地形:流经我国三大阶梯，流经青藏高原、横断山脉、四川盆地、云贵高原，长江中下游平原等地形区。气候：以亚热带季风气候为主，气候温暖湿润，降水量丰富水系：自东向西流,水量大,流程长,中上游支流众多,荆江段河道弯曲,中上游落差大.资源：水能资源、森林资源、矿产资源丰富\n四、流域的综合开发1、流域综合开发的总体构想流域开发的核心：田纳西河的开发核心：河流的利用与治理河流的梯级开发(TVA)\n\n2、流域综合开发的实施（1）防洪：防洪标准达百年一遇思考：1．田纳西河能实现梯级开发的条件是？2．田纳西河干流共修建了几座大坝？对航运的作用是？除此之外还有什么作用？地势起伏大，相对高度（落差）大（1）共修建9座。（2）抬高水位；改善通航条件（3）防洪发电；蓄水灌溉\n（2）航运：通航里程长；联系范围广；经济效益高。\n（3）发电：类型——水电、火电、核电影响——全国最大的电力供应基地——促进流域高耗能工业的发展两岸形成“工业走廊”\n（4）提高水质水库居民生活用水农业灌溉用水水生生物要求水质高污染防治水源涵养林保护库区生态环境改善\n（5）旅游：旅游业水库的修建流域环境改善带动促进建立公园、野生动物管理区、风景区、宿营地和俱乐部以及教育中心成为著名的风景旅游区带动游船制造业和经营业的发展\n（6）土地利用：自然保护区建立保护区，调整农林牧，稳定河湖线，恢复采矿区。\n田纳西河梯级开发如何促进第一、第二、第三产业的发展？对于农业，梯级开发为其种植业和林业、牧业提供了水源、消除了洪涝灾害；为水产养殖提供了场所；对于工业，水电使其污染下降，成本降低；对于第三产业，梯级开发提供了旅游资源和便利的交通。另外，三大产业还相互影响。比如：森林得到恢复，为木材加工、造纸工业提供了原料。生态环境的改善提供了旅游业的基础。方便的水运为工业提供了廉价的运输。\n流域的综合开发提高土地利用程度会导致其它五个方面的哪些变化？\n参考：土地充分利用起来发展工农业及其他行业，促进当地经济，从而推动旅游业发展；由于土地利用的扩大，植被的减少，其他生产规模的扩大，污染源的增多，势必造成河流水质下降；植被减少后水土流失加剧，河道被淤浅，河流水量季节变化增多，会使航运条件下降；河道的淤积，致使泄洪能力减弱，水库的淤积则使库容降低，从而使防洪的难度提高；土地利用的变化对发电没有造成影响。\n河流上该不该建大坝《中国国家地理》杂志2004年专门做了一期“建坝与拆坝”专题，“在河流上该不该建大坝呢？”为什么有的国家建坝热火朝天，而有的国家正在悄悄地拆坝呢？\n一.尼罗河尼罗河为沿岸地区人民从事耕种提供了哪些有利条件？①为定期泛滥的河水带来了肥沃的土壤；②为中下游两岸带来了充足的灌溉水源。\n1.阿斯旺大坝从哪些方面提高了尼罗河的利用效益？2.水能是可再生能源，水电站建成后，不仅可以永续利用水能发电，而且可以减少对矿物能源的使用，由此会产生哪些环境效益？二.阿斯旺大坝带来的经济效益阿斯旺大坝的修建，提高了尼罗河灌溉、防灾、发电、养殖、航运等利用效益。利用水电产生的环境效益主要是减少“三废”的排放。废渣的少排放可少占土地；废水的少排放，不仅节约了水资源，而且减少了水污染；废气的少排放，减少大气中的温室气体和酸雨的危害。\n1.阿斯旺大坝的不利影响主要表现在哪几个方面？2.为什么会产生这些不利影响？三.阿斯旺大坝带来的消极影响①对土地（土壤）的影响，肥力下降，加重盐渍化；②对海洋生物的影响，主要是沙丁鱼数量减少；③对海岸地形的影响，海岸遭到侵蚀后退。主要由下游及入海口处水沙减少所致，输水输沙之所以变化就是因为阿斯旺大坝修建。\n四.深入思考1.比较阿斯旺大坝的利与弊，是利大于弊还是弊大于利？阿斯旺高坝曾经是埃及民众和政府的骄傲，为埃及的现代化事业做出了积极的贡献。高坝在带给埃及人民各种益处的同时，还存在不得不正视的弊端。近年来，埃及政府正在积极采取措施，尽可能地把阿斯旺高坝的负面影响减小到最低点。阿斯旺大坝的修建还是利大于弊。\n2.阿斯旺大坝的利和弊对于其他大坝具有普遍性吗？3.我们应该怎样看待修建水库和大坝？说说前期规划和论证的重要性。阿斯旺大坝的利和弊对于其他大坝不具有普遍性。因为大坝所处的河流的水文特征不同、流域的气候条件、地形条件不同，所产生的生态效应就不同。我们应当一分为二地看待修建水库和大坝，既有利也有弊。前期规划和论证充足了、科学了，在工程完工后所造成的负面效应会降低到最小。若论证不充分、不严密，造成的后果将不堪设想。\n河流开发的自然背景决定河流的利用方式流域的开发方向河流开发的自然背景研究一般规律\n大分水岭达令河墨累河墨累－达令河流域开发结果：下游水量明显减少，生态环境恶化，在极干旱时，出现海水倒灌现象。合理利用河流水资源，避免中、上游过多引水灌溉\n1、田纳西河水量不稳定，影响到该河流的航运，特别是夏秋季节降水少，农业用水增加，水位下降较大，使吨位大的船只不能通航，大大影响客货运量。2、改善航运办法是：与农业的需求相结合，将修水库与建船闸结合起来，通过修建水库蓄水和建船闸使河流各段保持较稳定的水位，以利于通航。返回\n第九章系统开发中的需求分析与管理一、需求工程概述二、需求开发三、需求管理四、需求工程方法与工具\n一、需求工程概述用户需求产品需求系统设计系统实现单元测试集成测试系统测试验收测试\n一、需求工程概述1、什么是需求基本概念：宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。需求可能来自以下几个方面：用户（客户）、接口、环境（硬件、组织文化、政策等）。需求的重要性:开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。（Brooks：《没有银弹》）\n案例——凭空想象的需求一家大型电信设备企业有多个分支机构，A与B是研发机构，B是核心平台的研发机制，A做增值业务的研发，C是整个公司的项目管理机构，负责立项、结项与经费管理，D是销售机构。B研制出一种数据接入服务器的原型，找到A，说该产品市场前景看好，请你们开发网管软件，一起做好产品。D对A，B说“你们把软硬件都做好，我负责销售，挣到钱大家分”。于是A决定参与合作，向C提出立项，立项后，A把该项目外包给一家专业的网管软件开发公司E，预期半年完成。由于网管软件要运行于B的产品上，A与E派出开发人员到B处进行需求分析，而B的产品还是原型并不成熟，不断在变化，最终用了1年时间才完成软件开发。开发完成后，E将软件交付给A后，A付清开发费用，再把软件交付到D，D又卖给某电信局F，结果F对软件的功能不满意，要求按自己的要求修改后才能付钱。D不得不要求A修改软件，而A已经将开发费用付给了E，只能自己吞苦果，结果是A想办法把软件转让给B，希望拿出成本并且以后再也不与B合作。——这在很多大企业中都是普遍发生的事实。产品是闭门造车出来的，根本没有弄清楚要开发的系统应该是什么样的。\n一、需求工程概述2、系统需求的来源1)客户：购买系统的人。2）用户：实际使用系统进行日常业务活动的人。3）技术人员：维护系统运行的人。4）其他系统相关者。\n一、需求工程概述3、需求工程1)基本概念：在软件开发的生命周期中，与需求直接相关的活动。主要包括：需求开发和需求管理两部分内容。\n一、需求工程概述3、需求工程需求开发过程：通过调查与分析，获取用户需求并定义产品需求。需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。\n一、需求工程概述3、需求工程需求管理过程：在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。\n一、需求工程概述3、需求工程2）需求工程的主要内容：需求开发产生的主要文档为《用户需求说明书》与《软件需求规格说明书》。需求管理产生的主要文档为《需求评审报告》、《需求跟踪报告》和《需求变更控制报告》\n\n一、需求工程概述4、需求工程中的主要问题知识技能问题态度问题合作关系用户说不清楚需求双方误解需求开发人员写不好需求文档用户经常变更需求\n知识技能问题应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。当需求分析员缺乏应用域知识时，他该怎么办？–首先要有勇气做事，否则连实践的机会都没有。–其次应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。\n态度问题相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。\n合作关系如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧 ……。对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训\n合作关系用户在需求工程中的“权利”–1.有权要求开发方派遣资质合格的需求分析员和相关人员。–2.有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂得需求文档。–3.有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。–4.如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。用户在需求工程中的“义务”–1.以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。–2.乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答需求分析员的问题。–3.在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的材料。–4.与需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿。\n用户说不清楚需求用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。有些用户虽然心里明白想要什么，但却说不清楚需求。系统分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。无论是什么原因导致用户说不清楚需求，系统分析员必须设法搞清楚用户真正的需求，这是系统分析员的职责，也是职业的挑战。\n双方误解需求了解需求的过程中会发生“问非所求，答非所问”的事情。\n开发人员写不好需求文档需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。要想写出好的需求文档，前提条件是把需求调查工作做好。企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。\n用户经常变更需求需求变更通常会对项目的进度、人力资源、经费产生很大的影响。如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。\n用户经常变更需求需求变更通常会对项目的进度、人力资源、经费产生很大的影响。如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。\n一、需求工程概述5、需求工程的层次开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。–“被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。–“主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。–“领先型”是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。\n二、需求开发1、需求的获取一般地，分析员首先要通过与用户面谈、问卷调查等方式获取需求，通过对这些需求进行记录与定义并进行讨论与修正，将未解决的问题放在一个条目中，等下一次调查解决。通过多次迭代最终得到完整的系统需求。1)需求获取规程现代软件系统分析与开发一般都遵循一定的范式和规程。在需求调查阶段，一般按以下规程进行：\n目的获取用户的需求信息，经过分析产生《用户需求说明书》角色与职责系统分析员调查分析需求，用户提供必要的需求信息启动准则系统分析员已经确定输入任何与用户需求相关的材料主要步骤1．准备调查2．调查与记录3．分析需求信息4．撰写《用户需求说明书》5．需求确认输出《用户需求说明书》结束准则完成《用户需求说明书》并确认无误度量统计工作量和文档规模，上报项目经理\n二、需求开发1、需求的获取2)调查准备(1)需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。问题表可以有多份，随着调查的深入，问题表将不断地被细化。根据经验，用户通常没有耐心回答复杂的论述题，所以问题表应当以“选择题”和“是非题”为主。制定问题表最简便的方法就是从《用户需求说明书》的模板中提取需求问题。\n二、需求开发1、需求的获取2)调查准备(2)确定调查方式，调查的方法有：问卷调查复查现有报表和业务过程的描述与用户面谈与讨论观察与记录业务过程与同行或专家交谈，听取意见与建议分析已经存在的软件系统，提取需求从行业标准和规则中提取需求到Internet上查找相关信息\n二、需求开发1、需求的获取2)调查准备(2)确定调查方式，辅助调查的方法有：可通过原型的方法获取需求，这对于“说不出需求”的用户尤其适用。JAD（联合应用开发会议）是加快调查的重要方法，即将相关人员全部召集在一起参加单一会议直接解决需求分析问题。\n二、需求开发1、需求的获取2)调查准备(3)需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型的用户。\n二、需求开发1、需求的获取3)调查与记录准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息。通过完成计划的调查任务，系统分析员获取用户需求并将其正确的记录。记录形式一般为表格需求标题调查方式调查人调查对象时间、地点需求信息记录是什么？不是什么？为什么？\n二、需求开发1、需求的获取3)调查与记录面谈中要注意的问题：注重时间与礼节，建立与用户的良好关系事先了解用户的身份、背景从宏观入手，然后细化，而不是象侦探那样从蛛丝马迹着手轻松的气氛，不轻意打断用户的谈话不为用户添加必要的麻烦，但也不要因怕麻烦而降低调查力度\n二、需求开发1、需求的获取3)调查与记录调查的技术——问答分析法：通过提问与回答了解系统需求。最主要的问题是：“是什么”和“为什么”。每个需求都用陈述句说明“是什么”，如果表达不清，则加上“不是什么”；如果“是”与“不是”不是理所当然的，就必须加上解释“为什么”——目标：获得正确、清晰的需求。其他常见问题：需求存在二义性吗？需求文档的上下文有矛盾吗？需求完备吗？需求是必要的吗？需求可实现吗？需求可验证吗？需求的优先级确定了吗？\n二、需求开发2、需求冲突的解决需求从获取渠道收集到以后，可能产生不一致的地方。解决原则主要有：当客户需求与开发方预计需求冲突时，以客户需求为主。用户间需求冲突则以级别大的用户需求为准，同级则少数服从多数。多个客户以出钱多的客户需求为准\n二、需求开发3、用户需求说明书对收集到的用户需求进行分析、归纳与总结，然后根据一定的格式撰写《用户需求说明书》，调查过程中的中间资料可作为附件。用户需求说明书完成后，应邀请专家与用户对其进行评审，使其最大限度地符合用户的真实意愿。之后才能进行进一步的需求分析与定义，产生《软件需求规格说明书。》\n（模板）\n二、需求开发4、需求分析与定义1)概述需求分析的结果是通过建立系统的逻辑模型来定义需求。逻辑模型：详细展示系统要完成的功能，而不依赖具体技术的模型。物理模型：表明系统是如何真正实现的模型。\n二、需求开发4、需求分析与定义1)概述结构化分析方法兴盛的时期，软件系统的开发过程是从物理模型到逻辑模型，再从逻辑模型到新的物理模型的过程。这种方法可以保证系统分析能按步就班的完成，但缺点是a)系统分析时间较长，要花费更多时间与资金去分析、了解和记录旧系统的运行，提炼出运行逻辑。b)新系统往往是旧系统的简单自动化，不论原系统的效率有多低，是否合理，都原样地进入新系统，并不能通过信息化改造原来的业务管理流程，提高管理水平。不适合于全新系统的开发，特别是一些WEB项目，如电子商务方面的项目开发，这些项目没有可参考的旧系统。\n二、需求开发4、需求分析与定义1)概述现代的需求分析过程，往往是直接在对用户需求进行收集地过程中直接产生新系统的逻辑模型（直接通过对比要解决的商业问题和软件需要实现的功能）。系统分析员只有在需要理解商业业务流程时才去检查现有系统。系统分析员的焦点是：以新系统为中心。提出创新的问题解决之道是系统分析员的素质要求之一。此外，新系统的引入还可能对组织原来的业务流程进行改造——BPR。两种思维方式：还没有坏，就不需要修理总有一种更好的解决方法\n案例——Ford的业务流程重组20世纪80年代，福特北美分部的帐目支付部门雇佣了500多名员工。为了提高效率，公司决定引入信息系统，最初的目标是提高20%的效率。在项目小组进行系统分析时发现，马自达公司的帐目支付部门只有5名员工。虽然福特比马自达大得多，但相对于而言也达不到100倍的业务量。在借鉴了马自达的业务过程的同时，项目组设计了全新的自动化系统，将帐目支付功能包含在更大的购买功能中，实现了从购买到支付全程跟踪的自动化，项目结束时，只需求100人即可完成原来500多人才能完成的帐目支付功能，大大超出了预计。\n二、需求开发4、需求分析与定义2)系统分析规程目的定义准确的产品需求，产生《产品需求规格说明书》角色与职责系统分析员定义产品需求，用户确认产品需求启动准则《用户需求说明书》撰写完成输入《用户需求说明书》主要步骤1．细化和分析用户需求2．撰写《产品需求规格说明书》3．需求确认输出《产品需求规格说明书》结束准则《产品需求规格说明书》撰写完成并通过确认（评审与承诺）度量系统分析员统计工作量与文档规模，上报项目经理\n二、需求开发4、需求分析与定义2)系统分析规程第一步：细化并分析用户需求–需求分析员首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。建模分析产生的文档可以作为《产品需求规格说明书》的附件。补充说明：建模分析的技术难度比较高，分析员应当根据自身水平进行取舍。第二步：撰写产品需求规格说明书–需求分析员按照指定的文档模板撰写《产品需求规格说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当撰写《软件需求规格说明书》和《硬件需求规格说明书》。第三步：进行需求确认–项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《产品需求规格说明书》，尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿。–需求评审之后，开发方和客户方的责任人对《产品需求规格说明书》作书面承诺。\n二、需求开发4、需求分析与定义3)需求分析方法文字描述（可从问答法直接获得）模型描述有些时候用语言描述某个问题特别费劲，而采用图形则使人一目了然，所谓“一图低千言”就是这个道理。在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。因此在需求分析中常使用建模的方法来定义需求。\n二、需求开发4、需求分析与定义3)需求分析方法模型描述(1)需求建模:就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。\n二、需求开发4、需求分析与定义3)需求分析方法模型描述(2)结构化分析法结构化分析方法并不是明确地由涉及这个主题的一篇文章或者一本著作引入的，它也不是被所有使用者一致采用的单一方法。相反地，它是几乎发展了20多年的一个混合物。结构化分析方法在70年代和80年代非常流行，相关论著很多。Pressmen对结构化分析方法作了高度概括——“一个中心三种图”：\n数据字典实体－关系图数据流图状态－变迁图\n二、需求开发4、需求分析与定义3)需求分析方法模型描述(3)面向对象分析法面向对象分析设计（OOAD）方法兴起于20世纪80年代，从90年代起至今它已经在分析设计领域占据了无可争议的主流地位。面向对象分析设计领域有一些比较著名的学派，如：lCoad和Yourdon学派。lBooch学派。lJocobson学派。lRumbaugh学派。UMLRationalRose\n二、需求开发4、需求分析与定义3)需求分析方法模型描述(4)建模原则——恰当地使用图形符号现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。–世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。\n二、需求开发5、产品需求规格说明书1)《用户需求说明书》与《产品需求规格说明书》的主要区别与联系前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。\n二、需求开发5、产品需求规格说明书2)应按一定规范书写\n（模板）\n二、需求开发5、产品需求规格说明书3)书写原则（1）正确（2）清楚（3）无二义性（4）一致（5）必要（6）完备（7）可实现（8）可验证（9）确定优先级（10）阐述“做什么”而不是“怎么做”\n三、需求管理1、需求验证系统分析员往往认为他们了解与掌握了用户的需求，然而却没有真正把握商业过程的最精妙之处。在项目早期发现和解决这方面的问题，比到了开发与实现阶段解决的代价要小百倍。发现和解决需求分析问题的手段是需求验证。类似于房屋建造，需求分析相当于设计蓝图，在进行设计时可能会存在问题，如果在正式建造前不加以解决可能导致完全的失败，在建造之前首先要验证图纸的正确性。\n三、需求管理1、需求验证1)需求验证过程需求确认是指开发方和客户方共同对《产品需求规格说明书》进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”。\n三、需求管理1、需求验证2)需求评审要注意的问题：l需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。主持人应当控制节奏，将重要内容放在前面。l需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。l开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。l开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。控制争议不变为争吵，争吵不仅对评审工作没有好处，而且会无意中伤害同事间及与客户的关系，影响项目组下一步的工作。人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。\n三、需求管理1、需求验证3)需求承诺需求承诺是指开发方和客户方的责任人对通过了正式技术评审的《产品需求规格说明书》作出承诺，该承诺具有商业合同的效果。本《产品需求规格说明书》建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该《产品需求规格说明书》开展。如果需求发生变化，我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。甲方签字乙方签字人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。\n三、需求管理2、需求验证需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式：–正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。–逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。–正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。\n\n三、需求管理3、需求变更管理1)需求发生变更的起因：–随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。–市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。“没有软件系统开发中用户需求的变化不超过3次”?\n三、需求管理3、需求变更管理2)需求变更管理：提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。需求变更控制的目的：如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。如果需求变更带来的坏处大于好处，那么拒绝变更。需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”：-开发方与客户方达成“事不过三”的约定（符合中国人的习惯），即允许客户变更三次需求；如果客户第四此变更需求，开发方有权拒绝，除非客户愿意补偿开发方的损失。-如果事先没有“游戏规则”的话，开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时修改需求。\n四、需求工程的技术与工具