第四章软件需求工程.ppt

第四章 软件需求工程软件工程课件Software Requirements Engineering1第四章软件需求工程武侠小说中，任何一个大侠都不会在不了解敌人的时候出手！2第四章软件需求工程情景课堂------老太太买李子记【情景 1】 小贩 A：我这里有李子，您要买李子吗？ 老太太：我正要买李子，你这个李子好吗？ 小贩 A：我的李子又大又甜特别好吃 老太太：（来到水果面前仔细看了看，李子果然是又大又红就摇摇头）我不买 小贩 A 不知道老太太到底想买什么口味的李子，所以没有卖出去3第四章软件需求工程情景课堂------老太太买李子记【情景 2】 小贩 B：我这里是李子专卖店，有大的，有小的，有酸的，有甜的，有国产的，有进口的，您到底要什么样的李子？ 老太太：要买酸李子 小贩 B：我这堆李子啊特别酸，您要不要尝一口 老太太：（尝了一口，酸得受不了）真酸，来一斤 小贩 B 探知了老太太的要求，并迎合其心理，取得了一定的销售成绩 4第四章软件需求工程【情景 3】 小贩 C：老太太，别人都买甜的，您为什么买酸李子呀？ 老太太：我的儿媳妇怀孕了，想吃酸的 小贩 C：您对您儿媳妇真好，您儿媳妇喜欢吃酸的，就说明她要给您生个孙子，所以您天天给她买李子吃，说不定能生出一个大胖小子。

老太太：（高兴地）你可真会说话 小贩 C：您知不知道孕妇最需要什么样的营养？ 老太太：我不知道 小贩 C：孕妇最需要的是维生素，因为她要供给胎儿维生素您知不知道什么水果含维生素最丰富？ 老太太：不知道 小贩 C：这水果之中，猕猴桃含维生素是最丰富的，如果您天天给儿媳妇买猕猴桃补充维生素，儿媳妇一高兴，说不定就生出一对双胞胎来 老太太：（很高兴）不但能够生胖小子还能生双胞胎，那我就来一斤猕猴桃 小贩 C：我每天都在这里摆摊，而且水果都是新鲜进来的，您下次再来呢，我再给您优惠 情景课堂------老太太买李子记5第四章软件需求工程66第四章软件需求工程例2：需求没有满足完备性和一致性，就开始了设计7第四章软件需求工程项目失败的原因分析Source: Carnegie-Mellon University, Software Engineering Institute8第四章软件需求工程9第四章软件需求工程10第四章软件需求工程11第四章软件需求工程12第四章软件需求工程13第四章软件需求工程14第四章软件需求工程15第四章软件需求工程16第四章软件需求工程17第四章软件需求工程18第四章软件需求工程19第四章软件需求工程20第四章软件需求工程21第四章软件需求工程什么是工程?工程的定义:工程就是运用科学知识，对现实问题提供性能价格比合理的解决方案。

–性价比合理：涉及性能价格的权衡，尤其是在资源的使用方面–解决方案：工程是有创造性和实效性的–现实问题：问题是受人们关注的–科学知识：用到应用科学中的分析方法2222第四章软件需求工程软件工程的特殊性Think about these:Think about these: က – 软件成本低于物理设备成本– 软件易修改– 计算机比物理设备可靠性高– 软件的正确性可形式化的证明– 软件重用提高安全性和可靠性– 计算机系统同机械系统相比风险更低23关于软件的荒谬说法( Myths )( Myths )：23第四章软件需求工程错误认识•A general statement of objectives is sufficient to begin writing programs — we can fill in the details later需求不清楚就进入编程阶段，期望以后修改更多的情况下是边写边修改•Project requirements continually change, but change can be easily accommodated because software is flexible软件调节和改变是很灵活的，任何需求的变更都可容易地在软件中反映出来这些认识多来自极小项目的开发经验，当你面对一个中大型项目时必须彻底改变这些错误观念！24第四章软件需求工程什么是需求工程？•需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。

它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持–注意，和所有工程学科一样，需求工程并不是以零星偶发的、随机的或无计划的方式进行，而是代之以已证明方法的系统化应用2525第四章软件需求工程需求工程的重要意义•对大多数人来说，若要建一幢20万美元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性然而，涉及到软件开发，人们却变得“大大咧咧”起来软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” （Le ffingwell 1997）2626第四章软件需求工程需求工程的重要意义•问题的严重性：–对软件的依赖不断增加：•汽车，，Web Services，……–软件成本的比重加大：•Boeing777–软件项目失败带来巨大浪费：•1997 GAO 报告- 6年内烂尾软件项目耗资1470亿美元 General Accounting Office(美国)总审计局2727第四章软件需求工程需求工程的重要意义•问题的严重性：–软件失败的严重后果：•Ariane 5: 3.7亿美元的损失；2828第四章软件需求工程需求工程的重要意义•问题的成因：–软件质量认证的高成本：•Boeing 777 > 40%的软件成本用于测试–以修正软件缺陷为目的的软件重写：•Motorola: 曾将60%-80% 的软件费用用于重写–需求的频繁变化：•Capers Jones（1994）在报告中称扩展需求对百分之八十的管理信息系统项目和百分之七十的军事软件项目造成风险。

2929第四章软件需求工程解决方案？？•然而，早期的建模和分析是非常重要的–可以节省纠错成本：晚期修改可能会使成本高出200倍•当然，仅仅有早期的建模和分析是不够的–所有项目参加者均需了解系统需求–所有风险承担者均需对需求达成共识–需透彻了解系统运作的背景–需透彻了解系统设计过程及其背景–当需求发生演变时，要及时更新3030第四章软件需求工程需求工程的领域划分31软件需求工程划分为需求开发和需求管理31第四章软件需求工程需求管理 32n通常的需求管理活动包括 ：¨定义需求基线（迅速制定需求文档的主体）¨评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它¨以一种可控制的方式将需求变更融入到项目中¨使当前的项目计划与需求一致¨基于估计变更需求所产生影响的基础上，协商新的承诺（约定）¨让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪¨在整个项目过程中跟踪需求状态及其变更情况 32第四章软件需求工程需求开发和需求管理之间的界限3333第四章软件需求工程SRE Engineer 需求工程师3434第四章软件需求工程Requirements Engineer 需求工程师1. 分析问题和解决问题的能力2. 人际沟通及交流能力3. 软件工程知识和技能4. 应用领域有关知识5. 书面语言组织和表达能力6. ……3535第四章软件需求工程需求工程师做什么着手点是有待解决的“问题”出现例如：–对系统现状不满；–有新的商机出现；–有可能节能、降耗、省时等。

