软件工程课件 07.需求工程过程.pptVIP

需求工程过程 Requirements Engineering Process 需求工程过程 是发现，分析和确认系统需求的过程 （Processes used to discover, analyse and validate system requirements） 目标（Objectives） 描述主要的需求工程活动以及它们的关系 介绍需求提取（ elicitation）和分析的技术 描述需求确认（validation）和评审的意义 讨论需求管理在支持其他需求工程过程所扮演的角色 课题 可行性研究 需求提取和分析 需求确认 需求管理 需求工程过程 需求工程所采用的过程多种多样，它由应用领域、参与人员和开发需求的机构决定 然而，在所有过程中也存在着一些相同的一般活动 需求提取； 需求分析； 需求确认； 需求管理。 需求工程过程 需求工程 可行性研究（Feasibility studies） 一个可行性研究决定提出的系统是否值得去做。 研究焦点在于检查 该系统是否对机构目标有贡献； 在既定预算和现有技术的情况下，是否能完成该系统的工程； 该系统是否能与其它正在使用的系统进行集成。 可行性研究的实现 实现手段依赖于信息评估（需要什么），信息收集和报告编写 对机构里的人来说，问题是 如果系统实现不了怎么办? 现有流程的问题是什么? 提出的系统会有多大的帮助? 集成将会遇到什么问题? 需要新的技术吗? 要具备什么技能? 对提出的系统提供支持的必要工具有那些? 提取（ Elicitation）与分析 有时称其为需求提取或需求发现 需要技术人员与顾客一起找出应用领域，所提供的系统服务以及系统操作限制 它可能涉及到最终用户，管理人员，维护工程师，领域专家，同业商会等等。这些被称为利益相关人（ stakeholders） 需求分析问题 利益相关人不知道他们真正需要什么。 利益相关人用自己的语言来表达需求。 不同的利益相关人的需求可能会有冲突。 机构和政治的因素可能会影响系统需求。 在分析过程中需求变化了。有新的利益相关人加入进来，业务环境也发生改变。 需求螺旋 过程活动 需求发现 通过与利益相关人进行互动来发现需求，领域需求也要在这个阶段找出来。 需求的组织和分类 把相关的需求进行分组并把它们放到一个聚类中。 协商和优先级排序 将需求进行优先级排序并解决需求冲突。 编写需求文档 编写需求文档并进入下一个螺旋阶段 需求发现 是对现有系统和提出的系统进行信息收集以及从这些信息中提取出用户需求和系统需求的过程。 信息来源包括文档、系统的利益相关者和类似系统的规格说明。 银行自动取款机系统（ATM） 这里所用的例子是一个自动出纳（ auto-teller）系统，它能够提供某些自动银行服务。 有些系统只为具有本系统的银行的顾客提供一些服务，而对其他顾客提供的服务却很少。 服务包括提取现金（ cash withdrawal ），传递信息（ message passing，对一个服务请求发送一个消息），定出结算单（ ordering a statement）和转账（ transferring funds ）。 ATM利益相关人 银行顾客 其他银行的代表 银行管理人员 柜台职员 数据库管理员 安全管理人员 市场部门 硬件和软件维护工程师 银行校对员 观点（Viewpoints） 观点是用一种构造需求的方法来表达不同利益相关人的观念。 这种多角度的分析方法是很重要的，因为没有唯一正确的分析系统需求的方法。 观点的类型 互动者观点 人或其它系统是与系统直接互动的。在一个ATM上，客户数据库和账目数据库都代表互动者观点。 间接观点 那些不用系统的利益相关人也会影响到需求。在一个ATM上，管理员和保安人员就代表间接观点。 领域观点 领域特征和限制也会影响需求，在一个ATM上的例子就是银行间的通信标准。 观点识别 识别观点要采用： 系统服务的提供者和接受者； 与被识别的系统直接互动的系统； 规则和标准； 业务和非功能需求的源头； 开发和维护系统的工程师； 市场和其它业务观点。 LIBSYS观点的层次结构 面谈（Interviewing） 通过正式的或非正式的面谈，需求小组向利益相关人询问关于他们如何使用系统和怎样开发系统的问题。 有两种面谈方式： 限定式面谈——回答一组预先拟定好的问题。 开放式面谈——没有预定的议程和议题和利益相关人交谈。 面谈实践 通常是限定式与开放式面谈相结合。 面谈有利于收集到利益相关人的观点以及有关他们如何与系统互动的信息。 面谈不利于对领域需求的理解 需求工程师不理解特定领域的术语； 人们认为一些领域知识太普通了，以至于不值得去考虑或讲出来。 有效的面谈者 面谈者应该以乐意和虚心的态度倾听利益相关人的意见，不要对需求抱有成见。 他们应该