《第二部分 软件需求分析与建模》由会员分享，可在线阅读，更多相关《第二部分 软件需求分析与建模（140页珍藏版）》请在金锄头文库上搜索。
1、 软件工程方法与实践 （机械工业出版社）高等院校计算机课程案例教程系列窦万峰 编著主讲：曾婕 13767792699 1.现代软件工程(国家示范性软件学院系列教材)张家浩/东南大学 机械工业出版社 2009.1 2.软件工程 理论与实践许家珆 曾翎 彭德中 编著 高等教育出版社 2004.73.软件工程-实践者的研究方法（美）Roger S. Pressman著 郑人杰等译 机械工业出 版社 2008.6 4.Software Engineering, 6th EditionSoftware Engineering, 6th EditionSommerville.I. (影印版) 机械工业出版
2、社 2003.4主要参考书：主要参考书：总 目 录第1章 软件工程学概述（2学时） 第2章 软件过程（2学时） 第3章 软件过程模型（4学时） 第4章 案例研究（2学时） 第5章 软件需求分析过程（4学时） 第6章 结构化分析建模（4学时） 第7章 面向对象分析（6学时）第8章 软件设计（4学时） 第9章 结构化设计方法（4学时）总 目 录第10章 面向对象设计（4学时） 第11章 软件实现（2学时） 第12章 软件测试（4学时） 第13章 软件维护（2学时）第14章 软件项目管理（2学时） 第15章 软件项目估算（1学时） 第16章 软件项目计划与管理（1学时）第5章 软件需求分析过程5.1
3、 什么是软件需求 5.2 需求分析过程 5.3 启动分析过程 5.4 非形式化需求分析技术 5.5 案例分析 5.6 实验要求及习题在生命周期不同阶段修复缺陷的相对成本205210.50.1需求设计编码单元测试验收测试维护l 如果把编码阶段发现和修复一个错误所需要的努力用1个成本单元表示的话,那么需求阶段的错误修复成本是它的5到10倍。而且,在维护阶段发现和修复一个错误的成本超过20倍。l 在项目的需求阶段发现错误所花费的成本与维护阶段发现错误的成本比例是200:1 需求分析是软件定义时期的第一个阶段，它 的基本任务是准确地回答“系统必须做什么?（ what）”这个问题。需求分析的任务还不是确
4、定系统怎样（How ）完成它的工作，而仅仅是确定系统必须完成哪些 工作，也就是对目标系统提出完整、准确、清晰、 具体的要求。在需求分析阶段结束之前，系统分析员应该 写出软件需求规格说明书(SRS)，以书面形式准确 地描述软件需求。在分析软件需求和书写软件需求规格说明书 的过程中，分析员和用户都起着关键的、必不可少 的作用。只有用户才真正知道自己需要什么，但他们 并不知道怎样用软件实现自己的需求，用户必须把 他们对软件的需求尽量准确、具体地描述出来。分析员知道怎样用软件实现人们的需求，但 是在需求分析开始时他们对用户的需求并不十分清 楚，必须通过与用户沟通获取用户对软件的需求。需求分析和规格说明
5、是一项十分艰巨复杂的 工作。必须严格审查验证需求分析的结果。 功能需求：描述系统预期提供的功能或服务 系统应提供的服务 如何对输入做出反应 系统在特定条件下的行为 非功能需求：指那些不直接与系统具体功能相关的需求 产品需求：性能、可靠性、可用性 机构需求：过程标准、实现要求、交付需求 外部需求：互操作、道德 领域需求：对已存在的功能预期的约束或一个特别的计算 ，影响可用性5.1 什么是软件需求功能需求 软件系统的功能需求描述可以有许多方式： 文字描述 图表表示 功能需求可以以不同的详细程度反复编写和细化 功能需求描述应该完整而且一致和准确 完整性意味着用户所需的所有的服务应该全部给出描述 一致
6、性意味着需求描述不能前后矛盾 准确性是指需求不能出现模糊和二义性的地方功能需求描述：出卷系统 教师能够根据自己的要求手动或自动出一份试卷； 教师可以修改试卷中不合适的题目，并能自动生成各种样式的试卷； 教师可以对试题中的题目进行更新。非功能需求非功能需求主要与系统的总体特征相关，是一些限制性要求，是对实际使 用环境所做的要求性能要求可靠性要求安全性要求可用性要求移植性要求非功能需求关心的是系统整体特征而不是个别的系统的特征，比功能需求 对系统更关键。非功能需求却很难检验非功能需求与功能需求有时会发生冲突，它们之间存在着相互作用关系非功能需求举例 一个POS系统所需的存储因为成本原因有所限制，而
7、商品的描述和价目表的信息量很大。 如果采用远程服务器，提供商品描述和价目表信息，那必然需要网络通信，而这需要网络技术。 当POS机数量多时必然引起服务器处理瓶颈问题。领域需求 领域需求反映应用领域的基本问题，直接影响到系统的可用性。 例如：图书馆系统的功能需求基于标准用户界面将一些文档输出到本地打印机或网络打印机上，但因为版权限制，这些文档打印之后应立即删除。 例如：短信息系统-短消息协议标准 例如：校园编码-高等学校编码标准 例如：手机上网-WAP（Wireless Application Protocol)E需求分析主要是理解客户需要什么、分析要求、评价可行性、协商合 理的方案、无歧义地详
8、细说明方案、确认规格说明、管理需求以至将 这些需求转化为可行系统过程包括： 初步沟通 导出需求 分析和精化 可行性研究 协商与沟通 规格说明 需求验证 变更管理5.2 需求分析过程初步沟通 业务领域的共利益者（如业务管理人员，市场营销人员，产品管理人员）定义业务用例 确定市场的范围 初略地可行性分析 确定项目范围的工作说明导出需求 导出需求应理解问题 范围问题：系统的边界，是客户和开发者共同关心的 部分 理解问题：确定业务需求、需求冲突、说明有歧义和 不可测试的需求，确定各类需求 易变问题：分清需求稳定部分和易变部分 收集活动： 识别真正的客户/用户(例：POS机系统) 正确理解客户的需求 耐
9、心听取客户意见和思考 尽量使用符合客户语言习惯的表达分析和精化 开发一个精确的技术模型，用以说明软件的功能、特征和约束。 精化是一个分析建模动作，由一系列建模和求精任务构成 精化的结果是形成一个分析模型，其定义了问题的信息域，功能域和行为域可行性研究可行性研究的目的是确定用最小的代价，在尽可能短的时间内确定问 题是否能够解决，可行性研究的目的不是解决问题，而是确定问题是 否值得解决。 可行性研究的输入是系统的一个框架描述和高层逻辑模型输出是一份需求开发评价报告，对需求工程和系统开发是否值得做的 具体建议和意见回答三个问题： 系统是否符合机构的总体要求？ 系统是否可以在现有的技术条件、预算和时间
10、限制内完成？ 系统能否把已存在的其他系统集成？技术可行性、经济可行性、操作可行性、时间可行性可行性研究示例协商与沟通 调节冲突和问题 需求排序 识别和分析与每项需求相关的风险、开发工作量 、成本和交付时间软件需求规格 一个规格说明可以是一份写好的文档、一套图形 化的模型、一个形式化的数学模型、一组使用场 景、一个原型或以上各项的任意组合。 软件需求规格（SRS，Software Requirement Specification）是需求分析任务的最终“产品”，它 是客户、管理者、分析工程师、测试工程师、维 护工程师交流的标准和依据。 软件需求规格描述了系统的数据、功能、行为、 性能需求、设计约
11、束、验收标准、以及其他与需 求相关的信息。 分为：用户需求和系统需求用户需求描述示例: 2.1 处理销售：完成一次销售过程。 2.1.1 基本流程：（1）顾客携带所购商品或服务到收 银台通过POS机付款；（2）收银员开始一次新的销 售交易；（3）收银员输入商品条码；（4）系统逐条 记录销售的商品，并显示该商品的描述、价格和累计 额；重复（3）（4），直到输入结束；（5）系统 显示总额；（6）收银员告知顾客总额，并请求付款 ；（7）顾客付款，系统处理支付；（8）系统记录完 整的销售信息，并将销售金和支持信息发送到外部的 帐务系统和库存系统；（9）系统打印票据；（10） 顾客携带商品和票据离开。
12、2.1.2 扩展流程：.系统需求: 系统需求是比用户需求更详细的需求描述，是系 统实现的基本依据 系统需求描述可能包括许多不同的模型，如对象 模型和数据流模型需求规格文档标准（GB856D-1988）1 引言1.1 编写目的1.2 项目背景（单位和与其他系统的 关系）1.3 定义（专门术语和缩写词） 2 任务概述2.1 目标2.2 运行环境2.3 条件限制 3 数据描述3.1 静态数据3.2 动态数据3.3 数据库描述3.4 数据字典3.5 数据采集 4 功能需求 4.1 功能划分4.2 功能描述5 性能需求5.1 数据精确度5.2 时间特性5.3 适应性 6 运行需求6.1 用户界面6.2
13、硬件接口6.3 软件接口6.4 故障处理 7 其他需求（检测或验收标准、可用性、可维护性、 可移植性、安全保密性）示例需求验证 需求验证对需求文档和制品进行质量评估，确保需求 说明准确、完整 包括以下内容： 正确性 一致性 完整性 可行性 必要性 可检验性 需求的可跟踪性 最后签字需求变更管理 需求变更管理是组织、控制和文档化需求的系统 方法 建立基线以便在客户和开发人员之间建筑一个约 定 需求管理从标识开始，建立跟踪表 需求跟踪表可以跟踪需求的特征、来源、依赖、 子系统和接口等关系通用跟踪表需求 系统A01A02A03A04A05AmmR01R02R03R04Rnn 确定共利益者：直接或间接
14、从正在开发的系统中 获益的人 例如，POS机系统中的共利益者有：收银员、 售货员、顾客、公司、经理、支付授权服务、 帐务系统和库存系统等 识别视点：从不同的视角看待该系统 比如，收银员关心准确、快速生成一次销售， 且没有支付错误；售货员关注销售提成 协同工作：共利益者之间的协作 首次提问：集中于客户和其他共利益、整体目标 、收益等5.3 启动分析过程 会谈： 非正式会谈：提出一些可自由回答的问题 正式会谈：提出一些事先准备好的议题 情景分析：需求分析从对场景的评论中得到信息，然 后再将其以形式化方式表示出来。 使用调查表 制定调查表 分析 建立原型 界面 执行过程5.4 非形式化需求分析技术场
15、景分析 分析员与项目相关人员共同识别出情景，并捕获 这些情景的细节。 把细节加入到一个纲要的需求描述中时，情景特 别有用 情景是对交互实例片断的描述，每个情景可能包 含一个或多个交互，它们能在不同的细节层次上 提供不同类型的情景信息 情景开始于一个框架，在导出过程中，细节被逐 渐增加，直到产生交互的一个完整的描述情景 一个情景可能包括如下内容： 在情景开始部分有一个系统状态描述； 一个关于标准事件流的描述； 一个关于哪儿会出错，以及如何处理错误的 描述； 有关其他可能在同一时间进行的活动的信息 ； 在情景完成后系统状态的描述POS机系统中处理销售的场景用例名称：处理销售 范围：POS机应用级别：用户目标 主要参与者：收银员 涉众及其关注点： 收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收货 款，将从其薪水众扣除。 售货员：希望自动更新销售提成 顾客：希望以最小代价完成购买活动并得到快速服务。希望便捷、清晰地看 到所输入的商品项目和价格。希望得到购买凭证，以便退货。 公司：希望准确地记录交易，满足顾客要求。希望确保记录了支付授权服务 的支付票据。希望有一定的容错性，即便在某些服
