作业要求：总结尽可能多的需求工程的方法和技术，要求归纳总结各种方法的适用场景、优缺点等。说明：其中需求工程包括需求获取、需求分析、规格说明、验证、管理等。只要是用于需求工程相关的技术和方法都可以算。
软件需求工程划分为需求开发和需求管理，需求开发阶段又可进一步划分为需求获取、需求分析、规格说明和需求验证。本人将总结每一阶段中可以用到的方法和技术，包括适用场景、优缺点。
一、需求获取
1.用户访谈
- 适用场景：分析人员以个别访谈或小组会议的形式与用户进行初步的沟通，适合于开发方不清楚项目需求（一般开发方是刚开始做这种业务类型的工程项目）但用户方清楚项目需求的情况。
- 优点：直接有效、形式灵活、交流深入。
- 缺点：①占用时间长：通常要访谈的人比较多，语言交流会占用大量时间。②信息存在片面性：用户代表经常各执一词，导致收集的信息无法代表所有用户的想法，从而导致偏差的出现。
2.用户调查
- 适用场景：适合于开发方和用户方都清楚项目需求的情况。
- 优点：调查面比较宽，用户反馈多。这恰好能够成为用户访谈的有效补充，能够克服用户访谈的片面性。
- 缺点：缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。
3.文档分析
- 适用场景：对于一些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法。
- 优点：能够详细、直观地对数据流细节进行了解和分析。
- 缺点：企业机构中，文档量通常非常大，由此容易使需求获取人员陷入文山书海中不能自拔，甚至引起误导。
4.原型法
原型法主要分为界面原型法和可运行系统原型法。
- 适用场景：界面原型法适合于开发方和用户方都不清楚项目需求的情况。可运行系统原型法适合于开发方比较清楚项目需求但用户方不清楚项目需求的情况。同时，对于这种类型的项目，开发方一般都有类似项目的建设经验，因此可以在以往项目的基础上，快速“构建”出一个可运行系统。
- 优点：①使用户更好地理解需求工程师的假设；②使需求工程师通过观察用户的反馈来加深对用户的理解，并明确自己的一些假设为什么不准确。
- 缺点：在构建原型的过程中会花费一定的人力和经济成本，而且还可能浪费开发时间。
二、需求分析
1. 原型化方法：根据用户提出的需求，由用户与开发者共同确定系统的基本要求和主要功能，并在较短时间内简历一个实验性的，简单的小型系统。
- 适用场景：适用于小型系统的开发。
- 优点：符合人们认识事物的规律，开发周期短，费用相对少，应变能力强。
- 缺点：不适用大型系统，开发难以控制，系统难以维护。
2. 建模方法
3. 5W2H模型法
三、规格说明
四、需求验证
1.验证软件需求的方法
- 验证一致性：自然语言描述需求、形式化语言描述需求、使用软件工具验证
- 验证现实性：参照开发经验
- 验证完整性和有效性：建立软件原型
2.验证需求正确性的四个方面
- 一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾
- 完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能
- 现实性：指定的需求应该能用现有的硬件和软件技术可以实现
- 有效性：必须证明需求是正确有效的，确实能解决用户面对的问题
五、需求管理
需求管理流程主要包括6大部分：制订需求管理计划、求得对需求的理解、求得对需求的承诺、管理需求变更、维护对需求的双向跟踪性、识别项目工作与需求之间的不一致性。
用CMMI指导需求管理。
