一、什么是软件需求
可从三方面对软件需求进行定义：
业务知识：包括业务事件、业务实体和业务规则。
问题列表：用户在工作中遇到的困难与障碍，这也是软件开发时需要解决的问题。
其他因素：包括了一些设计约束和非功能方面需求。
需求的三个层次
包括业务需求、用户需求和功能需求。
反映到需求文档中，可用下图表示：业务需求一般在项目视图/范围文档中体现，用户需求通过用例文档以用户的视角呈现，软件需求需要写到软件需求规格说明书（SRS）中。
需求的三种类型
需求按类型划分可分为功能需求、非功能需求以及设计约束。
优秀需求的标准
优秀的需求要符合以下几个标准：
①完整性：验证需求规格说明书中罗列的主题域、业务事件、业务活动、业务步骤等是否完整；同时，需求是有层次的，高层管理人员、中层管理人员、操作人员，在验证需求完整性时需要采用分层评审。
②不失真：求在信息传递的过程中不失真，即正确和无歧义。
③有优先级：“事有轻重缓急”，想要更好地对项目进行管理，就需要有效地区分出优先级。
④有技术早期介入：解决方案既要具备可行性，又要具备可验证性。
而一旦需求不完整、失真，会使软件项目付出很大的成本代价，甚至失败风险。
上张图是说，如果在需求阶段只需花费1个单位时间就能改正的错误，拖到设计阶段来改正就需要5倍的时间，到了编码阶段将是10倍，测试阶段可能达到20~50倍，而到了运行与维护阶段或许会达到200倍之多。足见需求分析人员对一个软件项目的重要性。
二、软件需求工程
需求工程的范畴
软件需求工程包括需求开发和需求管理两个过程域。需求开发是收集、分析、整理、编写、验证需求的全过程，重点在于开发出高质量的需求规格说明。需求管理是对需求的实现、变化进行追踪的全过程，重点在于确保开发的软件满足这些需求。
需求开发工作要点
通过需求获取、需求分析、编写规约和需求验证4个具体活动多次循环的形式进行需求开发。
一般经过三次循环，可形成一份合格的需求产物。
需求获取也称为需求捕获，它们都是主动动词。而现实的需求实践中最大的问题恰好是比较被动的。存在捕获范围不足、缺乏计划性、缺乏科学性、捕获对象不明确、捕获手段不足等问题。
需求分析是需求开发中的核心任务，但在实践中却经常被“忽略”，也就是直接将需求捕获得到的信息整理到需求规格说明书中。
①需求分析首先是业务分析，是对问题域进行研究，要从从业务线索入手，而非系统结构。
②需求分析是一种分解活动，将待开发的系统按职责划分成不同的主题域(可以将其理解成子系统，在划分时是按业务视角进行），然后分解成组成该主题域的所有业务流程，再分解到业务活动（用例）、业务步骤。
③需求分析是一种提炼与整合活动：将用户的原始需求合并到业务活动中去，将各个业务流程合并成全局业务流程图，将每个业务事件相关的领域类图片段合并成全局领域类图，将各个业务事件的用例图片断合并成全局的用例模型等。
④需求分析是一种规格化活动：要找到冲突、矛盾，并且通过访谈等手段解决这个问题。
注意区分内容与形式，需求分析是任务，建模是手段。建模的过程就是分析的过程，核心思想是用“图形”代替“文本”，以更加可视化的方法表述信息。建模产生的结果并不一定非得是规范性很高的模型，重在分析、交流，重在解决问题。
需求分析和需求捕获交替进行，获取了部分信息之后，就可以对其进行分析，并将分析的结果填写到已经规划好章节的需求规格说明书中。通过分析会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次需求调研的计划、问题、素材。
注：按照现代软件工程思想，通常会采用迭代、增量的开发过程，需求分析工作贯穿整个软件生命周期。
编写规约是将需求分析结果文档化的过程。软件需求规格说明书总结了四字要诀：共享、更新，而每个要诀都包括两层含义。
需求验证，对于需求验证工作，大多数组织都不够重视，有时只是找一个客户代表签字确认，甚至直到交付系统时通过测试系统来验证。这样当系统交付时，可能会出现大量需求变更。
需求验证的关键手段是评审，且要分层次、分内容进行验证，以期在早期阶段尽可能多地暴露出问题。
需求管理工作要点
需求管理工作包括基线管理、变更管理和需求跟踪三个活动。而要想真正使需求管理活动获得实效，可以将整个管理改进分成4步：
①统一明确的需求项划分标准；
②引入基线管理；
③引入变更管理；
④引入需求跟踪。
需求分析人员的技能组成
需求分析人员是需求收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道。他们需要完成的活动包括：定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求等。
因此必须掌握的技能包括倾听、交谈和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力。而这些能力可以概括为业务知识、技术知识和沟通能力三个方面。
SERU软件需求过程框架全景图
对于遗留系统项目，SERU模型也适用。在S层，考虑项目是一个新主题域，还是对某些主题域产生影响；在E层，考虑项目新添或修改了哪些业务事件。
相关阅读：
wend huo：1.软件需求最佳实践笔记 | 需求框架
wend huo：2.软件需求最佳实践笔记 | 需求实践现状
wend huo：3.软件需求最佳实践笔记 | 需求视图
wend huo：5.软件需求最佳实践笔记 | 需求定义
wend huo：6.软件需求最佳实践笔记 | 需求捕获
wend huo：7.软件需求最佳实践笔记 | 需求分析与建模（一）
wend huo：8.软件需求最佳实践笔记 | 需求分析与建模（二）
wend huo：9.软件需求最佳实践笔记 | 需求分析与建模（三）
wend huo：10.软件需求最佳实践笔记 | 需求描述
wend huo：11.软件需求最佳实践笔记 | 需求验证
wend huo：12.软件需求最佳实践笔记 | 需求基线
wend huo：13.软件需求最佳实践笔记 | 需求变更
wend huo：14.软件需求最佳实践笔记 | 需求跟踪
wend huo：15.软件需求最佳实践笔记 | 总结
