第四章软件需求工程

1、第四章第四章 软件需求工程软件需求工程软件工程课件软件工程课件1第四章软件需求工程武侠小说中，任何一个大侠都不会在不了解敌人武侠小说中，任何一个大侠都不会在不了解敌人的时候出手！的时候出手！2第四章软件需求工程【情景 1】 小贩 A：我这里有李子，您要买李子吗？ 老太太：我正要买李子，你这个李子好吗？ 小贩 A：我的李子又大又甜特别好吃。 老太太：（来到水果面前仔细看了看，李子果然是又大又红。就摇摇头）我不买。 小贩小贩 A 不知道老太太到底想买什么口味的不知道老太太到底想买什么口味的李子，所以没有卖出去。李子，所以没有卖出去。3第四章软件需求工程【情景 2】 小贩 B：我这里是李子专卖店，有

2、大的，有小的，有酸的，有甜的，有国产的，有进口的，您到底要什么样的李子？ 老太太：要买酸李子。 小贩 B：我这堆李子啊特别酸，您要不要尝一口。 老太太：（尝了一口，酸得受不了）真酸，来一斤。 小贩小贩 B 探知了老太太的要求，并迎合其心理，取得了一探知了老太太的要求，并迎合其心理，取得了一定的销售成绩定的销售成绩 4第四章软件需求工程【情景 3】 小贩 C：老太太，别人都买甜的，您为什么买酸李子呀？ 老太太：我的儿媳妇怀孕了，想吃酸的。 小贩 C：您对您儿媳妇真好，您儿媳妇喜欢吃酸的，就说明她要给您生个孙子，所以您天天给她买李子吃，说不定能生出一个大胖小子。 老太太：（高兴地）你可真会说话。

3、小贩 C：您知不知道孕妇最需要什么样的营养？ 老太太：我不知道。 小贩 C：孕妇最需要的是维生素，因为她要供给胎儿维生素。您知不知道什么水果含维生素最丰富？ 老太太：不知道。 小贩 C：这水果之中，猕猴桃含维生素是最丰富的，如果您天天给儿媳妇买猕猴桃补充维生素，儿媳妇一高兴，说不定就生出一对双胞胎来。 老太太：（很高兴）不但能够生胖小子还能生双胞胎，那我就来一斤猕猴桃。 小贩 C：我每天都在这里摆摊，而且水果都是新鲜进来的，您下次再来呢，我再给您优惠。 5第四章软件需求工程66第四章软件需求工程例2：需求没有满足完备性和一致性，就开始了设计。7第四章软件需求工程项目失败的原因分析No. Top

4、 10 Factors 平均值平均值 1 Inadequate requirements specification 不充分的需求规范不充分的需求规范 4.5 2 Changes in requirements 需求的改变需求的改变 4.3 3 Shortage of systems engineers 缺乏系统工程师缺乏系统工程师 4.2 4 Shortage of software managers 缺乏了解软件特性的经理人缺乏了解软件特性的经理人 4.1 5 Shortage of qualified project managers 缺乏合格的缺乏合格的项目经理项目经理 4.1 6 S

5、hortage of software engineers 缺乏软件工程师缺乏软件工程师 3.9 7 Fixed-price contract 固定价合同固定价合同 3.8 8 Inadequate communications for system integration 系统集成系统集成阶段阶段, 交流与沟通不充分交流与沟通不充分 3.8 9 Insufficient experience as team 团队缺乏经验团队缺乏经验 3.6 10 Shortage of application domain experts 缺乏应用领域缺乏应用领域专家专家 3.6 Scale: 5 = Ve

6、ry Serious 3 = Serious 1 = No Serious Source: Carnegie-Mellon University, Software Engineering Institute8第四章软件需求工程9第四章软件需求工程10第四章软件需求工程11第四章软件需求工程12第四章软件需求工程13第四章软件需求工程14第四章软件需求工程15第四章软件需求工程16第四章软件需求工程17第四章软件需求工程18第四章软件需求工程19第四章软件需求工程20第四章软件需求工程21第四章软件需求工程什么是工程?工程的定义工程的定义:工程就是运用科学知识，对现实问题提供性能价格比合理的解

7、决方案。 性价比合理：性价比合理：涉及性能价格的权衡，尤其是在资源的使用方面。 解决方案：解决方案：工程是有创造性和实效性的。 现实问题：现实问题：问题是受人们关注的。 科学知识：科学知识：用到应用科学中的分析方法。2222第四章软件需求工程 软件成本低于物理设备成本 软件易修改 计算机比物理设备可靠性高 软件的正确性可形式化的证明 软件重用提高安全性和可靠性 计算机系统同机械系统相比风险更低2323第四章软件需求工程错误认识错误认识A general statement of objectives is sufficient to begin writing programs we can

8、fill in the details later需求不清楚就进入编程阶段，期望以后修改。更需求不清楚就进入编程阶段，期望以后修改。更多的情况下是边写边修改多的情况下是边写边修改Project requirements continually change, but change can be easily accommodated because software is flexible软件调节和改变是很灵活的，任何需求的变更都软件调节和改变是很灵活的，任何需求的变更都可容易地在软件中反映出来可容易地在软件中反映出来这些认识多来自极小项目的开发经验，当你面对这些认识多来自极小项目的开发经验，

