第三章 软件需求与需求工程

Posted 2023-04-16

参考技术A 软件需求 = 业务知识 + 问题列表 + 其他因素。

业务知识：业务事件，业务实体，业务规则。

问题列表：用户在工作中遇到的困难和障碍，也是软件需要解决的问题。

其他因素：设计约束，非功能性需求等。

3.1.1.1 业务需求

业务需求是系统的高层次目标要求，即系统的建设目标，这种目标通常体现在两个方面：问题和机会。

业务需求的提出通常是高层管理人员，它是团队努力的方向。但如果业务需求过于夸大，可能会导致不必要的资源浪费。

业务需求是在项目立项阶段整理，也就是需求定义的产物。关于业务需求定义的方法，将在“第四章 需求定义最佳实践”中讲解。

3.1.1.2 用户需求(也叫原始需求)

用户需求是需求捕获的产物，是指用户使用软件需要完成什么任务，怎么完成。通常在业务需求定义的基础上进行调查整理。

用户需求有几个特点：

》零散：用户会提出不同角度，不同层面，不同粒度的需求。

》存在矛盾：由于用户处于企业不同位置，需求具有片面性，不同用户将存在不同观点。

正因如此，我们需要对用户需求进行分析，整理，从而得出更精确的需求说明。

3.1.1.3 软件需求

软件需求就是用户需求整理后的产物。

业务需求是需求定义的产物，用户需求是需求捕获的产物，软件需求是需求分析与建模的产物。

软件需求可以分为功能需求，非功能需求和设计约束三种类型。

3.1.2.1 功能需求

功能需求的要点在于如何组织。

对于功能需求的组织形式有以下几种：

》层次结构。在传统方法论中，会以系统-子系统-模块-子模块-功能-子功能的层次结构来组织，这也是一种方法。但它更多是一种程序结构，而非需求结构，它很可能会割裂用户的使用场景。

》RUP方法论中的用例方法。

》敏捷方法论中的用户故事。

》特征驱动开发中的Feature。

笔者建议首选用例方法，详细内容将在“第六章 需求分析与建模最佳实践”中介绍。

3.1.2.2 非功能需求

对于非功能需求最典型的问题有两个：

》信息传递的无效性：在前面的章节也讲到过，许多需求规格说明书中都有“设计原则”这一章，里面写着：高可靠性，高可用性，高扩展性等要求。但没人真正去看它，因为定性描述是没有判断标准的。所以这种就是信息无效传递。将在“第七章 需求描述最佳实践”中说明解决办法。

》忽略了非功能性需求的局部性。有时会看到“所有查询时间都应该小于10秒”。但当用户执行年度查询时，这是不合理的要求，最终也变成摆设。所以要抓住具体的场景来描述。

非功能需求的要点在于保证信息的有效传递和注意其局部性。

3.1.2.3 设计约束

设计约束包括非技术因素的技术选型，预期的软硬件环境和预期的使用环境三大类型。

在收集设计约束时，不能出现遗漏：

》非技术因素决定的技术选型。

》预期的软硬件环境。在整理需求时，应该将这些预期的软硬件环境描述出来，最有效的方法就是部署图，将在“第六章 需求分析与建模最佳实践”中讲述。

》预期的使用环境。

完整性，正确性，无歧义性，必要性，有优先次序，可行性，可验证性。这7个标准可以分为4组。

3.1.2.1 完整性

完整性就是没有遗漏。将来在需求变更时“新需求”占比会较少。但在实际需求活动中，完整性是一个难题。完整性的关键在于以下两个方面：

》用户才是验证需求完整性的合适人选。但是用户往往需求都提不完整，如何对完整性进行验证？问题还是在需求组织结构上。很多人在组织需求时，通常是按照程序结构来梳理，这样做的结构就是用户在验证完整性时遇到障碍，无法直观系统的了解系统是否能满足所有需求。要保证需求的完整性，就必须从业务角度来组织各种需求像，让用户验证需求规格说明书中罗列的主题域，业务事件，业务活动，业务步骤，困难与障碍点是否完整。

业务导向的需求层次结构是保障完整性的关键。

》需求完整性存在不同层面。需求是有层次的，企业中高层，中层，操作员所了解和掌握的信息是不一样的， 在验证需求完整性时，需要采用分层评审的方式 ，不同层次的人员评审与自己相关的需求层次。

3.1.2.2 不失真

需求的正确性和无歧义性就是不失真。

