软件需求工程

软件工程是以借鉴传统工程的原则、方法，以提高质量，降低成本为目的指导计算机软件开发和维护的工程学科

软件工程的基本目标 付出较低的开发成本； 达到要求的软件功能； 取得较好的软件性能； 需要较低的维护费用； 能按时完成开发工作，及时交付使用；

错误扩大现象 Xerox 查找和修复故障的时间表

Requirement Modelling—Use case 需求分析的第一步是确定系统能够做什么？谁来使用这个系统？ 用例图显示用例（表示系统功能）与角色（表示提供或者接收系统信息的人或系统）之间的交互。 用户、项目管理员、分析人员、开发人员、质保人员都可以通过用例图了解系统功能。 用例分析技术已成为重要的需求分析技术之一。

课程登记实例的Use Case图

订单处理系统——初始问题描述 我们正在为National Widgets邮递公司开发订单处理系统。这是一家转售各种商品的公司。这家公司一年公布两次产品目录，并将其邮递给了客户和其他感兴趣的人。公司接到用户订单并适当投递。 ………… “你认为一年公布两次合适吗？我们的产品变化得可非常快呀？” “这只是我们的开始。我们会在需求分析过程中进一步补充和完善，加深理解。”

订单处理系统——补充问题描述 客户以递交订单并且向National Widgets公司付款的方式购买商品。National Widgets公司处理订单并且将产品投递到客户指定地址。 订单处理软件记录从订单收到直到商品被投递给客户的整个过程。 National Widgets公司提供快捷的服务。他们应该能够以最快、最有效的方法来运送客户订购的产品。

风险分析——邮购市场调研 多数家庭成年人都有工作，至少是兼职工作。他们都很少有时间购物。因此他们通常愿意付钱邮购商品。   网上购物日前很流行，是邮购市场的竞争者。 其它的邮递公司提供24小时订单接收服务，邮递的次数从一天到两周不等；此外还有礼品打包服务，并提供大量的折扣。 优势…….信息广泛? 实时处理? 易于操作? 可靠性高?

National Widgets的风险因素 如何在系统出错时防止丢失订单？* 系统必须易于操作以使得非专业人士可以使用？*** 如果我们不提供Web界面是否会成功？*** 我们应该如何处理公司不同部门的众多实时用户？** 我们应该如何应付数据库崩溃？* 有些软件设计人员没有开发经验，特别是缺少团队开发精神。***

问题描述 我们在为一个称为National Widgets的邮递公司开发订单处理软件，这是一家经销各种产品的中间公司。 这家公司一年两次公布产品目录，这些产品以邮递的方式送到客户以及其他感兴趣的人手中。 客户以递交订购产品清单，并向National Widgets公司付费的方式购买商品。National Widgets公司处理订单，并把商品投递给客户。 订单处理软件记录从订单收到直到商品被投递给客户的整个过程。 National Widgets公司将提供快捷的服务，它们应该能够以最快捷、最有效的方法来运送客户订购的产品。 客户可能退货，也可能要求重新进货。 假设 一种电子订购界面，例如Web，可能对某些客户更适合。 我们希望使用多家运输公司和多种保险方法。

问题描述（续） 高： l 某些软件开发人员没有经验，特别是缺少团队开发精神 l 系统应该使得非专业人员便于使用 l    如果不支持Web接口，我们是否会成功？  中： l    我们应该如何处理同一公司之中不同部门的并发用户? 低： l    我们在系统失败时应该如何避免丢失订单？ l    如果系统立即被订单淹没将会怎样？ l   如何处理数据库崩溃？

初始阶段交付项 完成 交付项 ü           项目描述 风险分析   用例图 角色和用例描述 项目提议  

确定系统边界 什么是系统边界？ National Widgets公司需要把订购的商品投递给客户。投递过程包括打包和贴标签、称重量，再根据运送方法、邮递速度、保险、重量、目的地等等收取邮资。 我们的订单处理系统要包括计算邮费吗？ 如何计算？