9、当你面对一个中大型项目时必须彻底改变这些错误观念！一个中大型项目时必须彻底改变这些错误观念！24第四章软件需求工程需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。 注意，和所有工程学科一样，需求工程并不是以零星偶发的、随机的或无计划的方式进行，而是代之以已证明方法的系统化应用。2525第四章软件需求工程对大多数人来说，若要建一幢20万美元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改

10、会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” 。 （Le ffingwell 1997）2626第四章软件需求工程问题的严重性：对软件的依赖不断增加：汽车，手机，Web Services，软件成本的比重加大：Boeing777软件项目失败带来巨大浪费：1997 GAO 报告- 6年内烂尾软件项目耗资1470亿美元 General Accounting Office(美国美国)总审计局总审计局2727第四章软件需求工程问题的严重性：软件失败的严重后果：Ariane 5: 3.7亿美元的损

11、失；亿美元的损失；2828第四章软件需求工程问题的成因： 软件质量认证的高成本：Boeing 777 40%的软件成本用于测试 以修正软件缺陷为目的的软件重写：Motorola: 曾将60%-80% 的软件费用用于重写 需求的频繁变化：Capers Jones（1994）在报告中称扩展需求对百分之八十的管理信息系统项目和百分之七十的军事软件项目造成风险。2929第四章软件需求工程然而，早期的建模和分析是非常重要的 可以节省纠错成本：晚期修改可能会使成本高出200倍当然，仅仅有早期的建模和分析是不够的 所有项目参加者均需了解系统需求 所有风险承担者均需对需求达成共识 需透彻了解系统运作的背景 需

12、透彻了解系统设计过程及其背景 当需求发生演变时，要及时更新3030第四章软件需求工程31 软件需求工程划分为需求开发和需求管理软件需求工程划分为需求开发和需求管理31第四章软件需求工程管理 32n通常的需求管理活动包括 ：定义需求基线（迅速制定需求文档的主体）。评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。以一种可控制的方式将需求变更融入到项目中。使当前的项目计划与需求一致。基于估计变更需求所产生影响的基础上，协商新的承诺（约定）。让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。在整个项目过程中跟踪需求状态及其变更情况。 32第四章软件需求工程需求开发和需求管

13、理之间的界限3333第四章软件需求工程3434第四章软件需求工程1. 分析问题和解决问题的能力2. 人际沟通及交流能力3. 软件工程知识和技能4. 应用领域有关知识5. 书面语言组织和表达能力6. 3535第四章软件需求工程着手点是有待解决的“问题”出现例如： 对系统现状不满； 有新的商机出现； 有可能节能、降耗、省时等。3636第四章软件需求工程需求工程师促进变化的发生，要完成以下工作： 确定“问题”及“机会” 要解决的问题是什么? (问题的界定) 问题出在何处? (了解问题的领域及上下文) 问题与谁相关? (确定干系人-Stakeholder) 为什么解决该问题? (确定干系人的目标) 软

14、件系统如何促进问题的解决? (搜集情景实例) 解决问题的期限? (确定开发活动的约束和限制) 影响问题解决的因素有哪些? (确定可行性和风险) 成为问题领域的专家 拥有更多的机会和解决问题的方案3737第四章软件需求工程ACM/IEEE 职业道德规范:PUBLIC 保护公众利益。CLIENT AND EMPLOYER 在保护公众利益的前提下，为客户及雇主的最高利益服务。PRODUCT 尽可能令你的产品符合行业的最高标准。JUDGEMENT 在进行职业判断时，保持正直及独立性。MANAGEMENT 对软件开发和维护的管理应遵循和提倡符合职业道德。PROFESSION 在符合公众利益的前提下，推进

15、职业的正直性和声誉。COLLEAGUES 对同事要持公正和支持的态度。SELF 毕生坚持学习并在职业生涯中提倡职业道德。38 38第四章软件需求工程 与需求工程相关的职业规范: Competence 永不对你的工作能力说谎。 Confidentiality 坚持为你的客户及合作者保密。 Intellectual property rights 保护他人的新观点及设计，即知识产权。 Data Protection 在处理个人信息时注意遵守相关法令保护数据。3939第四章软件需求工程 倾听的能力访问能力分析能力协调能力观察能力书写能力40组织能力建模能力交际能力创新能力领域知识40第四章软件需求工

16、程 每一个“人造物”都是一个内部环境与外部环境的“接口”。这里内部环境指人造物本身的设计组成。外部环境指人造物的周遭及其作用环境。对这个接口的描述即是需求。 Herbert Simon, 1969 需求, 即是人们要解决的某个问题或达到某种目的的需要。是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。需求将作为系统开发，测试，验收，提交的依据。 IEEE 610.12, 19904141第四章软件需求工程 理解问题需求获取需求获取 问题的形式化表示形式规约，形式建模形式规约，形式建模 就问题性质达成共识验证验证, 冲突及矛盾消解冲突及矛盾消解, 磋商磋商需求管理需求管理

