《需求工程——软件建模与分析》读书笔记

《需求工程——软件建模与分析》，整体来说这本书内容还是挺多的。我先从目录看起，看看这本书的知识框架是怎样的，整个需求分析会涉及到哪些知识。

该书共分为5个部分：绪论，需求获取，需求分析，需求的格式化与验证，需求的管理及工程管理。

下面将会简述每一部分部分里面的章节并结合自己的项目和Excel截取的记录做出一些思考，算是我对这本书的心得吧。

第一章：需求工程导论

主要讲解了需求问题的具体原因分析，需求工程（requirement engineering）的简介，重要性和复杂性，然后引出需求工程师这一职业。**有些问题广为人知，有些问题小而简单，这些问题掩盖了需求工程的重要性，常常被学生忽略。**在阿拉丁问答系统中，无论是问题，回答还是评论，都是我们日常上网能接触的，广为人知的问题。但我们并不能因此轻视。需求分析也是很复杂的：处理范围广泛，涉及诸多参与方，处理内容多样，处理活动互相交织，处理结果要求苛刻。因此需求工程师的存在就显得十分有必要，他负责衔接现实世界和计算机世界，是涉众和开发者之间的桥梁。

第二章：需求基础

给出了需求的定义，满足需求就是解决问题，从问题域（problem domain）和解系统两个方面解决问题，问题域通俗点来说就是对用户简单模糊的一句话进行准确细致的分析，转化成清晰详细的需求。需求和问题都有层次性，可以分成业务需求，用户需求，系统级需求。通俗的说：**业务需求就是对系统业务的期望，用户需求运用问题域知识，系统级需求是对系统功能提出的要求，包含更多技术实现。**具体例子参照P28. 需求开发必须遵从层次性：业务需求-》用户需求-》系统级需求。

需求分类还分为功能需求和性能需求。性能需求包括：**速度，容量，吞吐量，负载，实时性。**质量属性需求也是很重要的一环。常见的有可靠性（在规定时间间隔和条件下执行目标功能的能力），可用性（使用时可操作可访问的程度），安全性（权限相关），可维护性（排除故障的容易程度），可移植性（从一个环境移植到另一个环境的特性），易用性（用户使用该软件的效率），具体例子参照P40。就阿拉丁问答系统来说，之前对可靠性，可维护性，可移植性没有进行过多的分析。

在需求分析时还需要注意约束，常见的约束有系统开发与运行的环境，问题域内相关标准（法律法规，企业规章等），商业规则（用户执行任务中的一些潜在规则），社会性因素（文化，信仰等）。规则描述参照P43.

如何判断自己的需求是否是优秀需求？从完备性，正确性，可行性，必要性，无歧义这5个方面进行参考。具体参照P45-48.

第三章：需求工程过程

具体的需求工程过程参照P54。

**需求获取：**收集背景资料（和用户交流）；获取问题与目标，定义项目前景与范围；识别涉众，选择信息来源；选择获取方法，执行获取，获取功能与非功能的需求；记录获取结果；

**需求分析：**背景分析，问题分析，目标分析，业务分析，确定系统边界；软件需求建模；细化需求；确定优先级；需求协商；

**需求规格说明：**定制文档模板；编写文档；

**需求验证：**执行验证；问题修正；

**需求管理：**建立和维护需求基线集；建立需求跟踪信息；进行变更控制；

**以上过程都是迭代和并发的。**具体过程模型参照P61.

第四章：需求获取概述

**需求获取（Requirement Acquirement）**就是进行需求收集的活动。

**常见困难：**用户和开发人员知识理解的困难（隔行如隔山），默认知识现象（表达者惯性忽略自认简单的知识），用户存在认知困境（用户无法明确表达自己的需求），用户越俎代庖（超出自己业务范围细说我们管的事），缺乏用户参与（用户太多，选择困难；用户认识不足，不愿参与；用户情绪抵制，消极参与；没有明确用户）

**需求获取活动：**具体流程参照P79的图。下面对一些名词进行解释：

涉众：所有和该软件系统有关的人。对于阿拉丁问答系统，可分为用户（网络用户，大V，项目管理员等），客户（为软件付费的人），开发者（各种工程师）

