软件项目需求管理课程

系统需求和软件设计描述则是具体的，可以根据它 们来进行编码实现．
通常情况下，经常提到的是用户需求和系统需求．
2.1.2软件需求层次
➢ 用户需求
用户需求从用户的角度描述系统的需求，以便没有专业技术 背景的用户能看懂．它只描述系统的外部行为，尽量避免涉及系 统内部的设计特性，因而用户需求就不可能使用任何实现模型来 描述，而只能通过自然语言，图表，图形等来叙述．
见课本P57
2.3需求管理
2.3.1 需求管理的必要性 2.3.2 需求管理的困难性 2.3.3 需求管理的目标和原则 2.3.4 需求管理活动 2.3.5 需求变更管理 2.3.6 需求状态 2.3.7 需求文档版本控制 2.3.8 需求跟踪 2.3.8 案例：需求变更的代价
能级，并逐渐渗透到需求级。
2.1.5需求工程研究内容
➢ 需求工程的目标 需求工程有两个主要任务： 其一是：通过对问题及其环境的理解、分析和综合，建 立分析模型; 其二是：在完全弄清用户对软件系统的确切要求的基础 上，用SRS把用户的需求表达出来。
2.1.5需求工程研究内容
（１）建立需求分析模型 分析模型是描述软件需求的一组模型。 需求分析模型包含问题及其环境所涉及的信息流、
与能力
2.1.1软件需求概念
➢软件需求在软件项目的作用（如图2.1所示）
制定项目计划
系统构建
基础
产品可 追溯到
用户编制
基础
文档过程
作为 基线确定前 输入 缩小范围
跟踪
状态
项目跟踪和 控制过程
需求管理
验证实现 作为 的正确性 参考
进行 变更 作为 基线
请求范围 缩减
变更控制过程
系统测试过程
图2.1 软件需求与其他软件过程的关系
处理功能、用户界面、行为模型及设计约束等，是形成 需求说明、进行软件设计及实现的基础。 （２）编写SRS
SRS的编写要以需求分析模型为基础、按照软件组 织定义的SRS大纲、采用某种需求描述语言来进行。
2.1.5需求工程研究内容
➢ 需求工程的层次分解
需求工程可分为需求开发和需求管理，前者测重于需求的生成， 而后者测重于需求变更的控制。
2.2.4编写需求文档
➢软件需求规格说明
(1)基本含义 规格就是一个预期的或已存在的计算机系统的表示，它可 以作为开发者和用户之间协议的基础来产生预期的系统． 软件需求规格SRS也称为功能规格说明，需求协议或系统规 格说明，精确地阐述一个软件系统必须提供的功能和性能 以及它所要考虑的限制条件，是对外部行为和系统环境 （软件，硬件，通信端口和人）接口的简洁完整的描述性 文档．
为保证软件项目的成功，无论在哪个阶段，只要发现 问题，都必须修正需求文档．
2.1.2软件需求层次
(2) 非功能需求
非功能需求是指那些不直接与系统的具体功能相关的一类需求， 但它们与系统的总体特性相关，如可靠性，响应时间，存储空间 等。
非功能需求定义了对系统提供的服务或功能的约束，包括时间约 束，空间约束，开发过程约束及应遵循的标准等。
达将引起需求的不可验证．
2.2.4编写需求文档
需求文档的作用:
使用对象 需求文档的作用
软件项目客户 了解软件项目能够提供的软件产品，检查软件需求是 否满 足需要 项目管理人员 根据需求文档制定项目的开发计划和软件过程，初步 预测资 源的使用 软件开发人员 理解要开发的产品及具体要开发的内容 软件测试人员 验证软件系统是否满足了预期的要求 软件维护人员 使用需求文档帮助理解软件系统内在的逻辑关系 软件发布人员 在需求文档的基础上编写用户文档，如用户手册 软件培训人员 在需求文档的基础上编写培训材料
可用性需求 效率需求
可靠性需求 可移植性需求 交付需求 实现需求 标准需求 互操作需求 道德需求 立法需求
性能需求 空间需求
隐私需求安全性需求
2.1.2软件需求层次
(3) 领域需求
领域需求的来源不是系统的用户，而是系统应用的领域，反应 了该领域的特点。
领域需求可能是功能需求，也可能是非功能需，其确定需要领 域知识。
功能需求描述系统所应提供的功能和服务，包括系统 应该提供的服务，对输入如何响应及特定条件下系统 行为的描述．
系统的功能需求应该具备全面性和一致性．要做到全 面和一致几乎是不可能的．原因有二，其一是系统本 身固有的复杂性；其二是用户和开发人员站在不同的 立场上，导致他们对需求的理解有偏颇，甚至出现矛 盾
2.1.2软件需求层次
使用自然语言可能出现如下问题 描述困难 需求混乱
因此写需求文档应遵守一些简单原则： 标准的格式 使用一致的语言 使用特殊文本 尽量避免专业术语
2.1.2软件需求层次
➢系统需求
系统需求是比用户需求更为详细和专业的需求描述，是 系统实现的依据．一个完整且一致的系统需求描述，是 软件设计的起点．
需求获取的主要活动和展现成果：
2.2.2 需求获取
确定需求开发过程 编写项目视图和范围文档 用户群分类 选择产品代表 建立核心队伍 确定使用实例 召开应用程序开发联系会议 分析用户工作流程 确定质量属性 检查问题报告 需求重用
2.2.3 需求分析
需求分析包括提炼、分析和仔细审查已收集 到的需求，以确保项目的参与者都明白其含 义并找出其中的错误、遗漏或其它不足的地 方。
护性及可见性等。
(2)IEEE标准830-1998
2.2.4编写需求文档
a 引言
a.1需求规格的目的 a.2软件产品范围 a.3定义、首字母缩写词语缩略语 a.4参考文献 a.5文档概要
b一般描述
b.1产品透视 b.2产品功能 b.3用户特征 b.4一般约束 b.5假设和依赖性
c专门需求
包括功能需求、非功能需求和接口需求
2.1.2软件需求层次
➢软件需求的四个抽象层次
原始问题描述 用户需求 系统需求 软件设计描述
2.1.2软件需求层次
软件需求的抽象层次如图2.2所示：
图2.2 软件需求的抽象层次
2.1.2软件需求层次
① 原始问题：描述是对要解决问题的叙述 ② 用户需求：是用自然语言和图表给出的关于系统需要提供
图2.3 需求工程的研究内容
2.1.5需求工程研究内容
需求开发和需求管理是有界限的如图2.4所示：
图2.4 需求开发和管理的界限
2.2 需求开发
2.2.1 需求开发活动 2.2.2 需求获取 2.2.3 需求分析 2.2.4 编写需求文档 2.2.5 需求验证 2.2.6 案例:某公司“船代”项目的需求开发
系统需求描述通常采用结构化语言和过程设计语言PDL.
2.1.2软件需求层次
系统需求的描述语言:
表2.1系统需求的描述语言
名称 说明
结构化 是对自然语言格式化， 语言 依赖于定义标准格式或
模板来表达需求描述
优点
缺点
表现能力强、易 于理解 、一致性 约束 、控制结 构 、图形化显示
仍然有一定程度的 二义性；细致程度 欠缺
非形式化方法：使用未作任何限制的自然语言，易 于理解和使用，但它固有二义性，且难以保证正确性、 可维护性，难以用计算机系统提供自动化的支持。
半形式化方法：介于上述两者之间，在宏观上对语 言和语义有较精确的描述，而在某些局部方面则允许使 用非形式化的自然语言。
2.1.4 需求工程发展历程
(3) 自动化 在自动化的层次方面，已从实现级、设计级发展到功
第２章 软件项目需求管理
2.1需求工程 2.2需求开发 2.3需求管理 2.4案例故事解析 2.5总结
2.1需求工程
2.1.1 软件需求概念 2.1.2 软件需求层次 2.1.3 软件需求质量评价 2.1.4 需求工程发展历程 2.1.5 需求工程研究内容
2.1.1软件需求概念
定义：
简单地说，软件需求就是确定系统需要做什么． 严格意义上，软件需求是系统或软件必须达到的目标
需求分析的目的：获得高质量的、具体的需 求
2.2.3 需求分析
绘制关联图 创建用户接口原型 分析可行性 确定需求优先级 建立需求模型 编写数据字典 应用质量功能调配
2.2.4编写需求文档
编写需求文档时，以下几点是应该注意的： 语句和段落尽量简短． 表达时采用主动语态． 语句要完整，且语法，标点等正确无误． 使用的术语要与词汇表中的定义保持一致． 陈述时要采用一致的样式． 避免模糊的，主观的术语，如性能＂优越＂ 避免使用比较性的词汇，尽量给出定量的说明，含糊的语句表
2.2.1 需求开发活动
➢ 需求矩阵（表2.5）：
需求获取
编写前景 确定用户需求开发过程 用户群分类 选择产品代表 确定用例 联系会议 分析用户工作流程 确定质量属性 检查问题报告 需求重用
表2.5 需求开发矩阵
需求分析
规格说明
需求验证
绘制关联图
采用软件需求规格说明模板 审查需求文档
创建开发原型
指明需求来源
的服务及系统的操作约束 ③ 系统需求：用详细的术语给出系统要提供的服务及受到的
约束，因而系统需求文档也称为功能描述． ④ 软件设计：描述是在系统需求的基础上加入更详细的内容
构成的，它作为软件详细设计和实现的基础，是对软件设
计活动的概要描述．
2.1.2软件需求层次
原始问题描述和用户需求的抽象层次比较高．能帮 助我们在较高的抽象层次上进行交流，便于用户和 软件开发人员之间的理解和沟通．
2.1.3 软件需求质量评价
一个好的需求集应该满足用户解决问题需要的功能和服务,而且尽 量避免软件设计与软件实现的细节.
软件需求质量度量的九个元素:
正确性 无歧义 完备性 一致性 根据重要性和稳定性分级 可验证性 可修改性 可跟踪性 可理解性
2.1.4 需求工程发展历程
➢ 产生