17、 维护双方的共识维护双方的共识4242第四章软件需求工程需求描述必须给出为什么需要这样一个系统。 Ross, 1977通常，需求描述系统要做什么，而不是怎么做。但是，二者不太容易区分，上一个抽象层次的“怎么做”经常在下一个抽象层次上转化为“做什么”。Jackson给出的稍为清楚的解释：“为什么”和“做什么”是指系统的设计目的，是置身系统外部，对应用领域性质的描述。“怎么做”是指系统的内部结构和行为。 Jackson, 19954343第四章软件需求工程 含糊的需求描述： “工资总额由上一条记录获得” “所有客户都具有同一控制域“ 错误的需求描述： “所有系统将九月作为财政年度的起始时间” 不完

18、整的需求描述： “出错信息显示在屏幕的第24行“ 矛盾或不一致的需求描述： “C=A+B”；“C=A-B” 无法测试的需求： “系统应具有友好的界面“4444第四章软件需求工程问题域问题域 Problem Domain问题域问题域 接口接口 解系统解系统分析分析规格说明规格说明设计设计45第四章软件需求工程问题域的类型问题域的类型数据为主数据为主交互为主交互为主算法为主算法为主气象预报系统气象预报系统收银机系统收银机系统电梯控制系统电梯控制系统工资系统工资系统文字处理系统文字处理系统文件转换系统文件转换系统手机定位系统手机定位系统A AB BC CD DE EF FG G46第四章软件需求工程

19、软件需求包括三个不同的层次业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求 (user requirement) 描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。功能需求(functional requirement)（包括非功能需求）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。4747第四章软件需求工程客戶由客戶的Goal 找出流程出口押汇转账 (Domain)世华银行外汇业务出口托收48第

20、四章软件需求工程看单人员结账人员柜台人员收件 - 审单审单 -解款解款 -呈报审单解款收件呈报IS 使用使用 表示表示之之49第四章软件需求工程50 管理人员或市场分析人员管理人员或市场分析人员确定软件的业务需求，使公司确定软件的业务需求，使公司运作更加高效（对信息系统而运作更加高效（对信息系统而言）或具有很强的市场竞争力言）或具有很强的市场竞争力（对商业软件产品而言）。（对商业软件产品而言）。 所有的用户需求必须所有的用户需求必须与业务需求一致。用户需与业务需求一致。用户需求使需求分析者能从中总求使需求分析者能从中总结出功能需求以满足用户结出功能需求以满足用户对产品的要求从而完成其对产品的要

21、求从而完成其任务，而开发人员则根据任务，而开发人员则根据功能需求来设计软件以实功能需求来设计软件以实现必须的功能。现必须的功能。50第四章软件需求工程4. 软件需求的分类软件需求的分类 功能需求功能需求是开发人员必须实现的软件功能。功能需求可是开发人员必须实现的软件功能。功能需求可以在多种不同的抽象层次上来表达，这使得导以在多种不同的抽象层次上来表达，这使得导出需求过程比较复杂和困难：出需求过程比较复杂和困难：a) Physical behaviora) Physical behaviorb) Input-output relationshipb) Input-output relations

22、hipc) Observable statesc) Observable statesd) User interfaced) User interface51第四章软件需求工程4. 软件需求的分类软件需求的分类 非功能需求非功能需求非功能需求是功能需求的补充，它描述了系统非功能需求是功能需求的补充，它描述了系统完成功能实现的补充和约束条件。如产品必须完成功能实现的补充和约束条件。如产品必须遵从的标准、国际规范和合约；外部界面的规遵从的标准、国际规范和合约；外部界面的规范；性能需求如：系统运行速度范；性能需求如：系统运行速度(Speed)(Speed)，可靠，可靠性性(Reliability)(

23、Reliability)，容量，容量(Capacity)(Capacity)，可用性，可用性(Availability),(Availability),可使用性可使用性(Usability)(Usability)；其它；其它质量属性如：质量属性如：快捷性、简易性、直觉性、健壮快捷性、简易性、直觉性、健壮性等。性等。52第四章软件需求工程4. 软件需求的分类软件需求的分类 非功能需求非功能需求a) Responsea) Responseb) Accuracyb) Accuracyc) Frequencyc) Frequencyd) Capacityd) Capacitye) Throughput

24、e) Throughputf) Defect ratesf) Defect ratesg) Modifiabilityg) Modifiabilityh) Supportabilityh) Supportability53第四章软件需求工程4. 软件需求的分类软件需求的分类 设计约束设计约束设计约束是真正意义上的非功能约束，它们约束系统怎设计约束是真正意义上的非功能约束，它们约束系统怎样被构建而不是系统做什么。设计约束的一般内容为样被构建而不是系统做什么。设计约束的一般内容为 解系统将在其上运行的目标机器解系统将在其上运行的目标机器 底层的体系结构底层的体系结构 - - 分布式的或本地的分布式

25、的或本地的 系统运行的内存大小系统运行的内存大小 应当采用的任何前端图形用户界面应当采用的任何前端图形用户界面(GUI)(GUI)程序包程序包 系统运行的操作系统系统运行的操作系统 应当使用的编程语言应当使用的编程语言 其它应集成的软件包如数据库管理系统其它应集成的软件包如数据库管理系统(DBMS)(DBMS) 必须应用的开发标准必须应用的开发标准 应采用的设计方法等等应采用的设计方法等等54第四章软件需求工程4. 软件需求的分类软件需求的分类 设计约束设计约束a) Languagea) Languageb) OSb) OSc) SW to HW interfacec) SW to HW in