》正确性。要使需求正确，一方面要分层次验证，一方面应该找到直接相关人员进行验证，另一方面，为了避免片面性，还要通过用户调查来补充。更多细节将在“第五章 需求捕获最佳实践”中介绍。

》无歧义性。是指在传递过程中不同的人加入不同的理解。因此光靠文档来传递需求是不充分的，沟通和验证活动能尽量缓解歧义问题。

3.1.2.3 有优先级

需求有时会戴上“高优先级”的面具，实际上只是担心你不实现而已。

所以引导用户从业务角度划分优先级是最关键的。除业务角度外，也要考虑技术角度和项目管理角度。

》从必要性的角度评价优先级

满意/不满意模型是需求必要性评价的有效手段。

3.1.2.4 技术人员早期参与

需求规格说明书，来源于用户，提供给技术人员，包括开发和测试。所以与技术团队交流，探讨需求规格存在哪些不足，缺少什么信息，是改进需求规格说明书的有效方法。

》可行性，由开发软对重点需求项，及复杂技术解决方案进行验证。

》可验证性，由测试团队验证。

需求工程包括需求开发和需求管理。需求开发是指收集，分析，整理，编写，验证的全过程，重点在于产出高质量的需求规格说明。需求管理是对需求的实现，变化进行追踪的全过程，重点在于确保开发的软件满足需求。

注意，需求定义并不包含在需求工程中，这是因为需求定义通常叫做项目立项，属于项目管理的范畴。将在“第四章 需求定义最佳实践”中介绍。

现代软件工程的思想更偏向于多次循环，需求工程也不例外，通常需求获取，需求分析，编写规约，需求验证至少要经历三次循环。

对于需求获取，需求分析，编写规约，需求验证这四个活动，将在5-8章中详细介绍，这里只对其核心要点和盲区进行说明。

3.2.2.1 需求获取(需求捕获)

需求捕获是一个主动的过程，而显示中却常常是比较被动的，主要体现在：

》捕获范围不足：只注重用户要实现什么功能，不注重对业务知识的捕获。

》缺乏计划性：捕获过程随意，预先没有对问题，时间，访谈人员进行计划。

》缺乏科学性：捕获过程比较分散，没有做到定向，聚焦，常常把宏观问题和微观问题混在一起。

》捕获对象不明确：很少主动寻找合适的被访谈者，常常是对方主动指定。

》捕获手段不足：通常认为只有用户访谈和调研会是有效手段，但忽略了不同场景下捕获手段的不同组合将有更好的效果。

“第五章 需求捕获最佳实践”中将详细说明需求捕获的策略，方法和工具。

需求捕获活动中，化被动为主动是关键。

3.2.2.2 需求分析

需求分析是需求工程中的核心任务，但在实践中常被忽视，也就是捕获的需求直接整理到需求规格说明书中。

》需求分析是什么。需求分析是业务分析，因此要从业务线索入手，而非程序结构；需求分析是一种分解活动，将按职责划分成不同的主题域，再分解到业务流程，再分解到用例；需求分析是一种提炼与整合活动，将原始需求整合到业务活动中，将业务活动整合到全局业务流程图中；需求分析是一种规格化活动。将在“第六章需求分析与建模最佳实践”中详解。

需求分析就是向下分解+向上提炼，外加一些规格化。

》内容和形式

建模语言越来越流程，但一定要理解：分析是任务，建模是手段。建模的过程就是分析的过程。尽量团队建模；大胆使用草图，而不是一上来就开rose。

需求分析是目标，需求建模是手段。

3.2.2.3 编写规约

编写规约就是需求分析结果文档化的过程。软件需求规格说明书的要点在于：分享，更新。

3.2.2.4 需求验证

需求验证不是签字，细节将在“第八章 需求验证最佳实践”中阐述。

需求管理包括基线管理，变更管理和需求跟踪三个活动。

需求管理可以分为四步：统一明确的需求项划分标准，引入基线管理，引入变更管理，引入需求跟踪。下面将逐一讲解。

3.2.3.1 统一明确的需求项划分标准。

》颗粒均匀。即衡量需求工作量的单位是相同的，人天，人月，人周都可以，但是需要统一。

》大小合适。

》完整。最低一级的需求项应该覆盖所有开发任务。

“第六章 需求分析与建模最佳实践”中将具体阐述。

划分出大小合适，颗粒均匀的需求项是需求管理的前提。

3.2.3.2 引入基线管理

基线管理将需求分为两个部分：已经开始开发的需求(baseline)，还没安排开发的需求(backlog)。(一个基线内容就是Scrum里的一个冲刺)

