1、软件工程第4章 理解需求主要内容v需求工程需求工程v建立根基建立根基v导出需求导出需求v开发用例开发用例v构建需求模型构建需求模型v协商需求协商需求v确认需求确认需求v小结小结需求工程v需求工程帮助软件工程师更好地理解他们需求工程帮助软件工程师更好地理解他们将要解决的问题。其中所包含的一系列任将要解决的问题。其中所包含的一系列任务有助于理解软件将如何影响业务、客户务有助于理解软件将如何影响业务、客户想要什么以及最终用户将如何和软件交互。想要什么以及最终用户将如何和软件交互。v软件工程师软件工程师和和项目共利益者项目共利益者都将参与需求都将参与需求工程。工程。需求工程v在设计和开发某个一流的计算
2、机软件时，在设计和开发某个一流的计算机软件时，如果软件解决的问题不对，那么即使软件如果软件解决的问题不对，那么即使软件再精巧也满足不了任何人的要求。这就是再精巧也满足不了任何人的要求。这就是在设计和开发一个基于计算机的系统之前，在设计和开发一个基于计算机的系统之前，理解客户需求的重要性。理解客户需求的重要性。需求工程v理解问题的需求是软件工程师所面对的最理解问题的需求是软件工程师所面对的最困难的任务之一。困难的任务之一。v客户难道不知道需要什么？客户难道不知道需要什么？v最终用户难道对给他们带来实际收益的特最终用户难道对给他们带来实际收益的特征和功能没有清楚的认识？征和功能没有清楚的认识？v很
3、多情况下很多情况下的确是这样的的确是这样的。甚至即使用户。甚至即使用户和最终用户清楚地知道他们的要求，这些和最终用户清楚地知道他们的要求，这些要求也会在项目的实施过程中改变。要求也会在项目的实施过程中改变。需求工程v需求工程是指致力于不断理解需求的大量任务和技术。需求工程是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通并持续至建模。开始于沟通并持续至建模。v需求工程在设计和构造之间建立起联系的桥梁。有人认需求工程在设计和构造之间建立起联系的桥梁。有人认为开始于为开始于项目共利益者项目共利益者，
4、即在那里定义业务需求，刻画，即在那里定义业务需求，刻画用户场景，描述功能和特性，识别项目约束条件。另外用户场景，描述功能和特性，识别项目约束条件。另外一些人可能会建议从宽泛的系统定义开始，此时软件只一些人可能会建议从宽泛的系统定义开始，此时软件只是更大的系统范围中的一个构件。但是不管起始点在哪是更大的系统范围中的一个构件。但是不管起始点在哪里，横跨这个桥梁将把我们带到项目之上更高的层次：里，横跨这个桥梁将把我们带到项目之上更高的层次：由软件团队检查将要进行的软件工作的内容，必须提交由软件团队检查将要进行的软件工作的内容，必须提交设计和构建需要的特定要求，完成指导工作顺序的优先设计和构建需要的特
5、定要求，完成指导工作顺序的优先级定义以及将深切影响随后设计的信息、功能和行为。级定义以及将深切影响随后设计的信息、功能和行为。需求工程任务v需求工程为以下工作提供了良好的机制：需求工程为以下工作提供了良好的机制：理解客户需要什么，分析要求，评估可行理解客户需要什么，分析要求，评估可行性，协商合理的方案，无歧义地详细说明性，协商合理的方案，无歧义地详细说明方案，确认规格说明，管理需求以至将这方案，确认规格说明，管理需求以至将这些需求转化为可运行系统。需求工程过程些需求转化为可运行系统。需求工程过程通过执行七个不同的活动来完成：通过执行七个不同的活动来完成：起始、起始、导出、精化、协商、规格说明、
6、确认和管导出、精化、协商、规格说明、确认和管理。理。起始v通常都是当确定了商业要求或发现了潜在通常都是当确定了商业要求或发现了潜在的新市场、新服务时项目才开始。业务领的新市场、新服务时项目才开始。业务领域的共利益者定义业务用例，确定市场的域的共利益者定义业务用例，确定市场的宽度和深度，进行粗略的可行性分析，并宽度和深度，进行粗略的可行性分析，并确定项目范围的工作说明。确定项目范围的工作说明。v在项目起始阶段，软件工程师会询问一些在项目起始阶段，软件工程师会询问一些似乎与项目无直接关系的问题。目的是对似乎与项目无直接关系的问题。目的是对问题、方案需求方、期望方案的本质、客问题、方案需求方、期望方
7、案的本质、客户和开发人员之间初步的交流和合作的效户和开发人员之间初步的交流和合作的效果建立基本的谅解。果建立基本的谅解。导出v系统或产品的目标是什么？系统或产品的目标是什么？v想要实现什么？想要实现什么？v系统和产品如何满足业务的要求，最终系系统和产品如何满足业务的要求，最终系统或产品如何用于日常工作？统或产品如何用于日常工作？v而实际上导出需求却是异常的困难。而实际上导出需求却是异常的困难。导出v范围问题范围问题：系统的边界不清楚，或客户：系统的边界不清楚，或客户/用户的用户的说明带有多余的技术细节，这些细节可能会混说明带有多余的技术细节，这些细节可能会混淆而不是澄清系统的整体目标。淆而不是
8、澄清系统的整体目标。v理解问题理解问题：客户：客户/用户并不完全确定需要什么，用户并不完全确定需要什么，对其计算环境的能力和限制所知甚少，对问题对其计算环境的能力和限制所知甚少，对问题域没有完整的认识，与系统工程师在沟通上有域没有完整的认识，与系统工程师在沟通上有问题，省略那些他们认为是问题，省略那些他们认为是“明显的明显的”信息，信息，确定的需求和其他客户确定的需求和其他客户/用户的需求相冲突，需用户的需求相冲突，需求说明有歧义或不可测试。求说明有歧义或不可测试。v易变问题易变问题：需求随时间变化。：需求随时间变化。精化v精化是一个精化是一个分析建模分析建模动作，由一系列的建模和动作，由一系
9、列的建模和求精任务构成。当描述最终用户如何与系统交求精任务构成。当描述最终用户如何与系统交互的用户场景创建和求精时，就会发生精化动互的用户场景创建和求精时，就会发生精化动作，每个用户场景被分解为精炼分析类作，每个用户场景被分解为精炼分析类最最终用户可见的业务域实体。应该定义每个分析终用户可见的业务域实体。应该定义每个分析类的类的属性属性，确定每个类所需要的，确定每个类所需要的服务服务，确定类，确定类之间的之间的关联和协作关联和协作关系，并完成各种关系，并完成各种UML图作图作为补充。为补充。v精化的最终结果是形成一个精确的精化的最终结果是形成一个精确的需求模型需求模型，用以说明软件的用以说明软
10、件的功能功能、特征特征和和信息信息的各个方面。的各个方面。协商v需求工程师必须通过协商过程来需求工程师必须通过协商过程来调解调解客户客户提出的过高的目标要求和相互冲突的需求。提出的过高的目标要求和相互冲突的需求。应该让客户、用户和其他共利益者对各自应该让客户、用户和其他共利益者对各自的需求排序，然后按的需求排序，然后按优先级优先级讨论冲突。识讨论冲突。识别和分析与每项需求相关联的别和分析与每项需求相关联的风险风险；粗略；粗略“估算估算”开发工作量，并用于评估需求对开发工作量，并用于评估需求对项目项目成本和交付时间成本和交付时间的影响；的影响；使用迭代的使用迭代的方法、删除、组合或修改需求方法、
11、删除、组合或修改需求，以便相关，以便相关各方均能达到一定的满意度。各方均能达到一定的满意度。规格说明v一个规格说明可以是一份写好的文档、一一个规格说明可以是一份写好的文档、一套图形化的模型、一个形式化的数学模型，套图形化的模型、一个形式化的数学模型，一组使用场景、一个原型或上述各项的任一组使用场景、一个原型或上述各项的任意组合。意组合。v在开发规格说明时保持灵活性有时是必要在开发规格说明时保持灵活性有时是必要的，对大型系统而言，文档最好采用自然的，对大型系统而言，文档最好采用自然语言描述和图形化模型来编写。而对于技语言描述和图形化模型来编写。而对于技术环节明确的较小产品或系统，使用场景术环节明
12、确的较小产品或系统，使用场景可能就足够了。可能就足够了。确认v确认确认将对需求工程的工作产品进行质量评估。将对需求工程的工作产品进行质量评估。需求确认要检查规格说明以保证：所有的系统需求确认要检查规格说明以保证：所有的系统需求已被无歧义地说明；不一致性、疏漏和错需求已被无歧义地说明；不一致性、疏漏和错误已被检测出并被纠正；工作产品符合为过程、误已被检测出并被纠正；工作产品符合为过程、项目和产品建立的标准。项目和产品建立的标准。v正式技术评审正式技术评审是最主要的需求确认机制。确认是最主要的需求确认机制。确认需求的评审小组包括软件工程师、客户、用户需求的评审小组包括软件工程师、客户、用户和其他共
13、利益者，他们检查系统规格说明，查和其他共利益者，他们检查系统规格说明，查找内容或解释上的错误，以及可能需要进一步找内容或解释上的错误，以及可能需要进一步解释澄清的地方、丢失的信息、不一致性、冲解释澄清的地方、丢失的信息、不一致性、冲突的需求或不现实的需求。突的需求或不现实的需求。需求确认检查表v需求说明清晰吗？有没有可能造成误解？需求说明清晰吗？有没有可能造成误解？v需求的来源（如人员、规则、文档）弄清了吗？需求的最终说明是需求的来源（如人员、规则、文档）弄清了吗？需求的最终说明是否已经根据或对照最初来源检查过？否已经根据或对照最初来源检查过？v需求是否用定量的术语界定？需求是否用定量的术语界
14、定？v其他哪些需求与此需求相关？是否已经使用交叉索引或其他机制清其他哪些需求与此需求相关？是否已经使用交叉索引或其他机制清楚地加以说明了？楚地加以说明了？v需求是否违背某个系统领域的约束？需求是否违背某个系统领域的约束？v需求是否可以测试？如果可以，能否说明测试检验了需求？需求是否可以测试？如果可以，能否说明测试检验了需求？v对已经创建的任何系统模型，需求是否可跟踪？对已经创建的任何系统模型，需求是否可跟踪？v对整体系统对整体系统/产品目标，需求是否可跟踪？产品目标，需求是否可跟踪？v规格说明的构造方式是否有助于理解、引用和翻译成更技术性的工规格说明的构造方式是否有助于理解、引用和翻译成更技术
15、性的工作产品？作产品？v对已创建的规格说明是否建立了索引？对已创建的规格说明是否建立了索引？v和系统性能、行为及运行特征相关的需求的说明是否清楚？哪些需和系统性能、行为及运行特征相关的需求的说明是否清楚？哪些需求是隐含出现的？求是隐含出现的？需求管理v基于计算机的系统其需求会变更，而且变基于计算机的系统其需求会变更，而且变更的要求贯穿于系统的整个生存期。更的要求贯穿于系统的整个生存期。v需求管理是用于帮助项目组在项目进展中需求管理是用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一标识、控制和跟踪需求以及变更需求的一组活动。组活动。v需求管理从标识开始。每个需求被赋予唯需求管理从标
16、识开始。每个需求被赋予唯一的标识符。一旦需求被标识，便开始建一的标识符。一旦需求被标识，便开始建立跟踪表，每个跟踪表将标识的需求与系立跟踪表，每个跟踪表将标识的需求与系统或其环境的一个或多个方面相关联。统或其环境的一个或多个方面相关联。建立根基v在理想情况下，利益相关者和软件工程师在理想情况下，利益相关者和软件工程师在同一个小组中工作。在这种情况下，需在同一个小组中工作。在这种情况下，需求工程就只是和组里熟悉的同事进行有意求工程就只是和组里熟悉的同事进行有意义的交谈。义的交谈。但实际情况往往不是这样。但实际情况往往不是这样。v客户可能正在不同的城市或国家，对于想客户可能正在不同的城市或国家，对
17、于想要什么可能仅有模糊的想法，对于将要构要什么可能仅有模糊的想法，对于将要构建的系统可能存在不同的意见，技术知识建的系统可能存在不同的意见，技术知识可能很有限，可能仅有有限的时间与需求可能很有限，可能仅有有限的时间与需求工程师沟通。工程师沟通。软件开发团队经常被迫在这软件开发团队经常被迫在这种环境的限制下工作。种环境的限制下工作。确认利益相关者v利益相关者可定义为利益相关者可定义为“直接或间接从正在直接或间接从正在开发的系统中获益的人开发的系统中获益的人”。可以确定如下。可以确定如下几个容易理解的利益相关者：几个容易理解的利益相关者：业务操作管业务操作管理人员、产品管理人员、市场营销人员、理人
18、员、产品管理人员、市场营销人员、内部和外部客户、最终用户、顾问、产品内部和外部客户、最终用户、顾问、产品工程师、软件工程师、支持和维护工程师工程师、软件工程师、支持和维护工程师以及其他人员以及其他人员。每个共利益者对系统都有。每个共利益者对系统都有不同的考虑，当系统成功开发后所能获得不同的考虑，当系统成功开发后所能获得的利益也不相同，同样地，当系统开发失的利益也不相同，同样地，当系统开发失败时所面临的风险也不同。败时所面临的风险也不同。确认利益相关者v在开始阶段，需求工程师应该创建一个人在开始阶段，需求工程师应该创建一个人员列表，列出那些有助于诱导出需求的人员列表，列出那些有助于诱导出需求的人
19、员。最初的人员列表将随着接触的共利益员。最初的人员列表将随着接触的共利益者人数增多而增加，因为每个共利益者都者人数增多而增加，因为每个共利益者都将被询问将被询问“你认为我还应该和谁交谈你认为我还应该和谁交谈”。识别多种观点v因为存在很多不同的利益相关者，所以系因为存在很多不同的利益相关者，所以系统需求调研也将从很多不同的视角展开。统需求调研也将从很多不同的视角展开。v这些参与者中的每一个人都将为需求工程这些参与者中的每一个人都将为需求工程贡献信息。当从多个角度收集信息时，所贡献信息。当从多个角度收集信息时，所形成的需求可能存在不一致性或相互矛盾。形成的需求可能存在不一致性或相互矛盾。需求工程师
20、的工作就是需求工程师的工作就是把所有共利益者提把所有共利益者提供的信息分类，供的信息分类，分类的方法应该便于决策分类的方法应该便于决策制定者为系统选择一个制定者为系统选择一个内部一致的需求集内部一致的需求集合合。协同合作v需求工程师的工作是标识需求工程师的工作是标识公共区域公共区域（即所（即所有共利益者都同意的需求）和有共利益者都同意的需求）和矛盾区域矛盾区域或或不一致区域不一致区域（即某个共利益者提出的需求（即某个共利益者提出的需求和其他共利益者的需求相矛盾）。和其他共利益者的需求相矛盾）。v很多情况下，共利益者的协作是很多情况下，共利益者的协作是提供他们提供他们各自关于需求的观点各自关于需
21、求的观点，而一个有力的，而一个有力的“项项目领导者目领导者”可能要对删减哪些需求做出最可能要对删减哪些需求做出最终判断。终判断。基于“优先点”的投票方案v所有的共利益者都会分配到一定数量的优所有的共利益者都会分配到一定数量的优先点，这些优先点可以适用于很多需求。先点，这些优先点可以适用于很多需求。每个共利益者在一个需求列表上，通过向每个共利益者在一个需求列表上，通过向每个需求分配一个或多个优先点来表明该每个需求分配一个或多个优先点来表明该需求的相对重要性（从他或她的个人观需求的相对重要性（从他或她的个人观点）。优先点用过之后就不能再次使用，点）。优先点用过之后就不能再次使用，一旦某个共利益者的
22、优先点用完，他就不一旦某个共利益者的优先点用完，他就不能再对需求实施进一步的操作。所有共利能再对需求实施进一步的操作。所有共利益者在益者在每项需求上的优先点总数每项需求上的优先点总数显示了该显示了该需求的综合重要性。需求的综合重要性。首次提问v第一组与环境无关的问题集中于客户和其第一组与环境无关的问题集中于客户和其他共利益者、整体目标、收益。他共利益者、整体目标、收益。v谁是这项工作的最初提出者？谁是这项工作的最初提出者？v谁将使用该解决方案？谁将使用该解决方案？v成功的解决方案将带来什么样的经济收益？成功的解决方案将带来什么样的经济收益？v对于这个解决方案你还需要其他资源吗？对于这个解决方案
23、你还需要其他资源吗？首次提问v下一组问题有助于软件开发组更好地理解下一组问题有助于软件开发组更好地理解问题，并允许客户表达其对解决方案的看问题，并允许客户表达其对解决方案的看法。法。v如何描述由某成功的解决方案产生的如何描述由某成功的解决方案产生的“良好良好的的”输出？输出？v该解决方案强调了什么问题？该解决方案强调了什么问题？v能向我们展示（或描述）解决方案的使用环能向我们展示（或描述）解决方案的使用环境吗？境吗？v存在影响解决方案的特殊性能问题或约束吗？存在影响解决方案的特殊性能问题或约束吗？首次提问v最后一组问题关注于沟通活动本身的效率。最后一组问题关注于沟通活动本身的效率。v你是回答这
24、些问题的合适人选吗？你的回答你是回答这些问题的合适人选吗？你的回答是是“正式的正式的”吗？吗？v我的提问和你想解决的问题相关吗？我的提问和你想解决的问题相关吗？v我的问题是否太多了？我的问题是否太多了？v还有其他人员可以提供更多的信息吗？还有其他人员可以提供更多的信息吗？v还有我应该问的其他问题吗？还有我应该问的其他问题吗？首次提问v这些问题将有助于这些问题将有助于“打破坚冰打破坚冰”，并有助，并有助于交流的开始，而且这样的交流对需求导于交流的开始，而且这样的交流对需求导出的成功至关重要。但是，会议形式的问出的成功至关重要。但是，会议形式的问与答并非一定是会取得成功的好方法。事与答并非一定是会
25、取得成功的好方法。事实上，实上，Q&A会议会议应该仅仅用于首次接触，应该仅仅用于首次接触，然后就应该用然后就应该用需求诱导需求诱导形式（包括问题求形式（包括问题求解、协商和规格说明）取代。解、协商和规格说明）取代。导出需求v导出需求是与问题求解、精化、谈判和规导出需求是与问题求解、精化、谈判和规格说明等方面的元素结合在一起的。为了格说明等方面的元素结合在一起的。为了鼓励合作，一个包括利益相关者和开发人鼓励合作，一个包括利益相关者和开发人员的团队共同完成如下任务：确认问题，员的团队共同完成如下任务：确认问题，为解决方案的要素提供建议，商讨不同的为解决方案的要素提供建议，商讨不同的方法并描述初步的
26、需求解决方案。方法并描述初步的需求解决方案。协同需求收集v提出面向团队的需求收集方法是为了鼓励提出面向团队的需求收集方法是为了鼓励合作，即一个包括共利益者和开发人员的合作，即一个包括共利益者和开发人员的团队共同完成如下任务：确认问题，为解团队共同完成如下任务：确认问题，为解决方案的要素提供建议，协商不同的方法，决方案的要素提供建议，协商不同的方法，以及说明初步的解决方案需求集合。以及说明初步的解决方案需求集合。协同需求收集会议的基本原则v会议由软件工程师和其他的利益相关者共同举办会议由软件工程师和其他的利益相关者共同举办和参与。和参与。v制定筹备和参与会议的规则。制定筹备和参与会议的规则。v建
27、议拟定一个会议议程，这个议程既要足够正式，建议拟定一个会议议程，这个议程既要足够正式，使其涵盖所有的重要点；但也不能太正式，以鼓使其涵盖所有的重要点；但也不能太正式，以鼓励思想的自由交流。励思想的自由交流。v由一个由一个“调解人调解人”(可以是客户、开发人员或其可以是客户、开发人员或其他人他人)控制会议。控制会议。v采用采用“方案论证手段方案论证手段”。v目的是识别问题，提出要解决方案的要素，协商目的是识别问题，提出要解决方案的要素，协商不同的方法以及在有利于完成目标的氛围中确定不同的方法以及在有利于完成目标的氛围中确定一套解决需求问题的初步方案。一套解决需求问题的初步方案。协同需求收集v在需
28、求的起始阶段，基本问题和问题的答在需求的起始阶段，基本问题和问题的答案确定了问题的范围和对解决方案的整体案确定了问题的范围和对解决方案的整体理解。除了这些最初的会议之外，理解。除了这些最初的会议之外，共利益共利益者要写一个者要写一个12页的页的“产品要求产品要求”。此外此外还要选择会议地点、时间和日期，并选举还要选择会议地点、时间和日期，并选举“调解人调解人”。来自开发组和其他共利益者。来自开发组和其他共利益者组织的代表被邀请出席会议，在会议召开组织的代表被邀请出席会议，在会议召开之前应将产品要求分发给所有的与会者。之前应将产品要求分发给所有的与会者。SafeHome实例1协同需求收集v在召开
29、会议评审产品要求的前几天，要求在召开会议评审产品要求的前几天，要求每个与会者列出每个与会者列出构成系统周围环境的对象、构成系统周围环境的对象、由系统产生的其他对象以及系统用来完成由系统产生的其他对象以及系统用来完成功能的对象功能的对象。此外，要求每个与会者列出。此外，要求每个与会者列出服务操作或与对象交互的服务服务操作或与对象交互的服务（过程或功（过程或功能）能）列表列表。最后，还要开发。最后，还要开发约束列表约束列表（如（如成本、规模大小、业务规则）和成本、规模大小、业务规则）和性能标准性能标准（如速度、精确度）。这些列表不要求完（如速度、精确度）。这些列表不要求完美无缺，但要反映每个人对系
30、统的理解。美无缺，但要反映每个人对系统的理解。SafeHome实例2协同需求收集v这些对象列表可以用大的纸张钉在房间的这些对象列表可以用大的纸张钉在房间的墙上或用便签纸贴在墙上或写在墙板上。墙上或用便签纸贴在墙上或写在墙板上。或者，列表也可以贴在内部网站的电子公或者，列表也可以贴在内部网站的电子公告牌上或聊天室中，便于会议前的评审。告牌上或聊天室中，便于会议前的评审。理想情况下，应该能够分别操作每个列表理想情况下，应该能够分别操作每个列表项，以便于合并列表、删除项以及加入新项，以便于合并列表、删除项以及加入新项。在本阶段，项。在本阶段，严禁批评和争论。严禁批评和争论。协同需求收集v当某个话题域
31、的各个列表被提出后，小组当某个话题域的各个列表被提出后，小组将生成一个将生成一个组合列表组合列表。该组合列表将。该组合列表将删除删除冗余项冗余项，并加入在讨论过程中出现的一些，并加入在讨论过程中出现的一些新的想法新的想法，但是，但是不删除任何东西不删除任何东西。在所有。在所有话题域的组合列表都生成后，主持人开始话题域的组合列表都生成后，主持人开始讨论协调。组合列表可能会缩短、加长或讨论协调。组合列表可能会缩短、加长或重新措词，以求更恰当地反映即将开发的重新措词，以求更恰当地反映即将开发的产品产品/系统，目标是为每个话题域（对象、系统，目标是为每个话题域（对象、服务、约束或性能）提交一个意见一致
32、的服务、约束或性能）提交一个意见一致的列表，在后面的工作中将用到这个列表。列表，在后面的工作中将用到这个列表。协同需求收集v一旦完成意见一致的列表，一旦完成意见一致的列表，团队被分为更团队被分为更小的子团队小的子团队，每个子团队试图为每个列表，每个子团队试图为每个列表中的一个或多个项目编写中的一个或多个项目编写小规格说明小规格说明。每。每个小规格说明是对包含在列表中的单词或个小规格说明是对包含在列表中的单词或短语的精炼。短语的精炼。SafeHome实例3vSafeHome对象控制面板的小规格说明：对象控制面板的小规格说明：控制面板是一个安装在墙上的装置，尺寸控制面板是一个安装在墙上的装置，尺寸
33、大概是大概是95英寸；控制面板和传感器、计英寸；控制面板和传感器、计算机之间是无线连接；通过一个算机之间是无线连接；通过一个12键的键键的键盘与用户交互，通过一个盘与用户交互，通过一个33的的LCD彩色彩色显示器为用户提供反馈信息；软件将提供显示器为用户提供反馈信息；软件将提供交互提示、回显以及类似的功能。交互提示、回显以及类似的功能。协同需求收集v然后，每个子团队将他们完成的每个小规然后，每个子团队将他们完成的每个小规格说明提交给所有的与会者讨论，进行格说明提交给所有的与会者讨论，进行添添加、删除和进一步细化加、删除和进一步细化等工作。在某些情等工作。在某些情况下，编写小规格说明可能况下，编
34、写小规格说明可能会发现新的对会发现新的对象、服务、约束或性能需求象、服务、约束或性能需求，可以将这些，可以将这些新发现加入到原始列表中。在所有的讨论新发现加入到原始列表中。在所有的讨论过程中，团队可能会提出某些在会议上过程中，团队可能会提出某些在会议上不不能解决的问题能解决的问题，将这些问题列表保留起来，将这些问题列表保留起来以便这些意见在以后的工作中发挥作用。以便这些意见在以后的工作中发挥作用。质量功能部署v质量功能部署质量功能部署QFD是一种将客户要求转化是一种将客户要求转化成软件技术需求的质量管理技术。成软件技术需求的质量管理技术。QFD强强调理解调理解“什么是对客户有价值的什么是对客户
35、有价值的”，然后，然后在整个工程活动中部署这些价值。在整个工程活动中部署这些价值。QFD确认的需求v正常需求正常需求：这些需求反映了在和客户开会：这些需求反映了在和客户开会时确定的针对某产品或系统的目标。如果时确定的针对某产品或系统的目标。如果实现了这些需求，将满足客户。实现了这些需求，将满足客户。v期望需求期望需求：这些需求隐含在产品或系统中，：这些需求隐含在产品或系统中，并且可能是非常基础的以至于客户没有显并且可能是非常基础的以至于客户没有显式地说明，但是缺少这些将导致客户明显式地说明，但是缺少这些将导致客户明显不满。不满。v令人兴奋的需求令人兴奋的需求：这些需求反映了客户期：这些需求反映
36、了客户期望之外的特点，但是如果实现这些特点的望之外的特点，但是如果实现这些特点的话将会使客户非常满意。话将会使客户非常满意。质量功能部署vQFD通过通过客户访谈和观察、调查以及检查客户访谈和观察、调查以及检查历史数据历史数据（如问题报告）为需求收集活动（如问题报告）为需求收集活动获取原始数据。然后把这些数据翻译成获取原始数据。然后把这些数据翻译成需需求表求表称为称为客户意见表客户意见表，并由客户评审。，并由客户评审。接下来使用接下来使用各种图表、矩阵和评估方法各种图表、矩阵和评估方法抽抽取期望的需求并努力导出令人兴奋的需求。取期望的需求并努力导出令人兴奋的需求。用户场景v当收集需求时，系统功能
37、和特点的整体愿当收集需求时，系统功能和特点的整体愿景开始具体化。但是在软件团队弄清楚不景开始具体化。但是在软件团队弄清楚不同类型的最终用户如何使用这些功能和特同类型的最终用户如何使用这些功能和特征之前，很难转移到更技术化的软件工程征之前，很难转移到更技术化的软件工程活动。为实现这一点，开发人员和用户可活动。为实现这一点，开发人员和用户可以创建一系列的以创建一系列的场景场景场景可以识别对场景可以识别对将要构建的系统的使用线索将要构建的系统的使用线索。场景通常称。场景通常称为为用例用例，它，它提供了系统将如何被使用的描提供了系统将如何被使用的描述述。导出工作产品v要求和可行性陈述。要求和可行性陈述
38、。v系统或产品范围的界限说明。系统或产品范围的界限说明。v参与需求导出的客户、用户和其他共利益参与需求导出的客户、用户和其他共利益者的列表。者的列表。v系统技术环境的说明。系统技术环境的说明。v需求列表以及每个需求适用的领域限制。需求列表以及每个需求适用的领域限制。v一系列使用场景，有助于深入了解系统或一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用。产品在不同运行环境下的使用。v任何能够更好地定义需求的原型任何能够更好地定义需求的原型。开发用例v一个一个用例用例捕获一个合同，即说明当对某个捕获一个合同，即说明当对某个共利益者的请求响应时，在各种条件下系共利益者的请求响应时，在各
39、种条件下系统的行为。本质上，用例讲述了能表达主统的行为。本质上，用例讲述了能表达主体场景的故事：体场景的故事：最终用户如何在一特定环最终用户如何在一特定环境下和系统交互境下和系统交互。这个故事可以是叙述性。这个故事可以是叙述性的文本、任务或交互的概要、基于模板的的文本、任务或交互的概要、基于模板的说明或图表显示。不管形式如何，用例从说明或图表显示。不管形式如何，用例从最终用户的角度描述了软件或系统最终用户的角度描述了软件或系统。开发用例v撰写用例的第一步是定义各类故事中所包撰写用例的第一步是定义各类故事中所包含的含的“参与者参与者”。参与者是在将要说明的。参与者是在将要说明的功能和行为环境内使
40、用系统或产品的功能和行为环境内使用系统或产品的各类各类人员（或设备）人员（或设备）。参与者是任何与系统或。参与者是任何与系统或产品通信的事物，且对系统本身而言参与产品通信的事物，且对系统本身而言参与者是外部的。当使用系统时，者是外部的。当使用系统时，每个参与者每个参与者都有一个或多个目标都有一个或多个目标。开发用例v参与者与最终用户并非一回事。典型的用户可能参与者与最终用户并非一回事。典型的用户可能在使用系统时扮演了许多不同的角色，而参与者在使用系统时扮演了许多不同的角色，而参与者表示了一类外部实体（经常是人员，但不限于人表示了一类外部实体（经常是人员，但不限于人员），在用例中他们仅扮演一种角
41、色。例如，员），在用例中他们仅扮演一种角色。例如，考考虑一个机床操作员（一个用户），他和生产车间虑一个机床操作员（一个用户），他和生产车间（其中布置了许多机器人和数控机床）内的某个（其中布置了许多机器人和数控机床）内的某个控制计算机交互。控制计算机交互。在仔细考察需求后，控制计算在仔细考察需求后，控制计算机的软件需要四种不同的交互模式（角色）：机的软件需要四种不同的交互模式（角色）：编编程模式、测试模式、监测模式和纠错模式。程模式、测试模式、监测模式和纠错模式。4个个参与者可定义为：参与者可定义为：程序员、测试员、监控员和故程序员、测试员、监控员和故障检修员障检修员。有些情况下，。有些情况下，
42、机床操作员可以扮演所机床操作员可以扮演所有这些角色有这些角色，而有些情况下，而有些情况下，每个参与者的角色每个参与者的角色可能由不同的人员扮演。可能由不同的人员扮演。开发用例v需求导出是一个逐步演化的活动，第一次需求导出是一个逐步演化的活动，第一次迭代中并不能确认所有的参与者。在第一迭代中并不能确认所有的参与者。在第一次迭代中有可能识别次迭代中有可能识别主要的参与者主要的参与者，而对，而对系统了解更多之后，才能识别出系统了解更多之后，才能识别出次要的参次要的参与者与者。主要参与者直接且经常使用软件，。主要参与者直接且经常使用软件，和他们交互可以获取所需的系统功能并导和他们交互可以获取所需的系统
43、功能并导出系统的预期收益。次要参与者支持系统，出系统的预期收益。次要参与者支持系统，以便主要参与者能够完成他们的工作。以便主要参与者能够完成他们的工作。开发用例v一旦确认了参与者，就可以开发用例。为了开发一旦确认了参与者，就可以开发用例。为了开发一个有效用例，可以考虑如下问题：一个有效用例，可以考虑如下问题：v谁是主要参与者、次要参与者？谁是主要参与者、次要参与者？v参与者的目标是什么？参与者的目标是什么？v故事开始前有什么前提条件？故事开始前有什么前提条件？v参与者完成的主要工作或功能是什么？参与者完成的主要工作或功能是什么？v按照故事所描述的还可能需要考虑什么异常？按照故事所描述的还可能需
44、要考虑什么异常？v参与者的交互中有什么可能的变化？参与者的交互中有什么可能的变化？v参与者将获得、产生或改变哪些系统信息？参与者将获得、产生或改变哪些系统信息？v参与者必须通知系统外部环境的改变吗？参与者必须通知系统外部环境的改变吗？v参与者希望从系统获取什么信息？参与者希望从系统获取什么信息？v参与者希望得知意料之外的变更吗？参与者希望得知意料之外的变更吗？SafeHome实例4SafeHome实例5SafeHome实例6SafeHome实例7SafeHome实例8SafeHome实例9SafeHome实例10SafeHome实例11构建需求模型v分析模型的目的是为基于计算机的系统提分析模型
45、的目的是为基于计算机的系统提供必要的信息、功能和行为域的说明。随供必要的信息、功能和行为域的说明。随着软件工程师更多地了解将要实现的系统着软件工程师更多地了解将要实现的系统以及其他利益相关者更多地了解他们到底以及其他利益相关者更多地了解他们到底需要什么，模型将动态地变更。需要什么，模型将动态地变更。v当需求模型演化时，某些元素将变得相对当需求模型演化时，某些元素将变得相对稳定，为后续设计任务提供稳固的基础。稳定，为后续设计任务提供稳固的基础。但是，有些模型元素可能是不稳定的，这但是，有些模型元素可能是不稳定的，这表明利益相关者仍然没有完全理解系统的表明利益相关者仍然没有完全理解系统的需求。需求
46、。需求模型的元素v有很多不同的方法考察计算机系统的需求。有很多不同的方法考察计算机系统的需求。某些软件人员坚持最好选择一个表达模式某些软件人员坚持最好选择一个表达模式（如用例）并排斥所有其他模式。有些专（如用例）并排斥所有其他模式。有些专业人士则相信使用许多不同的表现模式来业人士则相信使用许多不同的表现模式来描述需求模型是值得的，不同的表达模式描述需求模型是值得的，不同的表达模式促使软件团队从不同的角度考虑需求促使软件团队从不同的角度考虑需求一种方法更有可能造成需求遗漏、不一致一种方法更有可能造成需求遗漏、不一致性和歧义性。性和歧义性。基于场景的元素v使用基于场景的方法可以从用户的视角描使用基
47、于场景的方法可以从用户的视角描述系统。例如，基本的用例及其相应的用述系统。例如，基本的用例及其相应的用例图演化成更精细的基于模板的用例。课例图演化成更精细的基于模板的用例。课本图本图4-3描绘了一张使用用例引发的需求并描绘了一张使用用例引发的需求并表达它们的表达它们的UML活动图。活动图。导出需求的UML活动图课本图4-3 导出需求的UML活动图基于类的元素v每个使用场景都暗示着当一个参与者和系每个使用场景都暗示着当一个参与者和系统交互时所操作的一组对象，这些对象被统交互时所操作的一组对象，这些对象被分成类分成类具有相似属性和共同行为的事具有相似属性和共同行为的事物集合。例如：可以用物集合。例
48、如：可以用UML类图描绘类图描绘SafeHome安全功能的传感器安全功能的传感器Sensor类如类如课本图课本图4-4所示。除了类图，其他分析建模所示。除了类图，其他分析建模元素描绘了类相互之间的协作以及类之间元素描绘了类相互之间的协作以及类之间的关联和交互。的关联和交互。传感器Sensor的类图课本图4-4 传感器Sensor的类图行为元素v基于计算机系统的行为能够对所选择的设基于计算机系统的行为能够对所选择的设计和所采用的实现方法产生深远的影响。计和所采用的实现方法产生深远的影响。因此，需求分析模型必须提供描述行为的因此，需求分析模型必须提供描述行为的建模元素。建模元素。v状态图是一种表现
49、系统行为的方法，该方状态图是一种表现系统行为的方法，该方法描绘系统状态以及导致系统改变状态的法描绘系统状态以及导致系统改变状态的事件。状态是任何可以观察到的行为模式。事件。状态是任何可以观察到的行为模式。另外，状态图还指明了在某个特殊事件后另外，状态图还指明了在某个特殊事件后采取什么动作。采取什么动作。UML状态图表示课本图4-5 UML状态图表示面向数据流的元素v信息在基于计算机的系统中流动时会被转信息在基于计算机的系统中流动时会被转换，系统接受多种形式的输入；使用函数换，系统接受多种形式的输入；使用函数将其转换；生成多种形式的输出。将其转换；生成多种形式的输出。v我们可以为任何基于计算机的
50、系统创建数我们可以为任何基于计算机的系统创建数据流模型。据流模型。分析模式v任何有一些软件项目需求工程经验的人都开始注任何有一些软件项目需求工程经验的人都开始注意到，在特定的应用领域内某些事情在所有的项意到，在特定的应用领域内某些事情在所有的项目中重复发生。目中重复发生。分析模式分析模式为特定应用领域提供了为特定应用领域提供了一些解决方案，在为许多应用项目建模时可以重一些解决方案，在为许多应用项目建模时可以重复使用。复使用。v分析模式提高了抽象分析模型的开发速度，通过分析模式提高了抽象分析模型的开发速度，通过提供可重复使用的分析模型捕获具体问题的主要提供可重复使用的分析模型捕获具体问题的主要需