3636第四章软件需求工程需求工程师做什么需求工程师促进变化的发生，要完成以下工作：•确定“问题”及“机会”–要解决的问题是什么? (问题的界定)–问题出在何处? (了解问题的领域及上下文)–问题与谁相关? (确定干系人-Stakeholder)–为什么解决该问题? (确定干系人的目标)–软件系统如何促进问题的解决? (搜集情景实例)–解决问题的期限? (确定开发活动的约束和限制)–影响问题解决的因素有哪些? (确定可行性和风险)•成为问题领域的专家–拥有更多的机会和解决问题的方案3737第四章软件需求工程ACM/IEEE 职业道德规范:–PUBLIC – 保护公众利益–CLIENT AND EMPLOYER – 在保护公众利益的前提下，为客户及雇主的最高利益服务–PRODUCT – 尽可能令你的产品符合行业的最高标准–JUDGEMENT – 在进行职业判断时，保持正直及独立性–MANAGEMENT – 对软件开发和维护的管理应遵循和提倡符合职业道德–PROFESSION – 在符合公众利益的前提下，推进职业的正直性和声誉–COLLEAGUES – 对同事要持公正和支持的态度–SELF – 毕生坚持学习并在职业生涯中提倡职业道德。

38职业责任 (Code of Ethics)38第四章软件需求工程职业责任 (Code of Ethics)•与需求工程相关的职业规范:–Competence – 永不对你的工作能力说谎–Confidentiality – 坚持为你的客户及合作者保密–Intellectual property rights – 保护他人的新观点及设计，即知识产权–Data Protection – 在处理个人信息时注意遵守相关法令保护数据3939第四章软件需求工程需求工程师的素质要求 1.倾听的能力2.访问能力3.分析能力4.协调能力5.观察能力6.书写能力407.组织能力8.建模能力9.交际能力10.创新能力11.领域知识40第四章软件需求工程what is a requirement?•每一个“人造物”都是一个内部环境与外部环境的“接口”这里内部环境指人造物本身的设计组成外部环境指人造物的周遭及其作用环境对这个接口的描述即是需求—— Herbert Simon, 1969•需求, 即是人们要解决的某个问题或达到某种目的的需要是系统或其组成部分为满足某种书面规定（合同，标准，规范等）所要具备的能力。

需求将作为系统开发，测试，验收，提交的依据—— IEEE 610.12, 19904141第四章软件需求工程将问题与解决方案分开•理解问题需求获取•问题的形式化表示形式规约，形式建模•就问题性质达成共识验证, 冲突及矛盾消解, 磋商需求管理– 维护双方的共识4242第四章软件需求工程需求：关于为什么？做什么？不包括怎么做？（why, what, how）•…需求描述必须给出为什么需要这样一个系统—— Ross, 1977•通常，需求描述系统要做什么，而不是怎么做但是，二者不太容易区分，上一个抽象层次的“怎么做”经常在下一个抽象层次上转化为“做什么”•Jackson给出的稍为清楚的解释：–“为什么”和“做什么”是指系统的设计目的，是置身系统外部，对应用领域性质的描述–“怎么做”是指系统的内部结构和行为—— Jackson, 19954343第四章软件需求工程存在问题的需求描述实例•含糊的需求描述：–“工资总额由上一条记录获得”–“所有客户都具有同一控制域“•错误的需求描述：–“所有系统将九月作为财政年度的起始时间”•不完整的需求描述：–“出错信息显示在屏幕的第24行“•矛盾或不一致的需求描述：–“C=A+B”；“C=A-B”•无法测试的需求：–“系统应具有友好的界面“4444第四章软件需求工程问题域 Problem Domain问题域 接口 解系统分析规格说明设计45第四章软件需求工程问题域的类型数据为主交互为主算法为主A.A.气象预报系统B.B.收银机系统C.C.电梯控制系统D.D.工资系统E.E.文字处理系统F.F.文件转换系统G.G.定位系统A AB BC CD DE EF FG G46第四章软件需求工程需求的层次软件需求包括三个不同的层次•业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。

•用户需求 (user requirement) 描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明•功能需求(functional requirement)（包括非功能需求）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求4747第四章软件需求工程EnvironmentEnvironment客戶由客戶的Goal 找出流程出口押汇转账 (Domain)世华银行外汇业务出口托收48第四章软件需求工程看单人员结账人员柜台人员收件 -> 审单 ->解款出口托收作业出口托收作业: : ->呈报审单解款收件呈报IS 使用UML 表示之49第四章软件需求工程软件需求各组成部分之间的关系50 管理人员或市场分析人员确定软件的业务需求，使公司运作更加高效（对信息系统而言）或具有很强的市场竞争力（对商业软件产品而言） 所有的用户需求必须与业务需求一致用户需求使需求分析者能从中总结出功能需求以满足用户对产品的要求从而完成其任务，而开发人员则根据功能需求来设计软件以实现必须的功能。

50第四章软件需求工程4. 软件需求的分类③③功能需求是开发人员必须实现的软件功能功能需求可以在多种不同的抽象层次上来表达，这使得导出需求过程比较复杂和困难：a) Physical behaviora) Physical behaviorb) Input-output relationshipb) Input-output relationshipc) Observable statesc) Observable statesd) User interfaced) User interface51第四章软件需求工程4. 软件需求的分类④④非功能需求非功能需求是功能需求的补充，它描述了系统完成功能实现的补充和约束条件如产品必须遵从的标准、国际规范和合约；外部界面的规范；性能需求如：系统运行速度(Speed)(Speed)，可靠性(Reliability)(Reliability)，容量(Capacity)(Capacity)，可用性(Availability),(Availability),可使用性(Usability)(Usability)；其它质量属性如：快捷性、简易性、直觉性、健壮性等。