在划分基线时，通常需要完成三件事：

1 确定优先级，确保高优先级，高风险的需求尽早完成。

2 工作量估算，确保每次迭代的安排是紧凑的。

3 未完成项的合并，每次迭代还是可能有些工作未完成，分配下一次基线时就要考虑进去。

具体将在“第九章 需求基线操作事务”中距离说明。

需求优先级与工作量估算是基线管理的关键。

3.2.3.3 引入变更管理

变更如果简单地转交给开发人员，会使开发团队变成救火队，陷入大量紧急却不重要的工作中 。所以引入变更管理是非常重要的。就需求管理而言，变更管理的重要在于完成业务影响分析，技术影响分析，项目影响分析三方面工作。具体可以参考“第十章 变更管理操作事务”。

》业务影响分析：从业务角度对变更的合理性，优先级，对原有需求的影响进行分析，以便决定是否纳入backlog中。

》技术影响分析：从技术角度对变更的影响范围，工作量进行分析。

》项目影响分析：基于前面的工作量分析，考虑是否对整个项目的进度成本产生较大影响。

变更管理的核心是控制变更的影响，而非消除变更。

3.2.3.4 引入需求跟踪

需求跟踪是一种高阶管理活动，将辅助大量的工作量，因此在前三个活动还不是很顺畅时，不建议引入需求跟踪。我们将在“第十一章 需求跟踪操作事务”中介绍。

需求分析人员必须掌握的技能包括：倾听，交谈，提问的技巧，分析，协调，观察，写作，组织，建模，人际交往和创造能力。这些能力可以概括为业务知识，技术知识，沟通能力三个方面。

3.2.4.1 需求分析人员的来源

推荐是以用户背景的人员(甲方需求人员)为核心，以开发人员作为解决方案的选择和技术论证(乙方需求人员)，领域专家作为顾问。

但在现实中，更多还是以乙方需求分析人员为主角，这时就要充分发挥用户背景的需求人员作为业务支持。

3.2.4.2 各种能力培养的要点

对于沟通能力方面，在“第五章 需求捕获最佳实践”中有很多案例。

SERU模型分为三个阶段：Subject1-3是需求定义阶段，Event和Report4是理清脉络阶段，User case5是细节填充阶段。

》需求定义阶段：就是项目立项阶段。核心目标在于定义项目目标和范围。主要任务就是划分主题域，并标识出每个主题域中的Event(业务事件)和Report(报表)。

》理清脉络阶段：相当于需求捕获，分析和建模的第一阶段。就是将每个Event(业务事件)，每个Report(报表)进行分析，包括事(流程)，物(业务实体)，人(角色)的分析。

》细节填充阶段，相当于需求捕获，分析和建模的第二阶段。

第三次博客作业-再谈对软件工程的认知与理解

再谈对软件工程的认知与理解

软件工程导论课程开课于大二下学期，课程持续时间为10周，团队项目于2021年6月18日完成答辩。在软件工程课程相关知识的学习和实践过程中，团队完成了需求调查、拟定需求、确定需求、使用Axure绘制原型、在Gitee上创建项目仓库、部署统一环境、分模块编写代码、进行单元测试、项目验收等任务。在学习和实践过程中，通过需求调查我们学习了调查问卷的设计方法和基本原则，以及如何能够使调查问卷覆盖到更多的人；通过绘制原型我们学习了Axure软件的使用方法及快速原型的软件设计方法；通过创建项目仓库、部署统一环境我们也学习制定了团队开发规范以及代码规范；通过分模块编写代码使我们对Java语言的使用更加熟练；最后通过单元测试改变了我们以往对项目测试的看法，我们尝试自行设计测试用例及编写测试代码。当团队项目完成后，我们团队也组织了一次交流会议，在会议上每一个人都说出了自己的心得及收获，大家都表示通过本次项目的实践后收获很大，对软件开发也有了一个更加系统的认识。软件工程导论课上所学的知识非常符合软件工程专业学生对未来软件开发的需求，对我们的启发也是巨大的。

