需求分析与系统设计.pptx

需求分析与系统设计需求分析与系统设计 第第3章章 需求确定需求确定 需求确定是一种关于社会、沟通和管理的技能。它是系统开发中最不需要技术的一个阶段，但是，如果没有完全地进行，其结果将会比其他阶段更糟。由于没有捕获、忽略或错误地理解客户需求，为此而付出的代价在软件过程的以后阶段将是不可承受的。需求确定 本章介绍需求确定中的一系列范围广泛的问题。本章前半部分涉及需求抽取、协商和验证以及需求管理的问题，后面还包括可追踪性和变化管理的问题，这个问题我们将在第10章中详细讨论。本章后半部分介绍用于描述与组织和目标应用领域相关的业务模型的基本图形建模技术。还讨论了需求文档的结构。第3章 需求确定 l3.1需求确定的原则 l3.2需求抽取 l3.3需求协商和验证 l3.4需求管理 l3.5需求业务模型 l3.6需求文档 3.1需求确定的原则 需求确定是系统开发生命周期的第一个阶段。要开发的系统由系统规划活动确定(1.2节），需求确定的目的包括提供功能和其他需求的叙述性定义，这些需求是投入者希望在实现的或部署的系统中所具有的。需求定义了系统被期望的服务（服务陈述）和系统要服从的约束（约束陈述）。服务陈述可以分为几个部分，它们是系统的范围、必要的业务功能（功能需求）和要求的数据结构（数据需求）。约束陈述可以按照系统不同限制的类型来划分，比如所要求的系统的“外观和感觉”、性能、安全性等。3.1需求确定的原则 需求需要从客户（用户和系统所有者）那里获得。这就是由业务（或系统）分析员引导的需求抽取活动，从传统的客户会谈到（如果必要）构建软件原型以通过它来发现更多的需求，有许多技术可以利用。3.1需求确定的原则 收集到的需求必须进行仔细的分析以消除多重性和矛盾，这个过程总会导致需求评审和与客户的再一次协商。一旦被客户所接受，需求就要在需求文档中进行定义、分类、编号并赋予不同的优先级。需求文档按组织选定的用于书写需求的文档模板进行组织。3.1需求确定的原则 虽然需求文档大部分都是叙述性的，它也可能包含一些高层图形化的业务模型，这个业务模型一般由系统范围模型、业务用例模型和业务类模型组成。客户需求是一个移动的目标。为了处理多变的需求，我们需要能够管理变化。需求管理包含诸如估计变化对需求和系统的其他部分的影响等活动。3.2需求抽取 业务分析员通过咨询发现系统的需求。这个咨询过程涉及客户和问题领域的专家。在一些情况下，业务分析员拥有足够的领域经验，领域专家可能就不需要了。这时，就像图3-l中用泛化关系构建的模型那样，一个业务分析员就是一种领域专家。（记住，图3-1不是用例模型，这里采用用例模型表示法只是为了方便而已。）3.2需求抽取 从领域专家处抽取的需求由领域知识组成，它们捕获了被广泛承认的与时间无关的业务规则，可适用于大多数的组织和系统。从客户处抽取的需求以用例实例表示。它们超出了基本的领域知识，捕获了组织的独特性质，即当前组织做业务的或业务应该怎样做的方式。3.2需求抽取 业务分析员的任务就是要组合这两部分需求以形成业务模型。如图3-l所示，业务模型包含业务类模型和业务用例模型。业务类模型是一个高层类图，标识并关联业务对象。业务用例模型是一个高层用例图，标识系统中的主要功能构建块。3.2需求抽取 一般来说，领域类（业务对象）不必由用例导出（。实际上，业务类模型应该由业务用例模型来验证，这个验证过程可能导致业务类模型的调整和扩展。我们区分传统的和现代的事实发现和信息聚集方法。3.2需求抽取l3.2.l传统的需求抽取方法l3.2.2现代需求抽取方法 3.2.l传统的需求抽取方法 传统的需求抽取方法包括面谈记问卷法、观察法和业务文档研究法。这些都是简单和合算的方法。但这些传统方法的效果与项目的风险是成反比的。高风险意味着系统难以实现，甚至高层的需求也非常不清楚。在这种项目中，这些传统的方法就不可能胜任。3.2.l传统的需求抽取方法l3.2.1.1与客户和领域专家面谈 l3.2.1.2问卷法 l3.2.1.3观察 l3.2.l.4文档和软件系统的研究 3.2.1.1与客户和领域专家面谈 面谈法是事实发现和信息聚集的基本技术。大多数的面谈过程都是与客户一起进行的。与客户面谈大多用来抽取“用例”需求（图3-1）。如果业务分析员没有足够的领域知识的话，可以把领域专家找来面谈。3.2.1.1与客户和领域专家面谈 与领域专家的面谈经常是一个知识转换的过程，即对业务分析员来说是一个学习过程。与客户的面谈就比较复杂了。客户可能对他们的需求只有一个模糊的认识，他们也可能不愿意合作或不能够表达他们的需求，他们还可能提出超出项目预算或不可实现的需求。最后，来自不同客户的需求还可能发生冲突。3.2.1.1与客户和领域专家面谈 面谈法有两种基本形式：结构化的（形式化的）和非结构化的（非形式化的）。结构化面谈法需要提前准备，有一个明确的日程，并且许多问题都是预先确定的。有一些问题可以是无确定答案的（对这些问题，其答案无法预计），其他问题可以是有确定答案的（回答从提供的答案中选取）。3.2.1.1与客户和领域专家面谈 结构化面谈法需要非结构化面谈法进行补充。非结构化面谈法更像非正式的会议，没有预定的问题或预计的目的。非结构化面谈法的目的是鼓励客户讲出他/她的想法，并且在这个过程中导出业务分析员没有想到的和因而没能提出的相关问题的需求。结构化和非结构化面谈法都必须有某个出发点和讨论的语境，这可以是一篇短的书面文档，或在解释面谈者目的或提出问题的会议之前发送给面谈对象的email。3.2.1.1与客户和领域专家面谈 一般来说，有三种问题应该避免：l固执己见的问题。在这种问题中，面谈者（直接地或间接地）表达了你她自己关于这个问题的观点（“我们必须按我们做这件事的方式来做它吗？”）。l带偏见的问题。它类似于固执己见的问题，但面谈者的观点明显是有偏见的（“我们不做这件事，对吗？”）。l强加的问题。它假设了问题的答案（“你用这种方式做这件事，对吗？”）。3.2.1.1与客户和领域专家面谈 成功的面谈存在许多因素，但也许最重要的是面谈者的沟通和人际交流技能。与面谈者提出问题和控制面谈过程的同时，认真倾听和保持耐心从而使得面谈对象不感到拘束也是同等重要的。为了维持好的人际关系并得到好的反馈，简单综述面谈的备忘录应该在一两天内发给面谈对象。3.2.1.2问卷法 问卷法是从多个客户中收集信息的有效方法。它一般用来作为面谈法的补充形式，而不是要替代它。但有一个例外，就是非常了解的低风险项目。对这种项目，具有被动特征和不是很深入的问卷法就已经足够了。3.2.1.2问卷法 一般而言，问卷法没有面谈法有效，因为无法澄清问题和可能得到的响应。问卷法是被动的，就它本身来说既有优点也有缺点。优点在于回答者有时间去考虑如何回答，并且口答可以是匿名的。缺点在于回答者不容易弄清楚这些问题的含义。3.2.1.2问卷法 问卷应该设计成便于问题的回答。特别地，应该避免开放式问题大多数问题都应该是封闭式的。封闭式问题可以采用如下三种形式：l评分问题，回答者在这里需要表达他她对一段陈述的观点，可能的分值可以是强烈同意、同意、中立、不同意、强烈不同意和不知道。l多项选择问题，回答者在这里必须从提供的答案集中选取一个或多个答案。可以允许回答者附加注释。l排序问题，这里所提供的答案应该用序数、百分比或相似的排序方式给出。3.2.1.2问卷法 一个设计良好，易于回答的问卷将鼓励回答者及时返回完成的文档。但是，在评估问卷结果时，业务分析员应该考虑到由于有些人没有回答以至于可能提供不同的答案的这个事实所带来的偏差。3.2.1.3观察 存在这样的情景，其中业务分析员发现通过交谈法和问卷法都很难获得完整的信息。客户可能不能够有效地表达信息，或者只有一个完整的业务过程中的片段知识。在这种情况下，观察可能是有效的事实发现技术。学习如何系领带的最好方法就是观察这个过程。3.2.1.3观察 观察可以有两种形式：l被动观察，业务分析员在这里不受干扰或直接干预的情况下观察业务活动。在有些情况下，摄像机可以用来进行更少干扰的观察。l主动观察，业务分析员在这里参与到活动中，并且有效地成为其中的部分。3.2.1.3观察 要使观察具有代表性，观察应该持续进行一个较长的时间段，在不同的时间段上进行，并且在不同的工作负荷下（挑选时间）进行。观察法的主要困难在于，人们在被观察的情况下总想表现出不同的行为。特别地，他们总想按照形式化的规则和过程去做。这会由于隐藏了正面或负面的工作方法而歪曲了现实情况。我们应该记住“按规则进行工作”在工业行为中是有效的形式。3.2.l.4文档和软件系统的研究 文档和软件系统的研究是发现用例需求和领域知识需求的不可限量的技术，虽然它可能只针对系统中所选择的方面。用例需求通过研究存在的组织文档和系统表格报表（如果存在当前系统的计算机化方案，因为一般是在大型组织中）。对用例需求最有价值的了解之一是缺陷（如果存在的话）的记录和对存在系统的变化要求。3.2.l.4文档和软件系统的研究 要研究的组织文档包括：业务表格（填好的，如果可能）、工作过程、职位描述、政策手册、业务计划、组织图、办公室之间的通信、会议纪要、财务报表、外部通信、客户投诉等。要研究的系统表格和报表包括：计算机屏幕和报表，并带有所关联的文档：系统操作手册、用户文档、技术文档、系统分析和设计模型等。3.2.l.4文档和软件系统的研究 领域知识需求通过研究领域刊物和参考手册获得。对专用软件包（如ERP）的研究也提供领域知识源。因此，访问图书馆和软件供应商是需求抽取过程的一部分（当然，因特网使得这种访问不离开办公室就能完成）。3.2.2现代需求抽取方法 现代需求抽取方法包括软件原型的使用、JAD（联合应用开发）以及RAD（快速应用开发）。它们提供了对需求更深的理解，但需要较高的开销和较大的努力。当然，长期的付出可能是非常值得的。当项目风险高的时候总采用现代方法。项目风险高的因素有很多，包括不明确的目标、未成文的过程、不稳定的需求、不完善的用户知识、没有经验的开发人员、没有足够的用户承诺等等。3.2.2现代需求抽取方法l3.2.2.1原型法 l3.2.2.2联合应用开发 l3.2.2.3快速应用开发 3.2.2.1原型法 原型法在现代需求获取方法中是最常用的方法。构造软件原型为了使系统或者是系统的一部分对客户可视化以获得他们的反馈。原型是一个演示系统，它是解决方案的一件“快速而粗糙的”工作模型，它呈现出 GUI（图形用户界面），并且对各种用户事件模拟系统的行为。GUI屏幕上的信息内容在原型程序中是硬编码的，而不是从数据库中动态取得的。3.2.2.1原型法 现代GUI的复杂性（和增长的客户期望）使原型法成为软件开发中必不可少的因素，系统的柔性和可用性可以通过原型在开始真正的实现之前就估计出来。通常，系统原型是抽取从客户那里用其他方式难以抽取的需求的一种非常有效的方式。对增加新的业务功能的系统常常是这种情况，对冲突的需求或者在客户和开发人员之间有沟通问题时也是如此。3.2.2.1原型法 原型有两种：l“丢弃”式原型。它是当需求抽取完成时要被丢弃的。“丢弃”式原型针对生命周期的需求确定阶段，它集中在理解得最少的需求上。l进化式原型。它是在需求抽取之后仍保留并被用来产生最终产品。进化式原型目标在于产品发布的速度，它集中在理解得最好的需求上，使得产品的第1版能够很快发布（虽然只具备不完整的功能）。3.2.2.1原型法 支持“丢弃”式原型的另一个论断是，它避免了在最终产品中保留“快速而粗糙”或者不够有效的方案。然而，当代软件生产工具的能力和灵活性淡化了这个论断。在一个管理得很好的项目中也不能根除无效原型是没有道理的。3.2.2.2联合应用开发 JAD在一个或多个工作会议中的一次联合应用开发将所有的投入者（客户和开发人员）带到了一起。虽然我们在这里将JAD归为现代需求抽取方法，但这种技术还是（由IBM）在20世纪70年代后期引入的。有许多JAD的品牌，也有许多专门提供组织和执行JAD活动的服务的咨询公司。一次JAD会议可能要几个小时、几天或者甚至一两个星期，参加者的人数不应超过25到30人。3.2.2.2联合应用开发 会议的参加者有：l领导：组织和召集这次会议的人。这个人具有很强的交流能力，他不是项目的投入者（除了作为JAD领导之外），但应具有很好的业务领域的知识（但不需要很好的软件开发知识）。l文书：在计算机上记录JAD活动的人。这个人应该有快速录入的技能，应该具备很强的软件开发知识。他能够使用 CASE工具为活动生成文档，并开发最初的解决方案模型。l客户（用户和经理）：他们是交流、讨论需求、作出决策、批准项目目标等工作的主要的参与者。l开发人员：开发队伍中的业务分析员和其他人员，他们听得多说得少他们在这个会议上是发现事实并收集信息，而不是支配这个过程。3.2.2.2联合应用开发 JAD利用了群体动力学原理。“组协同”很可能得到问题更好的解决方案。组提高生产力。学得更快、制定更多理智的判断、消除更多的错误、采取更具风险的决定（虽然这一点可能起负作用）、使参与者的注意力更集中在那些最重要的问题上、集成了人员等等。当按照规则引导时，JAD活动倾向于输出令人惊奇的好结果。但也有人警告说，“福特汽车公司在20世纪50年代因为Edsel（由一个委员会设计的汽车）而经历了一场市场的灾难。”3.2.2.3快速应用开发 RAD（快速应用开发）不仅仅是一种需求抽取方法，它还是视软件开发为一体的方法。RAD目的是快速发布系统方案，而技术上的优美对发布速度来说则是次要的。3.2.2.3快速应用开发 RAD组合了五个方面的技术：l进化原型。l带有代码生成以及在设计模型和代码之间的循环工程的CASE工具。l拥有先进工具的专门人员（SWAT）：RAD开发小组。最好的分析员、设计师和程序员是这个组织能得到的。这个开发组在严格的时间安排下工作，并与用户在一起。l交互式JAD：一个 JAD活动，在此期间文书由具有 CASE工具的 SWAT小组代替。l时间表：SWAT小组完成项目具有固定时间期限（时间表）的项目管理方法，这个方法禁止“范围扩张”；如果项目进展慢就削减方案涉及的范围以使项目能按时完成。3.2.2.3快速应用开发 RAD方法对许多项目来说是有吸引力的，特别是针对不是组织核心业务范围，并且因此不给其他开发项目制订日程表的小项目而言。快速求解很可能不是最优的或者不是核心业务范围内能承受的。与RAD相关的问题包括：l1.不一致的GUI设计。l2.支持软件复用的专门的解决方案，而不是通用的解决方案。l3.不足的文档。l4.难以维护和扩展的软件等。3.3需求协商和验证 从客户处抽取的需求可能是重叠和矛盾的，有些需求可能是二义的或不现实的，而其他需求又可能还没发现。由于这些原因，需求在被编进文档之前需要进行协商和验证。实际上，需求协商和验证是与需求抽取同步进行的。在需求抽取的同时，它们也经受某种程度的审查。在包括所谓组协同方法在内的所有现代需求抽取技术原本就是如此，而且，一旦所有抽取到的需求放到一起，它们还要经历仔细的协商和验证。3.3需求协商和验证 需求协商和验证不能不与书写需求文档的过程关联在一起。需求协商通常是以文档的草稿为基础的，如果需要，列在文档草稿中的需求就要被协商修改。错误的需求被移走，新发现的需求被加入。需求验证要求有更完整的需求文档的版本，其中所有的需求都要被清楚地标识和分类。投入者阅读文档并且召集正式的审查会，审查常常结构化为所谓的走查或检查。审查也是测试的一种形式。3.3需求协商和验证 l3.3.l超出范围的需求 l3.3.2需求依赖矩阵 l3.3.3需求风险和优先顺序 3.3.l超出范围的需求 IT项目的选择和因此要实现的系统（以及它们的广泛范围）都是在系统规划活动中确定的。然而，系统之间详细的相互依赖关系只有在需求分析阶段被发现。确定系统边界（系统范围）是需求分析的任务，使得“范围扩张”问题在这个过程中可以早点解决。3.3.l超出范围的需求 决定任何特定需求是在系统范围之内还是之外，需要一个参考模型来对照才能作出决定。历史上，这样一个参考模型由语境图来提供流行的结构化建模技术的顶级图称为DFD（数据流图）。虽然DFD在UML中已经被用例图所代替，语境图仍然是建立系统边界很好的方法。3.3.l超出范围的需求 然而，为什么需求落在范围之外还有其他的原因。例如，一个需求可能在计算机化的系统中难以实现，它留在人类完成的过程中。或者需求可能具有低的优先级并被排除在系统的第1个版本之外。需求可能己经在硬件或外部设备中实现了，并且超出了软件系统的控制范围。3.3.2需求依赖矩阵 假设所有的需求都被清楚地标识和编号，还可以构造需求依赖矩阵（或交互矩阵。这个矩阵按一个分类顺序分别在行和列的表头上列出需求标识符，如表3-1所示。表3-1需求依赖矩阵需求R1R2R3R4R1XXXXR2冲突XXXR3XXR4重叠重叠X3.3.2需求依赖矩阵 矩阵的右上部分（对角线的上面并包含对角线）没有用上，其余单元格指出任意两个需求是否重叠、是否矛盾或者是否独立（空单元格）。矛盾的需求应与客户进行讨论，并且可能的话重新构形这个需求以避免矛盾（并且矛盾的记录应该保留，对后续的开发可见）。重叠的需求也要重新陈述以消除重叠。3.3.2需求依赖矩阵 当需求的条数相对较小的时候，需求依赖矩阵是发现矛盾和重叠的一个简单而有效的技术。若不是这种情况，如果需求能组合成不同的类，并且能独立地在每个类中进行比较时，这种技术也是有用的。3.3.3需求风险和优先顺序 一旦解决了需求中的冲突和重叠，并且产生了一个修改后需求的集合，这个需求集合还需要进行风险分析和优先排序。风险分析标识那些可能引起开发困难的需求。需要优先排序是为了允许当遇到延迟时能够容易地重新界定范围。3.3.3需求风险和优先顺序 需求可能由于各种因素而“具有风险”，典型的风险种类是：l技术风险，当需求在技术上是难以实现的。l性能风险，当需求在实现后，反而会影响系统的响应时间。l安全风险，当需求在实现后，会把系统暴露到安全缺口。l数据库完整性风险，当需求不能被容易地验证并可能引起数据不一致性。l开发过程风险，当系统要求使用开发人员不熟悉的非常规开发方法（如形式化规格说明方法）。l政治风险，当需求由于内部的政治原因被证明是难以满足的。l法律风险，当需求可能招致当前法律上的困难，或者预先假定了法律的变化。l易变性风险，当需求很可能在开发过程中不断变化或进化。3.3.3需求风险和优先顺序 理想地，需求优先级首先在需求抽取过程中从个体客户处获得，然后在会议中协商并当风险因素附加在它们上面时进行再一次修改。为了消除二义性并支持优先级的赋值，优先级分类的数目应该小一些，通常设35个不同的优先级，它们可以被命名为“高”、“中”、“低”、“不确定”。另外可选的优先级可以是“本质的”、“有用的”、“几乎不可能的事情”、“待确定的”。3.4需求管理 需求必须被管理。需求管理实际上是项目管理的一个部分，它涉及三个主要问题：l1.识别、分类、组织需求，并为需求建立文档。l2.需求变化（即带有建立对需求不可避免的变化是如何提出、如何协商、如何验证以及如何形成文档的过程）。l3.需求可跟踪性（即带有维护需求之间以及与系统的其他制品之间依赖关系的过程。3.4需求管理 l3.4.l需求识别与分类l3.4.2需求层次 l3.4.3变化管理 l3.4.4需求可跟踪性 3.4.l需求识别与分类 需求是用自然语言陈述的，如：l“根据电话销售人员的请求，系统将安排下一次给客户打电话。”l“系统将自动拨通安排好的电话号码，并同时在电话销售人员的屏幕上显示客户信息，包括电话号码、客户号、客户名宇。”l“在成功接通时，系统应将显示一段介绍性文本，电话销售人员将与客户开始进行一次对话。”通常系统由几百或几千条像上面那样的需求陈述组成。要适当地管理好这样大量的需求，这些需求必须用某种识别方案进行编号，这个方案可以包含将需求分成更便于管理的组的一个分类。3.4.l需求识别与分类 有几种对需求进行识别和分类的技术：l惟一标识符：通常是一个连续的编号，由手工方式或由 CASE工具的数据库生成（即CASE工具存储分析和设计制品的数据库（或资源库）并赋值。l在文档层次之内连续编号：考虑需求在需求文档中位置的赋值。l在需求的种类之内连续编号：加上一些帮助记忆的标识需求的种类的名字的赋值（这里，需求的种类可以是功能需求、数据需求、性能需求、安全需求等等）。3.4.l需求识别与分类 每种标识方法都有正反两个方面的理由。最灵活和不容易出错的方法是数据库生成惟一标识符的方法，数据库具有对每一个数据记录在多用户同时存取数据的情况下生成惟一标识符的固有能力。一些数据库还有对相同记录的多个版本维护的支持（通过用版本值来扩展惟一标识符的值的方法）。最后，数据库能够维护包括需求在内的建模构件之间的索引完整性链，因而能对需求变化管理和可跟踪性提供必要的支持。3.4.2需求层次 需求可以按父子关系建立层次化结构。父子关系与组合关系相似，父级需求由各种子级需求组成，子级需求是父级需求有效的子需求。层次关系将另一种层次引入了需求分类。这个层次可以直接反映，也可以不直接反映在标识编号中（用点表示）。因此，编号为4.9的需求应该是指由编号为4来标识的父级需求的第9个子级需求。3.4.2需求层次 下面是一组层次的需求：l1.“对应电话销售人员的请求，系统将安排下一次给客户打电话。”1.l“系统将对应每次Telemarketinq Control表格的输入，或前一次电话被中断时都激活Next Call的按钮。”1.2“系统将从打电话队列的顶端删除这次电话，井使得这次电话成为当前的电话。”1.3等等。3.4.2需求层次 需求的层次允许定义在不同抽象层次上的需求，这与在向低抽象层次发展时应系统地细化模型全面的建模原则是一致的。结果是，高级模型可以构造成父级需求，而低级模型可以作为子级需求链接上去。3.4.3变化管理 需求是变化的。在开发生命周期的任何阶段，需求都可以被改变、可以被删除或者可以增加新的需求。变化井不是灾难，但没有管理的变化却是。开发越往前走，变化的开销越大。事实上，由于变化而将项目沿着开发轨迹向回拖的向下开销总是增长的，巳总是指数式增长的。改变一个刚创建的还没有与其他需求链接的需求仅仅是直接编辑的工作，而当同一个需求已经在软件中实现时再去改变它就可能会出现不可承担的开销了。3.4.3变化管理 一个变化可能与人为错误有关，但常常是由于内部政策的变化或外部因素而引起的，如竞争力、全球市场或技术进步。无论什么原因，需要强有力的管理政策来建立变化需求的文档，使得能够估计变化的影响并实现变化。由于需求的变化是开销很大的，因而对每一个变化请求必须建立正式的业务用例。一个有效的变化（以前没有处理的）必须从技术可行性、对项目其他部分的影响以及开销上进行估计。一旦批准，变化就被结合进相关的模型，并在软件中实现。3.4.3变化管理 变化管理涉及跟踪大量的跨越较长时间段的相互联系的信息，没有工具的支持，变化管理注定是要失败的。理想的情况下，需求的变化应该由软件配置管理工具存储和跟踪，这个工具由开发者使用来处理在整个开发周期中模型和程序的版本。好的 CASE工具应该要么具有自身的配置管理能力，要么链接到一个独立存在的配置管理工具上。3.4.4需求可跟踪性 需求可跟踪性虽然绝对重要但却仅仅是变化管理的一部分。需求可跟踪性模块对从需求出发贯穿整个开发生命周期的变化维护一个可跟踪的关系。3.4.4需求可跟踪性 考虑需求：“对应电话销售人员的请求，系统将安排下一次给客户打电话”。这个需求可以用一个序列图来建模，通过GUI用标记为“NeXt Call”的行为按钮来激活，并用一个数据库触发器来编程。如果这些元素之间的可跟踪性关系存在，其中任何元素的变化都会使得这个关系提交进行再讨论，这个轨迹成是可疑的（用一个工具术语来说）。3.4.4需求可跟踪性 可跟踪性关系可以在连续的生命周期阶段穿越许多模型。只有相邻的可跟踪性链接可以被直接修改。例如，如果元素A被跟踪到元素B，B又到C，则在这个关系每个端点的变化都要经过两步才能完成：修改AB链接和BC链接。3.5需求业务模型 需求确定阶段捕获需求并（主要）用自然语言定义需求，采用UML进行形式化的需求建模是在以后的需求规格说明阶段进行的。然而，采集到的需求的一个高级可视化表示，称为需求业务模型，却一般在需求确定阶段完成。作为最低要求，这个高级可视化表示需要确定系统范围、识别基本的用例并建立最本质的业务类。图3-2展示了需求确定阶段这三个模型和生命周期其余阶段的模型之间的相关性。3.5需求业务模型 用例图在生命周期中的主导作用如图3-2所示。因为承认测试模型，用户文档和项目规划都是由它导出的。除此之外，用例图和类模型在连续的开发送代中还同时应用并相互导出。设计和实现也是交织在一起的，并能够反馈到需求规格说明模型。3.5需求业务模型 l3.5.l系统范围模型 l3.5.2业务用例模型 l3.5.3业务类模型 3.5.l系统范围模型 也许系统开发的主要考虑是由于变化的需求引起的范围扩张，当需求的变化不可避免时，我们不得不要求变化不要超出项目已接受的范围。问题是：“我们怎样定义系统的范围？”这个问题不是能直接回答的，因为任何系统都是一个更大的环境的一个部分，一起组成这个环境的系统的一部分。这些系统通过交换信息和相互调用服务来进行合作。因此，上述问题可以解释为：“我们必须实现这个需求吗？”或者“所要求的功能是其他系统的职责吗？”3.5.l系统范围模型 为了能够回答这个问题，我们需要知道我们的系统在其中运作的语境。我们需要知道外部实体，其他的系统、组织、人员、机器等，这些期望从我们这里得到服务或为我们提供服务的实体。在业务系统，这些服务翻译成信息，即数据流。3.5.l系统范围模型 因此，系统范围可以通过外部实体以及外部实体和我们系统之间的输入输出流来确定，我们的系统获得输入信息，并做一些必要的处理而产生输出信息。任何不能由系统内部处理所支持的需求都在系统的范围之外。UML没有提供好的可视化模型来定义系统的范围，因此，老式的DFD语境图常常被应用于此。图3-3展示了电话销售应用的语境图。系统范围建模示例（例（例3.1电话销售）电话销售）考虑关于电话销售的问题陈述，并为它构造语境图。除此之外，还考虑如下需求：l1.活动按照社会信托人出于有价值和合时宜的原因提出的建议来规划。活动必须经当地政府批准，活动的设计和规划由一个独立的 Campaign Database应用系统来支持。l2.还有一个独立的 Supporter Database来存储和维护所有支持者的信息过去的和未来的。这个数据库用于在特定的活动中选择要联系的支持者，选择出来的部分支持者交给该活动中的电话销售行为。l3.来自支持者的彩票定单在活动过程都要记录下来，由Order Processing系统处理。一个定单处理系统维护支持者数据库中的定单状态。图3-3显示了你可能提出的作为这个例子的解决方案的语境图。图中间的“圆泡”表示我们的系统，围绕它的长方形框指定为外部实体，箭头描绘了数据流，数据流更细的信息内容在图上是不可见的，数据流的内容独立定义和存储在 CASE工具的资源库中。系统范围建模示例（例（例3.1电话销售）电话销售）Telemarketing系统从外部实体Campaign Database那里获取当前活动的信息。该信息包括票的数目和价格、彩票中奖值、活动期限等等。同样，Telemarketing从Supporter Database那里获取支持者的细节。在电话销售活动打电话的过程中，关于支持者的新的信息可能出现（例如支持者想要改变他们的电话号码）。Supporter Database需要依此更新，因而数据流Support Details是双向的。系统范围建模示例（例（例3.1电话销售）电话销售）主要的活动是在Telemarketing和Supporter之间，数据流Conversation包含电话通话期间被交换的信息。一个支持者对电话销售人员对供应的购买彩票的回复沿数据流outcome传送，而另一个独立的数据流Ticket Placement用于记录由支持者预定彩票的细节。系统范围建模示例（例（例3.1电话销售）电话销售）彩票预定的进一步处理超出了我们系统的范围。数据流Ticket Order转送到外部实体order Processing。我们可以假设在预定输入后，别的外部实体可以处理支持者的付款、票的寄出、抽奖等。这些不是我们所考虑的，只要来自外部实体Campaign Database和Supporter Database的定单当前状态和付款等对我们来说是存在的就可以了。系统范围建模示例（例（例3.1电话销售）电话销售）3.5.2业务用例模型 业务用例模型是一个在较高的抽象级别上的用例模型。业务用例模型标识高层业务进程：业务用例。业务用例相当于经常被称为系统特征的东西（系统特征在视点文档中标识。如果一个视点文档存在，则它可以用来代替业务用例模型）。3.5.2业务用例模型 业务用例图的焦点是业务进程体系结构。这个图提供了所希望的系统行为的鸟瞰图，对每个业务用例的陈述性描述是简短的和面向业务的并集中在活动的主要流程上。业务用例模型不适于传达给开发人员系统确切地应该做什么。3.5.2业务用例模型 业务用例在需求规格说明阶段被转换成用例，就是在这个阶段详细的用例才被标识。叙述性描述被扩展成包括子进程和替换进程，一些GUI界面被制作出模型，并且用例之间的关系也被建立。3.5.2业务用例模型 业务用例图中的参与者不同于语境图中的外部实体。区别在于参与者与系统交互，参与者是主动的，他们具有控制的作用，他们通过发送事件来触发用例。用例是事件驱动的，参与者与用例之间的通信线路不是数据流，它们表示来自参与者的事件流和来自用例的响应流。3.5.2业务用例模型 参与者具有很有意思的两面性。参与者对系统来说可以既是外部的又是内部的。因为他们从外部与系统交互，所以他们是外部的。因为系统可能维护关于参与者的信息，使得系统能够主动地与“外部”参与者交互，所以他们又是内部的。作为一个模型，系统规格说明必须描述系统以及环境。这个环境包含参与者，系统本身也可以保留关于参与者的信息。因此，规格说明保持了与参与者相关的两个模型：一个参与者的模型以及一个系统所记录的关于参与者的模型。业务用例建模示例例3.2（电话销售）考虑电话销售的问题陈述和语境图，构造其业务用例图。一个可能的业务用例图如图 3-4所示，有两个参与者：Telemarketer和Supporter。Telemarketer要求系统对于支持者的电话都要安排并拨号。一旦连接成功，Supporter被涉及作为一个参与者，业务用例Schedule Phone Conversation对所有参与者来说变成一块外部可见的求值的功能。业务用例建模示例例3.2（电话销售）在通话期间，Telemarketer可能需要存取和修改活动和支持者的细节。这个功能在业务用例CRUD Campaign and Supporter Details中被捕获。（CRUD是一个流行的字母首字，代表四个主要的数据操作：创建、读、更新、删除。）业务用例建模示例例3.2（电话销售）最后，业务用例Enter Conversation Outcome用于输入电话销售活动的成功或不成功的结果。这个用例传递一个对所有参与者都可标识的值。业务用例建模示例例3.2（电话销售）忽略用例 CRUD Campaign and Supporter Details和 Enter Conversation Outcome之间的关系是武断的。通常，用例之间的所有关系都可以隐藏起来，其目的是为了避免整个图太杂乱拥挤。用例倾向于拥有与大多数其他用例之间的某种类型的通信，因此包含所有关系比这个目的更重要。3.5.3业务类模型 业务类模型是一个类模型。业务类模型就像业务用例模型一样，区别仅仅在于它们的抽象层次上。业务类模型标识系统中的主要“业务对象”，支持和驾驭系统的业务数据结构。业务类模型也在一个高的抽象层次上提出，在这个层次上，我们很少对类的属性感兴趣类的名字和一个简短的描述就足够了。经常出现这样的情况，即业务用例模型的参与者被表示为业务类模型中的类。这与我们的观察，参与者对系统来说常常既是外部的又是内部的，是一致的。业务类模型示例 例3.3（电话销售）考虑电话销售的问题陈述，语境图和业务用例图，构造其业务类图。下面的提示可能具有辅助作用的。l1.系统强调的是电话的安排。电话的安排本身是一个过程式计算，即它的解决方案本质上是算法式的。而且被安排的电话队列和电话的结果必须存储在某个数据结构中。l2.像上面讨论的那样，关于参与者的信息可能需要存储在类中。业务类模型示例 例3.3（电话销售）业务类模型的第1版如图3.5所示。这个图包含六个类：其中的两个类（Supporter和Telemarketer）是从业务用例模型的参与者导出的。电话安排算法从类Supporter中获取电话号码和其他信息，给当前有空的Telemarketers中的一个安排一个电话。这个算法最终在系统数据库中用存储过程的形式实现。业务类模型示例 例3.3（电话销售）类Callscheduled包含当前电话的队列，包括那些当前正在进行的。电话结果记录在Ca11Outcome中，并被传播给其他受影响的类，如 Campaign Ticket或 SuPPorter。类Campaign包含Campaign Ticket，它能够拥有多个Callscheduled。同样，Supporter和Telemarketer可以有多个Callscheduled。Callscheduled和Calloutcome之间的关联是一对一的。3.6需求文档 需求文档是需求确定阶段的一个实实在在的结果。大多数的组织按照预先定义好的模板产生需求文档，这个模板定义了文档的结构（内容表）和风格。需求文档的主体由需求陈述组成。需求可以被划分为服务陈述（常常称为功能性需求）和约束陈述。服务陈述还可以进一步分为功能需求和数据需求。（在文献中，广义上的“功能性需求”或窄义上的“功能需求”被交替着使用。按窄义使用时，它相当于我们所说的功能需求。）3.6需求文档 除了所说的需求外，需求文档还要解决项目的问题。通常，项目的问题在文档的开头以及文档的结尾都要讨论。在文档的引言部分，项目业务的来龙去脉要讨论，包括项目的目的、投入者和主要约束。而在接近于文档结束时，所有项目其他方面的问题都要提到，包括日程安排、预算、风险、提供文档等。3.6需求文档 l3.6.l文档模板 l3.6.2项目准备 l3.6.3系统服务 l3.6.4系统约束 l3.6.5项目的其他问题 l3.6.6附录 3.6.l文档模板 需求文档的模板广泛来自教科书、标准化组织（IEEE，ANSI等）、咨询公司的Web页面、软件工程工具的供应商等。在适当的时候，每个组织应该开发自己的适合自身组织实践、文化所期望的读者、系统的类型等的标准。需求文档模板定义了文档的结构，并给出了关于文档中每一节的内容的详细指南。这个指南可以包含内容材料、动机、例子和其他方面的考虑。需求文档典型的内容表 l1项目准备l2.系统服务l3系统约束l4项目的其他问题l附录1项目准备l1.1产品的目的和范围l1.2业务语境l1.3投入者l1.4多种解决方案l1.5文档综述2.系统服务l2.1系统的范围l2.2功能需求l2.3数据需求3系统约束 l3.1界面需求l3.2性能需求l3.3安全性需求l3.4操作性需求l3.5政策和法律需求l3.6其他约束4项目的其他问题l4.1开放问题l4.2初步安排l4.3初步预算附录l术语表l业务文档和表格l参考文献 3.6.2项目准备 文档的项目准备部分主要针对管理者和决策制定者，这些人不可能仔细研究整个文档。项目的目的和范围需要在文档一开始紧跟着业务语境就清楚地解释。需求文档必须为系统做一个业务用例。特别地，必须涉及所有确立