在具体操作时，关于可靠性和可用性的在具体操作时，关于可靠性和可用性的规范最为困难，但又是客户最为关心的规范最为困难，但又是客户最为关心的52第四章软件需求工程4. 软件需求的分类④④非功能需求a) Responsea) Responseb) Accuracyb) Accuracyc) Frequencyc) Frequencyd) Capacityd) Capacitye) Throughpute) Throughputf) Defect ratesf) Defect ratesg) Modifiabilityg) Modifiabilityh) Supportabilityh) Supportability53第四章软件需求工程4. 软件需求的分类⑤⑤设计约束设计约束是真正意义上的非功能约束，它们约束系统怎样被构建而不是系统做什么设计约束的一般内容为–解系统将在其上运行的目标机器–底层的体系结构 - - 分布式的或本地的–系统运行的内存大小–应当采用的任何前端图形用户界面(GUI)(GUI)程序包–系统运行的操作系统–应当使用的编程语言–其它应集成的软件包如数据库管理系统(DBMS)(DBMS)–必须应用的开发标准–应采用的设计方法等等54第四章软件需求工程4. 软件需求的分类⑤⑤设计约束a) Languagea) Languageb) OSb) OSc) SW to HW interfacec) SW to HW interfaced) Algorithmd) Algorithme) Powere) Powerf) Timingf) Timingg) Memoryg) Memoryh) Processor utilizationh) Processor utilizationI) Weight etcI) Weight etc55第四章软件需求工程需求工程5656第四章软件需求工程Requirement activities in the SE lifecycle 软件生命周期中的需求活动5757第四章软件需求工程瀑布模型（Waterfall/Baseline）•核心思想：–系统开发是逐步求精的过程–各步骤相对独立，便于管理•存在的问题：–忽略了需求的动态性–需求完成后，用户对项目的参与即停止–需求描述与设计分开–不支持原型的使用和软件重用（Loucopoulos & Karakostas, 1995）5858第四章软件需求工程原型法（Prototype）•适用范围：–用于获取关于系统用户界面的需求–用于检验设计方案的可行性，或探讨系统性能问题•存在的问题：–用户将原型误认为最终系统–原型所反映的系统是不全面的（Loucopoulos & Karakostas, 1995, p30）5959第四章软件需求工程增量式开发与演化式开发Incremental vs. Evolutionary (Thayer & Dorfman, 1997, p10)Incremental vs. Evolutionary (Thayer & Dorfman, 1997, p10)6060第四章软件需求工程螺旋模型 (Spiral Model)•螺旋模型主要用于风险分析•每一轮开发活动具体包括:–制定下一轮计划–决定设计目标和限制条件–评估候选方案, 风险降解–产品开发•需求工程有关步骤为：–需求风险分析–规划设计•可以减少需求变更所带来的风险•存在的问题：–无法应付不可预见的需求变化6161第四章软件需求工程关于敏捷模型（Agile Models）基本原则：•减少沟通障碍–程序员与客户直接交流•减低繁重的文档负担–文档代价昂贵但用途有限•对开发人员给予充分信任–无需运用花样翻新的过程模型给与提示•响应客户要求–而非严格遵循合同条文62缺点：依赖程序员的记忆力源代码是难于维护的依赖口头交流易发生误解假定只有唯一的客户代表不可能反映多视角制作短期计划无长期及前瞻性规划62第四章软件需求工程1.需求获取（获取哪些内容？）1) 定义需求开发过程2) 定义项目愿景和范围3) 确定用户群4) 选择用户代理人5) 确定用例6) 确定系统事件和响应7) 描述软件的功能和性能8) 指明软件与其他系统元素的接口9) 建立软件必须满足的约束63第四章软件需求工程需求获取的主要步骤1.开发高层的业务模型u理解应用领域，即目标软件的应用环境。

如银行、电信公司、书店等u一旦系统分析人员对该领域有了充分了解，就可以建立一个业务模型，描述用户的业务过程，确定用户的初始需求u分析出企业的业务实体，开发或选取必需的构件，建立稳定的软件体系结构 64第四章软件需求工程EnvironmentEnvironment客戶由客戶的Goal 找出流程出口押汇转账 (Domain)世华银行外汇业务出口托收65第四章软件需求工程Scenario 叙述 客戶世华总管理处 焦点: 世华內部 国外银行中央银行看单人员结账人员柜台人员出口托收66第四章软件需求工程Viewpoints 关于需求的基本观点6767第四章软件需求工程关于需求的基本观点•需求工程活动不总是顺序进行–问题描述不总是先于解决方案描述•在系统开发的任何阶段描述问题均是有益的–需求工程是在各开发阶段持续进行的一系列活动•问题陈述无法追求完美–需求模型是对世界的近似表示•将包括不精确和不一致性•会省略某些信息•细致的分析将降低导致严重问题的风险•…但风险永不可能降解为零6868第四章软件需求工程关于需求的基本观点•追求规约的描述会降低性价比–需求分析是有开销的–不同的项目，性价比的平衡点是不同的•问题描述永不可能是固定的–变化是无法避免的，因此应纳入计划之中–对变化的处理应定期进行6969第四章软件需求工程不适当的需求引起的一些风险1.1.无足够用户参与 – – 用户参与不多会导致产品无法被接受2.2.用户需求的不断增加 – – 用户需求的增加带来过度的耗费和产品质量的降低3.3.模棱两可的需求说明 – – 将导致时间的浪费和返工4.4.不必要的特性 – – 用户增加一些不必要的特性和开发人员画蛇添足5.5.过分精简的规格说明 – – 过分简略的需求说明以致遗漏某些关键需求6.6.忽略用户分类 – – 忽略某类用户的需求将导致众多客户的不满7.7.不准确的计划 – – 不完善的需求说明使得项目计划和跟踪无法准确进行70第四章软件需求工程不适当的需求引起的一些风险1.1.无足够用户参与 客户经常不明白为什么收集需求和确保需求质量需花费那么多工夫，开发人员可能也不重视用户的参与。

很多情况下，开发人员觉得已经完全明白了用户的需求，甚至想当然地设计了一些用户并不认可的使用实例尽管原因是多方面的，尽早让具有代表性的用户参与是可以避免一定的风险的71第四章软件需求工程不适当的需求引起的一些风险2.2.用户需求的不断增加 在开发过程中，若不断地补充需求，项目就会越来越大直到超出计划和预算范围这是软件开发中极其普遍的问题，也是软件需求管理中重点涉及的问题如果变更发生在设计编码以后，这样的变更会使软件结构日渐紊乱，补丁代码使模块违背强内聚、低耦合的设计原则，使程序越来越难以理解和维护要想把变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束和成功标准给予明确说明，并作为今后需求变更处理时的参考框架72第四章软件需求工程不适当的需求引起的一些风险3.3.模棱两可的需求说明模棱两可，也就是需求的““二义性””，是需求说明中最可怕的问题模棱两可的需求风险承担者产生不同的期望，使开发人员产生错误的设计，使测试人员编写不匹配的测试用例模棱两可的需求直接的后果就是返工根据统计，返工会耗费总开发费用的40%40%，其中70%70%～80%80%是由需求方面的错误造成的认真、高质量的需求评审可以消除大部分的模棱两可型的错误。