硬数据采样：通过调查问卷等形式获取样本数据，了解用户的普遍需求

**获取信息的内容：**需求，问题域描述，环境与约束

**获取信息的来源：**涉众，硬数据，相关产品，重要文档（系统规格说明，客户需求文档），相关法律法规和行业规范

**获取信息的方法：**传统方法（调查问卷等），集体获取方法（头脑风暴(brainstorming)，专题讨论会(workshop)等），原型，模型驱动，认知，基于上下文。

**获取信息的过程：**整体组织方案，维护项目前景和范围（主路线不能乱），接受需求不稳定性（用户会不停的改需求，做好心理准备），控制探索性工作（尽可能控制为确认想法可行性付出的利益）。

**防止遗漏需求：**不要以抽象模糊的需求作为结束，防止不可见的因素遗漏。同时要注意检查边界值和布尔逻辑。

**结束获取：**用户想不出更多用例；用户提出的用例可推导；用户只是在重复问题；新特性，新需求都在项目之外或是在后续版本。

第五章：确定项目的前景与范围

确定项目的前景与范围的过程参考P95 图5-1.

问题分析：

在确定前景和范围之前，需要对问题进行分析，问题分析的前提就是获取问题，获取问题的方式参考第四章。

之后我们需要明确问题，在和涉众进行讨论前就先要对问题达成共识，具体方式就是用标准化格式描述问题，参考P97的表。

之后，我们要收集背景材料，判断问题的明确性。判断标准是”是否能够理解并解决“。我们需要分析不明确的问题，发现问题背后的问题。

之后，发现业务需求。业务需求需要得到所有涉众的一致认同，业务需求的描述也需要标准化格式，参照P100的表。

之后，定义问题解决方案和系统特性，分析不同方案的业务优势和代价，然后和涉众协商进行选定。

之后，确定解决方案和系统特性的边界。

之后，确定解决方案的约束，同样需要建立检查列表来帮助发现约束，参照P104的表。、

目标分析：

目标是系统被开发的目的。目标识别有时候可以通过涉众收集，但更多时候目标是需要努力发现和获取的。

高层目标的获取：可以先获取高层目标，建立相互联系的目标模型。

目标精化：对高层目标分析，收集高层目标资料，发现目标冲突关系等。需要强调的是，目标精化并不是自上而下分解的过程，而是一个不断获取，发现和分析的过程。

目标实现：最主要的两个工作是将最底层的目标分配给群体以及涉及实现最底层目标的操作。

非功能需求分析：

非功能需求体现在质量需求，各种约束等，获取难度较大，需求分散，依赖于功能需求。对于质量需求比较复杂，还会出现相互冲突，依赖的情况。

业务过程分析：

利用活动图进行分析，具体参考P122-134

定义系统边界：

定义问题分析，目标分析，分配主体的边界，分析目标所覆盖的场景和操作的任务，分析边界目标锁关注的数据对象。

前景与范围文档：

主要关注业务需求，项目前景，项目范围，项目环境这4个模块，具体参考P135-141

第六章：涉众分析与硬数据采样

涉众分析：

什么是涉众？一般情况对应用户（使用系统的人），客户（付钱的人）和开发者（开发项目的人）

涉众分析的过程参考P417.

我们需要对涉众进行识别。首先得发现所有涉众识别，然后过滤非关键涉众识别，之后再维护涉众识别。识别涉众的方法有线膨胀后收缩方法，检查列表法。

在识别出涉众类别之后，要描述涉众类别的特征。从个人特征，工作特征，地理和社会特征进行描述。

在涉众描述后要对涉众进行评估，以得到更深层次信息。常见的涉众评估包括优先级评估，风险评估和共赢分析。

我们还需要在涉众中选出代表，要求能够扮演涉众类别的角色，履行涉众类别的职责。涉众采样要求完整采样，态度积极，数量适中，比例恰当。如果实在无法找到合适的涉众代表时，可以考虑寻找一些涉众代替源。

之后，我们对涉众参与策略指定，这里可以采用敏捷方法。

硬数据采样：

硬数据：人们实际工作时产生的表格和文档资料，需求工程师从文档中获取事实，理解问题域。这些文档就是硬数据。

硬数据采样会根据一些统计学的原理分析，具体参照P167-168.