在项目开发的过程中，我们并不是一帆风顺的，每一个环节都遇到了不同的问题，团队也都在尽力解决每一个问题，将项目的每一个环节做到最好。在项目需求调查及需求确定环节中，首先是如何确定调查问卷的题目及题目类型问题。团队首先参考了“问卷星”小程序中预置的模板，其次查找了调查问卷设计方法的相关资料，最终在组内讨论并共同制定出最终的调查问卷。在团队选择快速原型设计模型后，团队成员便开始了解和学习快速原型设计模型，并在网络上查找相关的原型设计软件，最终选择了Axure团队版。由于团队部分成员在实验室参加过项目的开发，所以对于软件的使用相对熟悉，于是团队组织了一次队内教学活动。在所有成员安装正确的版本后，由有经验的成员未其他成员讲解软件的使用方法、页面布局规范、绘制方法等，让没有经验的成员也能快速的上手原型绘制。为了方便版本控制及记录绘制过程，团队创建了Axure Cloud并将所有原型页面上传到云端方便保存。

在项目开发中最大的问题应该是编程实现的过程。本项目采用Spring框架，使用Java语言编写，这对于从来没有进行过项目开发的团队来说是个不小的挑战。为了实现预想的功能及页面，我们也是学习了前后端不同的技术，前端主要是ajax传递值技术及html样式问题；后端主要是Java实现问题，因为要分层实现就会将代码分开实现，这个问题也是困扰了我们团队很长时间。对于解决方法我们采取了以下两点，第一点是询问有经验的学长、学姐，向他们请教项目开发的经验及相关技术问题；第二点是在不影响功能的前提下，将一些不必要的功能去掉，但是在数据库层面保留相关信息，这样在以后经历允许的情况下，我们也可以将被去掉的部分实现。

本次项目开发的过程，我们团队虽然有很多收获，但是也正视了自己的不足之处。在我们“村镇银行储蓄系统”的开发中，原先设想的是相关业务操作是基于银行卡号实现，同时用户页面也可以显示自己的卡号，在存款、取款操作时也需要对银行卡密码进行验证。但是由于时间及自身知识储备等问题，在后期我们去掉了这一业务流程，采用最简单的操作方式，进行操作时没有密码验证，并且相应的数据记录和用户ID绑定。这一点也是我们团队内部认为项目存在的最大的缺陷，如果实现了这些业务流程，我们的项目会更加的完美。

本次项目开发是我第一次作为团队的队长，这对我的自身能力也是一个重大的考验。在这之前我并没有担当团队队长的经历，在学习课上学习团队合作的知识时也没有过多的感触。但是当我带领团队面临团队项目开发的任务时，我才懂得了团队领导者的作用有多么重要。如果我在开发时没有方向、没有动力，那么团队成员也就不会有任何的方向和动力，这样也就会导致整个项目的延迟，甚至是项目质量的降低。所以我在开发过程中积极与团队成员沟通，时刻了解他们在开发过程中的思想变化及面临的困难，并积极发动其他成员共同帮助他解决困难。同时我也明白，团队队长的付出要比队员多很多，有时我需要先行规划开发过程、学习相关知识，同时要合理的指出队员存在的问题。经过这几周的开发，我自身的领导能力也得到了相应的锻炼，为日后的项目开发打下了基础。

学习完软件工程导论这门课程后，我们对于课程本身也有了一些想法。本门课的知识更加的抽象，对于刚开始接触这门课的我们来说，理解知识还是有一些困难，我们团队也希望以后的课程可以多引用一些实例，比如真正的软件开发团队是怎样进行软件开发的，他们遵循的流程是什么样的，他们又是如何执行的。如果是理论结何理论实践的授课方式，那么对于我们来说，课程知识就更容易被我们理解。老师也在超星平台上上传了一些课外资料及视频，这也是对于我们课程的一个补充及延申，我们在学习时也是获益匪浅。

以下是团队成员对于软件工程导论这门课的认识和理解。

贾一新：

在学习这门课之前，我们编写的程序都是单机的，并且由个人开发。但是作为软件工程专业的学生，我们应该具备工程项目开发的能力。在学习代码规范的时候，我认为十分强调代码的规范意义不大，但是我们还是按照要求在团队内部制定代码规范。当我们利用Gitee进行代码合并的时候，我终于明白了强调代码规范的意义。因为我们每一个人都遵守了我们制定的代码规范，所以在代码整合的过程中没有出现代码不理解或代码串行等问题，因此我们也是节省了很多时间以及避免了很多不必要的麻烦。实践才是检验真理的唯一标准，如果我们只学习理论知识，不将理论知识放到实践中去，我们也就永远不可能理解它存在的意义。

