片面, 不完全 模糊, 不准确 不一致, 歧义 需求复杂和庞大
因此必须使用系统的方法、借助于一系列行之 有效的技术和工具进行软件需求分析
软件需求的层次
业务需 求
用户需 求
非功能性需 求
系统需 求
功能需 求
质量特 性
约束和假 设
软件需求规格
chapter__2
3
chapter__2
4
项目失败的原因分析
Source: Carnegie-Mellon University, SoftwchaarpeterE__n2gineering Institute
平均值
4.5 4.3 4.2 4.1 4.1 3.9 3.8
3.8 3.6 3.6
5
软件需求管理的过程
需 求 需求获取 确 认
需求验证
需求分析 编写需求规格
缺乏了解软件特性的经理人
5
Shortage of qualified project managers
缺乏合格的项目经理
6
Shortage of software engineers
缺乏软件工程师
7
Fixed - price contract 固定价合同
Inadequate communications for system integration 8
15
需求变更管理
管理和控制需求基线的过程 需求变更控制系统 一个正式的文档，说明如何控制需求变更 建立变更审批系统（sccb，软件变更控制委员
会）
chapter__2
16
需求方 变更申请
选择变更方式
开发方
忽略 拒绝
SCCB评估 根据评估结果
接受本次修改
项目经理自行决定 下个版本再修改
修改合同相关信息
chapter__2
11
规格说明应该包括系统运行环境 规格说明应该是一个认识模型 规格说明应该容许不完备性并允许扩 充
chapter__2
12
3、规格文档参考
1. 引言 2. 系统定义 3. 应用环境 4. 功能规格 5. 性能需求 6. 产品提交 7. 实现约束 8. 质量描述 9. 其它 10. 签字认证
修改相关需求
修改相应的项目计划
chapter__2
17
申请人
项目名称
阶段名称 文件名称
修改内容
表4-3 需求变更提交单
软件基线产品修改提交单
申请日期 2002。10．11
项目管理系统
系统设计
RCR-PM-01.doc, RCR-PM-02.doc, 变更简述如下
1）修改测试流程控制：将2个角色，3个渠道流，改为3个角色，4个渠道流，详见RCR-PM-01.doc 2）增加开发人员技能信息库管理，详见RCR-PM-02.doc
No.
Top 10 Factors
1
Inadequate requirements specification
不充分的需求规范
2
Changes in requirements 需求的改变
3
Shortage of systems engineers 缺乏系统工程师
4
Shortage of software managers
需求分析
一、需求分析 二、需求管理过程 三、需求分析模型 四、需求建模方法 五、案例分析
chapter__2
0
软件需求
开发软件系统前，须了解用户的期望和要求
软件需求 需求分析过程
需求分析的重要性
软件开发的基础和前提 最终目标软件系统验收的标准 避免或者尽早剔除早期的错误
..
chapter__2
1
需求分析的复杂性和面临的困难
4.观察用户的工作流程或实践
5.原型化方法
6.基于用例的方法
chapter__2
7
需求分析
问题分析和方案的综合是需求分析的第二方面的 工作。需求分析的任务就是借助于当前系统的逻 辑模型导出目标系统的逻辑模型，解决目标系统 的“做什么”的问题。其实现步骤如下图所示。
chapter__2
8
需求分析模型
chapter__2
9
需求规格
需求分析工作完成的一个基本标志是形成 了一份完整的、规范的需求规格说明书
需求规格说明书的编制是为了使用户和软 件开发者双方对该软件的初始规定有一个 共同的理解，使之成为整个开发工作的基 础。
chapter__2
10
软件需求规格说明的原则
从现实中分离功能，即描述要“做什 么”而不是“怎样实现” 采用一定的规格说明语言 如果被开发软件只是一个大系统中的 一个元素，那么整个大系统也包括在 规格说明的描述之中
系统集成阶段 , 交流与沟通不充分
9
Insufficient experience as team 团队缺乏经验
10 Shortage of application domain experts
缺乏应用领域专家
Scale: 5 = Very Serious 3 = Serious 1 = No Serious
chapter__2
14
需求变更管理
1. 确定需求变更控制过程 2. 建立变更控制委员会(SCCB) 3. 进行需求变更影响分析 4. 跟踪所有受需求变更影响的工作产品 5. 建立需求基准版本和需求控制版本文档 6. 维护需求变更的历史记录 7. 跟踪每项需求的状态 8. 衡量需求稳定性
chapter__2
按照国家标准GB/T 8567—2006 《计算机软件文档编制规范》， 涉及需求规格说明的文档有“软 件需求规格说明（SRS）”、 “数据需求说明（DRD）”等。
chapter__2
13
需求验证
需求是正确的吗？ 需求是一致的吗？ 需求是完全的吗？ 需求是实际可行的吗？ 需求是必要的吗？ 需求是可检验的吗？ 需求是可跟踪的吗？ 最后的签字
3.需求专题讨论会 最有力的需求获取技术。有利于培养高效团队。
由开发方和用户方共同召开,操作步骤：
① 开发方根据双方制定的《需求调研计划》召开相关需求主题沟通会
② 会后开发方整理出《需求调研记录》提交给用户方确认
③ 如果此主题还有未明确的问题则再次沟通,否则开始下一主题
④ 所有需求沟通清楚后，开发方整理出《用户需求说明书》，提交给 用户方确认签字
需求变更
需求变更
..Leabharlann chapter__26
需求获取
需求获取技术的方法：
1.面谈法 重要而直接，简单的需求获取技术。
面谈的对象主要有用户和领域专家：
1） 面谈前的准备要充分；
2） 面谈后注意认真分析总结；
3） 注意掌握面谈的人际交流技能。
2.问卷法调查法 是对面谈法的补充。
是从多个用户中收集需求信息的有效方式 ，一般问卷设计形式：