3.1 需求分析

确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景。

即以一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面的陈述的一个集合。

需求分析的任务

? 建立分析模型【过程第二步】

准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么

内含两种模型：面向对象、面向过程的模型

?编写需求说明【过程第三步】

用《需求规格说明书》规范的形式准确地表达用户的需求。

需求分析/管理的过程

分为需求确认、需求变更。

需求确认又可以细分为：需求获取——需求提炼——需求描述——需求验证。

需求确认

第一步：需求获取

需求的获取

也称为需求抓取、需求发现和需求获得。

? 软件需求的来源

?软件工程师收集这些软件需求的方法。

需求的类型

功能性需求

描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务。

非功能需求

必须遵循的标准，外部界面的细节，实现的约束条件，质量属性等等

需求的来源

1. 用户目标

2. 领域知识

3. 投资者

4. 运行环境

5. 组织环境

需求获取技术

1. 采访

2. 设定情景（用例）

3. 原型

4. 会议

5. 观察商业过程和工作流

需求获取面临困难

为什么软件系统分析员的工资要比普通程序员高？就是因为需求分析困难嘛

1. 客户说不清楚需求
2. 需求自身经常变动【没有一个软件的需求改动少于三次】
3. 分析人员或客户理解有误【客户表达的需求，不同的分析人员可能有不同的理解。——（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上。（2）在合同中一定要说清楚“做什么”和“不做什么”。】

获取需求诱导十原则

1. 倾听
2. 有准备的沟通
3. 需要有人推动
4. 最好当面沟通
5. 记录所有决定
6. 保持通力协作
7. 聚焦并协调话题
8. 采用图形表示
9. 继续前进原则
10. 谈判双赢原则

第二步：需求提炼（需求分析）

?对应用问题及环境的理解和分析，为问题涉及的信息、功能及系统行为建立模型。

?将用户需求精确化、完全化，最终形成下一步的需求规格说明书。

1. 该过程的核心在于建立分析模型。

2. 采用多种形式描述需求，通过建立需求的多种视图，揭示出一些更深的问题。

3. 还包括与客户的交流以澄清某些易混淆的问题，并明确哪些需求更为重要，其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。

需求分析模型

第三步：需求规格说明书

软件需求规格说明书（SRS）------软件系统的需求规格说明，是对待开发系统的行为的完整描述。

它包含了功能性需求和非功能性需求的说明。

需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。

需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。

一、沟通活动通用任务集

1、识别主要客户和共同利益者

2、与主要客户会谈“上下文无关的问题”，以确定

? ①业务需要和商业价值

? ②最终用户的特性\需要

? ③需要的用户可见输出

? ④业务约束

3、写一页项目范围的说明

4、评审范围说明，并应客户要求做出相应修改

5、与客户/最终用户进行协作，确定：

? ①采用标准格式记录客户可见的使用场景

? ②输入和输出

? ③重要的软件特性、功能和行为

? ④客户定义的商业风险

6、描述场景、输入/输出、特性/功能以及风险

7、与客户细化场景、输入/输出、特性/功能以及风险

8、为每个用户场景、特性、功能和行为分配客户定义的优先级

9、回顾搜集的所有信息并修订

10、为计划活动做准备

二、软件需求规格说明的原则

1. 从现实中分离功能，即描述要“做什么”而不是“怎样实现”

2. 要求使用面向处理的规格说明语言（或称系统定义语言）

3. 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中

4. 规格说明必须包括系统运行环境

5. 规格说明必须是一个认识模型

6. 规格说明必须是可操作的

7. 规格说明必须容许不完备性并允许扩充

8. 规格说明必须局部化和松散耦合

三、软件需求规格说明的结构

（1）引言

? a. 需求文档的目的

? b. 文档约定

? c. 预期的读者和阅读建议

? d. 产品范围

? e. 参考文献

（2）综合描述

? a. 产品前景

? b. 产品功能与优先级

? c. 用户特征

? d. 运行环境

? e. 设计与实现上的限制

? f. 假设和依赖性

（3）需求描述

? a. 功能需求

? b. 数据需求：与功能有关的数据定义和数据关系

? c. 性能需求：响应时间、容量要求、用户数等

? d. 外部接口：用户界面、软硬件接口、通信接口

? e. 设计约束：软件支持环境、报表、数据命名等

? f. 软件质量属性（可维护性、可靠性、可移植性、可用性、安全性等）**

? g. 其他需求

? 这一节需求描述是文档中最实质性的部分，由于在机构组织的实践中存在极大的变数，对这一节定义的标准结构可以进行增删。

（4）附录（词汇表、分析模型、待定问题列表）

（5）索引

第四步：需求验证

? 需求验证的重要性：如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工。

需求验证的工作

对需求文档需执行以下类型的检查：

? （1）有效性检查

? 检查不同用户使用不同功能的有效性。

? （2）一致性检查

? 在文档中，需求之间不应该冲突。

? （3）完备性检查

? 需求文档应该包括所有用户想要的功能和约束。

? （4）现实性检查

? 检查保证能利用现有技术实现需求。

需求验证技术

（1）需求评审

（2）利用原型检验系统是否符合用户的真正需要

（3）对每个需求编写概念性的测试用例。

（4）编写用户手册。用浅显易懂的语言描述用户可见的功能。

（5）自动的一致性分析。可用CASE工具检验需求模型的一致性。

需求变更