软件工程（三）——敏捷开发和理解需求

笔者正在学习《软件工程-实践者的研究方法》这本书，记录下一些读书笔记，共勉！

1.敏捷

市场条件变化十分迅速，客户和最终用户的需求在演变，从业者必须使软件工程工作保持敏捷，要限定过程应是灵活机动的、有适应能力的和精益的以适应现代商务的需求。
敏捷可以应用于任何一个软件过程（沟通、策划、建模、构建和部署），过程的设计应该使项目团队适应于任务，并且使任务流水线化，在了解敏捷开发方法的流动性的前提下进行计划的制定，消除所有最基本软件产品并精简软件开发过程，强调这样一个增量交付策略：根据具体的产品类型和运行环境，尽可能快地将切实可行的软件交付给用户。
敏捷过程能够降低变更的成本，因为软件以增量方式发布，而且在增量内部变更能得到较好的控制。

1.1敏捷原则

（1）我们最优先要做的是通过尽早、持续的交付有价值的软件来使客户满意；
（2）即使在开发的后期，也欢迎需求变更，敏捷过程利用变更为客户创造竞争优势；
（3）经常交付可运行软件，交付的时间间隔可以从几个星期到几个月，间隔越短越好；
（4）在整个项目开发期间，业务人员和开发人员必须天天在一起工作；
（5）围绕有积极性的个人构建项目，给他们提供所需的环境和支持，并信任他们能够完成工作；
（6）在团队内部，最富有效果和效率的信息传递方法是面对面交谈；
（7）可运行软件时进度的首要度量标准；
（8）敏捷过程提倡可持续的开发速度，责任人、开发者和用户应该能够长期保持稳定的开发速度；
（9）不断的关注优秀的技能和好的设计会增强敏捷能力；
（10）简单是必要的；
（11）最好的架构、需求和设计出自于自组织团队；
（12）每隔一定时间，团队会反省如何才能更有效的工作，并相应调整自己的行为。

1.2 人的因素

敏捷开发关注个人的才智和技巧根据特定人员和团队来塑造过程。要求团队成员及团队本身具备以下一些特点：

• 基本能力：内在才能和特定的软件技能；
• 共同目标：团队为完成同一个任务而瞄准同一个目标；
• 精诚合作：项目组之间、项目内部成员之间精诚合作；
• 决策能力：具有掌握自身命运的自由；
• 模糊问题解决能力：不断面对不确定的问题并良好解决；
• 相互信任和尊重：以形成一个强有力的组织；
• 自组织：①敏捷团队组织自身以完成工作；②团队组织最能适应当前环境的过程；③团队组织最好的进度安排以按期交付产品。

1.3 应用最广泛的敏捷过程模型：极限编程 （eXtreme Programming, XP）

极限编程过程分为策划、设计、编码和测试4个框架活动的规则和实践。

• 策划：需求获取，使XP团队技术成员理解软件的商业背景，充分感受要求的输出、主要特征和功能。用户的需求产生了多个“故事”，每个“故事”根据优先级有权值。用户可以随时增加、修改故事和故事的权值。
• 设计：XP设计严格遵守保持简洁的原则；
• 编码：首先开发用于检测本次增量产品的测试单元，然后编码，最后测试；
• 测试：“在编码之前简历单元测试是XP方法的关键因素。”

2.理解需求

理解需求的重要性：“我知道你认为你理解我说的是什么，但是你并不理解的是：我所说的并不是我想要的”

2.1 需求工程 （Requirement Engineering，RE）

需求工程指致力于不断理解需求的大量任务和技术。需求工程通过执行7个不同的活动来实现：起始、导出、精化、协商、规格说明、确认和管理。

• 起始：项目起始阶段中，要建立基本的理解，包括对问题、谁需要解决方案、所期望解决方案的性质、与项目利益相关者和开发人员之间达成初步交流合作的效果。
• 导出：询问客户、用于和其他人，系统和产品的目标是什么、想要实现什么、系统和产品是如何满足业务要求、最终系统是如何用于日常工作；
• 精化：将起始和导出阶段的信息进行扩展和提炼，开发一个精确的需求模型，用以说明软件的功能、特征和信息的各个方面。
• 协商：解决客户过高需求与有限业务资源冲突的过程，让客户、用户和其他利益相关者对各自需求排序，按优先级讨论冲突；
• 规格说明：基于计算机的系统和软件的环境下，属于规格说明对不同的人有不同的含义。一个规格说明可能是一个说明文档、图形化的模型、形式化的数学模型、一组使用场景 、一个原型或上述任意组合。
• 确认：对需求工程的产品进行评估，检查规格说明，保证无歧义的说明的所有的系统需求、已检测出不一致性并得到纠正、工作产品符合过程、项目和产品建立的标准。
• 需求管理：用于帮助项目组在项目进展中标识、控制和跟踪需求以及需求变更的一组活动。