73第四章软件需求工程不适当的需求引起的一些风险4.4.不必要的特性““画蛇添足””是指开发人员力图增加一些““用户可能欣赏””，但需求规格中并未涉及的新功能；这类新功能可能很花哨但用户并不认为很有用，但实现却耗费可观相反的情况也存在，即客户会提出这些花哨的但缺乏实用价值的需求，需求分析人员应做的是去说服客户避免将资源浪费在这些无关紧要的功能上与此相关的做法是，在可能的情况下，为客户提供新的解决方案，在允许的资源和技术可行性之间求得平衡74第四章软件需求工程不适当的需求引起的一些风险5.5.过分精简的规格说明 有时客户并不明白需求分析如此重要，于是只作一份简略之至的规格说明仅涉及产品的某些概念，其它让开发人员在项目进展中去完善，结果是为了管理上的某种要求，开发人员先建立产品结构、甚至是完成编码，然后再补充需求说明大多数情况下，这会增加开发过程的迂回、返工75第四章软件需求工程不适当的需求引起的一些风险6.6.忽略用户分类 多数产品是由不同的人使用不同的特性，使用频繁程度、受教育程度、经验水平也不相同如果产品功能设计不能满足某些关键用户需求，会大大影响产品的用户接受度76第四章软件需求工程不适当的需求引起的一些风险7.7.不准确的计划 需求分析不充分和缺乏理解会导致计划的乐观估计；导致需求过程中软件成本估计极不准确的主要原因为：a)a)频繁的需求变更；b)b)遗漏的需求；c)c)与用户交流不够；d)d)质量低下的需求规格说明；e)e)不完善的需求分析。

77第四章软件需求工程•软件需求工程需要执行的活动包括：1) 确定目标系统将要面对的各类用户；2) 从各类用户的代表那里收集需求；3) 将顶层的需求分配到软件系统构架内定义好的软件成分中；4) 协商需求的实现优先级；5) 书面化；6) 审阅需求文档，以确保在认识上与用户需求相一致应在开发组接受需求之前解决所有分岐78第四章软件需求工程3.可能的需求的来源 u软件需求的来源取决于目标系统的性质和开发环境典型的需求来源是：1)与潜在用户进行交谈和讨论2)描述现有产品或竞争产品的文档3)系统需求规格说明4)当前系统的问题报告和改进要求5)市场调查和用户问卷调查6)观察用户如何工作7)用户工作的场景分析8)事件和响应79第四章软件需求工程需求工程指南(Roadmap: Bashar Nuseibeh & Steve Easterbrook, 2000)(Roadmap: Bashar Nuseibeh & Steve Easterbrook, 2000)•如何获取需求信息？–核心技术：• 座谈，问卷，代表会议• 采用人种学（Ethnographic）方法（社交嵌入系统）• 采用原型法，或参与设计法（缺乏了解的系统）8080第四章软件需求工程•根据所受限制不同，不同类型的应用系统能够从用户那里获取需求的比例也不同。

•所谓限制，是指受客观物理规律的限制相对低的相对高的从人群获取需求的大概百分比应用的类型高度受限的不受限制的导弹制导系统航班控制系统公司财务系统增强版制造控制系统公司财务系统视频游戏军事战略决策支持系统81第四章软件需求工程u如导弹制导系统更多地受物理运动定律的限制，而非人的决策视频游戏的大部分需求依赖人，因为它是一个想象出来的产品u应用受到的限制越少，能从人们那里获得的需求比例越大4.识别用户类和用户代表u确定目标系统的不同用户类型；u挑选出每一类用户和其他项目相关者的代表并与他们一起工作; ;u商定谁是项目需求的决策者82第四章软件需求工程u不同用户类可能还有不同的非功能需求u不同用户类的需求甚至可能发生冲突，导致需求不一致u用户类可以是人，也可以是与系统打交道的其他应用程序或硬件部件u分析员必须在项目初期便确定产品有哪些不同的用户类，并描述它们的特点，这样就能从每个重要用户类的代表那里获取用户需求u用户代表应当自始至终参与项目，而不仅仅是需求分析阶段83第四章软件需求工程描述用户需求•需求可以看成是应用与外部用户之间的交互可利用用例作为表达工具•描述客户需求的过程如下：1)  标识参与者    标识目标系统将支持的不同类型的用户，可以是人、事件或其他系统。

2)  标识场景    用场景描述目标系统典型功能的活动细节，并与用户沟通，加深开发人员对应用领域的理解84第四章软件需求工程3)  标识用例    当双方确定了一组场景后，开发人员从该场景抽象出一组用例，描述所有可能的情况用例表达了系统的范围4)  求精用例    细化每一个用例引入带有出错处理或带有异常处理的用例，描述系统的行为，保证需求的描述是完全的5)  标识用例之间的关系    描述用例之间的依赖关系，提取相同功能，建立用例模型6)  标识非功能需求    包括系统性能上的约束、文档、使用资源、安全性和质量等需求85第四章软件需求工程出口托收导出的系统流程看单人员国外银行收件审单解款呈报结账人员柜台人员世华总管理处 UML 的 Use Case 图86第四章软件需求工程草拟用户界面和其他接口•建立初始用户界面，是原型方法的一种，目的是快速与客户沟通•客户通常在看到应用的图形用户界面（GUI）才能相像到这个应用未来的样子87第四章软件需求工程88第四章软件需求工程分析建模•常用的分析方法u面向数据流的结构化分析方法 (SA)u面向数据结构的Jackson方法 (JSD)u面向数据结构的结构化数据系统开发方法 (DSSD)u面向对象的分析方法 (OOA) 等89第四章软件需求工程结构化分析方法•结构化分析方法最初只是着眼于数据流。

•扩充后，将建模技术扩展到数据建模、功能建模和行为建模，以实体- -关系图、数据流图和控制流图、状态- -迁移图为工具，数据字典为核心，从不同视点建立系统的分析模型90第四章软件需求工程结构化分析的分析模型实体—关系图状态—迁移图数据流图数据对象描述数据对象描述加工规格说明加工规格说明数据字典控制规格说明控制规格说明91第四章软件需求工程数据建模•数据模型包括三种互相关联的信息：数据对象，描述对象的属性，描述对象间相互连接的关系•在需求分析阶段描述数据对象和它们之间的关系，使用了E-R 图•例如，在教学管理中，一个教师可以教授零门、一门或多门课程，每位学生也需要学习几门课程因此，教学管理中涉及的对象有学生、教师和课程92第四章软件需求工程教学数据模型学号   姓名   专业   性别   ……学生职工号姓名专业职称年龄教师课程号   课程名   学分   学时      …………课程学号课程号成绩选课93第四章软件需求工程XY一个X与一个Y相关联一个X与一个或多个Y相关联XY一个X与零个或一个Y相关联XY一个X与零个, 一个或多个Y相关联XY一个X与一个Y或Z相关联XYZ一个X与一个Y与Z相关联XYZ94第四章软件需求工程功能建模和数据流n最初, ,结构化分析方法仅讨论数据流建模，目标系统被表示成如图所示的数据变换流程图。

