一.需求工程概述
软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
软件需求是指用户对系统在行为、功能、性能、设计约束等方面的期望。
需求工程包括两个维度：需求开发维度(技术维度)和需求管理维度(管理维度)。
需求定义的产出是：需求规格说明书SRS。
对需求规格说明书SRS进行需要验证得到需求基线，需求管理的对象就是需求基线。
在需求管理中，要求维持对用户原始需求和所有产品构件需求的双向跟踪；变更控制委员会对项目中任何基线工作产品的变更都可以做出决定。
在需求工程之前可能还需要做可行性分析报告。
主要包括：
对系统开发的各种候选方案进行成本/效益分析；
评价该项目实施后可能取得的无形收益；
评估现有技术能力和信息技术是否足以支持系统目标的实现。
二.需求开发
包括：
需求获取
需求分析
需求定义（输出需求规格说明书）
需求验证
1.需求获取：
用户访谈：用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。
采样：是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。
联合需求计划：为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。
2.需求分析：
需求分析是一种软件工程活动，它在系统级软件分配和软件设计间起到桥梁的作用，需求分析使得系统工程师能够刻画出软件的功能和性能，指明软件和其他系统元素的接口，并建立软件必须满足的约束。
需求分析允许系统分析师细化软件的分解，并建立将被软件处理的数据、功能和行为模型。最后，需求规约为开发者和客户提供了软件开发完成后质量评估的依据。
需求分析为软件设计师提供了可被翻译成数据、架构、界面和过程设计的模型，
需求分析的任务是发现、求精、建模和规约的过程，包括详细地细化由系统工程师建立并在软件项目计划中明确的软件范围，创建所需数据、信息和控制流及操作行为的模型，此外，还要分析可选择的解决方案，
并将它们分配到各软件元素中去。
需要注意的是，在需求分析阶段要得到详细的规约是不可能的。客户可能并不能精确地肯定需要什么，开发者可能不能肯定可用什么特定的方法来适当地完成功能和性能。
对收集到的需求进行细致的分析，理解其业务背景和具体要求，确保需求的完整性和正确性。
需求分析允许系统分析师细化软件的分解，并建立将被软件处理的数据、功能和行为模型。
（1）结构化需求分析SA
SA要求完成功能模型(数据流图DFD，也叫分层数据流图)、行为模型(状态转换图STD)、数据模型(ER图：从数据的角度对现实世界进行建模)，其中数据字典起到解释的作用，比如学生关系包含学号、名字、年龄等。
在数据库设计的需求分析阶段也产生数据流图和数据字典，以及需求说明书。
数据流图DFD是SA方法中的重要工具，是表达系统内部数据的流动并通过数据流描述系统功能的一种方法。
通常使用数据字典作为该工具的补充说明。
a.DFD是理解和表达用户需求的工具，是需求分析的手段。由于DFD简明易懂，不需要任何计算机专业知识就可以理解它，因此，系统分析师可以通过DFD与用户进行交流。
b.DFD概括地描述了系统的内部逻辑过程，是需求分析结果的表达工具，也是系统设计的重要参考资料，是系统设计的起点。
c.DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
（2）需求分析之面向对象 OOA
a.类封装组成
在系统设计过程中，类可以分为三种类型，分别是实体类、边界类和控制类。
b.构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。
c.使用UML建模
3.需求定义
把需求分析的成果落地成文档的过程就是需求定义的过程。
需求定义的产物的是：需求规格说明书SRS。
需求定义包含2大类：
严格定义法：过于理想化，同形式化开发方法类似。
原型法：同原型开发模型类似。
4.需求验证
对需求规格说明书SRS进行验证，需求甲方参与确认。最为最终的需求基线。
三.需求管理
需求管理是一个对系统需求变更、了解和控制的过程。需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动了需求管理计划，一旦形成了需求文档的初稿，需求管理活动就开始了。
关于需求管理过程域内的原则和策，可以参考：
①需求管理的关键过程领域不涉及收集和分析项目需求，而是假定己收集了软件需求，或者已由更高一级的系统给定了需求。
②开发人员在向客户以及有关部门承诺某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等。
③关键处理领域同样建议通过版本控制和变更控制来管理需求文档。
包括：
变更控制
版本控制
需求跟踪
需求状态管理
1.需求变更控制
需求变更是每个项目中客观存在的。无法杜绝的。我们要做的是管理和控制好需求的变更。
这样的管理软件应当具有：
a.记录每一个状态变更的日期及变更者的功能；
b.可以定义变更请求的数据项以及变更请求生存期的状态转换图；
c.可以加强状态转换图使经授权的用户仅能做出所允许的状态变更。
2.需求版本控制
7.需求跟踪
需求工程的目标是获取用户最真实的需求，可往往在开发测试过程中会出现遗漏，这时候需要及时跟踪需求，以发现纰漏。
用户的需求称为原始需求，软件需求可以认为是用例(功能)，UC-n没有打钩，表示这个功能多余了，用户其实不需要这个功能；FR-m没有打钩，表示这个功能漏做了。
需求跟踪是将单个需求和其他系统元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统架构和构件、源代码、测试用例，以及帮助文件等。
3.需求状态管理
又称为需求管理，一个需求确认以后，往往会有多个状态的变迁。
四.需求分类
简单地说，软件需求就是系统必须完成的事以及必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。
包括：
业务需求(整体全局)
用户需求(用户视角)
系统需求(计算机化)
基本需求(明示，常规需求)
期望需求(隐含)
兴奋需求(多余)
（1）业务需求。业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围。
（2）用户需求。用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求
（3）系统需求。系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。