软件需求工程--需求分析
需求特性
无二义性，完整性，一致性，可测试性， 确定性，可跟踪性，正确性，必要性。
需求分析的7个方面
绘制系统上下文范围关系图--系统与系统外部实体之间的界限和接口的简单模型
创建用户界面原型--关键界面接口示意图
分析需求的可行性--成本，性能，技术可行性。 发现需求之间的冲突和依赖
确定需求的优先级
为需求建立分析模型--一图抵千字， OOA的用例模型， 领域模型。 SA的DFD和ER
创建数据字典--所有数据项和结构定义
QFD
需求分析方法
PDOA方法（Problem Domain Oriented Analysis: 面向问题域分析方法）
与SA和OOA相比， PDOA更多的强调描述， 少强调建模
PDOA的两个部分
(1)关注问题域：对问题域进行相关的描述， 列出需要再该域中求解的问题列表（需求列表）
(2)关注系统实现的待求行为：对系统待求行为进行描述
PDOA过程
(1) 收集基本信息并开发问题框架， 以建立问题域的类型
(2) 在问题框架类型的指导下， 进一步收集详细信息， 并给出一个问题域相关的特性的描述
(3) 给予以上两点，收集并用文档说明系统的需求
SA方法（Structured Analysis 面向结构的分析方法）
关注功能的分层和分解， 符合自上而下，逐步分解问题， SA方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型
1. 数据模型 E-R图
2. 功能模型 DFD图
3. 行为模型（状态模型） STD图
OOA方法（Object-Oriented Analysis：面向对象分析方法）
基于抽象，信息隐藏，功能独立和模块化的基本理念对系统进行分析。
OOA，对象彼此之间通过接口来互相沟通，只有观测内部才能看到具体的属性和方法。
需求验证：
SRS正确的描述了预期的，满足项目干系人需求的系统行为和特征
SRS中的软件需求是从系统需求，业务规格和其他来源中正确推导而来
需求是完整的和高质量的
需求的表示在所有地方都是一致的
需求为继续进行系统设计，实现和测试提供了足够的基础
需求评审：
评审方式： 评审， 检查，走查
如何做好评审推荐方法如下
分层评审
正式评审和非正式评审相结合
分阶段评审
精心挑选评审人员
对评审人员进行培训
充分利用需求评审检查单
建立标准的评审流程
做好评审后的跟踪工作
充分准备评审
需求测试：
很多项目中， 软件测试都是后期的开发活动， 实际上，软件测试在需求定会就应该开始。
如果在项目早期就定制测试计划进行测试用例设计，就可以发送错误时立即检测并纠正他。
需求遗漏和错误具有很强的隐蔽性， 仅仅通过阅读SRS，很难想象特定环境下的系统行为。
概念测试用例：
需求开发不可能有真正意义的测试进行， 因为没有可执行的系统， 需求测试仅仅是给予需求进行概念上的测试
以需求为基础（SA需求分析模型）或用例为基础（OOA需求分析模型）来书写测试用例， 可以是项目干系人更清楚
的了解系统的行为，虽然没有执行测试用例，但是设计测试用例的简单动作可以解释需求的很多问题。
需求测试的过程：
1. 根据概念测试用例所描述的若干可能过程， 进行“概念”上的执行，期望发现遗漏的，错误的， 不必要的需求
2. 根据测试结果快速的修改对应的需求文档，完成一轮完整的需求测试过程。
需求获取，需求分析，需求定义，需求验证 4个阶段，不应该是瀑布式的发展，应该采用迭代式的演化过程。
需求管理
需求管理是可重复级的一个关键过程域， 其目标是为软件需求建立一个极限， 供软件开发及其管理使用，
使得软件计划，产品，活动与软件需求保持一致。其中有如下几个活动
1. 需求变更管理
2. 需求风险管理
3. 需求跟踪--设计跟踪矩阵， 各种测试用例跟踪矩阵，缺陷跟踪矩阵。