需求分析与系统设计3

需求分析与系统设计第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）。如果业务分析员没有足够的领域知识的话，可以把领域专家找来面谈。3.2.1.1与客户和领域专家面谈与领域专家的面谈经常是一个知识转换的过程，即对业务分析员来说是一个学习过程。与客户的面谈就比较复杂了。客户可能对他们的需求只有一个模糊的认识，他们也可能不愿意合作或不能够表达他们的需求，他们还可能提出超出项目预算或不可实现的需求。最后，来自不同客户的需求还可能发生冲突。3.2.1.1与客户和领域专家面谈面谈法有两种基本形式：结构化的（形式化的）和非结构化的（非形式化的）。结构化面谈法需要提前准备，有一个明确的日程，并且许多问题都是预先确定的。有一些问题可以是无确定答案的（对这些问题，其答案无法预计），其他问题可以是有确定答案的（回答从提供的答案中选取）。3.2.1.1与客户和领域专家面谈结构化面谈法需要非结构化面谈法进行补充。非结构化面谈法更像非正式的会议，没有预定的问题或预计的目的。非结构化面谈法的目的是鼓励客户讲出他/她的想法，并且在这个过程中导出业务分析员没有想到的和因而没能提出的相关问题的需求。结构化和非结构化面谈法都必须有某个出发点和讨论的语境，这可以是一篇短的书面文档，或在解释面谈者目的或提出问题的会议之前发送给面谈对象的e－mail。3.2.1.1与客户和领域专家面谈一般来说，有三种问题应该避免：固执己见的问题。在这种问题中，面谈者（直接地或间接地）表达了你她自己关于这个问题的观点（“我们必须按我们做这件事的方式来做它吗？”）。带偏见的问题。它类似于固执己见的问题，但面谈者的观点明显是有偏见的（“我们不做这件事，对吗？”）。强加的问题。它假设了问题的答案（“你用这种方式做这件事，对吗？”）。3.2.1.1与客户和领域专家面谈成功的面谈存在许多因素，但也许最重要的是面谈者的沟通和人际交流技能。与面谈者提出问题和控制面谈过程的同时，认真倾听和保持耐心从而使得面谈对象不感到拘束也是同等重要的。为了维持好的人际关系并得到好的反馈，简单综述面谈的备忘录应该在一两天内发给面谈对象。3.2.1.2问卷法问卷法是从多个客户中收集信息的有效方法。它一般用来作为面谈法的补充形式，而不是要替代它。但有一个例外，就是非常了解的低风险项目。对这种项目，具有被动特征和不是很深入的问卷法就已经足够了。3.2.1.2问卷法一般而言，问卷法没有面谈法有效，因为无法澄清问题和可能得到的响应。问卷法是被动的，就它本身来说既有优点也有缺点。优点在于回答者有时间去考虑如何回答，并且口答可以是匿名的。缺点在于回答者不容易弄清楚这些问题的含义。3.2.1.2问卷法问卷应该设计成便于问题的回答。特别地，应该避免开放式问题——大多数问题都应该是封闭式的。封闭式问题可以采用如下三种形式：评分问题，回答者在这里需要表达他／她对一段陈述的观点，可能的分值可以是强烈同意、同意、中立、不同意、强烈不同意和不知道。多项选择问题，回答者在这里必须从提供的答案集中选取一个或多个答案。可以允许回答者附加注释。排序问题，这里所提供的答案应该用序数、百分比或相似的排序方式给出。3.2.1.2问卷法一个设计良好，易于回答的问卷将鼓励回答者及时返回完成的文档。但是，在评估问卷结果时，业务分析员应该考虑到由于有些人没有回答以至于可能提供不同的答案的这个事实所带来的偏差。3.2.1.3观察存在这样的情景，其中业务分析员发现通过交谈法和问卷法都很难获得完整的信息。客户可能不能够有效地表达信息，或者只有一个完整的业务过程中的片段知识。在这种情况下，观察可能是有效的事实发现技术。学习如何系领带的最好方法就是观察这个过程。3.2.1.3观察观察可以有两种形式：被动观察，业务分析员在这里不受干扰或直接干预的情况下观察业务活动。在有些情况下，摄像机可以用来进行更少干扰的观察。主动观察，业务分析员在这里参与到活动中，并且有效地成为其中的部分。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现代需求抽取方法3.2.2.1原型法3.2.2.2联合应用开发3.2.2.3快速应用开发3.2.2.1原型法原型法在现代需求获取方法中是最常用的方法。构造软件原型为了使系统或者是系统的一部分对客户可视化以获得他们的反馈。原型是一个演示系统，它是解决方案的一件“快速而粗糙的”工作模型，它呈现出GUI（图形用户界面），并且对各种用户事件模拟系统的行为。GUI屏幕上的信息内容在原型程序中是硬编码的，而不是从数据库中动态取得的。3.2.2.1原型法现代GUI的复杂性（和增长的客户期望）使原型法成为软件开发中必不可少的因素，系统的柔性和可用性可以通过原型在开始真正的实现之前就估计出来。通常，系统原型是抽取从客户那里用其他方式难以抽取的需求的一种非常有效的方式。对增加新的业务功能的系统常常是这种情况，对冲突的需求或者在客户和开发人员之间有沟通问题时也是如此。3.2.2.1原型法原型有两种：“丢弃”式原型。它是当需求抽取完成时要被丢弃的。“丢弃”式原型针对生命周期的需求确定阶段，它集中在理解得最少的需求上。进化式原型。它是在需求抽取之后仍保留并被用来产生最终产品。进化式原型目标在于产品发布的速度，它集中在理解得最好的需求上，使得产品的第1版能够很快发布（虽然只具备不完整的功能）。3.2.2.1原型法支持“丢弃”式原型的另一个论断是，它避免了在最终产品中保留“快速而粗糙”或者不够有效的方案。然而，当代软件生产工具的能力和灵活性淡化了这个论断。在一个管理得很好的项目中也不能根除无效原型是没有道理的。3.2.2.2联合应用开发JAD在一个或多个工作会议中的一次联合应用开发将所有的投入者（客户和开发人员）带到了一起。虽然我们在这里将JAD归为现代需求抽取方法，但这种技术还是（由IBM）在20世纪70年代后期引入的。有许多JAD的品牌，也有许多专门提供组织和执行JAD活动的服务的咨询公司。一次JAD会议可能要几个小时、几天或者甚至一两个星期，参加者的人数不应超过25到30人。3.2.2.2联合应用开发会议