26、terfaced) Algorithmd) Algorithme) Powere) Powerf) Timingf) Timingg) Memoryg) Memoryh) Processor utilizationh) Processor utilizationI) Weight etcI) Weight etc55第四章软件需求工程5656第四章软件需求工程Requirement activities in the SE 5757第四章软件需求工程瀑布模型瀑布模型核心思想：系统开发是逐步求精的过程各步骤相对独立，便于管理存在的问题：忽略了需求的动态性需求完成后，用户对项目的参与即停止需求描述

27、与设计分开不支持原型的使用和软件重用（Loucopoulos & Karakostas, 1995）5858第四章软件需求工程适用范围：用于获取关于系统用户界面的需求用于检验设计方案的可行性，或探讨系统性能问题存在的问题：用户将原型误认为最终系统原型所反映的系统是不全面的（Loucopoulos & Karakostas, 1995, p30）5959第四章软件需求工程6060第四章软件需求工程螺旋模型主要用于风险分析每一轮开发活动具体包括:制定下一轮计划决定设计目标和限制条件评估候选方案, 风险降解产品开发需求工程有关步骤为：需求风险分析规划设计可以减少需求变更所带来的风险存

28、在的问题：无法应付不可预见的需求变化6161第四章软件需求工程基本原则： 减少沟通障碍 程序员与客户直接交流 减低繁重的文档负担 文档代价昂贵但用途有限 对开发人员给予充分信任 无需运用花样翻新的过程模型给与提示 响应客户要求 而非严格遵循合同条文62缺点： 依赖程序员的记忆力 源代码是难于维护的 依赖口头交流 易发生误解 假定只有唯一的客户代表 不可能反映多视角 制作短期计划无长期及前瞻性规划62第四章软件需求工程需求获取（获取哪些内容？）需求获取（获取哪些内容？）1) 定义需求开发过程定义需求开发过程2) 定义项目愿景和范围定义项目愿景和范围3) 确定用户群确定用户群4) 选择用户代理人选

29、择用户代理人5) 确定用例确定用例6) 确定系统事件和响应确定系统事件和响应7) 描述软件的功能和性能描述软件的功能和性能8) 指明软件与其他系统元素的接口指明软件与其他系统元素的接口9) 建立软件必须满足的约束建立软件必须满足的约束63第四章软件需求工程需求获取的主要步骤需求获取的主要步骤开发高层的业务模型开发高层的业务模型u理解应用领域，即目标软件的应用环境。如理解应用领域，即目标软件的应用环境。如银行、电信公司、书店等。银行、电信公司、书店等。u一旦系统分析人员对该领域有了充分了解，一旦系统分析人员对该领域有了充分了解，就可以建立一个业务模型，描述用户的业务就可以建立一个业务模型，描述用

30、户的业务过程，确定用户的初始需求。过程，确定用户的初始需求。u分析出企业的业务实体，开发或选取必需的分析出企业的业务实体，开发或选取必需的构件，建立稳定的软件体系结构。构件，建立稳定的软件体系结构。 64第四章软件需求工程客戶由客戶的Goal 找出流程出口押汇转账 (Domain)世华银行外汇业务出口托收65第四章软件需求工程Scenario 叙述 客戶世华总管理处 焦点焦点: : 世世华华內部內部 国外银行中央银行看单人员结账人员柜台人员出口托收66第四章软件需求工程6767第四章软件需求工程需求工程活动不总是顺序进行问题描述不总是先于解决方案描述在系统开发的任何阶段描述问题均是有益的需求工

31、程是在各开发阶段持续进行的一系列活动问题陈述无法追求完美需求模型是对世界的近似表示将包括不精确和不一致性会省略某些信息细致的分析将降低导致严重问题的风险但风险永不可能降解为零6868第四章软件需求工程追求规约的描述会降低性价比 需求分析是有开销的 不同的项目，性价比的平衡点是不同的问题描述永不可能是固定的 变化是无法避免的，因此应纳入计划之中 对变化的处理应定期进行6969第四章软件需求工程不适当的需求引起的一些风险不适当的需求引起的一些风险无足够用户参与无足够用户参与 用户参与不多会导致产品无法被接用户参与不多会导致产品无法被接受受用户需求的不断增加用户需求的不断增加 用户需求的增加带来过度

32、的耗用户需求的增加带来过度的耗费和产品质量的降低费和产品质量的降低模棱两可的需求说明模棱两可的需求说明 将导致时间的浪费和返工将导致时间的浪费和返工不必要的特性不必要的特性 用户增加一些不必要的特性和开发人用户增加一些不必要的特性和开发人员画蛇添足员画蛇添足过分精简的规格说明过分精简的规格说明 过分简略的需求说明以致遗漏过分简略的需求说明以致遗漏某些关键需求某些关键需求忽略用户分类忽略用户分类 忽略某类用户的需求将导致众多客户忽略某类用户的需求将导致众多客户的不满的不满不准确的计划不准确的计划 不完善的需求说明使得项目计划和跟不完善的需求说明使得项目计划和跟踪无法准确进行踪无法准确进行70第四

