2.一致性检查－－系统功能描述及约束是否一致。 3.完备性检查－－是否包含所有系统用户的需求和 约束。
4.可检验性检查－－能否设计出一组验证方法，确 定了检验的标准。
四、需求管理
需求管理贯穿需求分析全过程，包括:
需求管理
变更控制
• • • • • 评估建议变更 分析影响 交流 实施 合并 测量需求的稳 定性
图书的分类管理的标准。而第二条需求则是版权法对
图书馆文献资料的保护的需要，描述了对一类文献资
料有限制的使用和服务。
二、需求分析与建模
主要对收集到的需求进行提炼、分析和认真审 查，确保所有参加人员取得共识。找出错误、遗漏 和不足，建立完整的分析模型。
需求分析和建模又包含三个层次的工作。 1. 需求分析 2. 需求建模（分为企业建模、功能需求建模和非 功能需求建模等）
2. 无法对描述的准确度进行验证。
3. 难以适应需求的变化。
例：
酒店管理系统
按照功能分解为以下子系统：
1．客房预定系统 2．前台接待系统
3．前台收银系统 5．管家系统 7．客房系统 9．经理系统 11．密码管理系统 13．账务报表
4．账务系统 6．电话系统 8．合约系统 10．总经理系统 12．报表系统
需求获取技术
需求获取的方法一般有： 1.面谈法 重要而直接、简单的需求获取技术。 2. 问卷法调查法 是对面谈法的补充。 3.需求专题讨论会 最有力的需求获取技术，有利 于培养高效团队。 4. 观察用户的工作流程 适用于用户无法准确表达 由开发方和用户方共同召开需求主题沟通会 ,操作步骤： ① 开发方根据双方制定的《需求调研计划》确定会议内容； 需求的情况。 ② 会后开发方整理出《需求调研记录》提交给用户方确认； 5. 原型化方法 ③ 如果此主题还有未明确的问题则再次沟通,否则开始下一主题； 6. 基于用例的方法 ④ 所有需求都沟通清楚后，开发方根据历次《需求调研记录》整
1.1.3
验证库存 量级
●
一、需求获取(requirement elicitation)
是需求工程的主体。非常困难，主要原因有：
● 缺乏领域知识,应用领域的问题常常是模糊的、不 精确的；
● 存在默认的知识,如难以描述的常识问题； ● 存在多个知识源,且多个知识源之间可能有冲突； ● 客户可能的偏见，如不能提供或不想告知你所需 要了解的事情。
需求获取技术
需求获取的方法一般有： 1.面谈法 重要而直接、简单的需求获取技术。 2. 问卷调查法 是对面谈法的补充。 3.需求专题讨论会 最有力的需求获取技术。有利 面谈的对象主要有用户和领域专家： 于 培养高效团队。 1） 面谈前的准备要充分； 4. 观察用户的工作流程 适用于用户无法准确表达 2） 面谈后注意认真分析总结； 需求的情况。 3） 注意掌握面谈的人际交流技能。 5. 原型化方法 6. 基于用例的方法 还有知识工程方法等，如：场记分析法、卡片分 类法、分类表格技术和基于模型的知识获取等。
可行性研究
需求导出 和分析 需求描述
可行性报告 系统模型 需求有效性 验证
用户需求和 系统需求 需求文挡
需求工程过程
2.2 需求分析方法
功能分解方法 将系统看作若干功能模块的集合，每个功能又可 以分解为子功能,子功能还可继续分解,分解的结果即 是系统的雏形。
映射 问题空间 功能 子功能
存在问题 1. 需要人工完成
2
第二 章
软件需求工程
高等教育出版社 高等教育电子音像出版社
软件需求作为软件生存周期的第一个阶段，
其重要性越来越突出，到20世纪80年代中期，逐
步形成了软件工程的子领域——需求工程。 20世纪90年代后，需求工程成为软件界研究 的重点之一。从1993年起，每两年举办一次需求 工程国际研讨会（ISRE）；1994年起，每两年举 办一次需求工程国际会议（ICRE）。一些关于 需求工程的工作小组相继成立，使需求工程的研
一、软件需求内容
软 件需 求
用 户需 求
系 统需 求
由客户管理员、 用户等提出
功能 需求
软件需求的内容
非功能 需求
领域 需求
功能需求
它是对系统应该提供的服务、功能以及系统 在特定条件下的行为的描述。它与软件系统的类 型、使用系统的用户等相关，有时需要详细描述
系统的功能、输入/输出、异常等，有时还需要声
用户借书信息、还书的信息、书籍源信息、预留信
息等进行查询，对其他图书馆的书籍、资料源信息
的查询功能。
2.非功能需求 ① 系统安全性需求：为保证系统安全性，对本图书 馆的各项功能进行分级、分权限操作，对各类用户进 行确认。对其他图书馆借阅图书和文献资料服务控制 访问范围：如限IP、限用户等。 ② 对系统可用性的需求：为了方便使用者，要求对 所有交互操作提供在线帮助功能。 ③ 对系统查询速度的需求：要求系统在20 s之内响 应查询服务请求。
美国于1995年开始对全国范围内的8000个软件项目 进行跟踪调查。
分析失败的原因发现，
与需求过程相关的原因占了 45%，而其中缺乏最终用户的
未完成
完成
完成未实施
完成并实施 完成未实施 未完成
参与以及不完整的需求又是
两大首要原因，各占13%和 12%。
软件需求的困难
软件需求是软件工程中最复杂的过程之一。 1. 应用领域的广泛性，它的实施无疑与各个应用行 业的特征密切相关。 2. 非功能性需求建模技术的缺乏，及其与功能性需 求有着错综复杂的联系，大大增加了需求工程的 复杂性。 3. 沟通上的困难，由于系统分析员、需求分析员等 各方面人员有不同的着眼点和不同的知识背景， 给需求工程的实施增加了人为的难度。
究得到了迅速进展。
2.1 软件需求工程的基本概念
1.什么是软件需求工程？ 2.软件需求工程的任务是什么？
3.需求工程过程
4.软件需求分析方法 对系统应该提供的服务和所受到的约束进行理
解、分析、建立文档、检验的过程——需求工程。
软件需求的重要性
软件需求无疑是当前软件工程中的关键问题，
没有需求就没有软件。
三、需求的有效性验证
(一) 需求验证的重要性
１. 由于需求是软件开发的第一阶段，直接影响后 面各阶段的开发。
软件 需求 软件 设计 软件 编码 软件 测试 运行 维护
做什么
怎么做
２. 需求的可变性必须进行验证。
三、需求的有效性验证
(二) 需求验证的内容
1.有效性检查－－指功能需求是否符合用户所提出 的需求。
读者借、还书籍的登记管理功能，随时根据读者 借、还书籍的情况更新数据库系统，如果书籍已经借 出，可以进行预留操作以及书籍的编目、入库、更新 等操作。
⑶数据库管理功能 对所有图书信息及读者信息进行统一管理维护 的功能，对书籍的借还也要进行详细的登记，以便 协调整个图书馆的运作。 ⑷信息查询功能 提供对各类信息的查询功能，如对本图书馆的
版本控制
• 定义需求文档 版本 • 确定单个需求 文档版本 记录所有需求 的变化
需求跟踪
• 定义与其他需 求的链接 • 定义与其他系 统元素的链接
(需求跟踪能力矩 阵、分析影响)
需求状态跟踪 • 定义需求状态 • 跟踪所有需求 状态
四、需求管理
需求管理的所有活动中，最重要的是 “需求变更 管理”，包括:
④ 对系统可靠性的需求：要求系统失败发生率小于 1%。
3. 领域需求 例如：对“大学图书管理系统”，提出一些与图 书管理的业务相关的需求：
⑴ 图书编目要求按照《中国图书馆分类法》进行；
⑵ 由于版权限制，某些文献资料只能在图书馆规定 的阅览室阅读，并限制复制和打印。
第一条需求是遵循我国图书管理的规定，执行对
需求获取技术
需求获取的方法一般有： 1.面谈法 重要而直接、简单的需求获取技术。 2. 问卷法调查法 是对面谈法的补充。 3.需求专题讨论会 最有力的需求获取技术。有利 于 培养高效团队。 是从多个用户中收集需求信息的有效 方式 ，一般问卷设计形式： 4. 观察用户的工作流程 适用于用户无法准确表达 1）多项选择问题 ； 需求的情况。 2）评分问题 ； 5. 原型化方法 3）排序问题 。 6. 基于用例的方法
例：盘存/销售系统，用户提出系统应有以下功能: ① 计算买主订单 ② 准备销售报表 ③ 建立买主文件和应收账发票 ④ 运行更新的盘存文件 ⑤ 产生托运单和包装单 ⑥ 保证库存及时订货
盘存/销售系统
1.0.0
销售处理
1.1.0
盘存处理
1.2.0
计算销售 记录
1.1.1
产生销售 报表
1.1.2
核对买主 贷方金额
传统需求分析
在传统软件工程生存周期中，涉及需求的阶段 称作需求分析。一般来说，需求分析的作用是： ●定义软件的范围及必须满足的约束； ●确定软件的功能和性能及与其他系统成分的接 口; ●建立数据模型、功能模型和行为模型；
●最终提供需求规格说明，并用于作为评估软件 质量的依据。
二、需求工程的活动
需求工程是系统工程和软件工程的一个交叉分支，涉 及软件系统的目标、软件系统提供的服务、软件系统的 约束和软件系统运行的环境。它还涉及这些因素和系统的 精确规格说明以及系统进化之间的关系。它也提供现实需 求和软件能力之间的桥梁。
明系统不应该做什么。 领域需求 它是由软件系统的应用领域所决定的特有的 功能需求，或是对功能的约束。
非功能需求 产品需求 机构需求 外部需求
可用性 需求
效率 需求
可靠性 需求
可移植 性需求 交付 需求 实现 需求
互操作 需求 标准 需求
道德 需求
立法 需求
性能 需求
空间 需求
隐私 需求
安全 性需求
3. 需求规格说明－－不同的描述方式