第七章：基于用例/场景模型展开用户需求获取

确定项目前景和范围之后，需求工程就进入了后期阶段，可以在前景与范围指导下展开用户需求获取活动了。

用户需求获取活动的主线索：用例/场景模型

用例/场景是对用户需求以及相关内容的组织，如何组织参照P174-175的图。

用例/场景是有层次性的。其层次可以参照P177-179的图。

场景的定位在形式，内容，目的，生命周期；用例的定位往往需要结合UML用例图进行描述。用例图包含用例，参与者，关系，系统边界。

展开用户需求获取，首先依据系统用例图，目标目标模型建立初始用例/场景模型，然后根据该模型指导需求获取，完善层次结构，然后使用用例/场景组织获取内容，之后用新组织或修正的用例/场景完善用例/场景模型，通过该模型组织需求分析模型，然后分析用例/场景发现仍需获取的需求内容。

在用户驱动的软件开发中，用例是核心元素，因此将系统所有用例文档化是非常重要的，其产生的结果称为用例文档。

第八章：需求获取方法之面谈

在此不说面谈。这一部分没怎么看。

第九章：需求获取方法之原型

对于一些不确定的知识，涉众自己无法解释清楚，自然也无法通过面谈告知需求工程师。此时需求工程师会通过**原型(prototype)**解决不确定性。

原型：通过书面描绘，场景描述，动画模拟，PPT演示，程序代码等将未来事物带回到现在进行展示，因此可以解决不确定性。

原型分为演示原型（PPT演示那种），严格意义上的原型（探索和解决需求不确定内容），试验原型（解决技术方案不确定性）

使用原型法进行需求获取：

要先确定原型需求，起点是什么，期望的结束点是什么。

然后，原型开发。以最低的成本建立初始原型。

然后，原型评估。对上一阶段的原型进行评估，判断是否结束。评估者包含用户和开发者。

最后，原型修正，根据评估修正，直到评估者满意。

故事板原型也是一个很好用的原型，模拟的场景成本低。具体参考P228-231.

当然，原型方法也是有风险的：

用户看到原型就会觉得项目就快做好了，从而提出快速交付产品的不当要求。我们需要善意的提醒用户不要期望过高。

原型会蒙蔽客户的双眼，忽略了他们更该重视的功能特性。

原型会掩盖用户假设，这些假设难以发现。

因此，构建原型也需要进行细致的思考。

第十章：需求或许方法之观察与文档审查

在此不说，没怎么看。

第十一章：需求分析概述

需求分析的根本任务有两条：建立分析模型，创建软件系统解决方案。

建立分析模型：

建模的目标是建立系统的一个表示，使系统的使用更加容易。抽象和分解是建模中最常用的两个手段。抽象要求人们只关注重要信息，同时屏蔽更深层次的细节。分解则是将难以理解的问题分解成多个相对容易理解的子问题，并掌握各种子问题之间的联系（分治思想）。

对于软件开发来说，建模采用软件分析模型，以对象，类，函数，过程，属性等作为模型的基本元素，这样在描述解决方案时必业务模型更严谨更实用。常用的需求分析技术可参考P260-262的表。

需求分析的方法有以下几种：

传统分析：无方法论可言，完全依赖个体才智。
结构化分析：把现实世界描绘位数据在信息系统中的流动，帮助开发人员处理需求。缺点是数据需求和处理需求的连接仍然不容易，而且过于重视已有建模。
信息工程：改进了结构化方法，主要从信息角度开发系统而非功能，因此简化了结构化分析中功能需求处理技术，建立了功能分解图和过程依赖图两种技术。局限性在于是为信息系统开发而定制的，应用范围有限。
面向对象分析：认为系统是对象的集合，对象相互协作，共同完成任务，以对象为基础而非功能和数据。优点包括自然性和可复用性。

在需求分析的活动中，我们需要需求细化（将用户需求细化为系统级需求），确定需求优先级（难以完全解决用户提出的所有需求，因此需要根据一定规则确定优先级），需求协商（解决涉众与开发商之间的冲突）。

第十二章：过程建模

