第二章-需求分析

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