33、章软件需求工程不适当的需求引起的一些风险不适当的需求引起的一些风险无足够用户参与无足够用户参与 客户经常不明白为什么收集需求和确客户经常不明白为什么收集需求和确保需求质量需花费那么多工夫，开发保需求质量需花费那么多工夫，开发人员可能也不重视用户的参与。很多人员可能也不重视用户的参与。很多情况下，开发人员觉得已经完全明白情况下，开发人员觉得已经完全明白了用户的需求，甚至想当然地设计了了用户的需求，甚至想当然地设计了一些用户并不认可的使用实例。尽管一些用户并不认可的使用实例。尽管原因是多方面的，尽早让具有代表性原因是多方面的，尽早让具有代表性的用户参与是可以避免一定的风险的的用户参与是可以避免一定

34、的风险的71第四章软件需求工程不适当的需求引起的一些风险不适当的需求引起的一些风险 用户需求的不断增加用户需求的不断增加 在开发过程中，若不断地补充需求，项目就会越在开发过程中，若不断地补充需求，项目就会越来越大直到超出计划和预算范围。这是软件开发来越大直到超出计划和预算范围。这是软件开发中极其普遍的问题，也是软件需求管理中重点涉中极其普遍的问题，也是软件需求管理中重点涉及的问题。及的问题。如果变更发生在设计编码以后，这样的变更会使如果变更发生在设计编码以后，这样的变更会使软件结构日渐紊乱，补丁代码使模块违背强内聚、软件结构日渐紊乱，补丁代码使模块违背强内聚、低耦合的设计原则，使程序越来越难以

35、理解和维低耦合的设计原则，使程序越来越难以理解和维护。护。要想把变更范围控制到最小，必须一开始就对项要想把变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束和成功标准给予明确目视图、范围、目标、约束和成功标准给予明确说明，并作为今后需求变更处理时的参考框架。说明，并作为今后需求变更处理时的参考框架。72第四章软件需求工程不适当的需求引起的一些风险不适当的需求引起的一些风险 模棱两可的需求说明模棱两可的需求说明模棱两可，也就是需求的模棱两可，也就是需求的“二义性二义性”，是需求说，是需求说明中最可怕的问题。明中最可怕的问题。模棱两可的需求风险承担者产生不同的期望，使模棱两可的需求风险承

36、担者产生不同的期望，使开发人员产生错误的设计，使测试人员编写不匹开发人员产生错误的设计，使测试人员编写不匹配的测试用例。配的测试用例。模棱两可的需求直接的后果就是返工。根据统计，模棱两可的需求直接的后果就是返工。根据统计，返工会耗费总开发费用的返工会耗费总开发费用的40%40%，其中，其中70%70%80%80%是是由需求方面的错误造成的。由需求方面的错误造成的。认真、高质量的需求评审可以消除大部分的模棱认真、高质量的需求评审可以消除大部分的模棱两可型的错误。两可型的错误。73第四章软件需求工程不适当的需求引起的一些风险不适当的需求引起的一些风险 不必要的特性不必要的特性“画蛇添足画蛇添足”是

37、指开发人员力图增加一些是指开发人员力图增加一些“用户用户可能欣赏可能欣赏”，但需求规格中并未涉及的新功能；，但需求规格中并未涉及的新功能；这类新功能可能很花哨但用户并不认为很有用，这类新功能可能很花哨但用户并不认为很有用，但实现却耗费可观。相反的情况也存在，即客户但实现却耗费可观。相反的情况也存在，即客户会提出这些花哨的但缺乏实用价值的需求，需求会提出这些花哨的但缺乏实用价值的需求，需求分析人员应做的是去说服客户避免将资源浪费在分析人员应做的是去说服客户避免将资源浪费在这些无关紧要的功能上。这些无关紧要的功能上。与此相关的做法是，在可能的情况下，为客户提与此相关的做法是，在可能的情况下，为客户

38、提供新的解决方案，在允许的资源和技术可行性之供新的解决方案，在允许的资源和技术可行性之间求得平衡。间求得平衡。74第四章软件需求工程不适当的需求引起的一些风险不适当的需求引起的一些风险 过分精简的规格说明过分精简的规格说明 有时客户并不明白需求分析如此重要，于是只作有时客户并不明白需求分析如此重要，于是只作一份简略之至的规格说明。仅涉及产品的某些概一份简略之至的规格说明。仅涉及产品的某些概念，其它让开发人员在项目进展中去完善，结果念，其它让开发人员在项目进展中去完善，结果是为了管理上的某种要求，开发人员先建立产品是为了管理上的某种要求，开发人员先建立产品结构、甚至是完成编码，然后再补充需求说明

39、。结构、甚至是完成编码，然后再补充需求说明。大多数情况下，这会增加开发过程的迂回、返工。大多数情况下，这会增加开发过程的迂回、返工。75第四章软件需求工程不适当的需求引起的一些风险不适当的需求引起的一些风险 忽略用户分类忽略用户分类 多数产品是由不同的人使用不同的特性，使用频多数产品是由不同的人使用不同的特性，使用频繁程度、受教育程度、经验水平也不相同。如果繁程度、受教育程度、经验水平也不相同。如果产品功能设计不能满足某些关键用户需求，会大产品功能设计不能满足某些关键用户需求，会大大影响产品的用户接受度。大影响产品的用户接受度。76第四章软件需求工程不适当的需求引起的一些风险不适当的需求引起的