过程建模是结构化分析的典型技术，过程建模将系统堪称过程的集合，其中一部分由人来执行，另一部分由系统来执行。过程建模也会利用分治思想将复杂的过程分解成一些子过程，彼此相互配合完成父过程的任务。

数据流图

数据流图是过程建模所使用的主要技术，有4种基本元素：外部实体，过程（对数据的动作或行为），数据流（数据的运动）和数据存储（在内部收集，保存，以供日后使用的数据集合）。最终建立的数据流图会以图形的方式表现出来。

逻辑说明——微规格说明

在完成功能分解后，可以建立完整的数据流图层次结构。为了充分描述系统功能，需要描述这些过程的处理逻辑，这可以通过微规格说明技术实现。微规格说明主要有结构化自然语言(structured natural language)，行为图(action diagram)，决策表/树(decision table/tree)。

数据说明——数据字典

数据流图只是对原过程的逻辑内容进行细致描述，但数据流和数据存储也需要进行详细的说明，这就要用到数据字典(Data dictionary)。数据字典是一个储存库，包含软件使用和产生的所有数据对象的描述，其中包括数据流和数据存储的定义。具体格式可以参照P309-311的表。

当信息工程得到很大的发展，就采用了新模型增强结构化分析模型，其中包括功能分解图和过程依赖图。

功能分解图：

在一个图内自上而下集中显示系统的功能分解结构。里面最底层是人们所能找到的最基本，不可再细分的功能或处理。功能分解图可以更加集中，直观的展示大量过程之间的层次关系。

过程依赖图：

功能分解图展示了功能和过程的层次结构，但却丢失了功能和过程之间的联系，如数据依赖和顺序关系等。因此信息工程又引入了过程依赖图描述功能和过程之间的依赖关系，这其中还包括资源依赖关系和约束依赖关系。

第十三章：数据建模

在数据说明方面，过程模型更多是侧重数据产生与使用的时间，地点和方式，没有数据的定义，结构和关系等特性。数据建模技术就是用来弥补过程建模在数据说明上的缺陷。

实体关系图

数据建模最常用的方法就是实体关系图。表示法具体参照P322-323的图，包含实体，关系，属性，基数。

实体：描述事物的元素，对现实事物类别的描述，分为概念实体和逻辑实体。

属性：对实体进行更细致的描述，以数字，代号，单词等形式存在，具有值域，标识符。

关系：存在一个或多个实体之间的自然业务联系，通过度数和基数衡量关系复杂性。

在复杂情况下实体关系图的创建，要先发现系统的概念域（concept domain），然后建立对概念域的描述，然后展开概念域建立局部的数据模型，最后合并概念域的局部数据模型。

第十四章：面向对象建模

面向对象(Object Oriented)建模将系统看成是一系列对象的集合，每个对象具有独立的职责，完成独立的任务。UML是为面向对象建模的标准方法，其表示法比较复杂，本书仅介绍了主要概念和图示。

需求分析种涉及的UML技术有：用例图，类图，交互图，状态图，活动图，对象约束语言。具体参照P340的图。

对象模型：以对象和类的概念为基础描述系统对象和这些对象之间的关系。

领域模型：通过对问题域的观察显示概念类，建立领域模型包含4步骤：识别候选对象与类，确定概念类，建立类之间的关联和添加类的重要属性。

行为模型：对象需要相互协作才能完成任务。可以通过交互图实现。UML的交互图又包括顺序图(sequence diagram)，通信图(communication diagram)，交互概述图(interaction overview diagram)和时间图(timing diagram)。

对象约束语言：UML使用图形语言来进行系统数据和行为的描述，同时为了弥补图形无法表达的丰富性，又加上了注解的形式。对象约束语言是建模语言，保证一定表达能力的情况下注重语言的简洁性和抽象性。

第十五章：需求规格说明

这一部分主要是参照模板。P398-405详细介绍了示例模板。

第十六章：需求认证

验证包含两个含义：验证和确认。一方面要确保正确的得到需求（需求验证），得到足以作为软件创建基础的需求；另一方面，它要确保得到正确的需求（需求确认），得到能够准确反映用户意图的需求。

验证贯穿于整个软件生命周期，静态分析和测试是它的两个最主要的手段。

需求验证的方法：

需求评审：指由作者之外的其他人检查产品问题。评审是主要的静态分析手段，原则上每一条需求都需要进行评审。