系统的功能体现在核心的数据变换中外部实体外部实体外部实体外部实体目标系统输入信息输入信息输出信息输出信息顶层数据流图（上下文环境图）95第四章软件需求工程数据流图中的主要图形元素数据加工 (数据变换)数据源或数据潭 (外部实体)数据流数据存储文件或或96第四章软件需求工程借书过程的数据流图•外部实体、数据流和数据存储都为候选对象软件工程9797读者 1借书检验2借书登记图书借书证检验错误借书信息借阅记录 读者信息 图书信息 借书证图书日历日期日期97第四章软件需求工程分层的数据流图98第四章软件需求工程实例：考务处理系统的功能问题陈述1)对考生送来的报名单进行检查;2)对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站;3)对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者;4)制作考生通知单（含成绩及合格/不合格标志） 送给考生;5)按地区进行成绩分类统计和试题难度分析，产生统计分析表99第四章软件需求工程功能建模的步骤1.确定与系统有交互关系的外部实体这些外部实体即为系统的数据源和数据潭，它们与系统的交互构成系统的输入和输出本例外部实体有：u考生：填交报名表，退还不合规定的报名表，得到准考证，得到考试通知单。

u阅卷站：得到考生名单，提交考试成绩单，退还有误成绩单u考试中心：提供合格标准，得到成绩分类统计表和试题难度分析表2.画出顶层数据流图100第四章软件需求工程2.顶层数据流图描述了系统与外部实体的交互，界定了系统的边界考生考务处理系统考试中心阅卷站不合格报名表报名表准考证考生通知单成绩单合格标准错误成绩单考生名单统计分析表101第四章软件需求工程报名表准考证1 1登记报名表2统计成绩不合格报名表考生通知单成绩单统计分析表第0层数据流图考生名册合格标准考生名单错误成绩单102第四章软件需求工程第1层数据流图 (a)1.1 检查报名表报名表准考证1.2编准考证号码不合格报名表考生名册考生名单合格报名表1.3登记考生合格报名表103第四章软件需求工程第1层数据流图 (b)2.1检查成绩单2.2审定合格者考生名册正确成绩单2.3制作通知单2.4分析统计成绩2.5分析试题难度试题得分表考生通知单难度分析表合格标准分类统计表成绩单错误成绩单经审定的成绩单104第四章软件需求工程行为建模n数据流图不描述时序关系，控制和事件流通过行为模型描述n在描述系统或各个数据对象的行为时，采用状态迁移图。

通过描述系统或对象的状态，以及引起系统或对象状态转换的事件来表示系统或对象的行为105第四章软件需求工程状态迁移图•状态迁移图是描述系统的状态如何相应外部的信号进行推移的一种图形表示•例如，有关处理器分配的进程状态迁移t2t3t4t1运行就绪等待106第四章软件需求工程•在状态迁移图中，ü“○”表示可得到的系统状态ü“→”表示从一种状态向另一种状态的迁移•在箭头上要写上导致迁移的信号或事件的名字 S2S1S3t1t2t3t4t4t3t2t1事件状态S1 S2 S3S3S2S3S1107第四章软件需求工程Petri网•Petri网已广泛地应用于硬件与软件系统的开发中，它适用于描述相互独立、协同操作的处理系统，也就是并发执行的处理系统•Petri网简称PNG (Petri Net Graph)，它有两种结点：ü库所：符号“○”，表示系统状态ü变迁：符号 “|”, 表示系统中的事件 ü有向边“”表示向变迁的输入，或从变迁的输出108第四章软件需求工程ü令牌 (token)，是表明系统当前处于什么状态的标志§Petri网可能的变化有：109第四章软件需求工程•例如，处理两个进程PR1和PR2的同步问题（此时两个进程共用一个资源R）：•该资源 R 在系统运行的某一时刻只能为一个进程所占用。

为了解决两个进程在运行中可能会同时申请资源的矛盾，要用原语 LOCK 和 UNLOCK 控制 R 的使用，保证进程间的同步 进程 得到资源 占用资源运行 释放资源 不用资源运行PR1       LOCK R         处理11        UNLOCK R        处理12PR2       LOCK R         处理21        UNLOCK R        处理22110第四章软件需求工程p1p2p3p4p5p7p6t1t2t3t4t5t6等待R等待RR空闲处理11处理12处理21处理22进程1进程2111第四章软件需求工程数据字典•数据字典的任务是以词条的方式详细定义在数据流图中出现的所有被命名的图形元素，包括数据流、加工、数据文件、数据元素已经数据源和数据谭等1)数据流词条描述u数据流名：u说明：简要介绍它产生的原因和结果112第四章软件需求工程u数据流来源：来自何方u数据流去向：去向何处u数据流组成：数据结构u数据量流通量：数据量，流通量2)数据元素词条描述u类型：数字( (离散值，连续值) )，文字( (编码类型) )长度u取值范围u相关的数据元素及数据结构3) 数据文件词条描述113第四章软件需求工程u数据文件名：u简述：存放的是什么数据u输入／输出数据：u数据文件组成：数据结构u存储方式：顺序，直接，关键码u存取频率：4)加工逻辑词条描述u加工名：u加工编号：反映该加工的层次u简要描述：加工逻辑及功能简述114第四章软件需求工程u输入／输出数据流：u加工逻辑：简述加工程序，加工顺序5)数据源及数据谭词条描述u 名称：外部实体名u 简要描述：什么外部实体u 有关数据流：u 数目：该实体与系统交互的次数115第四章软件需求工程数据结构的描述   符号                      含义                 举     例＝＝                                                    被定义为＋＋                                                                  与                                x = a+bx = a+b[...,...][...,...]或或   [...|...]            [...|...]            或或                  x = [a, b], x = [a|b]x = [a, b], x = [a|b]{... }{... }或或   m{...}n          m{...}n          重复                x = {a}, x = 3{a}8x = {a}, x = 3{a}8(...)                             (...)                             可选                                x = (a)x = (a)“...”                    “...”                    基本数据元素                x = "a"x = "a"  ..                               ..                             连结符                            x = 1..9x = 1..9116第四章软件需求工程存折＝户名＋所号＋帐号＋开户日＋性质＋ (印密) ＋ 1{ 存取行}50户名＝ 2{ 字母}24所号＝ 001..999帐号＝ 00000001.. 99999999开户日＝年＋月＋日性质＝“ 1 ”..“ 6 ”注：“ 1 ”表示普通户，“ 5 ”表示工资户等印密＝“ 0 ”注：印密在存折上不显示存取行＝日期＋（摘要）＋支出＋存入＋余额＋操作＋复核117第四章软件需求工程基本加工逻辑说明•对数据流图的每一个基本加工，必须有一个基本加工逻辑说明。