确定执行者（ACTOR） l 谁使用这个系统？ l 谁安装系统？ l 谁启动系统？ l 谁维护系统？ l 谁关闭系统？

订单处理执行者

确定用例(USE CASE) 从执行者的角度看，用例应该是一个完整的任务。 考虑以下问题： 执行者想要系统有什么样的功能？ 系统存储信息吗？ 执行者将要创建、读取、更新、或删除什么样的信息？ 系统是否需要把自身内部状态的变化通知给执行者？ 有哪些外部的事件系统必须知道？

订单处理用例图

描述执行者和用例 客户（Customer）——从National Widgets公司订购商品的人 客户代表(Customer rep)——National Widgets公司处理客户请求的雇员 运输公司(Shipping company)——USPS,UPS,DHL,FedEx,DM等等 职员(Clerk)——National Widgets公司的雇员，负责包装、贴标 签和运送订货。 库存系统(Inventory system)—记录公司存货的软件 记账系统(Accounting system)—记录公司账目的软件

订单处理用例描述 订购货物(Place Order)—客户提交新商品订单并且为商品付费。 获得目录(Get Catalog)—客户要求得到一个目录或产品清单。 获得订单的状态(Get Status on Order)—客户得到一个已存在订单的状态。 退货(Return Product)—客户退还商品并要求赔偿。 取消订单(Cancel Order)—客户取消一个已存在的订单。 记录投诉(Register Complain)—客户向公司发送投诉信息。 运送包裹(Deliver Packages)—要求运输公司将商品运送到客户手中。 计算邮费(Calculate Postage)—计算将商品投递到客户手中需要多少邮费。 打印信件标签(Print Mailing Label)—打印信件标签。 更新商品数量(Update Product Quantities)—更新库存的商品数量

订单处理用例图

订购处理用例包——用例重组 如果用例图过于庞大和杂乱将会如何处理？—— 需要创建多个用例图。 如果用例图过于庞大和杂乱将会如何处理？—— 需要创建多个用例图。 每一个图可能代表系统中一个主要领域功能。在大型系统中，可以创建包来代表子系统或者主要功能领域。在UML之中，包是其他UML元素的载体。然后为每一个包绘制一张用例图，来表示它所包含的用例。 订购货物

订购货物用例图

订购完成用例图

我们已经考察了市场, 并且注意到网上商务的确很流行。在订单处理系统中是否应该有网页, 在线产品目录和电子订单? 确定项目范围 当分阶段实施项目计划时，要分清优先级，确定项目范围。 确定需求优先级时，需要考虑你所确定的风险和市场因素。因此“一定要有”不是仅仅基于技术需要，但是可能也会在市场上遇到风险。对于National Widgets公司来说，这可能意味着Web界面是一个订单处理系统“一定要有”的因素，因为其他的邮递公司都提供这一功能。这一特性是跟上市场竞争的要求。 根据优先级将需求确定为： 一定要有 应该有 考虑要有 我们已经考察了市场, 并且注意到网上商务的确很流行。在订单处理系统中是否应该有网页, 在线产品目录和电子订单?

初始阶段交付项 完成 交付项 ü 项目描述 风险分析 用例图 项目提议 完成 交付项 ü 项目描述 风险分析 用例图 角色和用例描述 ü           项目描述 风险分析   用例图 角色和用例描述 项目提议 完成 交付项 ü              项目描述 风险分析 用例图 角色和用例描述 项目建议 初始阶段交付项

细化阶段 编写详细的用例并归档 构建软件体系结构 确定进一步实施计划

