《软件需求》读书笔记

2020-02-01编写 2025-07-19发布分享

《软件需求》是关于软件需求的经典教材，非计算机专业的我初读此书感觉对需求工程有了系统的了解，而不只是在之前工作中自己感悟到了业务需求分析，就好像第一章关于定义提到的，不同的人会有不同的描述，称其为用户需求、软件需求、业务需求、系统需求等等。这本书从什么是软件需求？为什么要实现软件需求？哪些人应参与软件需求？到需求工程具体划分的需求开发和需求管理两部分，最后再到实践中实现需求工程。

在以后的需求分析岗位的工作中将此书作为指导性参考书，多思考为什么，参考书中方法提出问题，通过阅读搜索尝试解决，或请教公司前辈、领导快速胜任工作掌握更多更全面的知识与技能。

• 软件需求基础知识

1、需求的重要性

l 软件问题主要在于需求：许多软件问题都源于收集、记录、协商和修改产品需求过程中的方式不当。包括信息收集方式不正规，没有明确提出想要的功能，连假设也是未经沟通的错误假设，需求的定义不够充分，以及未经仔细考虑进行需求变更等。

l 需求问题造成很大的麻烦：软件项目中40%～60%的缺陷都是由需求分析阶段的过失所致。

2、软件或系统项目涉众：

客户: 为达到其公司的业务目标而投资项目或购买产品。

用户：直接或间接与产品打交道，是客户的一部分。

需求分析员：负责编写需求并传达给开发团队。

开发人员：设计、实现和维护产品。

测试人员：确定产品的行为是否与预计的相一致。

文档编制人员：负责编写用户手册、培训资料和系统帮助。

项目经理：制定项目计划并带领开发人员获得成功。

法律人员：确保产品符合所有相关法规。

生产人员：制造包含该软件的产品。

市场营销人员：技术支持及其他与产品和客户打交道的人员。

3、需求的定义

常见的几种关于需求的定义说法：

1. 需求是“任何促成设计决策的因素”；
2. 用户为解决某个问题或达到某个目标而需具备的条件或能力。系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。上述第一项或第二项中定义的条件和能力的文档表达。
3. 需求是对应该实现什么功能的说明——可以是对系统运行方式或系统特征与属性的描述；还可能是对系统开发过程的约束。

需求必须被记录成文档。

4、需求的层次

业务需求（表示组织或客户高层次的目标）、

用户需求（用户的目标，或用户要求系统必须能完成的任务）

功能需求（规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求）。

除此之外，每个系统还有各种非功能需求。

5、需求的开发与管理

需求开发的任务可进一步细分为获取、分析、规格说明和确认。 

需求管理的任务是“与客户就软件项目的需求达成并保持一致”

6、需求问题

1. 用户参与不足
2. 用户需求扩展
3. 有歧义的需求
4. 镀金问题
5. 过于抽象的需求
6. 忽略了某类用户
7. 不准确的计划

• 客户眼中的需求

1. 客户

广义地讲，客户泛指直接或间接得益于产品的个人或组织。

软件的客户包括那些提出软件需求，购买、定义、使用软件产品或选择接受软件功能的项目涉众。

低一层的需求——用户需求——则应来自实际使用产品的人。这类用户(通常被称为“最终用户”)构成了另一类型的客户。 

对于信息系统、签约开发或自己开发的项目，业务需求应来自投资项目人，而用户需求则应来自产品的实际使用者。

2、客户与开发人员的合作伙伴关系

要想开发出优秀的软件产品，必须以优质需求为基础精心制定计划。而高质量的需求则源自开发人员和客户之间良好的沟通与合作，即所谓的合作伙伴关系。

书中提到只有当参与各方都了解自己获得成功的条件，并且理解和尊重合作者的成功条件时，合作才能取得成功。不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最有效地进行协作。作为需求开发人员需要自身具备业务能力、需求分析提供备选方案引导客户，始终以合作和专业的态度与客户进行沟通。书中列举的软件客户的权利与义务，也可以理解为需求与开发人员的义务与权利。

表1 软件客户的权利法案

表2 软件客户的义务法案

