项目管理理论与实践（2）——软件需求分析
本篇文章主要是对于软件需求分析相关的介绍。
一、需求分析的目的
1. 马斯洛的需求层次理论
具体可以参考：（http://baike.baidu.com/view/295140.htm）
2. 需求分析的目的
1）与相关干系人在工作内容方面达成并保持一致
2）使设计、开发、测试人员能够更清楚地了解需求
3）定义系统边界，形成需求基线
4）为估算系统的规模、工作量、成本和进度提供基础
5）为开发计划的形成提供范围（SOW）基础
二、需求工程概述
1. 什么是需求工程？用一张图可以形象的表示
需求也属于一门工程学，需求工程包括需求开发、需求管理两个方面，其中需求开发包括需求开发准备、需求获取、需求分析、需求验证。
2. 需求分析的流程图
三、需求获取
1. 需求获取的基本原则
1）深入浅出
对企业的需求调研的要尽可能的全面、细致调研的需求是个全集，系统真正实现的是个子集。
调研的细致并不等于在分析时都面面俱到地将调研的内容纳入到新系统中, 而有可能实现的很少,但其中在向细处扩充时将会很容易。
2）以流程为主线
应该用流程将所有的内容串起来，如单据、信息、组织结构、处理规则等。
流程的描述既要有宏观，又要有微观。
3）鱼刺图
石川图，鱼骨图， ishikawa图
2. 六边形法则
1）组织结构：企业为进行相应的业务流程所做的人员的组织安排。
2）业务流程：企业开展业务所必须的各个环节及在每个环节中的具体做法。
3）业务数据：企业内部经营信息的存储和流动形式。
4）业务地点分布：反映企业在什么地方开展业务以及业务流程中的各个环节之间的地点关系。
5）业务应用：企业以什么样的应用软件处理业务流程中的各个环节。
6）技术基础设施：企业在信息技术基础设施上的状况。
五、需求分析
1. 绘制关联图
1）用于定义系统与系统外部实体间的界限和接口的简单模型。
2）明确了通过接口的信息流和物流。
2. 创建开发原型
1）使得许多概念和可能发生的事更为直观明了。
2）用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。
3. 确定需求优先级
1）应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。
2）以优先级为基础确定产品版本将包括哪些特性或哪类需求。
3）帕雷托图定理（Pareto，2,8定理）
4. 为需求建立模型
1）是软件需求规格说明极好的补充说明。
2）它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。
3）这样的模型包括用例图、流程图、实体关系图、状态图、时序图、类图、对象类及交互调用图。例如：
并且书写用例情况
| 用例名称：网站新闻发布 |
| 用例标识号：102 |
| 角色：后台系统管理员 |
| 用例说明：后台系统管理员用来填写和修改物流网站首页的新闻，新闻最终显示在物流网站的首页上。 |
| 前置条件：后台系统管理员已经登录物流网站后台管理系统 |
| 基本事件流： |
|
1． 选择发布新闻 2． 填写新闻标题，内容以及上传图片 3． 修改标题、内容、图片，也可以完全删除，重填新闻信息 4． 编辑完成，选择提交 5． 用例终止 |
|
其他事件流：在提交之前，随时可以返回，任何修改内容都不会影响网站首页的新闻 |
| 异常事件流： |
|
1． 提示图片大小超过范围错误信息，重新上传， 2． 返回到后台管理系统主页面 |
|
后置条件：网站首页的新闻信息被更新 |
|
注释：无 |
5. 编写数据字典
1）创建数据字典，数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。
2）在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。
6. 应用质量功能调配要
1）将产品特性、属性与对客户的重要性联系起来。
2）明确那些是客户最为关注的特性。
3）将需求分为三类：
–期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意
–普通需求
–兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备
六、编写需求规则说明书
1. 采用软件需求规格说明模版
1）为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。
2）其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。
| 1. 概述 | 编写目的 | 系统目标 | 术语定义 | ||
| 2. 功能需求 | 功能划分 | 模块名 | 子模块 | 功能名称 | 功能描述 |
| 3. 非功能需求 | 性能指标 | 可维护性 | 可扩展性 | 安全性 | |
| 4. 设计约束 | 语言约束 | 系统模型约束 | |||
| 5. 界面要求 | 页面布局 | ||||
| 6. 验收标准 | |||||
| 7. 附件 | 数据字典 | 模型 |
2. 指明需求的来源
1）为了让所有项目风险承担者明白需求规格说明书中为何提供这些功能需求，要都能追溯每项需求的来源；
2）可能是一种使用实例或其它客户要求，也可能是某项更高层系统需求、业务规范、政府法规、标准或别的外部来源。
3. 为每项需求注上标号
1）可跟踪性和可修改性的质量标准，必须唯一确定每个软件需求。
2）为每项需求注上标号制定一种惯例来为需求规格说明书中的每项需求提供一个独立的可识别的标号或记号。
3）这种惯例应当很健全，允许增加、删除和修改。
4）作了标号的需求使得需求能被跟踪，记录需求变更并为需求状态和变更活动建立度量。
5）需求标识方法有序列号;层次化编码;使用"待确定"（to be determined, TBD）符号等。
4. 记录业务规范
1）是指关于产品的操作原则，比如谁能在什么情况下采取什么动作。
2）将这些编写成需求规格说明书中的一个独立部分，或一独立的业务规范文档。
七、需求验证
1. 审查需求文档
1）在需求开发期间进行非正式评审。
2）对需求文档进行正式审查是保证软件质量的很有效的方法。
3）组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。
2. 依据需求编写测试用例
1）根据用户需求所要求的产品特性写出黑盒功能测试用例。
2）客户通过使用测试用例以确认是否达到了期望的要求。
3）从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。
4）要使用测试用例来验证需求模型的正确性，如对话框图和原型等。
3. 确定合格的标准
1）确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。
2）将合格的测试建立在使用情景描述或使用实例的基础之上。
4. 需求确认签字
1）在主要的业务清楚以后即可以进行需求确认
2）目的是确定需求基线
3）不要期望所有的需求在签字后不变
八、需求管理
1. 需求基线
1）软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线；
2）建立需求基准版本和需求控制版本文档确定一个需求基准，这是一致性需求在特定时刻的快照；
3）之后的需求变更就遵循变更控制过程；
4）每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
2. 需求变更控制
1）确定需求变更控制过程，确定一个选择、分析和决策需求变更的过程。
2）需求变更控制流程
3. 建立变更控制委员会
1）组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本；
2）变更控制委员会成员可以是甲方与乙方的人员共同组成；
3）定期进行需求变更评审会议；
4）每次评审要有评审报告。
4. 需求变更影响评估
1）进行需求变更影响分析，应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。
2）明确与变更相关的任务并评估完成这些任务需要的工作量。
5. 需求变更时，修改需求跟踪能力矩阵
1）跟踪所有受需求变更影响的工作产品当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。
6. 维护需求变更的历史记录
1）记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。
2）在需求基线的基础上记录变更历史记录；
3）针对每一个需求形成一个单独记录；
通过对于软件需求分析的学习，知道需求分析要承担着很多风险，因此做好计划以及风险控制是非常重要的。
