《第3章需求分析概述》
n本节主要学习以下内容：
² 了解需求分析的根本任务；
² 掌握需求分析的技术；
² 掌握需求分析的方法；
² 分析需求的可行性；
² 需求建模的过程和重要性；
² 建立数据字典的作用和方法。
本节重点
需求分析的方法，需求建模的方法。
本节难点
需求建模和数据字典的应用。
授课课时
2课时
教法建议
首先介绍需求的根本任务，然后展开关于需求分析的方法和过程。
回顾上节课的主要内容。
本节主要掌握需求分析的任务、方法、建模的过程、数据字典的生命等内容。
内容：
软件需求分析的基本任务就是分析和综合己收集到的需求信息。其中分析的工作就在于透过现象看本质，找出这些需求信息间的内在联系和可能的矛盾。综合的工作就是去掉那些非本质的信息，找出解决矛盾的方法并建立系统的逻辑模型。
某企业的业务关联图：
[详细讲解，并举例说明]
内容：
在实际需求分析中应考虑的风险类型：
1. 性能风险
2. 安全风险
3. 过程风险
4. 实现技术风险
5. 数据库风险
6. 日程风险
7. 外部接口风险
8. 稳定风险
通常使用定性的方法如分类为“高”、“中”、“低”来评估风险，而且所需要的时间可与需求的数目成正比。
[详细讲解，并举例说明]
内容：
任务：对于软件开发人员或用户不能明确化的需求，通过建立相应的用户接口原型然后评估该原型，使得项目相关人员能更好理解所要解决的问题。
用户接口原型：一个可能的局部实现，而不是整个系统。
目的：可使许多概念和可能发生的事更为直观明了。
构建用户接口原型的方法：
纸上原型化方法；
人工模拟原型化方法；
自动原型化方法。
[详细讲解，并举例说明]
内容：
好处：
帮助项目相关人员判断系统的核心需求，并有助于项目相关人员集中于重点问题的交流和协商；
需求优先级之间的关联可以帮助软件开发人员决定软件体系结构，还可以帮助解决可能发生的设计冲突；
根据需求的优先级权衡合理的项目范围和进度安排、预算、人力资源以及质量目标的要求。
| 命 名 | 含 义 | 方法来源 |
| 高 | 一个关键任务的需求或下一版本所需要的。 | Karl E. W. |
| 中 | 支持必要的系统操作或最终所要求的，但如果有必要的话，可以延迟到下一个版本。 | |
| 低 | 功能或质量上的增强；如果资源允许的话，实现这些需求总有一天使产品更完美。 | |
| 基本的 | 只有在这些需求上达一致意见，软件才会被接受。 | IEEE 1998 |
| 条件的 | 实现这些需求将增强产品的性能，但如果忽略这些需求，产品也是可以被接受的。 | |
| 可选的 | 对一个功能类有影响，实现或不实现均可。 | |
| 3 | 必须完美地实现。 | Kovize 1999 |
| 2 | 需要付出努，但不必做得太完美。 | |
| 1 | 可以包含缺陷 |
[详细讲解]
内容：
任务：导出目标系统的逻辑模型（或需求模型），以明确目标系统“做什么”的问题。
需求建模：需求建模就是把由文本表示的需求和由图形或数字符号表示的需求结合起来，绘制出对目标系统的完整性描述，以检测软件需求的一致性、完整性和错误等。
目的：增强对用自然语言描述的需求规格说明的理解，而不是要替换它。
几种早期的需求模型：PSA/PSL、SREM和SADT。
目前常用的需求分析方法：SA方法和面向对象的分析方法
[详细讲解]
内容：
数据词典：定义目标系统中使用的所有数据元素和结构的含义、类型、数量值、格式和度量单位、精度及允许取值范围的共享数据仓库。
作用：确保软件开发人员使用统一的数据定义，以及可提高需求分析，设计、实现和维护过程中的可跟踪性。
[详细讲解]
本节学习了以下主要内容：
2. 掌握需求分析的技术；
3. 掌握需求分析的方法；
4. 分析需求的可行性；
5. 需求建模的过程和重要性；
6. 建立数据字典的作用和方法。
考核点1：需求分析的任务
考核点2：需求分析的方法
思考：需求分析的任务。
（注：在此写上个人在授课过程中所遇到的教案中所没有涉及到的特殊问题及其解决方法或解决方案，也可以总结自己的授课体会，课程体系、教材的不足等。）
授课教师（签名）： 授课时间： 授课班级：