•描述数据加工逻辑的工具：结构化语言、决策表、决策树•结构化语言–结构化语言是一种伪码–它是一种介于自然语言和形式化语言之间的语言用以消除在语法上的歧义性 118第四章软件需求工程结构化语言•结构化语言是一种伪码，它的词汇表由n原形动词n数据字典中定义的名字n有限的自定义词n逻辑关系词 if_then_else、switch_case、for、while_do、do_while等组成•它是一种介于自然语言和形式化语言之间的语言用以消除在语法上的歧义性119第四章软件需求工程•语言的正文用基本控制结构进行分割，加工中的操作用自然语言短语来表示•其基本控制结构有三种：ü简单陈述句结构：避免复合语句；ü重复结构：while_do、for_do或do_while结构ü判定结构：if_then_else 或switch_do 结构；•用结构化语言描述的规格说明的正文可以在计算机上编辑，不必过多地考虑语言的在语法上的限制，使得分析员可以集中考虑加工的策略或规则120第四章软件需求工程商店业务处理系统中“检查发货单”if 发货单金额超过$500 then      if 欠款超过了60天 then              在偿还欠款前不予批准      else （欠款未超期）              发批准书，发货单      else （发货单金额未超过$500）      if 欠款超过60天 then              发批准书，发货单及赊欠报告      else （欠款未超期）              发批准书，发货单      121第四章软件需求工程判定表§如果数据流图的加工需要依赖于多个条件，使用判定表来描述比较合适。

条件茬条件项动作茬动作项规则单个条件单个动作122第四章软件需求工程以“检查发货单”为例操在偿还欠款前不予批准 作 发出批准书   发出发货单   发出赊欠报告 1234条 发货单金额> $500> $500≤ $500≤ $500件 赊欠情况> 60天≤60天> 60天≤60天123第四章软件需求工程判定树§判定树也是用来表达加工逻辑的一种工具有时侯它比判定表更直观检查发货单金额>$500金额 $500 欠款>60天不发出批准书 欠款 60天发货单发出批准书、 欠款>60天发出批准书、发货单及赊欠报告 欠款 60天发出批准书、发货单124第四章软件需求工程4.4  面向对象的需求分析125第四章软件需求工程识别类或对象 •面向对象分析模型由三个独立的模型构成：u由用例和场景表示的功能模型；u用类和对象表示的分析对象模型；u由状态图和顺序图表示的动态模型•在需求获取阶段得到的用例模型就是功能模型据此可导出分析对象模型和动态模型•需要注意，这些模型代表的是来自客户的概念，而非实际软件类或实际构件•分析中的类可以看作是高层抽象126第四章软件需求工程•在分析对象模型中的对象类分为有实体对象、边界对象和控制对象等三种类型。

•实体对象表示系统将跟踪的持久信息；边界对象表示参与者与系统之间的交互（接口）；控制对象负责用例的实现 •可用UML提供的衍型机制，区分不同类型对象ControlControlEntityEntityActorActorBoundary参与者     边界对象        控制对象     实体对象图示127第四章软件需求工程具有两个按钮的手表的分析对象<>Day<>Month<>Year<>ChangeDateControl<>ButtonBoundary<>LCDDisplayBoundary128第四章软件需求工程•分析建模活动包括以下步骤1)标识实体对象u自然语言分析法    利用Abbott启发式准则，将语言成分映射为模型成分语言成分模型成分示例专有名词实例李未普通名词类院士Doing动词操作创建、提交、选择Being动词继承是…的一种，是…中的一个Having动词聚合有…，由…组成，包括…情态动词约束必须是形容词属性事件描述129第四章软件需求工程u自然语言分析法主要关注用户术语。

限制有ü识别质量高度依赖人们的书写风格；ü可能会出现许多无关词汇，或同义词u检查每一个用例，标识候选对象ü用例中的连续名词（如借阅事件）；ü系统需要跟踪的现实世界中的实体（如借阅记录、书目信息）；ü系统需要跟踪的现实世界中的活动（如紧急情况操作预案）；ü数据源或数据潭（如读者、管理员）     130第四章软件需求工程图书管理系统中的实体对象①①Borrower：读者他们可以借阅、返还、预约和取消预约因为名字可能重复，可用读者ID识别②②Title：书目它表明某一种书，通过ISBN号码识别③③Book：图书它表明某一种书目的具体物理复本，通过馆藏号码识别④④Loan：借阅记录同一个人关于不同图书的借阅记录是不同的⑤⑤Reservation：预约记录131第四章软件需求工程图书管理系统中的边界对象①①mainWindow：主窗口有借书、还书、预约、取消预约、添加书目、修改书目、删除书目、添加读者、修改读者、删除读者、添加图书、删除图书等操作②②BorrowerDialog：读者对话框有添加读者、修改读者、删除读者等操作③③FindBwrDialog：弹出对话框有根据读者ID查找读者的操作。

④④TitleDialog：书目对话框有添加书目、修改书目、删除书目等操作132第四章软件需求工程⑤⑤FindTDialog：弹出对话框根据图书的ISBN号码查找书目⑥⑥BorrowDialog：借书对话框根据书目的ISBN号码和读者信息，执行借阅动作，创建和保存借阅记录⑦⑦ReturnDialog：还书对话框．根据图书的馆藏号码，执行还书动作，删除借阅记录⑧⑧ReserveDialog：预约对话框根据书目的ISBN号码和读者信息，执行预约、取消预约动作⑨⑨MessageWindow：显示提示信息窗口⑩⑩LoginDialog：输入用户名和密码的窗口133第四章软件需求工程4)使用顺序图将用例映射为对象u画顺序图的启发式准则如下：ü顺序图第一栏对应激活该用例的参与者;ü顺序图第二栏是边界对象;ü顺序图第三栏是管理用例中其他参与对象的控制对象;ü通过边界对象来初始化用例，并创建控制对象;ü通过控制对象可创建其他边界对象;ü实体对象允许边界对象和控制对象访问;ü实体对象不能访问边界对象和控制对象;134第四章软件需求工程借书用例的顺序图:mainWindow :BorrowDialog:Title:Book:Borrower :Loan:Librarian1:borrow()2:createDialog()3:borrow()4:findTitle(string)5:getTitle()6:getAvaliableBook()7:findBorrower(string)8:newLoan(OID, OID, Date)9:store()10:getBorrower(OID)11:update()12:addLoan(OID)13:getObject(OID)14:setLoan(OID)15:update()135第四章软件需求工程5)  使用CRC卡片对对象之间的交互建模CRC是类、职责和协作的缩写。