在我看来理论课程是我们学习软件工程的基础，学习了这些理论我们才能知其然更知其所以然。科学家为了解决软件开发中的高成本、低质量的问题提出了“软件危机”的概念，关注质量是软件工程的根本出发点和最终目标。其实不止是软件开发会遇到这样的问题，社会上的各行各业都面临着这个问题，大家都在为更好的品质而努力。其中的面向对象法也是后面实验课主要采用的方法，可见其重要性和实用性。其中软件的售后服务及维护阶段是占据了整个过程最高成本、时间。这一点我在复习提问时答错的，后来仔细一想，软件的错误有时候在开发完成时是没有出现的，而是随着用户在使用过程中出现的。但正是由于如此才能促进软件的不断升级。理论中的工作量估算也很实用，适用于各个领域。我觉得很有趣的一个知识点是聚合关系和组合关系，聚合关系表示事物的整体与部分关系较弱的情况，而组合关系表示事物的整体与部分关系较强的情况。当时老师就举了同学与班级的关系有趣生动的使我们对这两个关系的区别。

迟永鑫：

需求分析方法中结构化分析方法是十分重要的。首先是由“数据流、加工、数据存储和外部实体”构成的数据流图，体现了系统的逻辑模型或者说是功能建模。再来是，面向过程的结构化设计，模块独立的独立性主要采用耦合和内聚进行衡量，其标准是：低耦合，高内聚。比如说，内容耦合的耦合性高模块独立性弱，这是需要避免的耦合；至于内聚，偶然内聚、逻辑内聚和时间内聚都是低内聚，模块独立性弱，也是需要避免的。其次是结构化软件设计中，从数据流转换成数据模块图，要用到变换流以及事务流的分析方法。最后，软件测试中要注意的是测试用例，其中，输入数据和预期结果这两方面内容尤其重要。

房琳尧：

软件工程导论是一门软件工程专业的必修课，初读这本书，加上在知乎上看到的一些网友的讨论，我认识在软件工程中由“对象+类+继承+消息”组成的面向对象的开发方法是十分重要的。软件开发的生命周期中，问题定义、可行性、需求分析、概要设计、详细设计、程序设计、测试文档、技术支持和售后服务都是缺一不可的。特别注意的是，可行性的分析要从经济、技术、法律和社会四个方面考虑。软件过程改进中，软件能力成熟度模型划分为初始级、可重复级、已定义级、已定量管理级和优化级五个等级。项目进度管理的可视化工具中甘特图能直观地表明计划在什么时候进行，及实际进展与计划要求的对比，缺点是:没有指出影响项目寿命周期的关键所在。而任务网络图能比较直接地反映出依赖关系。以上是比较概念的知识点。

陈伟豪：

软件工程的学习中，我了解到了软件并非是一些代码这么简单，在开发软件的过程中，编写代码的工作量其实只占不到所有工程量的30%，而后期的管理和维护更是占了60%到80%之多。一个完整的项目规划须包括，软件的定义，可行性分析报告，项目开发计划，软件需求说明书，概要设计说明书，详细设计说明书，用户操作手册，测试计划，测试分析报告，开发进度报告，项目开发总结报告，软件维护手册，软件问题报告，软件修改报告，等多个文档，每个文档都要上级验收审查，而文档数量众多，要做好这点真的不是很容易，而恰恰写好文档正能保证完成软件工程其中一个目的的关键，既研究如何用最小的开销做出生存期较长的软件，再加上各个阶段都要进行周密的策划、详细的分工部署和人员安排，且各阶段要据具体情况不断的反复才能达成，所以代码只是开发软件这个浩大的工程的一个小小的过程。

蔡东杰：

曾经以为程序就是软件,软件就是程序。学习这门课程第一个收获是,知道了二者的不同之处。我学到的最大的一点就是，在写软件是编写程序并不是所有，很多前期准备也是很重要的，比如在进行分析,设计,编码,调试,维护这几部分的工作的时候,最核心的就是文档的编写。

1.可行性分析就是关于当前项目能不能干的分析结果。

2.项目描述这是在决定立项以后,对当前项目的一份扼要说明。

3.需求分析就是对客户要求的功能的定义。

4.软件设计这就是对程序的每一个模块的详细设计的说明文档。

5.开发日志我一直都认为这是文档中最有趣的部分。 开发日志相当于编码阶段的文档, 它的形式可以很随意, 主要是记录一些在写程序时突然萌发的灵感, 或对代码的一些微小的 修改,或对程序结构的一些微小变动等,还要对上述这些修改变动作些说明。

6.测试分析 用于指出程序存在或潜在的缺陷和错误,以及程序性能的数字描述。