软件工程 第3章 结构化分析与设计 3-1章 需求分析和结构化系统分析 CUMT 11-07-26

需求工程
系统服务 运行环境
课件制作人：谢希仁
需求工程的基本活动包括：
获取需求；深入实际，在充分理解用户需求的基础上 ，获取系统需求。
●
●需求分析与建模；进行需求建模、对模型或原型进行 分析。 ● 确认需求；确保需求说明准确、完整地表达系统的 主要特性。 ● 进化需求。客户的需要总是不断（连续）增长的 ， 进化需求是必要的。
IEEE Standard Glossary of Software Engineering Terminology
用户解决一个问题或达到一个目标所需要 的一种状况或能力 主观需求 系统为了满足一种约定、标准、规格说明 或其它正式文件而必须满足或拥有的一种 状况或能力 客观需求 以上两种状态或能力的文档化表示 需求文档 课件制作人：谢希仁
需求工程国际会议（ICRE）。一些关于需求工程
的工作小组相继成立，使需求工程的研究得到了迅 速进展。
课件制作人：谢希仁
软件需求的重要性
软件需求无疑是当前软件工程中的关键问题，
没有需求就没有软件。
美国于1995年开始对全国范围内的8000个软件项目 进行跟踪调查。
分析失败的原因发现，
与需求过程相关的原因占了 45%，而其中缺乏最终用户的
⑴ 基本数据维护功能
⑵ 基本业务功能
⑶ 数据库管理功能
⑷ 信息查询功能
课件制作人：谢希仁
1. 功能需求 ⑴基本数据维护功能： 提供使用者录入，修改并进行维护基本数据的 途径。基本数据包括读者的信息、图书资料的相关 信息，可以对这些信息进行修改，更新。 ⑵基本业务功能：
读者借、还书籍的登记管理功能，随时根据读
第3章 结构化分析与设计
第3-1章 需求分析和 结构化系统分析
张 磊 博士，副教授 zhanglei@
《计算机网络》课件
制作人：谢希仁
3-1.1 3-1.2 3-1.3 3-1.4 3-1.5
需求分析概述 需求获取 需求分析原则 需求规格说明 传统的软件需求分析基础
课件制作人：谢希仁
(1)
课件制作人：谢希仁
(3) 完整性 需求规格说明书不能遗漏任何用户需求， 具体地说，目标软件产品的所有功能、行 为、行为约束以及它在所有可能情况下的 预期行为，均应完整地包含在需求规格说 明书中。 (4) 可验证性 对于规格说明书中的每一个需求，均应存 在技术和经济上可行的手段进行验证和确 认。
课件制作人：谢希仁
3-1.2.1需求获取(requiremente licitation)
是需求工程的主体。
——非常困难，主要原因有：
● 缺乏领域知识,应用领域的问题常常是模糊的、 不精确的；
● 存在默认的知识,如难以描述的常识问题； ● 存在多个知识源,且多知识源之间可能有冲突； ● 客户可能的偏见，如不能提供或不想告知你所需 要了解的事情。
者借、还书籍的情况更新数据库系统，如果书籍已
经借出，可以进行预留操作，书籍的编目、入库、
更新等操作。
课件制作人：谢希仁
⑶数据库管理功能： 对所有图书信息及读者信息进行统一管理维护 的功能，对书籍的借还也要进行详细的登记，以便 协调整个图书馆的运作。 ⑷信息查询功能： 提供对各类信息的查询功能，如对本图书馆的
未完成
完成
完成未实施
完成并实施 完成未实施 未完成
参与以及不完整的需求又是
两大首要原因，各占13%和 12%。
课件制作人：谢希仁
需求:成功的软件开发的前提
软件质量= 系统所实现的需求/客户所期望的需求 软件项目投标及签订合同的基础 软件系统实现的基础 系统确认移交的基础
课件制作人：谢希仁
需求的定义
③ 如果此主题还有未明确的问题则再次沟通,否则开始下一主题 ； ④ 所有需求都沟通清楚后，开发方根据历次《需求调研记录》 整理出《用户需求说明书》，提交给用户方确认签字。 课件制作人：谢希仁
例1：有一个大学图书管理系统，该系统除了一般的
图书管理功能外，还能够为学生和教工从其他图书
馆借阅图书和文献资料提供服务。 因此系统应该具备以下功能：
课件制作人：谢希仁
需求获取技术
需求抽取的方法一般有： 1.面谈法 重要而直接，简单的需求获取技术。 2.问卷调查法 是对面谈法的补充。 3.需求专题讨论会 最有力的需求获取技术。有 利 于 培养高效团队。 4.观察用户的工作流程 适用于用户无法准确表达 由开发方和用户方共同召开,操作步骤： 需求的情况。 ① 开发方根据双方制定的《需求调研计划》召开相关需求主题 沟通会； 5.原型化方法 ② 会后开发方整理出《需求调研记录》提交给用户方确认； 6.基于用例的方法
课件制作人：谢希仁
3-1.2 需求分析(工程)的活动
需求工程是系统工程和软件工程的一个交叉分支，涉及 到软件系统的目标、软件系统提供的服务、软件系统的约 束和软件系统运行的环境。它还涉及这些因素和系统的精 确规格说明以及系统进化之间的关系。它也提供现实需求 和软件能力之间的桥梁。
系统目标 软件约束
IEEE公布的需求定义分别从用户和软件工程 师的角度阐述了什么是需求，需求一方面反 映了系统的外部行为，另一方面反映了系统 的内部特性，反映的方式是需求文档。 比较通俗的需求定义如下：需求是指明系统 必须实现什么的规格说明，它描述了系统的 行为、特性或属性，是在开发过程中对系统 的约束。
课件制作人：谢希仁
软 件需 求
用 户需 求
系 统需 求
由客户管理员、 用户等提出
功能 需求
非功能 需求
领域 需求
课件制作人：谢希仁
功能需求
它是对系统应该提供的服务、功能以及系统 在特定条件下的行为的描述。它与软件系统的类 型、使用系统的用户等相关，有时需要详细描述
系统的功能、输入/输出、异常等，有时还需要申
明系统不应该做什么。 领域需求 是由软件系统的应用领域所决定的特有的功 能需求，或是对功能的约束。
课件制作人：谢希仁
(5) 一致性 需求规格说明书的各部分之间不能相互矛 盾。这些矛盾可以表现为术语使用方面的 冲突，功能和行为方面的冲突，以及时序 方面的前后不一致。 (6) 可理解性 追求上述目标不应妨碍需求规格说明书 对于用户、设计人员和测试人员的易理解 性。特别是对于非计算机专业的用户而言， 不宜在说明书中使用太多的专业化词汇。
课件制作人：谢希仁
3. 按必要性分类 (1) 强制的需求 是指除非软件与这些需求一致，则该软 件是不可接受的。 (2) 希望的需求 是指这些需求将增进软件产品功能，但 是如果缺乏的话也不是不可接受。 (3) 任选的需求 是指这个功能可有可无。
课件制作人：谢希仁
3-1.1.3 需求特性
正确性 需求规格说明书中的功能、行为、性能描 述必须与用户对目标软件产品的期望相吻 合。 (2) 无歧义性 对于用户、分析人员、设计人员和测试人 员而言，需求规格说明书中的任何语法单 位只能有唯一的语义解释。确保无歧义性 的一种有效措施是在需求规格说明书中使 用标准化术语，并对术语的语义进行显式 的、统一的解释。
课件制作人：谢希仁
(7) 可修改性 需求规格说明书的格式和组织方式应保证 能够比较容易地接纳后续的增删和修改， 并使修改后的说明书能够较好地保持其他 各项属性。 (8) 可追踪性 需求规格说明书必须将分析后获得的每项 需求与用户的原始需求项清晰地联系起来， 并为后续开发和其他文档引用这些需求项 提供便利。
课件制作人：谢希仁
非功能需求 产品需求 机构需求 外部需求
可用性 需求
效率 需求
可靠性 需求
可移植 性需求 交付 需求 实现 需求
互操作 需求 标准 需求
道德 需求
立法 需求
性能 需求
空间 需求
隐私 需求
1.2 需求类型
1. 按内容分类
软件需求代表系统的综合要求，包括以下几种类 型： (1) 系统功能需求 系统功能需求指根据系统所能实现的功能要求， 对于每一类功能或者有时对于每一个功能，需要 书弄清输入、加工和输出等需求。 (2) 系统性能需求 按照系统的性能要求分类。例如联机系统的响 应时间、系统需要的存储容量、后援存储器、重 新启动、安全性和可靠性等方面的要求。
课件制作人：谢希仁
2. 按用户的期望分类 (1) 正常需求 用户陈述的针对系统的目标。 (2) 期望需求 隐式的需求，可能由于是非常基础的而 用户没有显示的陈述，如人机交互的容易 性、整体的操作正确性和可靠性，以及软 件安装的容易性。 (3) 兴奋需求 在用户的期望范围之外，如果实现将令人 愉快和出乎意料。
② 对系统可用性的需求：为了方便使用者，要求 对所有交互操作提供在线帮助功能。 ③ 对系统查询速度的需求：要求系统在20S之内响 应查询服务请求。
④ 对系统可靠性的需求：要求系统失败发生率小 于1%。
课件制作人：谢希仁
3. 领域需求
例如：对“大学图书管理系统”，提出一些与图 书管理的业务相关的需求： ⑴ 图书编目要求按照《中国图书馆分类法》进行； ⑵ 由于版权限制，某些文献资料只能在图书馆规定 的阅览室阅读，并限制复制和打印。 第一条需求是对遵循我国图书管理的规定，执行 对图书的分类管理的标准。而第二条需求则是版权法 对图书馆文献资料的保护的需要，描述了对一类文献 资料有限制的使用和服务。
课件制作人：谢希仁
需求分析常用技术
为了降低软件的复杂度，便于对问题的分析和 理解，常采用以下技术： 1. 分解 将大问题分解为小问题，通常是自顶而 下，不断细化的过程。 2. 抽象 抓住问题的本质特性，从不同抽象层次 进行分析，提出解决问题的方案。
课件制作人：谢希仁
(3) 系统运行需求 这类要求集中表现为对系统运行时所 处的环境、使用的资源、安全保密和用户 界面的要求。如支持系统运行的硬件和软 件是什么，采取哪种数据库管理系统，需 要什么样的外存储器和数据通信接口。 (4) 未来可能出现的问题 就是把不属于当前系统开发范围的问题 都明确地列出来，因为将来很可能会提出 这些问题。这些问题主要是为了系统将来 的扩充和修改做准备，当以后需要时就可 以很容易地进行扩展和修改了。
3-1.1 需求分析概述 3-1.1.1需求分析的内容
软件需求作为软件生命周期的第一个阶段，其 重要性越来越突出，到20世纪80年代中期，逐步 形成了软件工程的子领域——需求工程。 90年代后，需求工程成为软件界研究的重点 之一。从1993年起，每两年举办一次需求工程国 际研讨会（ISRE），1994年起，每两年举办一次
课件制作人：谢希仁
3-1.2.2需求分析与建模
主要对收集到的需求进行提炼、分析和认真审 查，确保所有参加人员取得一致共识。找出错误、 遗漏和不足，建立完整的分析模型。
需求分析和建模又包含三个层次的工作。
1、需求分析
2、需求建模（分为企业建模、功能需求建模和非 功能需求建模等） 3、需求规格说明—不同的描述方式。
用户借书信息，还书的信息，书籍源信息，预留信
息等进行查询，对其他图书馆的书籍、资料源信息
的查询功能。
课件制作人：谢希仁
2.非功能需求
① 系统安全性需求：为保证系统安全性，对本图 书馆的各项功能进行分级、分权限操作，对各类用户 进行确认。对其它图书馆借阅图书和文献资料服务控 制访问范围：如限IP、限用户等。
课件制作人：谢希仁
需求获取技术
需求抽取的方法一般有： 1.面谈法 重要而直接，简单的需求获取技术。 2.问卷调查法 是对面谈法的补充。 3.需求专题讨论会 面谈的对象主要有用户和领域专家： 最有力的需求获取技术。有 利 于 培养高效团队。 面谈前的准备要充分； 1） 2） 适用于用户无法准确表达 4.观察用户的工作流程 面谈后注意认真分析总结； 需求的情况。 3） 注意掌握面谈的人际交流技能。 5.原型化方法 6.基于用例的方法 还有知识工程方法等如：场记分析法、卡片分 类法、分类表格技术和基于模型的知识获取等。
课件制作人：谢希仁
需求获取技术
需求抽取的方法一般有： 1.面谈法 重要而直接，简单的需求获取技术。 2.问卷调查法 是对面谈法的补充。 3.需求专题讨论会 最有力的需求获取技术。有 是从多个用户中收集需求信息的有效 利 于 培养高效团队。 方式 ，一般问卷设计形式： 4.观察用户的工作流程 适用于用户无法准确表达 1）多项选择问题 ； 需求的情况。 2）评分问题 ； 5.原型化方法 3）排序问题 。 6.基于用例的方法