每一个类可用一张CRC卡片表示建立CRC卡片有以下几个步骤：识别类和职责： 首先识别类或对象，然后从客户需求说明中寻找有关行为的描述，以发现职责将职责分配到类 ：记录在相应的卡片上 找寻协   依次检查每一类承担的责任，看是否需要其他类的帮助，找寻与每个类协作的伙伴，并记录在相应卡片上136第四章软件需求工程 职责  显示欢迎词            密码验证器          接收磁卡                菜单选择器          让密码验证器检验          启动菜单选择器          退出磁卡   类名  读卡机                    协作职责  从账户中取出密码       账户          如无此账户返回假值          提示客户输入密码          读入密码          比较核实, 返回结果   类名  密码验证器                   协作职责  检查账户有效性          返回密码          检查取款/存款信息类名  账户职责  显示菜单             存款管理器          等待客户选择     取款管理器          调用相应的              存款/取款管理器类名  菜单选择器         协作职责  询问取款额          账户          要求验证账户      出银机          启动出银机发款类名  取款管理器          协作137第四章软件需求工程④④细化：模拟在执行每个基本功能时系统内部出现的场景，以此推动细化工作的进行。

u在模拟一个场景的过程中，每当一个类开始“执行”时，它的卡片就被拿出来讨论，当“控制”传送到另一个类时，注意力就从前一张卡片转移到另一张上去了不同的场景，包括例外和出错状况，都应逐一加以模拟u在这个过程中可以验证已有的定义，不断发现新的类、职责以及伙伴u在模拟不同的场景中会发现某些职责需要重新加以分配这些都导致进一步的开发工作138第四章软件需求工程6)识别关系（结构）u使用类图，能够表示对象之间的关系u关联表示了两个或多个类之间的关系标识关联的启发式准则如下：ü检查指示状态的动词或动词短语；识别动作的主体和客体ü准确地命名关联和角色；ü应消除可导出其他关联的关联；ü在一组关联稳定之前不必关心重复性；ü过多的关联使得一个模型不可读；139第四章软件需求工程a)建立系统的包图（主题）Ø建立包图是为了降低复杂性Ø提供整体框架每一个包就是一个主题Ø通过对主题的识别，可以让人们能够比较清晰地了解大而复杂的模型LibraryGUIDataBase140第四章软件需求工程b)建立边界类的类图Ø标明类之间的关系，包括关联、泛化等messageWindowloginDialogreturnDialogborrowerDialogreserveDialogmainWindowfindTDialogborrowDialogfindBwrDialogTitleDialog141第四章软件需求工程c)建立实体类的类图Ø这些类与数据库相关，为了操作方便，以它们为子类，建立一个持久类（Persistent）作为它们的父类，共享与数据库相关的操作。

BookBorrowerReservationTitleLoanPersistent(from DataBase)110..1*0..*0..*0..*0..*11142第四章软件需求工程d)建立边界类与实体类之间关系的类图Book(from Library)110..1*0..*1Title(from Library)Loan(from Library)Borrower(from Library)Reservation(from Library)BorrowDialog(from GUI)ReturnDialog(from GUI)143第四章软件需求工程Book(from Library)110..1*0..*1Title(from Library)Loan(from Library)Borrower(from Library)Reservation(from Library)TitleDialog(from GUI)findTDialog(from GUI)0..*0..*10..*144第四章软件需求工程7)标识属性u对象所保存的信息称为它的属性类的属性所描述的是状态信息，每个实例的属性值表达了该实例的状态值。

u标识属性的启发性准则如下：ü每个对象至少需包含一个属性；例如：idü属性取值必需适合对象类的所有实例；ü系统的所有存储数据必须定义为属性；ü对象的导出属性应当略去例如，“年龄”是由属性“出生年月”导出，它不能作为基本属性存在145第四章软件需求工程8) 表示类的服务u对每个类的增加、修改、删除、选择等服务有时是隐含的，在图中不标出，但实现类和对象时有定义u其它服务则必须显式地在图中画出①①首先标识在每个类中封装的服务; ;②②画出对象之间的消息通信路径方法：①①找出每一对象在其生存周期中的所有状态每一状态的改变都关联到对象之间消息的传递②②使用顺序图，标识和描述对象之间的相互通信软件工程146146146第四章软件需求工程 Scenario 叙述 刘备孔明关羽求战请拟策略张飞请防守荊州请防守荊州前线孙权曹操请联络孙权请孙权领兵相助借东风火攻火攻曹军147第四章软件需求工程4.5 快速原型化方法•这是一种有效驾驭风险的技术。

通过原型u可以增进软件开发者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求（主要是功能）明确化u可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果u有的原型可以直接成为产品，有的略加修改就可成为最终系统的一个组成部分148第四章软件需求工程原型分类1)探索型：  目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性适用于对项目缺乏经验的情况2)实验型：  这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠3)进化型：  这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统149第四章软件需求工程原型使用策略•软件原型支持需求工程的两项活动：u需求获取u需求有效性验证•其他用途：u用户培训u系统测试•原型开发主要分类：u进化式原型开发u抛弃式原型开发150第四章软件需求工程1）进化式原型开发•基本思路是：先给出一个系统的最初实现，让用户去使用和评价，不断进行细化和改善，经过多次这样的反复过程后形成最终的完善的系统开发抽象描述建立原型系统使用原型系统系统充分吗?交付系统否是151第四章软件需求工程2）抛弃式原型开发•基本思路是：原型的根本作用是弄清楚需求和为风险评估提供补充信息。

