把握关键点（软件需求管理一）

    最近根据工作需要，梳理软件产品研发管理流程。需求管理首当其冲，先整理一下。

   

    开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。(《No Silver Bullet》 1987 Frederick Brooks)(原文：The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. )

 

    这就是需求，它是产品的根源。

 

    软件需求是有层次的，从对原始问题的描述，到用户需求，到系统需求，到设计描述，需求的采集和分析必须跨越原始问题域和解决方案域的鸿沟。与需求直接相关的活动就是所谓的需求工程；按照活动内容，又可以分为需求开发和需求管理两大类活动。对需求管理活动的管控，是一般软件产品研发管理流程必须要覆盖到的。
 

    需求管理活动在需求提出、需求描述(分析)、需求评审这几个阶段都有展开，但一般意义上我们说的需求管理，基本都是在需求评审阶段进行的，关注点也主要集中在需求评审的一些输入输出物，或者再说的绝对一些，基本上是围绕着需求基线进行。管什么？需求状态、需求跟踪、需求版本、需求变更，如此而已。

 

    构成需求基线有两个很重要的文档不得不提：用户需求分析说明书和软件需求规格说明书（SRS，Software Requirements Specification）。我在百度上查这两个概念，有些博客和观点对这两个文档的作用表述是含混的，甚至混为一谈。所以有必要澄清一下，而且我觉着分清还有些重要。

 

    用户需求分析说明书(也有资料称需求分析说明书、用户需求说明书等)，它最主要的目的是用来与用户进行信息交互和确认的。也就是说，这个文档的表述方式，一切信息与需求都是站在用户的角度上来表述的。用户（不是指软件系统的最终用户，而是指关键的项目干系人）是该文的预期和核心读者。而SRS的核心目的是保证业务需求提出者提出的需求，能够在需求分析人员、（项目）管理人员、设计开发人员、测试人员及其他相关利益人中间对需求达成共识，另外，SRS的还有一个核心功能是要为评价软件质量提供依据。目标决定路线。预期读者的变化，决定了它们的根本不同。如果一定要给这两类文档建立关系，那么可以这样说：用户需求分析说明书是需求调研者与用户沟通的产物，而SRS是系统分析员通过需求分析，逐步细化对软件的要求后，对软件开发提供的一种可转化为数据设计、结构设计和过程设计的数据和功能的表达。

 

    需求评审要做的，就是审查这两类文档中间的那些分析和推演过程是否合理，是否存在缺漏。所以需求评审过程必定会有模型推导。需求评审重要，就在于这一轮审查，是软件产品从期望到落地的第一轮演绎，如果这一轮都破绽百出，那后面就可想而知了。