原型与模拟：当有些需求涉及复杂的动态行为时，它可能就需要使用原型或模拟方法来加以验证。

开发测试用例：需求开发完成后，测试人员就作为软件需求规格说明文档的读者开始进行测试计划。

用户手册编制：和开发测试用例一样，也可以在工作中发现很多软件需求规格说明文档的问题和缺陷。

问题的修正：

在验证过程中发现的问题都应该得到及时的修正。常见行为有以下几种：

需求澄清：发生理解偏差时，需求工程师重新进行分析工作，修正需求文档。

发现缺失需求：需求验证当中发现关键需求没有获取（遗漏某些关键涉众类型等，会造成大量返工）。

解决需求冲突：需求不一致和严重冲突时，需要重新协商解决。

修正不切实际的期望：技术无法解决或项目在既定条件下无法解决的单一需求。

第十七章：需求管理

需求开发活动之后，需求基线应该称为后续系统开发工作的基础。我们需要维护需求基线，实现需求跟踪，控制变更。

需求中的不稳定性在实践调查被关注，需求变更和糟糕的项目计划并列为导致项目失败的两个最重要的因素。在对需求变更的处理上，变更控制可以起到重要的作用，对需求变更的有效应对不仅仅是需求工程，更是整个软件工程的重要发展方向。

第十八章：需求工程的过程管理

虽然需求工程的重要性已经得到了一致的认识，但是这些认知很难在实际开发活动中得到贯彻。建立需求工程的工作不是可以轻易完成的。

需求工程过程需要依赖的环境因素有：市场特性，领域特性，技术成熟度，组织文化，项目特性。

需求工程过程的建立

建立过程框架有3种典型的模型：完全线性的过程模型，线性迭代的过程模型，迭代式的过程模型。管理者需要通过上述的环境因素选择合适的模型。

要想将需求过程加以实施，还需要为框架充实和选择细节的工作组件，包括支持工具，管理工具，建模工具等。

需求工程过程的改进

需求工程过程需要专门，特定的评价标准和改进方法。人们对过程的评价进行了很多的工作，具体参照P455的表。

对于过程的改进，需要评估当前过程，然后进行计划改进活动，然后培训参与人员，然后实现新过程并度量新过程，最后确定下一步行动。

第十九章：需求工程中的项目管理

这章没看。

发展建议

在粗略读完整本书后，写完了对每个章节的简述。里面还有很多具体，细致，复杂的内容没有去理解。在整理文档的时候让我意识到了”需求工程师“这一职业的重要性。需求分析很大程度上决定了项目的成败，因为它不容易被开发者重视，而且它有很多细枝末节难以用语言表达。需求分析不是靠人的脑力随意发挥，而是要遵守前人研究的各种各样的框架才能尽可能保障需求的完善。我们现在大学生写的需求分析只能是很粗糙的，我们社会阅历不足，也没什么经验，只能看着书里的图大概设计一下，而一份粗糙的需求分析是很难满足涉众意愿。不仅如此，对项目的完成也会带来很多的不便。比如需求获取一块，我们很难通过原型和用例/场景模型获取需求，因为光是设计原型和用例/场景就已经很复杂了，要考虑很多的细节，但这还只是整个需求分析过程里的一个模块而已。

但是，回归我们的阿拉丁问答系统的需求分析，哪怕再粗糙的一份需求分析，只要保证它的完整（可以从用户需求细化到系统级需求，确定好约束和边界等等），还是可以为开发带来相对明确的思路和规划。虽然我没有理解的很细致，但是我大概知道需求分析涉及到哪些方面，我们之前设计的阿拉丁问答系统需求分析缺乏哪些方面。

因此，我对项目的发展建议只有一个，就是完善需求分析的”完整性“，做需求分析时思路要清晰。比如说，在画用例图时，不要仅仅将思想停留在”我在建模“上面，而是明确画用例图处于需求分析的哪个环节，作用是什么，想通过用例图达到什么样的目标，不要仅仅是觉得需求分析需要画用例图就开始画。虽然我们无法涵盖各种容易导致项目难以实现的细枝末节，但能实现一份相对完整的需求分析框架也算是尽其所能了。