《软件需求提取与分析》由会员分享，可在线阅读，更多相关《软件需求提取与分析（50页珍藏版）》请在金锄头文库上搜索。
1、软件需求提取与分析主讲：周荣辉需求分析的重要性需求分析的目标是为系统设计和实现提供足够的 指导和信息支持。如果需求分析不充分，则设计和实 现很难进行；如果设计和实现中涉及的内容无法与需 求建立对应关系，则显得多余。对论文而言，就是失 败之作。软件开发类论文评价的基本标准之一：需求与设 计和实现的一致性，即任何需求必须在设计和实现中 得到体现，任何设计与实现必须与需求有对应关系。需求分析概述在传统的软件工程中，需求分析作为软件生存周期的一 个阶段，尽管有需求获取和分析的两个任务，这两个任务没 有严格地划分时间段，在需求获取过程中要进行分析，在分 析过程中要不断地进行调研和完善。需求获取和需求分析
2、的 工具都是采用数据流图和数据字典。明确地指出需求分析报 告主要用于用户交流。在统一过程和UML提出后，特别是软件迭代开发方法提 出后，把需求和分析分成了两个不同的阶段，有时也叫需求 获取（或需求捕获）和需求分析，每个阶段有完全不同的目 标和任务，包括建模工具和建立的模型都完全不同。需求捕 捉阶段主要采用用例模型捕捉功能需求，需求分析阶段主要 采用对象模型，建立领域对象间的协作关系。需求获取所建 立的模型主要用于与用户交流，需求分析模型是开发组织自 己的文档，不用于与用户交流。需求分类（1）功能性需求-系统应该提供什么功能。（2）非功能需求-系统的特定特性或约束。软件需求功能需求非功能需求质量
3、属性约束运行期质量属性开发期质量属性软件运行期质量用户在使用软件过程中对软件质量的要求，包括：易用性：指软件系统容易使用的程度。性能：指软件系统及时提供相应服务的能力。性能包括 响应时间、吞吐量、持续高速性。安全性：指软件系统同时兼顾向合法用户提供服务，以 及防止非授权使用的能力。持续可用性：指软件长时间无故障运行的能力。如有的 系统要求提供7*24小时服务就是持续可用性的要求。可伸缩性：指当用户数量和数据量增加时，软件系统维 持高服务质量的能力。互操作性：指本软件系统与其它软件系统交换数据和相 互调用服务的难易程度。可靠性：软件系统在一定时间内无故障运行的能力。鲁棒性：也称健壮性、容错性。有
4、时也把持续可用性、 鲁棒性也归类为可靠性。软件运行期质量为保证软件的可维护性而在软件开发过程中应该关注的 软件质量属性，有时将其称为隐含质量属性。包括：可扩展性：为适应新需求或需求变化为软件增加功能的 能力。有时称为灵活性。可重用性：重用软件系统或其一部分的能力的难易程度 。可测试性：对软件测试以证明满足需求规约的难易程度 。在实际工作中主要指进行单元测试，插桩测试的难易程度 。可维护性：在修改Bug、增加功能、提高质量属性等而 定位修改点并适时修改的难易程度。可移植性：将软件系统从一个运行环境转移到另一个运 行环境的难易程度。易理解性：设计被开发人员理解的难易程度。 任何一个开发期质量属性的
5、满足都可能增加软件开发成本。 。约束约束不是行为，是设计或项目的限制条件，强调其限制 性，新系统的开发无法回避这些事实或因素。约束主要包括 ：系统开发的资源约束：如网络环境、操作系统、数据库 管理系统、开发工具、硬件等。新系统的开发必须考虑这些 资源的有效利用和限制。接口约束：本系统关联的系统是哪些，新系统可能接受 其它系统提供的数据作为输入，其输出数据作为其它系统的 输入。操作约束：系统操作环境中的管理要求。如身份认证必 须通过第三方认证机构的认证，以网络为基础的业务处理， 在网络不通的情况下如何处理业务等。政策约束：行业标准，企业标准，法律法规、政府规章 等。需求的层次性组织的不同层次人员
6、对需求不同，通常有三个层次：业务需求：组织要达到的目标业务目标用户需求：用户使用系统来做什么行为需求：开发人员需要实现什么高管人员希望软件系统能帮助他们达到业务目标。系统实际使用者希望系统提供的能力能辅助他们更好地 完成日常业务工作。开发人员为满足用户诸多需求而觉察到的需求。高层管理人员的需求与系统实际使用人员的需求可以起 到相互验证和印证的作用。如果不关注“高层管理人员”的 要求，系统开发就没有明确的目标，系统的功能将是零散而 脆弱的，极易受到变更的冲击。不满足开发人员的要求，软 件的开发、维护和移植变得非常困难。 需求提取内容确定业务目标确定业务范围和业务流程建立用例模型建立用例规约确定非
7、功能需求确定业务目标业务目标系统开发中占有非常重要的位置，它明确规定 了建立该软件系统的最终目的。业务目标是客户方高层对未 来系统的期望。通过确定业务目标可以避免系统解决的问题 的层次太低而很快过时。项目业务目标要避免太抽象、太空洞，如“实现XX信息 化”。一个项目管理系统的业务目标定义为：帮助项目经理更好地控制项目帮助项目经理更有效地分配资源帮助项目成员之间更流畅地协作通过细化业务目标，列出一组高度概括的功能性需求。 如业务目标“帮助项目经理更好地控制项目”的特性有：任务管理跟踪进度查看报表任务分配和重分配确定业务范围和业务流程业务目标的实现需要通过具体的业务领域（有时也 称职能域）以及具体
8、的业务及业务流程来体现，使业务 目标落实到实处。这将引起企业组织机构的调整和业务 流程重组，以满足业务目标的要求。业务（有时也称业务过程）：是需要做的相对独立 的工作（或任务）。业务流程：是完成工作所经历的业务活动及顺序。业务活动：是基本的、不可再分的最小功能单元（ 通常指一个人在一个地点一个不可间断的时间内可以完 成的工作）。建立用例模型所谓用户需求，就是用户希望软件系统能为他做什 么。用例图技术是捕捉用户需求最合适的技术。用例名 是用户需求最直观、最简便的反映。业务流程分析将捕 捉到大部分用例，但不是全部用例，还需要补充一些与 管理人员相关、但与具体业务活动不一定直接相关的用 例和与信息查
9、询相关的用例。建立用例规约用例是用户“希望如何做”的行为需求。这里的“ 如何做”是从用户角度看他们“希望如何做”，而不是 软件系统是如何做，所以还是属于需求捕捉的内容。用 户“希望如何做”是软件系统“如何做”的依据。在用例规约中，将详细定义用户对用例运行期间的 质量要求和约束。不一定所有用例都要建立用例规约。有的用例使用 “用例简述”就足够了。如果一个用例基本事件流对需 求分析人员来说不是很清楚，而且可能涉及到非功能要 求，就需要用“用例规约”来详细描述。确定非功能需求通过对用例规约的分析和总结，归纳出系统的非功能 需求，特别是用户对系统运行期的质量需求和约束。用例 规约是系统运行期质量需求和
10、约束的主要来源。一般来说 ，开发期质量属性需求主要来自系统开发人员和维护人员 ，通过成为隐含的非功能需求。要善于抓住对用户来说至关重要的非功能需求，这种 非功能需求往往决定系统的命运。如特殊的性能问题、特 殊的安全性问题、典型的运行机制问题。若存在与其它系统的交互，互操作性是必须考虑的。特定的约束对系统的制约是架构设计必须考虑的问题 。 需求建模方法需求提取的建模包括业务建模和用例建模。业务建模是确定项目对应的业务领域所包含 的业务和业务流程，并用所选择的业务流程描述 工具进行描述。用例建模是以用例为基本单位来描述用户的 功能需求。与用例模型相关的概念包括：参与者，用例 ，场景需求建模-参与者
11、直接与系统交互的外部事物所扮演的角色。参与者对系统而言是外部的；参与者直接与系统交互，直接使用系统来支持其业务。强调参与者所扮演的角色，而不是特定的人或事物。时间可以作为参与者，通常用时间发生器来表示。参与者主要指系统业务功能的使用者。系统管理员不是这 种意义的参与者。因为他不是使用系统功能完成与单位业务 有关的工作。他使用系统的辅助功能实现对特定的人及其角 色的管理，使参与者在自己角色范围内使用系统。每个参与者使用一个具有业务意义的名称命名。需求获取的首要任务就是识别主要参与者。识别参与者是需求提取的首要任务，谁是系统的客户，他 们需要系统做什么，他们希望在什么时候、什么地点做，这 些都是系
12、统设计要考虑的重要因素。需求建模用例用例是参与者想要系统做的事情。具体表现为用户如何 使用系统来达到其目标的一组情节。例如在超市，“处理销售”的用例描述为：一个顾客携 带欲采购的商品到达收费口。收银员使用系统输入商品信息 ，系统给出商品的清单和累加值。顾客交款。收银员输入支 付信息，系统对付款信息进行计算，更新库存信息，并给出 余额信息；系统打印购物清单。顾客得到收据，然后携带商 品离开。只有对用例表现出的情节进行真实、完整、准确地描述 ，才能捕捉到对系统需求有价值的东西。需求建模用例的粒度指导原则1：在进行需求获取时，应专注于“基本业务过 程”（EBP）级别的用例。基本业务过程：由一个人在某
13、个时间某个地点执行的一 项任务，这个任务是对某一个业务事件的反应，而且可以增 加可度量的业务价值，并且能够保持数据状态的一致。用例没有层次结构的概念，即用例就是系统参与者要系统 帮助干的一件不可细分的事情，不存在把一个用例分解成粒 度更小的用例。EBP级别的用例就是用户对系统的业务功能需求。在进行 需求获取时，应主要关注EBP级别的主要用例，通常称他们为 基本用例。比基本用例粒度小的用例可能完不成“可度量的 业务价值”的一件事情，比基本用例粒度大的用例可能需要 多个参与者去完成或多个时间段去完成。用例的命名必须具有明显的业务领域特征需求建模用例与目标参与者都有自己的目标，并使用系统来帮助自己实
14、现目 标。一个EBP级别上的用例通常被称为一个用户目标级别上的 用例，以强调用例应该帮助系统的用户实现自己的目标。（ 这里强调“用户目标级别”，不是企业目标、组织目标、系 统目标）。“防盗”是企业级目标，不是用户级目标，因此不是一 个EBP。“向系统证明身份并被验证”也不是一个EBP，因为它没 有增加可见的或可以度量的业务价值。“登录”是一个次要 目标，是为其它有用的事情服务的。如“我今天登录了20次 ”不会留下任何有价值的东西。“用户管理”是系统目标，不是用户级目标。需求建模可观察的返回值每个用例的实例产生了对特定参与者而言可观察的返回 值。可观察的返回值实际上是告诉参与者是否实现了其业务
15、价值。如果一个用例不会告诉参与者任何东西，对参与者来 说，它没有任何价值，这肯定不是参与者的目标要求。需求建模场景场景：参与者与系统之间的一系列特定的活动和交互， 通常称为“用例的实例”。场景是使用系统的一个特定情节 或用例的一条执行路径。一个用例就是一个描述参与者使用系统来达到目标的一组 相关的成功场景和失败场景的集合。例如，客户在超市选择 购买的商品后到收银台验货和付款中，“收银员扫描仪录入 商品数据顾客交款收银员退余款打印购物清单”是一 个场景；同样，“收银员扫描仪录入商品数据顾客交卡 收银员刷卡打印购物清单”也是一个场景；“收银员扫描 仪录入商品数据顾客交卡收银员刷卡（卡中钱不足时 ）
16、顾客交款收银员退余款打印购物清单”还是一个场景 。场景可分为主要场景和次要场景。一个用例只有一个主要 场景，但可以包含多个次要场景。每个场景表示参与者达到 其目标的一个情节。在主要场景中，如果与某一步所希望的 事件不同，就会引出一个次要场景。需求建模方法识别主要参与者系统主要参与者就是系统的业务用户。在这里，我们反 复强调“业务用户”，因为开发一个软件系统的目的就是为他 们的业务工作服务的，这是系统的价值所在。在识别系统主要参与者时的首要工作就是列出所有系统 最终用户。任何人，只要他需要使用系统来行使自己的“职 责”，哪怕只有一小点“职责”，他就是系统的主要参与者。主要参与者不是具体人，而是抽象的职能名。但也不能 太抽象了，以致无法辨认他们的脚色。有的主要参与者的大部分业务工作都可能需要系统支持 ，如学校的“教务管理员”，有的主要参与者可能很少使用系 统，如各个“审批”人员，当别人把所有工作都作了，他只需 “审核”一下就行了。在识别主要参与者的过程中，最容易把 这些大量的干“审核”或“审批”的主要参与者忽