40、一些风险 不准确的计划不准确的计划 需求分析不充分和缺乏理解会导致计划的乐观估需求分析不充分和缺乏理解会导致计划的乐观估计；导致需求过程中软件成本估计极不准确的主计；导致需求过程中软件成本估计极不准确的主要原因为：要原因为：频繁的需求变更；频繁的需求变更；遗漏的需求；遗漏的需求；与用户交流不够；与用户交流不够；质量低下的需求规格说明；质量低下的需求规格说明；不完善的需求分析。不完善的需求分析。77第四章软件需求工程软件需求工程软件需求工程需要执行的活动需要执行的活动包括：包括：1) 确定目标系统将要面对的各类用户；确定目标系统将要面对的各类用户；2) 从各类用户的代表那里收集需求；从各类用户的

41、代表那里收集需求；3) 将顶层的需求分配到软件系统构架内定义好将顶层的需求分配到软件系统构架内定义好的软件成分中；的软件成分中；4) 协商需求的实现优先级；协商需求的实现优先级；5) 书面化；书面化；6) 审阅需求文档，以确保在认识上与用户需求相审阅需求文档，以确保在认识上与用户需求相一致。应在开发组接受需求之前解决所有分一致。应在开发组接受需求之前解决所有分岐。岐。78第四章软件需求工程可能的需求的来源可能的需求的来源 u软件需求的来源取决于目标系统的性质和开软件需求的来源取决于目标系统的性质和开发环境。典型的需求来源是：发环境。典型的需求来源是： 与潜在用户进行交谈和讨论与潜在用户进行交谈

42、和讨论 描述现有产品或竞争产品的文档描述现有产品或竞争产品的文档 系统需求规格说明系统需求规格说明 当前系统的问题报告和改进要求当前系统的问题报告和改进要求 市场调查和用户问卷调查市场调查和用户问卷调查 观察用户如何工作观察用户如何工作 用户工作的场景分析用户工作的场景分析 事件和响应事件和响应79第四章软件需求工程 如何获取需求信息？ 核心技术： 座谈，问卷，代表会议 采用人种学（Ethnographic）方法（社交嵌入系统） 采用原型法，或参与设计法（缺乏了解的系统）8080第四章软件需求工程根据所受限制不同，不同类型的应用系统能够根据所受限制不同，不同类型的应用系统能够从用户那里获取需求

43、的比例也不同。从用户那里获取需求的比例也不同。所谓限制，是指受客观物理规律的限制。所谓限制，是指受客观物理规律的限制。相对低的相对低的相对高的相对高的从人群获取需求的大概百分比从人群获取需求的大概百分比应应用用的的类类型型高度受限的高度受限的不受限制的不受限制的导弹制导系统导弹制导系统航班控制系统航班控制系统公司财务系统增强版公司财务系统增强版制造控制系统制造控制系统公司财务系统公司财务系统视频游戏视频游戏军事战略决策支持系统军事战略决策支持系统81第四章软件需求工程u如导弹制导系统更多地受物理运动定律的限如导弹制导系统更多地受物理运动定律的限制，而非人的决策。视频游戏的大部分需求制，而非人的

44、决策。视频游戏的大部分需求依赖人，因为它是一个想象出来的产品。依赖人，因为它是一个想象出来的产品。u应用受到的限制越少，能从人们那里获得的应用受到的限制越少，能从人们那里获得的需求比例越大。需求比例越大。识别用户类和用户代表识别用户类和用户代表u确定目标系统的不同用户类型；确定目标系统的不同用户类型；u挑选出每一类用户和其他项目相关者的代表挑选出每一类用户和其他项目相关者的代表并与他们一起工作并与他们一起工作; ;u商定谁是项目需求的决策者。商定谁是项目需求的决策者。82第四章软件需求工程u不同用户类可能还有不同的非功能需求。不同用户类可能还有不同的非功能需求。u不同用户类的需求甚至可能发生冲

45、突，导致需不同用户类的需求甚至可能发生冲突，导致需求不一致。求不一致。u用户类可以是人，也可以是与系统打交道的其用户类可以是人，也可以是与系统打交道的其他应用程序或硬件部件。他应用程序或硬件部件。u分析员必须在项目初期便确定产品有哪些不同分析员必须在项目初期便确定产品有哪些不同的用户类，并描述它们的特点，这样就能从每的用户类，并描述它们的特点，这样就能从每个重要用户类的代表那里获取用户需求。个重要用户类的代表那里获取用户需求。u用户代表应当自始至终参与项目，而不仅仅是用户代表应当自始至终参与项目，而不仅仅是需求分析阶段。需求分析阶段。83第四章软件需求工程描述用户需求描述用户需求需求可以看成是

46、应用与外部用户之间的交互。可需求可以看成是应用与外部用户之间的交互。可利用用例作为表达工具。利用用例作为表达工具。描述客户需求的过程如下：描述客户需求的过程如下：1) 标识参与者标识参与者 标识目标系统将支持的不同类型标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。的用户，可以是人、事件或其他系统。2) 标识场景标识场景 用场景描述目标系统典型功能的活用场景描述目标系统典型功能的活动细节，并与用户沟通，加深开发人员对应用动细节，并与用户沟通，加深开发人员对应用领域的理解。领域的理解。84第四章软件需求工程3) 标识用例标识用例 当双方确定了一组场景后，开发人当双方确定了一组场景后

