软考系统分析师-软件需求工程

1. 什么是需求

需求开发是主线，是目标；需求管理是支持，是保障；

软件需求是指系统必须完成的事或必须具备的品质。

2. 需求层次：业务需求/用户需求/系统需求，层次从目标到具体，整体到局部，概念到细节

业务需求：对系统高层次的目标要求，来自甲方高级管理人员（确定项目视图和范围）；

用户需求：用户的具体需求，能用这个系统做什么工作，可采用调查问卷完成收集；

系统需求：功能性需求/非功能性需求/系统设计约束等

3. 质量功能部署（QFD）

将用户要求求转化为软件需求的技术，提升用户满意度；

常规需求：用户认为需要做到的功能或性能，完成越多，满意度越高；

期望需求：用户想当然的认为需要完成的功能，但不能准确描述，若不能实现，会让用户感到不满意

意外需求：要求范围外（但是开发人员非常乐意赋予的功能或性能需求）,不实现也不影响购买需求；

4. 需求获取

用户访谈：最基本的获取手段，有良好的灵活性和较广的范围，记录/沟通 需要分析师具备良好的领域技能，且时间有限；

问卷调：获得大量的数据，方便记录；

采样：选着一部分样例进行观察；

情节串联版：通过故事的方式串联情节，获得需求；

联合需求计划：JRP 成本较高，召开会议讨论；

5. 需求分析：提炼/分析/仔细审查已获取的需求；需求分析工作包含一下方面

5.1 绘制系统上下文范围关系图【为需求确定范围】

5.2 创建用户界面原型

5.3 分析需求的可行性

5.4 确定优先级

5.5 需求建模

5.6 使用数据字典

5.7 使用QFD

6. 需求分析的方法

6.1 SA方法关注功能的分层和分解，自上而下，对现实的问题进行不断的测试和分解，最终得到问题域的逻辑模型；

6.2 OOA（面向对象）方法，基于抽象，信息隐藏，功能独立和模块化，彼此之间通过接口沟通；

总结： SA 假定系统分析师能理解问题域的全部，并能够正确识别和分解问题；OOA既不假定分析师能理解全部，也不假定分析师能识别和分解问题，它只承诺一种持续“观测并理解”的方法，并且“观测后建立”的表象与现实生活的表象是一致的；

6.3 SA采用功能分解的方式描述系统需求，很难从功能到全局的考量

6.4 在OOA方法中构建用例模型有四个阶段：识别参与者/合并需求获得用例/细化用例描述/调整用例模型，前三个是必须的

7. 需求的定义/验证/评审

需求定义分为：严格定义方法/原型方法

8. 需求管理

需求基线：需求开发的结果应该有项目视图和范围文档，用例文档及SRS及相关分析模型，经过评审，这些文档就是定义了开发的需求基线；

基线分为：功能基线/指派基线/产品基线 （经过评审后的SRS属于指派基线）

需求变更：规范的处理变更，不是一味地拒绝；

需求跟踪：