---

建立规格说明的大纲：
目录
版本历史
1 导言
1.1 目的
1.2 文档约定
1.3 适用人群和阅读建议
1.4 项目范围
1.5 参考文献
2 总体描述
2.1 产品愿景
2.2 产品特性
2.3 用户类型和特征
2.4 操作环境
2.5 设计和实现约束
2.6 用户文档
2.7 假设和依赖
3 系统特性
3.1 系统特性1
3.2 系统特性2 ……
4 外部接口需求
4.1 用户接口
4.2 硬件接口
4.3 软件接口
4.4 通信接口
5 其他非功能性需求
5.1 性能需求
5.2 安全需求
5.3 保密需求
5.4 软件质量属性
6 其他需求
附录A： 术语表
附录B： 分析模型
附录C： 问题列表

---

2.2 建立根基

起始阶段，首先需要确认该项目的利益相关者（直接或间接从正在开发的系统中获益的人），如业务运行管理人员、产品管理人员、市场销售人员、内部和外部客户、最终用户、顾问等。需求工程师应创建一个人员列表。不同的利益相关者提出的需求可能是重复的、矛盾的或者有某种关联的，因此需求工程师的下一步工作是将利益相关者提出的需求进行分类整理。第三步是根据需求的分类和目标，确定在利益相关者之间要团结协作，并与软件工程人员紧密协作。这一步需求工程师需要划分利益相关者和开发人员的职责、标识公共区域（都同意的需求）和矛盾区域。

2.3 导出需求

利益相关者和开发团队应该共同完成：确认问题，提供建议，商讨解决方法。

• 协作收集需求：首先为明确问题并提出解决方案，需要由软件工程师和利益相关者共同参与讨论会议，明确项目的各方面需求、约束列表、性能标准等，尽可能收集需求，并将需求分类整理。
• 质量功能部署（Quality Function Deployment，QFD）：是一种将客户要求转化成软件技术需求的质量管理技术。在此过程中，QFD确认三类需求：正常需求（开会时客户确定的需求）、期望需求（隐含在产品或系统中，但客户没有显式说明，但缺少这些将导致用户不满，如人机交互的容易性、安装的简易性）和令人兴奋的需求（客户期望之外的特点，实现这些将使客户非常满意）。
• 用户场景：收集需求时，逐步具体化系统功能和特性的整体愿景。
• 导出工作产品：工作产品包括要求和可行性陈述、系统或产品范围的界限说明、系统技术环境的说明、需求列表、一些使用场景、任何能更好定义需求的原型等。

2.4 开发用例

用例讲述了能表达主体场景的故事：最终用户如何在一个特定环境下和系统交互。这个故事可以是叙述性的文本、任务或交互的概要、基于模板的说明或图形表示。用例是从最终用户角度描述了软件或系统。
撰写用例首先要确定参与者，然后再开发用例。参与者是任何与系统或产品通信的事务，且对系统本身而言参与者是外部的。参与者并不等于系统的最终用户。

2.5 构建需求模型

需求模型为基于计算机的系统提供必要的信息、功能和行为域的说明。

2.6 协商需求

在多数情况下，让利益相关者以成本和产品投放市场的时间为背景，平衡功能、性能和其他的产品或系统特性。协调的目的是保证所开发的项目计划，在满足利益相关者要求的同时反映软件团队所处真实世界的限制。
协商需求一般有以下活动：

• 识别系统或子系统关键的利益相关者；
• 确认利益相关者“赢”的条件；
• 就利益相关者“赢”的条件进行协商，以便使其与所有涉及人的一些双赢条件一致。

2.7 确认需求

需求模型的每一个元素都已创建后，需要检查一致性、是否有遗漏以及是否有歧义。

• 每项需求都和系统或产品的整体目标一致吗？
• 所有的需求都已经在相应的抽象层上说明了吗？
• 需求是真正必须的，还是另外加上去的，有可能不是系统目标所必须的吗？
• 每项需求都是有界定并且无歧义的吗？
• 每项需求是标记了来源吗？
• 需求之间有冲突的吗？
• 现实资源环境基础上每项需求都能实现吗？
• 一旦实现后，是否每项需求都可测试？
• 需求模型是否恰当反映了将要构建系统的信息、功能和行为？
• ……

总结：需求工程的任务是为设计和构建活动建立一个可靠坚固的基础。需求工程发生在于客户沟通活动和为一般的软件过程定义的建模活动过程中。软件团队成员要实施7个不同的需求工程职能：起始、导出、精化、协商、规格说明、确认和管理。