需求工程
1.需求获取
1.1系统分析人员与用户交流
1.2对现有系统的观察
1.3对任务进行分析确定系统或产品范围的限制性描述
1.4与系统或产品有关的人员及特征列表
1.5系统的技术环境描述
1.6系统功能的列表及应用于每个需求的领域限制
1.7一组描述不同运行条件下系统或产品使用状况的应用场景
1.8为更好的定义需求而开发的原型
1.9我认为需求获取应记录下来（包括系统分析人员与用户的交流，以及对现有产品进行分析时的分析产物等）
2.分析与协商
2.1对需求进行分类组织
2.2分析每个需求与其他需求的关系，以检查需求的一致性、重叠和遗漏的情况
2.3根据用户的需要对需求进行排序
2.4用户提出的超出实现范围能力的需求和不同用户提出的相互冲突的需求，需要一个谈判过程来调解冲突
3.系统建模
3.1通过合适的工具和符号系统的描述需求
3.2建模工具的使用在用户和系统分析人员之间建立了同一的语言和理解的桥梁
3.3系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档反应用户的真是意图
3.4常用的分析建模方法：面向数据流方法、面向数据结构方法和面向对象方法
3.5画用例图，使用系统建模对需求进行理解，画图不是目的。
4.需求规约
4.1是需求分析任务的最终产物。
4.2主要内容
4.2.1引言
4.2.2信息描述
4.2.3功能描述
4.2.4行为描述
4.2.5检验标准
4.2.6参考书目
4.2.7附录
5.需求验证
5.1检验需求功能的正确性、完整性、清晰性，是否能够反映用户的意愿。
5.2由于需求的变化往往使系统的设计和实现也跟着改变，所以由需求问题引起的系统变更比修改设计或代码错误的成本高得多。
5.3评审应指定专门的人员负责，并按规程严格执行。
5.4检查的内容
5.4.1系统定义的目标是否与用户的要求一致
5.4.2系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确的反应了用户要求、
5.4.3被开发项目的数据流与数据结构是否确定且充足。
5.4.4主要功能是否已包括在规定的软件范围之内，是否都已充分说明。
5.4.5设计的约束条件或限制条件是否符合实际
5.4.5开发的风险是什么。
5.4.6是否详细地制定了检验标准，他们能否对系统定义进行确认。
5.5用户需要描述出系统的操作过程，构想出如何让系统加入到他们的工作中去，这种抽象对于一个普通用户来说比较困难。所以，需求验证不可能发现所有的需求问题，在需求验证之后，对遗漏的补充以及对错误理解的更正是不可避免的，因此需要进行需求管理。
6.需求管理
6.1每个需求—唯一标识符
6.2建立需求跟踪表
6.2.1特征跟踪表：需求是如何在系统中体现出来，记录了需求如何与产品或系统特征相关联
6.2.2来源跟踪表：记录每个需求的来源
6.2.3依赖跟踪表：需求间的关联
6.3正向跟踪：检查需求规约中的每个需求是否都能在后继工作产品中找到对应点。
6.4逆向跟踪：检查设计文档，代码，测试用例等工作产品是否都能在需求规约中找到出处。