订购货物 详细用例 前置条件：一个合法的客户已经登录到这个系统 事件流： 当客户选择订购货物时，用例开始。 客户输入他（她）的姓名和地址。 如果客户只输入邮编，系统将给出州和市区名。 客户输入想要购买的商品代码。 系统为每一项给出商品描述和价格。 系统保存有连续的的已经订购的产品清单。 客户输入信用卡支付信息。 客户选择提交。 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息。如果客户提交的信息不正确，系统就提示客户修改。 当支付被确认后，该订单也被标记上已经确认，同时返回给客户一个订单ID，用例也就结束了; 如果支付没有被确认，系统将提示客户去改正支付信息或者取消。 如果客户选择去修改信息，就回到第7步；如果选择取消，用例结束。 后置条件：如果订单没有被取消，它将被保存在系统里，并 做上标记。

用例的表格表示 客户代表 系统 记账系统 1．接收到取消订单的请求 2．输入一个订单ID 3．按下搜索 4．显示订单内容 5．选择取消   2．输入一个订单ID 3．按下搜索 4．显示订单内容 5．选择取消 6．给该订单作取消标记 7．向客户账号中返钱

基本路径与扩展

细化阶段交付项 ˇ 完成 交付项 ü 项目描述 风险分析 用例图 项目提议 完成 交付项 ü 项目描述 风险分析 用例图 角色和用例描述 ü           项目描述 风险分析   用例图 角色和用例描述 项目提议 完成 交付项 ü              项目描述 风险分析 用例图 角色和用例描述 项目建议 完成 交付项 ˇ 细化的基本路径 可选路径   活动图 用户接口图表（可选） 体系结构 项目计划 ü  

辅助分析技术 用活动图来描述用例的步骤，并在用例文档中专门加一节刻画活动图。 用简单的时序图来显示执行者和系统的相互作用，并加到用例文档中。 客户选择订购货物，用例开始。 客户键入他或她的姓名和地址。 如果客户键入唯一的邮递区码，系统提供州和市 客户键入想要订购的产品的产品号。 对于每一个键入的产品号 系统提供产品描述和价格。 系统把单价加入总价中。 结束循环 客户键入信用卡支付信息 客户选择提交 系统确认信息，把这次订购以未完成交易保存以来，向记账系统提交支付信息。 当支付确认后，订单被标志为确认，返回用户一个订单ID，用例结束。

活动图

免费样品领用 申请部门 物资管理部－综合计划 物资管理部－仓库 财务部 申请部门向物资管理部－仓库领料 物资管理部计划 员将有关材料计划输入系统 免费样品领用申请书 计划人员从系统中打印领料单 领料单 申请部门 经理审批 综合计划经理对领 料单进行审核　 已批准的领料单 材料帐务人员从系统中确认领料 成品发料员进行 签字、发料　 财务人员进行帐务处理

订购货物的简单时序图

细化阶段交付项 ˇ 完成 交付项 ü 项目描述 风险分析 用例图 项目提议 完成 交付项 ü 项目描述 风险分析 用例图 角色和用例描述 ü           项目描述 风险分析   用例图 角色和用例描述 项目提议 完成 交付项 ü              项目描述 风险分析 用例图 角色和用例描述 项目建议 完成 交付项 ˇ 细化的基本路径 可选路径   活动图 用户接口图表（可选） 体系结构 项目计划 ü   完成 交付项 ü         详细基本路径 可选路径 活动图 用户接口图（操作界面）   体系结构 项目计划

是刻画软件功能、性能，确定软件和其他系统元素之间的借口，并建立软件必需满足约束的过程。 总结 是指明系统必须实现什么的规格说明，它描述了系统的行为、特征或属性，是软件开发的基础和约束 软件需求 需求工程 需求分析过程 用例分析技术 是指系统分析人员通过细致的调研分析，准确地理解用户需求，确定需求定义，并在开发过程中管理需求的过程。 是刻画软件功能、性能，确定软件和其他系统元素之间的借口，并建立软件必需满足约束的过程。 基于用例图的需求分析技术。用例图用于显示用例（表示系统功能）与角色（表示提供或者接收系统信息的人或系统）之间的交互