47、，开发人员从该场景抽象出一组用例，描述所有可能的员从该场景抽象出一组用例，描述所有可能的情况。用例表达了系统的范围。情况。用例表达了系统的范围。4) 求精用例求精用例 细化每一个用例。引入带有出错处细化每一个用例。引入带有出错处理或带有异常处理的用例，描述系统的行为，理或带有异常处理的用例，描述系统的行为，保证需求的描述是完全的。保证需求的描述是完全的。5) 标识用例之间的关系标识用例之间的关系 描述用例之间的依赖关描述用例之间的依赖关系，提取相同功能，建立用例模型。系，提取相同功能，建立用例模型。6) 标识非功能需求标识非功能需求 包括系统性能上的约束、文包括系统性能上的约束、文档、使用资源

48、、安全性和质量等需求。档、使用资源、安全性和质量等需求。85第四章软件需求工程出口托收导出的系统流程看单人员国外银行收件审单解款呈报结账人员柜台人员世华总管理处 UML 的 Use Case 图86第四章软件需求工程草拟用户界面和其他接口草拟用户界面和其他接口建立初始用户界面，是原型方法的一种，建立初始用户界面，是原型方法的一种，目的是快速与客户沟通。目的是快速与客户沟通。客户通常在看到应用的图形用户客户通常在看到应用的图形用户界面界面（GUI）才能）才能相像到这个应用未来的样子。相像到这个应用未来的样子。87第四章软件需求工程88第四章软件需求工程分析建模分析建模常用的分析方法常用的分析方法

49、u面向数据流的结构化分析方法面向数据流的结构化分析方法 (SA)u面向数据结构的面向数据结构的Jackson方法方法 (JSD)u面向数据结构的结构化数据系统开发方法面向数据结构的结构化数据系统开发方法 (DSSD)u面向对象的分析方法面向对象的分析方法 (OOA) 等等89第四章软件需求工程结构化分析方法结构化分析方法结构化分析方法最初只是着眼于数据流。结构化分析方法最初只是着眼于数据流。扩充后，将建模技术扩展到数据建模、功扩充后，将建模技术扩展到数据建模、功能建模和行为建模，以实体能建模和行为建模，以实体- -关系图、数据关系图、数据流图和控制流图、状态流图和控制流图、状态- -迁移图为工

50、具，数迁移图为工具，数据字典为核心，从不同视点建立系统的分据字典为核心，从不同视点建立系统的分析模型。析模型。90第四章软件需求工程结构化分析的分析模型结构化分析的分析模型实体实体关系图关系图状态状态迁移图迁移图数据流数据流图图数据对象描述数据对象描述加工规格说明加工规格说明数据数据字典字典控制规格说明控制规格说明91第四章软件需求工程数据建模数据建模数据模型包括三种互相关联的信息：数据对象，数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系。描述对象的属性，描述对象间相互连接的关系。在需求分析阶段描述数据对象和它们之间的关系，在需求分析阶段描述数据对象和它们之

51、间的关系，使用了使用了E-R 图。图。例如，在教学管理中，一个教师可以教授零门、例如，在教学管理中，一个教师可以教授零门、一门或多门课程，每位学生也需要学习几门课程。一门或多门课程，每位学生也需要学习几门课程。因此，教学管理中涉及的对象有学生、教师和课因此，教学管理中涉及的对象有学生、教师和课程。程。92第四章软件需求工程教学数据模型教学数据模型学号学号 姓名姓名 专业专业 性别性别 学生学生职工号职工号姓名姓名专业专业职称职称年龄年龄教师教师课程号课程号 课程名课程名 学分学分 学时学时课程课程学号学号课程号课程号成绩成绩选课选课93第四章软件需求工程XY一个一个X与一个与一个Y相关联相关联

52、一个一个X与一个或多个与一个或多个Y相关联相关联XY一个一个X与零个或一个与零个或一个Y相关联相关联XY一个一个X与零个与零个, 一个或多个一个或多个Y相关联相关联XY一个一个X与一个与一个Y或或Z相关联相关联XYZ一个一个X与一个与一个Y与与Z相关联相关联XYZ94第四章软件需求工程功能建模和数据流功能建模和数据流n最初最初, ,结构化分析方法仅讨论数据流建模，目标结构化分析方法仅讨论数据流建模，目标系统被表示成如图所示的数据变换流程图。系系统被表示成如图所示的数据变换流程图。系统的功能体现在核心的数据变换中。统的功能体现在核心的数据变换中。外部实体外部实体外部实体外部实体外部实体外部实体外

53、部实体外部实体目标目标系统系统输入信息输入信息输入信息输入信息输出信息输出信息输出信息输出信息顶层数据流图（上下文环境图）顶层数据流图（上下文环境图）95第四章软件需求工程数据流图中的主要图形元素数据流图中的主要图形元素数据加工数据加工 (数据变换数据变换)数据源或数据潭数据源或数据潭 (外部实体外部实体)数据流数据流数据存储文件数据存储文件或或或或96第四章软件需求工程借书过程的数据流图借书过程的数据流图外部实体、数据流和数据存储都为候选对象外部实体、数据流和数据存储都为候选对象软件工程软件工程9797读者读者 1借书借书检验检验2借书借书登记登记图书图书借书证借书证检验错误检验错误借书信息

