软件需求工程综述
需求工程的任务与目标
清楚的理解用户要解决的问题，完整准确地获取用户的需求，并用《软件需求规格说明书》规范的形式准确地表达用户的需求。
软件需求的层次与内涵
（1）、软件需求的三个层次
a、业务需求（Business Requirments，BR）:BR描述组织（企业）对项目的高层次目标，从宏观上描述开发系统的必要性、意义和目标，具有以业务为想到、可度量、合理、可行的特点。BR的核心部分是业务建模，对当前企业当前业务流程进行评估，并对新开发系统的业务处理流程进行展望。
b、系统需求（System Requirments,SR）：SR描述软件产品要实现软件服务以及需要满足的约束条件。用户利用这些服务来完成工作任务，满足业务需求。SR是需求分析和建模的产物，由系统分析人员对UR进行分析、提炼、整理，从而生成指导开发的、更准确地软件需求。完整的表达了软件项目的预期特征，为接下来的软件设计和测试提供了依据和基础。
c、用户需求（User Requirements，UR）：UR描述用户对系统的期望和目标，即用户要系统做什么，产生什么业务价值。UR是需求获取的阶段的产物，建立在用户访谈、调查的基础上，对用户的工作场景进行调整，从而建立从用户角度的需求。
UR的特点：
离散性：用户从不同角度、不同层面、不同力度提出需求；
矛盾性：用户处于企业/组织的不同工作岗位，难免局限性和矛盾性。
（2）、软件需求的分类：软件系统需求常常分为功能需求和非功能需求。
a、功能需求：包括对系统应该提供的服务、如何对特殊输入做出反应，以及系统在特定条件下的行为的描述。用于定义软件产品必须提供的功能或者服务，以及相关输入、输出、处理逻辑以及异常处理等。在用户需求文档中，功能需求以一种用户可以理解的抽象模式进行表达；而在系统需求中，则要给出具体细节。
注意：系统的功能需求必须保持清晰、准确、完备和一致，并且能够实现业务需求里确定的所有功能目标。
b、非功能需求：对系统提供的服务或者功能给出的约束，包括时间约束、开发过程约束和所受到的标准约束。常常适用于整个系统软件，而非某一个子系统或模块。
（a）产品需求：产品需求定义软件工作时必须满足的约束条件。其中包括可用性需求、可靠性需求、可移植性需求、性能需求、空间需求。
可用性需求：可用性是对使用软件完成特点目标任务时令用户满意的程度，直接体现为直观、易用、高效、健壮等，从用户角度所看到的产品质量。包括：
人性化因素；
美学特性；
用户接口的一致性；
在线和上下文相关的帮助、智能助手；
用户文档、训练材料；
可靠性需求：产品在一定时间内、在一定条件下无故障地执行指定功能的能力或者功能性。包括：
失效频率和严重性、可恢复性；
可预测性；
精度；
平均失效时间；
可移植性需求：软件从某一环境转移到另一个环境下的难易程度。包括：
兼容硬件、操作系统、数据库等；
编程语言；
国际化；
性能需求：包括：
速度、效率、吞吐量；
响应时间、恢复时间、资源利用率；
空间需求：包括：
内存空间、外存空间；
（b）机构需求：客户/开发者项目相关的政策或者规定引发的需求。包括：
环境需求：
硬件：机型、外设、接口、地点、网络分布等；
软甲：操作系统、数据库、其他系统及接口等。
操作需求：
安装部署、配置、使用、日常管理、维护、权限管理及授权。
开发需求：
项目开发标准、规范、设计约束、开发语言等。
（c）外部需求：包括：
监管需求：政府及行业协会等监管部门制定的规定、规范、标准，决定了项目师傅在行业内被使用。
伦理需求：项目在伦理道德方面的规定，决定了项目师傅能被用户及大众所接受。
立法需求：项目要参照执行的法律法规，确保该项运行符合法律规定。
需求开发的流程、阶段任务与主要的技术
（1）、需求工程过程的螺旋模型
（2）、阶段任务：
a、系统可行性研究（评估系统是否对业务有用）：了解客户的要求及现实环境，从技术经济和社会等因素研究并论证本软件项目的可行性，编写可行性研究报告，指定初步项目开发计划，其中包括技术的可行性、经济的可行性、社会的可行性。
技术的可行性：对待开发项目的功能、性能和限制条件进行分析，确定在现有的资源条件下项目是否能实现，开发风险有多大。
经济可行性：对待开发项目的开发成本和预期收益进行评估，确定该项目是否值得投资开发。
社会可行性：是否违反法律，现有的管理体制、人员素质和操作方式是否可行。
b、需求导出和分析（需求发现）：完整获取必须提供的服务，需要满足的约束条件。其中过程活动包括以下几个方面：
需求发现：对系统涉众进行充分沟通与交流，从而发现出用户需求的过程。其中主要方法包括：用户访谈、用户调查、参与、观察业务流程、联合分析组、情景串联、现有产品和竞争对手文档。
需求分类和组织：将无序的需求收集起来，对其重要组织和整理，将其分成相关的几个组。
需求优先权排序和协商：在有多个项目相关人员参与的地方，需求将不可避免发生冲突，需求优先权排序和协商就是解决这个问题的。
需求描述：记录需求并将它作为螺旋下一循环的输入，产生形式化的或非形式化的需求文档。
c、需求描述：
d、需求有效性验证：尽可能的发现存在的错误，减少后期不必要出现的错误带来的工作。在需求有效性验证的过程中，要对需求文档中定义的需求执行多种类型检查，这些检查包括：
有效性检查；
一致性检查；
完备性检查；
真实性检查；
可检验性检查。
主要方法包括：快速原型：借助可运行的系统原型辅助验证用户需求，借助生动形象的原型验证、发掘需求；需求评审：对需求分析成果进行最后确认，以便进入后续的开发工作。
需求规格说明书的用途和主要内容
（1）、用途：用《需求规格说明书》规范的形式准确地表达用户的需求，表达软件项目的预期特征，为接下来的软件设计和测试提供依据和基础，详细描述待开发系统功能需求及非功能需求的正式文档。
（2）、需求规格说明书的主要内容
需求管理
（1）、定义：组织记录软件需求，控制变更， 确保软件开发与软件需求一致的一系列方法与活动。
（2）、目标：建立需求基线，需求变更受控；软件生产与需求始终保持一致。
（3）需求管理规划：规划阶段需要确定需求管理所需的细节水平，主要包括以下内容：
需求识别：每个需求要有一个唯一的标识以便可以被其他需求交叉索引，同时可以用到可以追溯的评估中。
变更管理过程：这是一组对变更带来影响和成本进行评估的活动。
可追溯策略：定义了需求之间的关系以及需求和系统设计之间的关系，这些关系是要被记录下来的，对此要给出记录的维护方法。
工具支持：需求管理涉及对大量需求信息的加工。
（4）、需求变更管理：需求文档被确认后对系统需求的所有变更提议。主要有三个阶段：
a、问题分析和变更描述：该过程始于一个识别出来的需求问题或者是一份详尽的变更提议。对问题或者提议进行分析以检查它的有效性。分析结果反馈给变更请求者，请求者进而产生一个更加详尽的需求变更提议或者是取消变更请求。
b、变更分析和成本计算：使用可追溯性信息和系统需求的一般知识对被提议的变更所产生的影响进行评估。变更的成本估算包括对需求文档的修改，还可以包括系统设计和实现。一旦分析完成，就有了对此需求变更是否执行的决策意见。
c、变更实现：必要的话，需求文档以及系统设计和实现都要修改。