通过评估后，原型被抛弃，重新规划和实施系统的开发框架需求开发原型确定系统评估原型开发软件问题可验证系统问题可交付的软件系统可复用构件152第四章软件需求工程需求规格说明的原则(1)功能与实现分离，描述要“做什么”而不是“怎样实现”2)如果目标软件只是一个大系统中的一个元素，那么整个大系统也要描述3)规格说明必须包括系统运行的环境4)系统规格说明必须是一个认识的模型（让用户理解），而不是设计或实现的模型5)规格说明必须是可操作的6)规格说明必须容许不完备性并允许扩充7)规格说明必须局部化和松耦合软件工程153153153第四章软件需求工程需求规格说明的质量要求1.完整性：2.不能遗漏任何必要的需求信息如果知道缺少某项信息，用“待定”作为标准标识来标明这项缺漏在开始设计和实现之前，必须解决需求中所有的“待定”项2.无歧义性 154第四章软件需求工程必须保证该需求规格说明对其每一个需求只有一种解释为此，要求最终产品的每一个特性都需使用某一确定的术语描述3.一致性必须保证在需求规格说明书中描述的每一个软件需求的定义不能与其他软件需求或高层（系统，业务）需求相矛盾在设计和实现之前必须解决所有需求间的不一致部分。

4.可验证性对于每一个需求，需指定所使用的验证方法，以确保需求得到满足 155第四章软件需求工程5.     可修改性n在内容组织上，需求规格说明应有目录表、索引和相互参照表，各个章节尽可能独立，以减少修改的波及面，使得修改局部化n尽可能减少冗余，每项需求只应在软件需求规格说明中出现一次6.可追踪性1)向后追踪：即向产生软件需求规格说明的前一阶段追踪2)向前追踪：即向由软件需求规格说明所派生的所有后续文档追踪 156第四章软件需求工程4.8 需求管理•需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更需求管理强调：u控制对需求基线的变动u保持项目计划与需求一致u控制单个需求和需求文档的版本情况u管理需求和跟踪链之间的联系或管理单个需求和其他项目可交付物之间的依赖关系u跟踪基线中需求的状态157第四章软件需求工程需求管理的主要活动 需求管理  需求跟踪l 定义对其   他需求的   跟踪链l 定义对其   他系统需   求的跟踪   链版本控制l 确定需求   文档版本l 确定单个   需求文档   版本需求状态跟踪l 定义需求状   态l 跟踪需求的   每一状态  变更控制l 建议变更l 分析影响l 做出决策l 交流l 合并l 测量需求   的稳定性158第四章软件需求工程需求的变更控制 •对于很多软件项目来说，需求变更是合理的，而且是不可避免的。

•如果对需求的变更不加控制，持续不断地返工，持续不断地调整资源、进度或质量目标，会导致开发过程混乱，开发成本上升和开发进度延误，同时导致产品质量的下降所以，必须严格控制需求的变更 1.变更控制的策略 159第四章软件需求工程(1)所有需求的变更必须遵循一个变更控制的过程，如果一个变更请求未被批准，则其后续过程不再予以考虑2)对于未获批准的变更，除可行性论证之外，不应再做其他设计和实现工作3)提交一个变更请求不能保证该变更一定能实现，要由项目变更控制委员会决定实现哪些变更4)项目风险承担者应该能够了解变更数据库的内容160第四章软件需求工程(5)绝不能从数据库中删除或修改变更请求的原始文档6)每一个集成的需求变更必须必须能跟踪到一个经核准的变更请求2.变更控制委员会（CCB）u变更控制委员会的主要工作是：(1)制定决策对每个变更权衡利弊后做出决定2)交流情况一旦变更控制委员会做出决策，应及时更新变更数据库中请求的状态，通知所有相关人员，保证他们能充分处理变更 161第四章软件需求工程(3)重新协商约定当软件开发组接受了重要的需求变更时，要与管理部门和客户重新协商约定协商内容包括推迟“交货”时间、要求增加人手、推迟实现尚未实现的较低优先级的需求，或者质量上进行折衷。

162第四章软件需求工程需求规格说明的版本控制 •版本控制是为了管理软件需求规格说明文档它主要的活动是统一标识需求规格说明文档的每一个版本，并让每一个开发组的成员能够获得和使用他所需要的任一版本•版本控制最简单的方法是根据约定，标记软件需求规格说明的每一次修改 163第四章软件需求工程需求跟踪 u需求跟踪是为了确保所有需求都被实现同时，使用跟踪信息，确保在变更需求时不遗漏每个受到影响的系统元素，包括其他需求、体系结构、源代码、测试用例、帮助文件、文档等1.需求跟踪链u通过需求跟踪链，可以在整个软件生存周期中跟踪一个需求的使用和更新情况 uJarke提出了4类需求跟踪能力链 164第四章软件需求工程(1) 第一个链是从用户需求向前追溯到软件需求:ü区分开发过程中或开发结束后由于用户需求变更受到影响的软件需求；ü确保软件需求规格说明中包含了所有的用户需求 需求追溯到需求用户需求从需求回溯下游工作制品追溯到下游制品向需求回溯165第四章软件需求工程(2) 第二个链是从软件需求回溯到相应的用户需求，确认每个软件需求的源头ü如果以用例的形式来描述用户需求，从软件需求直接就能回溯到某一个用例。

3) 第三个链是通过定义每个需求和特定的工作制品之间的联系实现从需求向前追溯:ü了解每个需求对应的下游制品;ü确保下游制品满足每个需求4) 第四个链是从下游制品回溯到需求，告诉人们每个下游制品之所以存在的原因  166第四章软件需求工程u跟踪链记录了每个需求的前后的互连和依赖关系当某个需求发生变更（删除或修改）后，这种信息能够确保正确的变更传递，并将相应的任务作出正确的调整 2.需求跟踪矩阵u该矩阵表明了每个功能需求向后连接一个特定的用例，向前连接一个或多个设计元素、代码段和测试用例u设计元素可以是数据流图、关系数据模型中的表单、对象类；代码段可以是对象类中的方法、源代码文件名、过程或函数 167第四章软件需求工程•跟踪链可以定义各种系统元素类型之间的一对一、一对多、多对多关系：u一对一：如一个代码模块应用于一个设计元素u一对多：如多个测试用例验证一个功能需求u多对多：如每个用例具有多个功能需求，而某些功能需求又具有几个用例•随着软件设计、构造、测试开发的进展不断更新矩阵例如，在实现某一功能需求后，可立即更新它在矩阵中的设计和代码单元，将需求状态设置为“已完成” 168第四章软件需求工程反映用例与功能需求之间联系的需求跟踪能力矩阵 •使用不同的符号明确表示“追溯到”（向前）和“从……回溯”（向后）或其他联系。

功能需求用  例UC-1UC-22UC-3UC-4FR-1FR-2FR-3FR-4FR-5FR-6169第四章软件需求工程。