作为需求人员的自己，当前在**领域相关的客户语言、业务办理流程还不够熟悉。亟待通过学习相关法规文件补充自己的业务知识。

作为项目计划的一部分，客户和所有参与开发的人员都应该仔细阅读这两张表，并达成一致看法。忙碌的客户也许不愿意参与需求工程（这是对第二项责任的逃避）。但是我们知道，缺少用户的参与会使生成不符合需求的产品的风险大为增加。需求开发的每一位参与者都应该了解并承担自己的义务。如有疑惑应该进行协商，使每个人都清楚各自应负的责任。这样能够减少以后因一方不愿意或不能提供对方所需而产生的矛盾。

1. 关于签字

不可能在项目初期就能明确所有的需求，需求肯定要随时间的推移而发生变化。参与者必须对项目初期的签字的准确含义应达成上述一致的理解。

• 需求工程的推荐方法

要运用合适的判断标准常识和经验而不是照本宣科地应用这些推荐方法。注意这些方法并非都己经被认定为行业最佳方法。

表3-1需求工程推荐方法

在**公司参与过的**的项目的需求调研工作中，逐渐地学习当前需求捕获与分析的文档模板其中业务流程、业务审查要点、业务规则、业务范围与权限等等也都是需求调研捕获阶段的方法。

• 需求分析员

即使没有明确指定，软件项目组中也会有某个人会担当需求分析员的角色。

1、需求分析员的职责

需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。需求分析员是用户群体与软件开发团队间进行需求沟通的主要渠道。

1. 需求分析员的工作

需求分析员是客户与开发人员交流的中间人，负责将客户对产品的初步想法转化为明确的需求说明，用来指导开发工作。需求分析员必须先充分理解用户对新系统的目标，然后再定义功能和质量需求。有了功能和质量需求，项目经理才能对项目进行估算，开发人员才能进行设计和开发，测试人员才能对产品进行验证。

1. 定义业务需求
2. 确定项目涉众和用户类别
3. 获取需求
4. 分析需求
5. 编写需求规格说明
6. 为需求建模
7. 主持对需求的验证
8. 引导对需求的优先级划分
9. 管理需求

3、需求分析员必备的技能

1. 倾听的技巧
2. 交谈和提问的技巧
3. 分析能力
4. 协调能力
5. 观察能力
6. 写作能力
7. 组织能力
8. 建模能力
9. 人际交往能力
10. 创造力

4、需求分析员必备的知识：

需求分析员还需具备从实践经验中积累的广博知识。其中最基本的是对当代需求管理技术的深刻理解，以及在各种不同的软件开发生命周期环境中应用这些技术的能力。掌握应用领域的知识、最大限度地减少与客户间的误解。

熟悉业务的需求分析员可以最大限度地减少与客户间的误解。对应用领域有较深了解的需求分析员，常常可以发现未声明的假设和隐含的需求。他们能够为客户找出业务流程的改进方法。这样的需求分析员能够不时地提出用户想不到的有用的功能。

• 确定产品前景与项目范围

1. 通过业务需求定义前景

产品前景将所有涉众统一到一个方向上。前景描述了产品用来干什么，它最终会是什么样子。项目范围则确定当前项目主要是解决产品长远规划中的哪一部分。范围声明为需求是否属于项目划定了界线。

对于当前的新疆省厅的政务办公系统，此前我参与需求调研工作中很重要的一点也就是明确需求范围，避免系统或者业务功能的缺失，也避免不必要的需求的开发。通过需求规格说明书控制范围。

2、前景与范围文档

项目的范围定义了所提出的解决方案的概念和范围。

(1)第一个版本的范围

概述计划在产品的第一个版本中实现的主要特性。

(2)各后续版本的范围

要采用阶段性的开发方式，需要决定推迟实现哪些特性，并为后续的版本做出时间安排。

(3)限制与排除

定义项目包含的需求与不包含的需求之间的界线。

3、关联图

对范围的描述确立了正在开发的系统与周围所有事物之间的界线和联系。

4、保持范围的适度

正常情况下依据前景和范围文档决定需求范围，但有时被提议的新需求不在范围之内，却很有价值，因而需要对项目范围做出调整以容纳这一新的需求。