需求分析看书小结
- 格式：doc
- 大小：216.00 KB
- 文档页数：12
1.软件需求定义
需求是指系统必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束
2.需求工程的本质
需求工程可以看作把一个定义不足的问题转换为一个定义充分的问题以便找出解决方案
3.问题域与解系统
问题域:被开发系统的应用领域
解系统:指可以在问题域内产生某种效果的系统
4.软件需求分类
功能需求
性能需求 (非功能需求)
设计约束
商业约束
5.客户/用户/开发者的需求观
6.不合格的需求派生的问题
1. 无足够用户参与
2. 用户需求的不断增加
3. 模棱两可的需求说明
4. 不必要的特性
5. 过分精简的规格说明
6. 忽略用户分类
7. 不准确的计划 问题域 接 解系分析 规格说明 设计
业务需求 项目视图用户需求
质量属性 使用实例文系统需求 功能需求 其它非功
能需求
约束条件
软件需求规格说明
SRS
7.高质量的需求带来的好处
8.优秀需求所具有的特征
8. 完整性(Complete)
9. 正确性(Correct)
10. 可行性(Feasible)
11. 必要性(Necessary)
12. 与实现无关性(Implementation Independent)
13. 划分优先级 (Prioritized, Future and trade-offs)
14. 无二义性(Unique)
15. 可验证性(Verifiable)
16. 正确的详细层次(Right level of details)
2. 需求规格说明的特征
1. 完整性(Complete)
2. 一致性(Consistent)
3. 简洁明了(Concise)
4. 可修改性(Modifiable)
5. 可跟踪性(Traceable)
• 软件需求工程定义
•
• 需求获取
– 应当收集什么信息
• 问题域的描述
• 要求解决的问题列表(需求)
• 用户对解系统的行为或结构施加的任何约束
– 有哪些信息来源 需求工程
需求管理 需求开发
编写规格说明 分析 问题获取 验证 包括软件类产品中需求收集、评建立并维护在软件工程中同客户• 高层系统需求 System Requirements
• 客户(实际的和潜在的) Customers
• 客户的“规格说明书” CRS
• 原有解系统(即运行在问题域中，执行与预期的新的解系统相似功能的系统)及其文档
• 原有系统的用户
• 竞争对手的产品
• 应用领域专家
• 定义了任何接口系统的特征和行为的文档
• 相关的技术标准和法规
– 可能通过什么机制或技术收集
• 面谈
• 准备
• 询问正确的问题
• 直接问题
• 原始的和派生的问题
• 总结性问题
• 集中精力倾听
• 重复关键问题
• 记录收集的信息
• 调查表
• 用例或场景分析
• 对客户进行分类 • 业务需求
• 使用实例
• 功能需求
• 质量属性
• 外部接口
• 限制
• 数据定义
• 解决思路
• 头脑风暴
• 需求剪裁
– 确定需求开发过程
– 编写项目视图和范围文档
• 业务需求
• 背景
• 业务机遇
• 业务目标
• 客户需求
• 业务风险
• 项目视图解决方案
• 范围和局限性
• 业务环境
• 产品成功的因素 • 基于项目视图和范围的管理
• 将用户群分类并归纳各自特点
• 选择每类用户的产品代表
• 建立起典型用户的核心队伍
• 让用户代表确定用户使用实例
• 召开应用程序开发联系会议(JAD)
• 分析用户工作流程
• 确定质量属性和其它非功能需求
• 通过检查当前系统的问题报告来进一步完善需求
• 跨项目重用需求
• 需求分析
– 绘制系统关联图
– 创建用户接口原型
– 分析需求可行性
– 确定需求优先级别
– 为需求建立模型
– 创建数据字典
– 使用质量功能部署
– 结构化分析工具
• DFD数据流图、DD数据字典和PSPEC
• CFD、CSPEC和STD
• E-R图 – 面向对象分析工具
• 用例图，类图，对象图
• 对象-关系图
• 对象-行为图
– 建模工具
• 数据流图
• 实体关系图
• 状态转换图
• 对话图
• 类图
• Petri Net
–
• 需求规格书
– 采用SRS模板
– 指明需求的来源
– 为项目需求注上标号
– 记录业务规范
– 创建需求跟踪能力矩阵
• 需求验证
– 审查需求文档
– 以需求为依据编写测试用例
– 编写用户手册 – 确定合格的标准
•
•
• 确定需求变更控制过程
• 建立变更控制委员会
• 进行需求变更影响分析
• 跟踪所有受需求变更影响的工作产品
• 建立需求基准版本和需求控制版本文档
• 维护需求变更的历史记录
• 跟踪每项需求的状态
• 衡量需求稳定性
• 使用需求管理工具
•
• 客户的需求观
• 相关人员 • 成功的目标 • 构成阻碍的因素
• 用户 • 产品易于使用，具有所• 不合理的期望 有期望的功能和操作能力
• 客户 • 在规定时间和投资下向用户递交产品，最大可能满足用户需要 • 不切实际的时间表和预算
• 频繁的需求变更
• 不确定的质量目标
• 开发人员 • 开发满足客户、用户需求的产品。收回投资 • 人员能力不足
• 个人表现欠佳
• 缺乏风险意识
• 接受客户不切实际的要求
•
• 需求知识技能获取
– 培训需求分析人员
• 熟练的需求分析员应具备以下特点：
• 耐心
• 思维条理性强
• 有良好的交际和沟通能力
• 理解产品应用领域
• 掌握丰富的需求工程技术
– 培训软件需求的用户代表和管理人员
• 明白重视需求的意义
• 需求工作包括哪些活动
• 要提交什么样的结果
• 忽略需求过程会导致的风险 • 更加体谅软件开发人员
–
– 让开发人员了解问题域(应用领域)的基本概念
– 编写项目术语汇编
• CMMI需求工程过程模型
需求分析的六个原则
（一）永远不要显得比客户更聪明
总结一下需求分析第一个原则的中心思想：
1、需求分析第一个原则：永远不要显得比客户更聪明。
聪明反被聪明误，这样的事情太多了，我们产品经理都是有智慧的人，而不是耍小聪明的人。
2、原则第一点：了解需求，而不是去批评客户。
产品经理不是批评家，心理上要重视客户，行动上要尊重客户，平等对待每一个客户。 3、原则第二点：客户比你更熟悉业务的环境。
产品经理熟悉的仅仅是产品本身，但是，产品经理要做的却不仅仅是产品本身。
4、原则第三点：真正的问题只有客户知道，我们要做的就是让客户愿意说出来。
客户会给你反馈，但是这些反馈有些是真实的，有些是敷衍的，你希望真实还是敷衍，请参考原则第一点。
需求分析的六个原则（二）尊重用户的现实选择
总结一下需求分析第二个原则的中心思想：
1、需求分析第二个原则：尊重用户的现实选择。
产品是客观的，用户是客观的，使用是客观的，需求也是客观的，一切都是现实的。
2、原则第一点：客户永远是对的。
客户不是我们的敌人，客户不会害我们，客户提出的需求看似在为难我们，但本质上是为了让客户自己更好的使用产品，因此，客户不会为难自己。
3、原则第二点：提供最合适的解决方案，而非最好或最贵的方案。
我们能够做的不一定是最好的，我们不想做的有时候往往是客户最需要的，找到最合适客户的，而不是最合适我们的。
4、原则第三点：不要把客户当傻瓜。
这个世界上没有傻瓜，自以为对方是傻瓜的人才真的是傻瓜，不要忽悠客户，不要欺骗客户，如果非要在这个前面加上一个期限的话，我希望是“永远”。
需求分析的六个原则（三）转述需求的人也是客户
总结一下需求分析第三个原则的中心思想：
1、需求分析第三个原则：第三方也是我们的客户。
只要是对我们的产品和业务提出需求，就是我们的客户，应该一视同仁。
2、原则第一点：第三方一般会把自己想象成设计者。
他们对产品或许很熟悉，但是对整个业务可能不熟悉，因此，他们成不了设计者。
3、原则第二点：第三方可能会遗漏或补充一些额外的需求。
每个人都期望产品能做好，这种强烈的成功心理容易让人们产生日晕心理，从而影响我们对需求的筛选。
