需求分析与系统设计3.ppt

需求分析与系统设计 第3章 需求确定 需求确定是一种关于社会、沟通和管理的技能。它是系统开发中最不需要技术的一个阶段，但是，如果没有完全地进行，其结果将会比其他阶段更糟。由于没有捕获、忽略或错误地理解客户需求，为此而付出的代价在软件过程的以后阶段将是不可承受的。 需求确定 本章介绍需求确定中的一系列范围广泛的问题。本章前半部分涉及需求抽取、协商和验证以及需求管理的问题，后面还包括可追踪性和变化管理的问题，这个问题我们将在第10章中详细讨论。 本章后半部分介绍用于描述与组织和目标应用领域相关的业务模型的基本图形建模技术。还讨论了需求文档的结构。 第3章 需求确定 3.1需求确定的原则 3.2需求抽取 3.3需求协商和验证 3.4需求管理 3.5需求业务模型 3.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需求抽取 3.2.l传统的需求抽取方法 3.2.2现代需求抽取方法 3.2.l传统的需求抽取方法 传统的需求抽取方法包括面谈记问卷法、观察法和业务文档研究法。这些都是简单和合算的方法。 但这些传统方法的效果与项目的风险是成反比的。高风险意味着系统难以实现，甚至高层的需求也非常不清楚。在这种项目中，这些传统的方法就不可能胜任。 3.2.l传统的需求抽取方法 3.2.1.1与客户和领域专家面谈 3.2.1.2问卷法 3.2.1.3观察 3.2.l.4文档和软件系统的研究 3.2.1.1与客户和领域专家面谈 面谈法是事实发现和信息聚集的基本技术。大多数的面谈过程都是与客户一起进行的。与客户面谈大多用来抽取“用例”需求（图3-1）。如果业务分析员没有足