54、借书信息借阅记录借阅记录 读者信息读者信息 图书信息图书信息 借书证借书证图书图书日历日历日期日期日期日期97第四章软件需求工程分层的数据流图分层的数据流图98第四章软件需求工程实例：考务处理系统的功能实例：考务处理系统的功能问题陈述问题陈述对考生送来的报名单进行检查对考生送来的报名单进行检查;对合格的报名单编好准考证号后将准考证送给考对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站生，并将汇总后的考生名单送给阅卷站;对阅卷站送来的成绩单进行检查，并根据考试中对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者心制定的合格标准审定合格者;制作考生通知

55、单（含成绩及合格制作考生通知单（含成绩及合格/不合格标志）不合格标志） 送给考生送给考生;1) 按地区进行成绩分类统计和试题难度分析，产生按地区进行成绩分类统计和试题难度分析，产生统计分析表。统计分析表。99第四章软件需求工程功能建模的步骤功能建模的步骤 确定与系统有交互关系的外部实体。这些外部实确定与系统有交互关系的外部实体。这些外部实体即为系统的数据源和数据潭，它们与系统的交体即为系统的数据源和数据潭，它们与系统的交互构成系统的输入和输出。本例外部实体有：互构成系统的输入和输出。本例外部实体有：u考生：填交报名表，退还不合规定的报名表，考生：填交报名表，退还不合规定的报名表，得到准考证，得

56、到考试通知单。得到准考证，得到考试通知单。u阅卷站：得到考生名单，提交考试成绩单，退阅卷站：得到考生名单，提交考试成绩单，退还有误成绩单。还有误成绩单。u考试中心：提供合格标准，得到成绩分类统计考试中心：提供合格标准，得到成绩分类统计表和试题难度分析表。表和试题难度分析表。 画出顶层数据流图。画出顶层数据流图。100第四章软件需求工程顶层数据流图描述了系统与外部实体的交互，顶层数据流图描述了系统与外部实体的交互，界定了系统的边界。界定了系统的边界。考考生生考务考务处理系统处理系统考考试试中中心心阅卷站阅卷站不合格报名表不合格报名表报名表报名表准考证准考证考生通知单考生通知单成成绩绩单单合格标准

57、合格标准错误成绩单错误成绩单考考生生名名单单统计分析表统计分析表101第四章软件需求工程报名表报名表准考证准考证1 1登记登记报名表报名表2统计统计成绩成绩不合格不合格报名表报名表考生通知单考生通知单成成绩绩单单统计分析表统计分析表第第0层数据流图层数据流图考生名册考生名册合合格格标标准准考考生生名名单单错错误误成成绩绩单单102第四章软件需求工程第第1层数据流图层数据流图 (a)1.1 检查检查报名表报名表报名表报名表准考证准考证1.2编准考证编准考证号码号码不合格不合格报名表报名表考生名册考生名册考生名单考生名单合格合格报名表报名表1.3登记登记考生考生合格报名表合格报名表103第四章软件

58、需求工程第第1层数据流图层数据流图 (b)2.1检查检查成绩单成绩单2.2审定审定合格者合格者考生名册考生名册正确正确成绩单成绩单2.3制作制作通知单通知单2.4分析统分析统计成绩计成绩2.5分析试分析试题难度题难度试题得分表试题得分表考生考生通知单通知单难度难度分析表分析表合格合格标准标准分类分类统计表统计表成绩单成绩单错误错误成绩单成绩单经审定的经审定的成绩单成绩单104第四章软件需求工程行为建模行为建模n数据流图不描述时序关系，控制和事件流通过行数据流图不描述时序关系，控制和事件流通过行为模型描述。为模型描述。n在描述系统或各个数据对象的行为时，采用状态在描述系统或各个数据对象的行为时，

59、采用状态迁移图。通过描述系统或对象的状态，以及引起迁移图。通过描述系统或对象的状态，以及引起系统或对象状态转换的事件来表示系统或对象的系统或对象状态转换的事件来表示系统或对象的行为。行为。105第四章软件需求工程状态迁移图状态迁移图状态迁移图是描述系统的状态如何相应外部的信状态迁移图是描述系统的状态如何相应外部的信号进行推移的一种图形表示。号进行推移的一种图形表示。例如，有关处理器分配的进程状态迁移。例如，有关处理器分配的进程状态迁移。t2t3t4t1运行运行就绪就绪等待等待106第四章软件需求工程在状态迁移图中，在状态迁移图中， “”表示可得到的系统状态表示可得到的系统状态 “”表示从一种状

60、态向另一种状态的迁移。表示从一种状态向另一种状态的迁移。在箭头上要写上导致迁移的信号或事件的名字。在箭头上要写上导致迁移的信号或事件的名字。 S2S1S3t1t2t3t4t4t3t2t1事件事件状态状态S1 S2 S3S3S2S3S1107第四章软件需求工程Petri网网Petri网已广泛地应用于硬件与软件系统的开发网已广泛地应用于硬件与软件系统的开发中，它适用于描述相互独立、协同操作的处理中，它适用于描述相互独立、协同操作的处理系统，也就是并发执行的处理系统。系统，也就是并发执行的处理系统。Petri网简称网简称PNG (Petri Net Graph)，它有两种，它有两种结点：结点： 库所：符号库所：符号