概念设计的创建.doc

141第4章 概念设计的创建第4章 概念设计的创建在构思阶段，项目团队收集足够多的信息来启动项目，这样允许他们创建基准远景/范围文档。在构思阶段接近结束时，团队进入 Microsoft 解决方案框架（MSF）过程模型的计划阶段。在这一阶段，要保证待解决的业务问题得到充分地理解，这样才能设计出解决业务问题的解决方案。此外，还要计划如何开发解决方案，并确定是否已经有了开发解决方案的资源。在计划阶段，创建一个模型和需求文档的集合。这个模型和文档的集合构成了解决方案的功能说明书或蓝本。在计划阶段开始制作解决方案的功能说明书。在本章中，将学习计划阶段的目的，以及在计划阶段发生的三个设计过程：概念设计、逻辑设计和物理设计。还将学习功能说明书的用途和优点。另外，将详细地学习概念设计。 注意：有很多建模方法可以用来对一个公司的业务过程和主要活动进行建模。本课程主要使用用例和使用场景来对业务过程建模。学习完本章后，将能够：l 描述 MSF 过程模型的计划阶段的目的l 描述计划阶段内功能说明书的作用l 描述概念设计的目的l 分析一个概念设计l 优化一个概念设计4.1 计划阶段概述在计划阶段，团队定义解决方案：要开发什么，如何开发，由谁来开发。在这一阶段，团队准备功能说明书，完成设计过程，准备工作计划、成本估计以及各种交付成果的日程表。在本课中，将学习计划阶段的目的以及在计划阶段中不同 MSF 角色的责任。此外，还将学习本阶段的主要交付成果。学习完本课后，将能够：l 描述计划阶段的目的l 描述计划阶段的三个步骤和中间角色l 描述计划阶段中不同 MSF 角色的责任l 确定计划阶段的公共交付成果4.1.1 计划阶段图4-1 计划阶段在开始学习计划阶段及其交付成果之前，理解计划阶段在整个 MSF 过程中的位置是非常重要的。图4-2说明了计划阶段在 MSF 过程模型中的位置。图4-2 计划阶段在 MSF 过程模型中的位置（1） 进入计划阶段在构思阶段，团队收集足够多的信息以确定项目的范围。在构思阶段，只要团队收集了足够的信息，可以开始组织和分析那些信息，计划阶段就可以开始了。在计划阶段，团队接过构思阶段已经完成的工作，然后继续完善并进一步组织这些工作。图4-1说明了项目团队如何从构思阶段进入计划阶段。（2） 计划阶段的目的在计划阶段，团队继续构思阶段开始的工作，特别是需求草案、任务和任务序列以及用户档案。计划阶段将得出解决方案的体系结构和设计，完成开发和部署解决方案的计划，以及与任务和资源有关的日程表。在计划阶段期间，团队努力工作以获得一个更加清晰的解决方案构想。虽然计划过程的目的是使项目前进，但是很多团队却把很多精力花在计划阶段本质上说，他们做了过多的计划。团队的关键是知道什么时候有了足够的信息可以继续前进。信息太少是一个风险，信息过多又会引起项目团队停滞不前。4.1.2 三个设计过程：概念设计、逻辑设计和物理设计图4-3 三个设计过程在计划阶段有三个设计过程：概念设计、逻辑设计和物理设计。这三个过程不是并行的。它们的开始和结束是交错的。这些过程是相互依赖的。逻辑设计依赖于概念设计，物理设计依赖于逻辑设计。概念设计的任何变动都会影响到逻辑设计，同时又会引起物理设计的变动。图4-3展示了计划阶段的三个过程。（1） 三个设计过程表 41 概括了计划阶段的设计过程。表 41设计类型角度目的概念从用户和公司的角度查看问题根据使用场景定义问题和解决方案逻辑从项目团队的角度查看解决方案将解决方案定义为一套逻辑上协同的服务物理从开发人员的角度查看解决方案定义解决方案的服务和技术注意：概念设计可以分成概念设计调研、概念设计分析和概念设计优化三个步骤。本章将着重讲述概念设计过程的这三个步骤。4.1.3 计划阶段的角色和责任图4-4计划阶段的角色和责任虽然在计划阶段项目团队作为一个整体工作，但是在这一阶段团队中每个角色都有不同的责任。l 产品管理角色保证计划满足客户需要。这个角色负责完善需求、分析当前的业务状态、优化解决方案概念以及创建概念设计l 程序管理角色保证团队得到了完成项目计划所需要的所有资源。这个角色负责整体设计，重点是放在逻辑设计和功能说明书。这个角色创建项目计划和日程表，负责完成计划阶段l 开发角色保证计划在技术上是可行的。这个角色负责创建解决方案的逻辑设计和物理设计，并将它们添加到功能说明书中。这个团队还确定开发和稳定解决方案所需的时间和工作l 测试角色保证计划满足需求。这个角色负责评估设计，评估设计的目的是确定功能是否已经测试过，并为测试功能提供一个计划和日程表l 发布管理角色为使部署、管理和支持更加容易而评估设计。此外，这一角色还计划解决方案的部署并安排其日程l 用户体验角色保证用户能够使用产品。这个角色负责分析用户需要，创建性能支持策略，对整个设计的可用性进行评估。这个角色还将对为所有用户界面交付成果开发用户支持系统和实施可用性测试所需的时间和工作进行评估4.1.4 计划阶段的里程碑和交付成果图4-5计划阶段的里程碑和交付成果计划阶段最后到达项目计划认可里程碑（approved milestone），到达该里程碑表示项目团队、客户和项目干系人对以下内容达成共识：项目交付成果、计划满足需求、计划可以成功地实现。在计划阶段的这一里程碑上最后的交付成果是：l 功能说明书（基准）。功能说明书表示根据整个团队的投入，产品应该是什么样的。你将会在本书的下一课“功能说明书概述”中学习功能说明书l 主项目计划（基准）。主项目计划是：任务的计划汇总，而任务是由六个团队角色的每一个角色来完成以实现功能说明书中描述的功能。它记录不同的团队打算完成他们的工作时所使用的策略l 主项目日程表（基准）。日程表为主计划确定了一个期限。主项目日程表跨团队同步项目日程表。它包含团队打算完成工作的期限。整合单个的日程表能够使团队对项目日程表有一个总体的认识，这是决定一个确定的交货日期的第一步l 更新的主风险评估文档。团队定期地（但主要是在这一里程碑上）复查和更新在构思阶段开发的主风险评估文档。它描述与开发解决方案相关的风险。一般来说，团队对多个风险评估排序，以确定必须解决的最高风险，并将这些风险整合到总体风险评估中所有这些文档都是即时文档，它们随项目的进展而演进。虽然这些文档可以修改，但是对文档的任何修改首先都要经过用户和干系人组成的一个委员会认可。4.2 功能说明书概述在计划阶段，项目团队的焦点开始从问题定义转向解决方案设计。MSF过程模型的计划阶段最后到达项目计划认可里程碑。在这一里程碑上一个主要的交付成果是功能说明书。功能说明书定义应该开发什么、应该如何开发、应该在什么时候开发。项目计划和日程表文档记录项目如何前进，并为项目的不同里程碑提供日期。在本课中，你将会学习功能说明书的目标和优点。你还将学习不创建功能说明书会带来的风险。创建功能说明书没有一个固定的起点和终点。在计划阶段，每个设计过程概念设计、逻辑设计和物理设计都向功能说明书提供不同的元素。随着计划阶段每个任务的完成，功能说明书变得更加完整。在物理设计结束时，功能说明书成为一个基准版本，该版本应该在整个开发过程中更新。学习完本课后，将能够：l 描述功能说明书的用途l 描述创建功能说明书的目标和优点l 列出不创建功能说明书会带来的风险l 描述功能说明书的内容4.2.1 功能说明书功能说明书是项目和成品虚拟储备库，这里的成品是指与设计相关的，在 MSF 过程模型的计划阶段创建的成品。成品是发生在计划阶段的概念设计、逻辑设计以及物理设计中的设计活动的结果。这些成品可以包括统一建模语言（Unified Modeling Language，UML）模型，例如用例图、使用场景、候选需求（演进的），候选功能以及不同的信息模型等。更多信息：UML 是一种标准的建模语言，用于对使用面向对象设计的项目编制文档。下面的参考资料提供了更多有关 UML 的信息：UML Distilled: A Brief Guide to the Standard Object Modeling Language, 2nd edition，Martin Fowler 和 Kendall Scott（Addison-Wesley，2000），Use Case Driven Object Modeling with UML: A Practical Approach，Doug Rosenberg 和 Kendall Scott（Addison-Wesley，1999）。（1） 功能说明书的格式功能说明书本身是虚拟的，搞清楚这一点是非常重要的。很多概念设计、逻辑设计和物理设计成品都很可能是电子形式的，并且保存在不同工具的数据库中。功能说明书本身可以表现为不同的形式电子形式或者纸上形式；文字文档或图形；Microsoft Word 文档或者 Microsoft PowerPoint 演示。因此，将所有这些成品收集为一个单一的物理文档或交付成果都不是很容易。功能说明书不是一个人或者一个角色的工作，而是一个团队中很多角色共同努力的结果。（2） 功能说明书的用途功能说明书通过列出将要成为解决方案的一部分的功能来描述当前版本解决方案的范围。不包括的项应该作为未来版本解决方案的潜在功能，或者作为希望或不应该考虑在范围之内的项而留在远景/范围文档中。功能说明书用来记录对有关解决方案的功能、界面、设计目标和优先级等所做的决策及达成的共识。通过使用功能说明书可以将团队设计工作的结果告知给开发团队。测试团队也使用功能说明书来创建测试脚本、测试计划和数据来测试解决方案的硬件需求。4.2.2 功能说明书的目标功能说明书的一些目标有：巩固对业务需求和用户需求的共同理解。解决方案的功能取决于解决方案将要解决的业务需求和用户需求。对于小型项目来说，需求的数量可能比较小并且容易编制成文档。而对于复杂的大型项目而言，需求的数量和复杂性会增加。功能说明书能够帮助客户和项目团队对解决方案的需求达成共识。将问题划分并在逻辑上模块化解决方案。为了使复杂的项目能够成功，团队清楚地确定问题的所有部分是很重要的。而且，团队需要将解决方案划分成不同的，明确的部分。功能说明书帮助团队将解决方案简化成为多个逻辑部分并为它们编制文档。它还帮助团队在开发过程的早期对设计做出更改。在这一阶段对解决方案做出更改比在开发过程的晚期对解决方案做出更改具有较小的风险和更小的代价。为解决方案的计划、日程安排和开发提供一个结构。功能说明书为程序经理提供一个基础来确定团队的任务，并为整个项目创建成本估计和预算。此外，程序经理还可能估计项目所需的资料和时间，并创建项目计划和日程表。测试团队使用功能说明书在项目生命周期的早期创建测试用例和测试场景。发布管理团队使用功能说明书来部署解决方案，并提供开发和测试环境。 作为团队和客户之间的一个契约，用于说明将要交付的内容。在大多数组织和项目中，功能说明书充当团队和客户之间的一个契约；它是将要开发以及交付内容的一个书面证据。功能说明书并不一定要是一个法律文件，但是它可以充当法律文件。如果有外部团队或者其他组织参与到项目中，那么功能说明书可以充当项目工作顺序的一个补遗。不创建功能说明书的风险有时候，像预算和时间之类的约束会妨碍团队创建和使用功能说明书。虽然没有功能说明书团队依然可以继续进入MSF过程模型的开发阶段，但是项目的风险会明显增加。不创建功能说明书的一些风险有：l 团队可能开发一个不完全解决用户需求的解决方案l 团队可能无法清楚地定义客户期望，无法与客户达成共识。后果是团队可能不知道他们是否正在开发所需的解决方案l 团队可能没有足够的详细信息来确认解决方案满足了客户期望并且达到了所需的质量等级l 项目经理可能无法准确地估计项目的预算和日程表。功能说明书中的信息帮助团队估计开发解决方案必需的工作和技能4.2.3 功能说明书的元素l 概念设计摘要。本节提供解决方案概念设计的一个摘要，还包括解决方案概述和解决方案体系结构的信息。功能说明书将用到以下来自概念设计的成品：l 用例l 使用场景l 上下文模型这些成品可以以各种形式存在。例如，上下文模型可以是一个现有系统的截屏，或者当前用户手册或报表的影印件；用例可以保存在一个用例文档数据库中；概念用户界面（UI）原型可以是电子形式。l 逻辑设计摘要。本节提供逻辑设计的摘要，还包括用户、对象和属性等信息。功能说明书中包括以下来自于逻辑设计阶段的成品：l 任务和任务序列模型l 逻辑对象和服务模型l 提议的解决方案概念模型l 用户界面（UI）流l 逻辑数据库模型l 系统体系结构l 物理设计摘要。本节提供物理设计文档的一个摘要，还包括来自该文档关键部分的信息，比如应用程序和基础设施部分等。功能说明书将包括以下来自于物理设计阶段的成品：l 组件打包l 组件分布拓朴l 技术使用指导方针l 基础设施体系结构和设计l UI 屏幕描述l 物理数据库模型l 标准和过程。本节包括团队在完成项目的不同任务时用作指导方针的标准和过程。此外，本节还包括将要使用的质量和性能量度的详细信息。这些量度在测试中收集，并且有助于实现需求定义的目标。根据项目的大小和范围，功能说明书中还可以包括以下部分。为了避免版本的不同步，建议使用对独立存在文档的引用，而不要复制信息。例如，功能说明书不应包括已经存在于远景/范围文档或风险评估文档中的信息。l 项目远景/范围摘要。本节概括在远景/范围文档中的业务机会、解决方案概念和项目范围。l 项目历史。本节描述有助于使项目进入当前状态的重要事件和已做的决策。记录这些信息能够保证项目团队和客户对项目已经有了相同的理解。这一信息还有助于保证彻底地理解项目。l 功能说明书摘要。该摘要通常对客户和新团队成员来说是非常有用。在收集和分析用户需求，创建 UI 设计之后创建该摘要的第一个版本。除了引用组成整个功能说明书的其他文档之外，本节一般还包含说明解决方案提议的功能的截屏。l 需求摘要。本节提供用户需求、系统需求、运营需求和业务需求的一个摘要。业务需求摘要描述客户、用户和干系人认为解决方案必须实现的功能。用户需求摘要包括使用场景，还描述谁将使用解决方案，什么时候使用解决方案以及如何使用解决方案。系统需求摘要包括系统和服务依赖性之类的信息。运营需求摘要包括组织的安全性需求、可管理性需求和可支持性需求之类的信息。l 使用场景和用例分析摘要。本节提供使用场景文档内容的一个摘要。这一摘要包括对文档中每个主要用例简要说明。l 假定和依赖性。本节列出面向项目的假定和依赖性。开发解决方案所需的技术技能集是一个依赖性例子。而解决方案使用 Microsoft Windows 操作系统作为部署系统是一个假定的例子。你还需要确定挑战和验证这些假定的测试。l 安全策略摘要。本节描述将会影响解决方案设计的安全策略。物理设计文档包含具体的安全细节，这些安全细节以每个功能或者每个组件的方式出现。本节包含安全策略的一个大纲，以及对安全计划的一个引用。l 安装和设置需求摘要。本节是安装解决方案的环境需求的摘要。这一信息来自解决方案部署计划的安装部分。物理设计文档包含如何解决这些需求的详细信息。l 移除需求摘要。本节描述解决方案如何从它的环境中移除。这个说明应该包含一个定义，定义在移除解决方案之前必须做哪些事情。此外，本节包括的信息还有，在移除解决方案之前有哪些数据必须备份，以保证在以后进行安全恢复和重建。l 集成需求摘要。本节包含集成、互操作性需求以及与这些需求相关的项目目标的摘要，同时本节还包括迁移计划的摘要。物理设计文档中包含与集成实现方面的信息。l 可支持性摘要。本节提供可支持性需求以及与这些需求相关的项目目标的摘要。这些信息包含在运营计划和支持计划中。物理设计文档描述在解决方案中可支持性如何交付。l 法律需求摘要。本节概述了所有必须考虑的法律需求。法律需求一般由客户的公司政策，以及管理客户所在行业的管理机构来定义。l 风险摘要。本节描述可能影响解决方案的开发和交付的风险。风险摘要通过估计每个风险的可能性和潜在的影响，提供了一种对比风险的方法。风险摘要还描述减轻每个风险的计划。l 参考资料。本节描述为功能说明书提供补充信息的任何内部或外部资源。l 附录。本节是团队用来开发功能说明书的设计过程的一个输出集合。它包括更多的概念设计细节，比如行业调查和用户设置等，还包括更多的物理设计细节，比如现有服务器和客户端配置等。更多信息：要想得到更多有关功能说明书的信息，请参阅 AWC Functional Specification Summary。该文档位于培训材料光盘根目录下的 AppendicesMod04 文件夹中。4.3 概念设计过程概述MSF 过程模型的计划阶段涉及到三个设计过程：概念设计、逻辑设计和物理设计。 概念设计在 MSF 过程模型的构思阶段开始，并贯穿于整个计划阶段。因为 MSF 设计过程是随反复而演进的，所以概念设计充当逻辑设计和物理设计的基础。在本课中，将会学习概念设计过程，还会学习概念设计的目标和优点。学习完本课后，将能够：l 定义概念设计l 描述概念设计的目标l 描述概念设计中的步骤l 描述概念设计的调研步骤4.3.1 概念设计图4-6 概念设计概念设计是收集、分析公司和用户对问题及解决方案的看法，并对其按优先级排序，然后创建解决方案的高层次表现的过程。（1） 开发需求团队在收集信息的过程中记录需求草案。项目团队理解需求的不同类别之间的区别是非常重要的，需求有以下几种类别：用户需求、系统需求、运营需求和业务需求。需求草案可以从最初的访谈或其他已经收集的信息中收集。随着团队更好地理解业务问题，需求草案可以开发为更加准确的陈述。这些需求叫做候选需求，以后团队将它们由用户语言转换为需求语言。注意：在本章后面的构建概念设计中，你将会学习如何将需求草案转换为候选需求。（2） 通过建模交流需求为了创建一个精确有用的解决方案概念设计，你需要提出一个有效的方法来理解解决方案，并将解决方案告知给所有类型的用户。为了进行这种交流，你需要创建解决方案范围所涵盖任务的模型。其中一种方法是对这些任务及它们的任务序列建模，以生成用例和使用场景。更多信息：有关编写用例的更详细的信息，请参阅Writing Effective Use Cases，Alistair Cockburn（Addison-Wesley，2001）。考虑下面的这个例子，假设团队已经分配到了一个设计电子商务 Web 站点的任务。为了确定客户想从电子商务 Web 站点得到什么，团队需要询问客户哪些产品线要在站点上销售，以及最终用户将如何使用站点。要回答这些问题，客户必须考虑产品编录及其维护，以及最终用户在站点上可能完成的不同活动。团队可以生成一组任务，并用用例描述这组任务。对于用户档案的每个活动，架构师将创建一个详细的使用场景。一个活动中的所有异常或可选路径也都要记录在使用场景中。（3） MSF 过程模型的概念设计正如 MSF 过程模型所定义的，概念设计发生在计划阶段。然而，项目团队可以在草拟远景文档的时候就已经开始了概念设计。在团队建立了足够的信息以供进一步收集和完善需求之后，概念设计就可以开始了。有一点需要记住的是，设计过程是反复的。因此，逻辑设计和物理设计可以与概念设计重叠。这三个设计阶段不是并行的；它们有不同的开始点和基准。由于设计过程反复的本质，可能要根据逻辑设计和物理设计的结果对概念设计进行修改。4.3.2 概念设计的目标没有概念设计，你可能就会创建出一个针对错误问题的大解决方案。创建概念设计的目标包括：l 理解待解决的业务问题。概念设计涉及到理解待解决的业务问题以及为改进业务过程而定义过程的未来状态。它具体表现为一个完善问题陈述以及将用户和公司对解决方案的需要编制成文档并进行验证的过程l 理解业务、客户和最终用户的需求。概念设计帮助项目团队确定一个项目在上下文中的需求，从而得到解决方案的一个视图，该视图注重过程同时也注重用户。该视图不局限于一系列合意的功能，它还包括业务过程和业务活动更广泛的上下文l 描述业务的目标未来状态。概念设计还形式化表示业务活动的目标未来状态。这个未来状态将变成设计过程下一阶段的基础在概念设计中，项目团队尝试理解问题的上下文，记录业务活动，并试图描绘它们的边界和它们的关系。整个功能说明书不全是在概念设计中创建的。无论如何，项目团队将使用概念设计开始创建功能说明书的工作。（1） 概念设计的范围表 42 阐明了概念设计的范围。表 42概念设计不是但是概念设计能够帮助你完整的功能说明书开始创建功能说明书系统组件的定义确定由最后的组件解决的业务问题的部分。一个技术解决方案记录业务活动，描述它们的边界和关系4.3.3 概念设计的步骤图4-7 概念设计的步骤概念设计有以下三个步骤以及相关的基准。概念设计是一个反复的过程，其步骤根据需要反复。1. 调研。在该步骤中，你将完成以下任务：l 获得关键问题的答案l 确定关键过程和活动l 对过程和活动进行优先级排序l 验证、完善和扩展在构思阶段创建的需求草案、用例及使用场景2. 分析。在该步骤中，你将完成以下任务：l 回顾用户和公司调研l 完善候选需求l 对上下文、工作流、任务序列和环境关系编制文档以及建模3. 优化。在该步骤中，你将完成以下任务：l 优化构思阶段创建的解决方案概念l 验证和测试改进的业务过程优化基准导出概念设计基准。（1） 概念设计的调研步骤在概念设计的调研步骤中，团队收集更多的信息以完善和验证在构思阶段收集的数据。一般来说，在构思阶段收集的信息是高层次的且不够详细。而在概念设计的第一步，团队需要收集详细的信息。例如，团队首先确定在信息收集的第一次反复中出现的问题；然后继续阐明这些任务，业务过程和工作流。随着团队发现更多的细节，团队将它们并入到用例和需求草案中。更多信息：在本章的后面，你将会在构建概念设计中学习概念设计的分析步骤，在优化概念设计中学习概念设计的优化步骤。4.4 构建概念设计在收集了业务需求和用户需求以及业务过程的详细信息之后，团队进入到概念设计的分析步骤。在该步骤中，团队分析在构思阶段创建的成品，然后完善并详细描述它们。在本课中，将学习如何使用需求重述来完善收集的信息，如何分类需求以及完善用例和使用场景。此外，还将学习如何为解决方案选择一个高层次体系结构。学习完本课后，将能够：l 描述概念设计的分析步骤l 重述需求l 将需求分类为用户需求、系统需求、运营需求和业务需求l 完善用例图l 为一个解决方案选择合适的应用程序体系结构4.4.1 概念设计的分析步骤在概念设计的分析步骤中，综合调研步骤收集到的信息，然后创建详细的使用场景。分析步骤的目的是：l 回顾用户和业务的过程及活动l 对业务的上下文、工作流、任务序列和环境关系编制文档和建模（1） 分析步骤的任务在分析步骤中，完成以下任务：l 综合信息l 完善用例图l 为解决方案选择合适的应用程序体系结构l 创建解决方案概念模型综合信息是吸收所收集到的数据以及解释结果的过程。团队将收集到的数据转换为有意义的信息。要综合数据，项目团队需要完成以下任务：l 确定与用户所说、所做相关的散乱信息l 记录用户完成任务的详细流程l 确定用户使用的工具和信息l 确定在用户完成一个任务时发生的异常和可选任务序列l 对业务过程、业务系统和用户之间的关系建模l 对用户工作的当前环境以及该环境可能发生的任何变化建模（2） 分析步骤的交付成果表 43 展示了分析步骤的主要任务和交付成果。表 43任务交付成果综合收集到的信息信息模型：业务过程、业务系统和用户之间的关系工作流过程任务序列更新的用户设置候选需求详细的用例创建使用场景当前的使用场景4.4.2 重述需求图4-8重述需求在重述需求时，需要将以下标准铭记于心：l 需求必须是定义完善的。定义完善的需求是一个完整的句子，并且一般都使用将、可以、必须，应该等词l 需求必须简练。每个需求必须只解决一个惟一项l 需求必须是可测试的。每个需求必须有特定的输入产生可知的输出l 需求必须组织为相关需求的一个层次结构。需要将相关的需求组织在一个单一的高层次需求之下，以组成功能集l 需求应该用业务语言编写，并且不能包含行业术语（1） 重述需求的例子考虑下面的潜在的需求表述。项目团队直接从构思阶段的访谈记录中收集和形式化了这些需求。需求编号需求1根据产品和位置确定最佳客户；他们是销售人员应该关注的客户。（收益分析和地理分析）2确定一个客户的销售量的减少3确定最佳客户4确定高级买主在概念设计的分析步骤，团队重述需求以保证每个需求都是简练、完整、可测试的语句。在团队完善需求时，他们可能还会发现新的需求。根据上表中的需求，下表列出了重述后的需求。重述后的需求更加接近它们最后的形式，即简练、完整、可测试的语句。多个相关的需求被组织在一个逻辑层次结构中。需求编号需求1.1必须能够根据产品、客户和区域分析客户数据。还有其他需要吗1.1.1必须能够根据产品分析收益1.1.2必须能够根据客户分析收益1.1.3必须能够根据区域分析收益1.2必须能够对客户排序（升序、降序）。（我们需要对这些项进行升序和降序两种排序吗？）1.2.1必须能够根据销售量对客户排序（升序、降序）1.2.2必须能够根据特定产品的销售量对客户排序（升序、降序）1.2.3必须能够根据在某个区域的销售量和某段指定的时间内的销售量对客户排序（升序、降序）。（假设天是最小的时间段，检验？）1.2.4必须能够根据某段时间内的销售量对客户排序（升序、降序）。（假设天是最小的时间段，检验？）1.3必须能够确定销售趋势1.3.1必须能够确定销售减少1.3.2必须能够确定某个客户销售量的下滑注意：记住在每一步你都必须让客户验证需求。4.4.3 对需求进行分类图4-9对需求进行分类有时候，系统在开发时考虑更多的是技术因素或系统约束，而非关键的业务需求。或者一个系统的设计可能满足纸上的需求，但是对于特定的一类最终用户和干系人来说依然缺少关键的成功因素。对需求进行分类能够使你确信团队已经彻底发现了所有关键需求。（1） 什么时候对需求进行分类在完善需求之后，你可以将需求分类为用户需求、系统需求、运营需求和业务需求。（2） 用户需求用户需求 定义用户与解决方案交互的非功能方面。它们可以帮助你根据解决方案的可靠性、可用性和可访问性来确定其用户界面和性能期望。此外，它们还能够帮助确定用户需要哪些培训才能有效地使用解决方案。一个成功的解决方案既要满足组织在技术上的需要，又要满足用户对使用该技术的期望。（3） 用户需求的例子下面是一些用户需求：l 在任何单一销售调用中，销售代表不应该键入任何他们以前已经输入过的姓名l 收银员应该能够在每分钟内完成多个交易l 在五分钟内客户应该能够在购物 Web 站点完成一个产品的购买（4） 系统需求系统需求 指定系统中的原子事务以及它们的顺序，它帮助项目团队定义新系统如何与现有系统交互。项目团队还确定新系统对他们必须管理的外部系统的关键依赖性。在开发一个新系统之前，项目团队必须理解组织内当前的基础设施。这样有助于项目团队设计和开发的系统能够以最小的负面影响部署到组织中。（5） 系统需求的例子下面是一些系统需求：l 所有支持接近实时（near-real-time）用户通知的企业经营项目（line-of-business）应用程序，要么必须实现认可的通知组件，要么必须在最后的设计评审时已经接收到一个弃权说明书l 除非用户凭证是登录到公司网络来通过验证，否则解决方案不需要再要求用户凭证（6） 运营需求运营需求描述为了提供最大可运营性，以及通过减少停机时间和风险来改进服务交付，解决方案必须交付什么。它解决运营的以下关键要素：l 安全性l 可用性及可靠性l 可管理性l 可扩展性l 可支持性（7） 运营需求的例子考虑下面这个例子，假设一家零售商店需要实现一个电子商务 Web 站点。该站点的一些运营需求包括：l 可用性和可靠性。客户应该能够访问站点，并在规定的服务级别内在任何时间使用站点的资源l 可扩展性和灵活性。解决方案应该能够处理变化的用户量和事务量。此外，站点必须设计为在不影响可用性或性能的前提下能够修改和升级。基础设施和业务过程都必须具备可扩展性和灵活性l 性能可管理性。站点设计应该包括一个系统，该系统负责管理在规定服务级别内总系统吞吐量和响应时间l 强安全性。系统中的数据、服务、设备必须受到保护，以防止未授权的访问。系统还应该提供身份验证和安全交易l 管理的可操纵性。站点应该允许管理员在现场和远程完成他们的任务l 可恢复性。站点应该能够在没有重大的影响，或者在规定的服务级别内从严重失败中恢复（8） 业务需求业务需求描述组织和用户对解决方案的需要和期望。业务需求定义了为利用商业机会或满足商业挑战，解决方案必须交付的东西。为了确定业务需求，你需要考虑将公司看作是一个有效的实体，该实体对解决方案有它自己的一组需要。这些需求存在于管理决策层，并提供解决方案运营的上下文。（9） 业务需求的例子下面是一些业务需求：l 呼叫中心经理必须能够查看每个电话操作员的上一个呼叫时间、当前呼叫时间和平均呼叫时间l 收银员能够在没有超级用户密码的情况下将一个物品的价格提高到某一指定的值l 解决方案必须尽可能快地设计、开发和部署l 解决方案必须能够与其他业务过程、应用程序和数据源进行交互和通信设想下面的这个例子，假设一家音乐商店想要提高其 CD 和 DVD 的销售量，并扩大其市场范围。因此音乐商店决定实现一个在线购物站点。这个音乐商店的一些业务需求如下：l 在用户提交了一个订单之后，库存必须标记为“待执行”，并从“可用”状态中删除l 应用程序必须提供一个方法，可以对达到一定数量的订单进行打折4.4.4 完善用例图在构思阶段，项目团队创建一个指定了组织中所有高层次用例的用例图。这个用例图的用途是列出系统中的关键用例，以定义解决方案的范围，为解决方案概念提供一个基础。为了创建解决方案概念模型，你需要使用概念设计的调研步骤所收集到的信息来完善解决方案范围内的用例。为了完善用例图，你需要完成以下任务：l 创建子用例l 为每个子用例创建使用场景l 根据最初的访谈以及其他文档，由用户确认每个用例和使用场景l 根据确认的用例和使用场景信息完善需求图4-10展示了完整的用例集合。该图现在以数字表示出了它的层次，但是没有展示它的子用例。例如，Manage Orders 就包含很多需要编制文档的子任务。图4-10 完整的用例集合（1） 创建子用例为了创建子用例，你需要回顾项目范围内用例图中的每个用例。然后你需要确定每个与用例相关的任务，并将它们建模为高层次用例的子用例。你还要确定完成任务的所有操作者，以及不同任务的操作者之间的关系。图4-11展示了一个完善后的用例图。该图展示了 Manage Orders 用例的很多子用例。图4-11 完善后的用例图（2） 子用例的使用场景在创建子用例之后，你需要为新用例创建使用场景。该步骤包括详细说明初始的使用场景，并添加一个详细的场景叙述；指定基本路线；如果存在可选路线，指定一个可选路线；以及描述前提条件和后置条件。以下是 Adventure Works Cycles 用例分析中一个高层次用例的一个简单的使用场景。用例标题：Order Product Specifications（订购产品说明书）标题缩写：Order Product Specifications（订购产品说明书）用例编号：UC 05.1需求编号：14.1目的：提供完整的（非基本的）产品说明书文档给客户。场景叙述：在客户查看编录中的一个项时，客户请求产品说明书。操作者：客户前提条件： l 客户正在浏览产品编录l 客户正在浏览编录中的一个项基本路线：1. 用例开始于客户点击 Order Specifications for This Item（订购该产品的明书） 。2. 客户选择说明书的格式。3. 客户选择交货的方法。4. 确认地址。5. 用例结束于订单完成、提交并处于准备执行状态。可选路线：后置条件：订单完成、提交并处于准备执行状态。使用/扩展：扩展 UC 05.9，创建订单用户实现请求：没有频率：占 Web 客户会话的17%未决问题：没有授权：Mike Danseglio修改历史：日期：2003年9月6日作者：Heidi Steen描述：初始版本Order Product Specification 用例有一个子用例 Order Product Specifications by Mail。该子用例的使用场景如下：用例标题：Order Product Specifications by Mail（通过邮件索取订单产品说明书）标题缩写：Order Product Specifications by Mail（通过邮件索取订单产品说明书）用例编号：UC 05.1.1需求编号：14.1.1目的：为客户提供一个通过邮政服务接收所选的编录项说明书的方式。场景叙述：客户想要通过邮政服务接收一个产品说明书。客户浏览编录（UC 06.1）并查看他感兴趣的编录项。在选择使用邮政服务交货方式之后，客户必须指定一个交货地址。如果客户已经以一个有效的帐号登录，那么他可以从文件中的地址列表中选择一个地址。客户还可以通过一个表单指定地址。在提交了请求之后，客户接收一个供将来参考的确认号码。操作者：客户前提条件：l 客户浏览产品编录l 客户查看编录中的一个项基本路线：1. 用例开始于客户点击 Order Specifications for This Item 。2. 客户选择说明书的格式，比如说明书电子表或小册子。3. 客户选择交货方式，比如电子方式、联邦邮政服务方式、一日交付方式、或两日交付方式等。4. 用户档案中的地址列表出现。5. 客户从地址列表中选择一个地址。6. 客户确认地址。7. 客户提交请求。8. 用例接受于客户得到确认号码。可选路线：1. 可选路线从第4步开始。2. a.案中没有地址。3. b.到 Customer Updates Profileor Customer Creates Profile。4. 用例重新从第5步开始。后置条件：订单完成、提交并处于准备执行状态。用户返回到 Browse Products 中的最后一个视图。使用/扩展：扩展 UC 05.1，Order Product Specifications用户实现请求：没有频率：占 Web 客户会话的6%未确定问题：没有授权：Mike Dansglio修改历史：日期：2002年9月6日作者：Heidi Steen描述：初始版本（3） 确认用例和使用场景团队让用户和其他干系人确认候选需求、用例和使用场景是非常基本的。该步骤有助于确定在过程中是否有任何步骤还没有编制成文档。团队然后根据需求开发功能列表。功能列表的修订通过清楚说明用例来确定，而向该列表中添加任何内容都要经过客户的确认。记住确认是一个反复的过程。它能够帮助你确定需求、用例以及使用场景中的遗漏信息。4.4.5 选择应用程序体系结构图4-12选择应用程序体系结构概念设计的主要交付成果是解决方案概念模型。为了能够创建概念模型，需要理解解决方案必须提供的服务。（1） 解决方案中的服务服务定义为一个应用程序逻辑单元，它包括实现一个操作、一个功能或一个转换的方法。服务与行为相关，用于实现业务守则、操纵数据，并允许一些行为，比如添加、检索、查看和修改数据。服务可以使用一个包含接口规范的公共接口通过网络来访问。客户不关心服务如何实现，他们关心完成必要行为的能力。服务可以简单，也可以复杂。例如，创建、读取、更新和删除信息的服务就比较简单。你还可以开发实现复杂数学运算的服务。（2） 服务类型一个解决方案一般提供的服务有：l 用户服务。用户服务是在应用程序中提供用户界面的应用程序逻辑单元。应用程序的用户服务管理应用程序与它的客户之间的交互。要设计有效的用户服务，你需要彻底地理解应用程序的用户，他们所执行的任务，以及他们使用应用程序执行活动的典型交互l 业务服务。业务服务是以正确顺序执行业务规则的应用程序逻辑单元。业务服务隐藏业务规则的实现逻辑，以及对用户服务、其他业务服务和数据服务传来的数据进行转换l 数据服务。数据服务是提供操纵数据的最低可见级细节的应用程序逻辑单元。数据服务用以在应用程序所使用的数据存储上实现业务模式。数据服务用于管理各种数据静态数据、结构化数据和动态数据。你需要在用户服务或业务服务要访问数据或操作数据的所有场景中使用数据服务l 系统服务。系统服务是提供业务逻辑之外的功能的应用程序逻辑单元。常见的系统服务包括 备份服务 错误处理服务 安全服务 消息服务（3） 服务的例子表 44 列出了一个订单处理应用程序中的不同服务：表 44服务例子用户服务显示订单服务显示客户帐号服务显示产品信息服务业务服务下订单服务更新客户帐号服务检索产品信息服务检查产品库存服务数据服务订单信息服务客户帐号服务产品信息服务记住，要根据服务的功能，而不要根据服务的位置来对服务进行分类。将服务分类为用户服务、业务服务或数据服务取决于服务具体做什么，而不取决于它的位置。例如，位于客户端工作站上的数据服务依然是数据服务。（4） 应用程序体系结构同样必须知道在解决方案中如何组织服务。服务要依据应用程序体系结构来组织。应用程序体系结构由形成一个应用程序结构的定义、规则和关系所组成。它展示了应用程序的组织方式，但不包括实现细节。它关注于解决方案而非用来实现解决方案的技术。为了能够开发解决方案的概念模型，你需要选择解决方案将要使用的应用程序模型以及候选应用程序的体系结构。项目团队根据解决方案必须提供的用户对应用程序的性能期望来选择体系结构。此外，项目对解决方案的假定和约束也会影响解决方案的应用程序体系结构的选择。假定包括在系统中使用的操作系统。约束的例子有完成项目的预算、时间、技能以及资源可用性。可以使用的应用程序体系结构包括：l 客户端/服务器体系结构l 分层体系结构l 无状态体系结构l 缓存体系结构l 分层-客户端-缓存-无状态-缓存-服务器体系结构在解决方案中，根据需要你可以使用很多不同的层及服务，选择不同的状态和缓存来定义服务。图4-12中展示了结合使用服务和层作为一种组织应用程序的方式。（5） 客户端/服务器体系结构客户端/服务器体系结构是一个基于请求-提供（request-provide）策略的两层方法。客户端启动一个与服务器的会话，并控制会话，根据需要支持服务器。首先客户端请求服务器的一个服务，然后服务器在接受到请求之后，完成需要的操作并返回结果给客户端。实现这个应用程序体系结构的优点是，可以将完成一个任务所需的处理分配到两个设备上。客户端可以执行专门的处理，从而避免由于处理请求造成服务器过载。然而，这种体系结构的一个局限性是客户端非常依赖于服务器。如果客户端不能与服务器通信，那么它甚至连最基本的任务都不能完成。当应用程序需要可扩展性时，就不应该使用这种应用程序体系结构，因为它面向的是必须处理非常多请求的任何解决方案。（6） 分层体系结构分层体系结构是客户端/服务器体系结构的一个演进，它由多个处于不同层次的层所组成。应用程序中的不同服务以某种方式清楚地定位在特定的层中，这种方式即一个服务只能与它相邻层中的服务通信。层将服务包装并将服务相互隔离，同时提供了一组用于共享资源的简单接口。表示层、业务层、数据服务层和数据存储层是分层体系结构中的几个不同的层。分层体系结构的一些优点包括它能提高系统可扩展性并提供较高的安全性。可以在可用的资源和各层之间平衡服务。此外，层还允许你在定义完善的边界上实现安全性，同时对系统内服务之间通信的负面影响又很小。分层增加了系统的开销和延迟，从而会给系统的性能带来用户能够感觉到的负面影响。可以通过为系统增加共享缓存来降低这个问题的影响。然而，该方法会增加解决方案的复杂性、设计和开发解决方案的工作、以及运营解决方案必需的资源。（7） 无状态体系结构无状态体系结构是客户端/服务器或分层体系结构的一个版本，在这种体系结构下，每个客户端请求包含服务器理解和处理请求所必须的所有信息。客户端不存储任何信息。无状态系统的优点包括：l 改进的可见性。例如，一个监控系统只需要读取一个单一请求就能够确定请求的全部信息l 可靠性。例如，解决方案可以容易地从一个部分失败中恢复l 可扩展性。解决方案使用的资源可以快速地发布，并且很容易收回注意：无状态环境为客户端增加了额外的负担，即它们要管理自己的状态。因为在每个请求中有更多的信息发送给服务器，所以发送的总请求数也相应地会减少。因此，通信通道上的负载也会随之降低。（8） 缓存体系结构缓存是应用程序处理客户端请求的另外一种方法，使用这种方法的应用程序无须将请求转发给其他设备。要实现这种应用程序体系结构，需要确定什么能够缓存