2024年最全软件需求最佳实践笔记（三）_需求文档 最佳实践，2024年最新Golang面试题汇总

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

变更处理过程流程图

变更处理过程中要做影响分析，包括业务影响、技术影响、项目影响等。

①业务影响分析

首先，确定影响范围。

行为需求类变更：具体功能方面的需求，包括用户界面需求，可直接找到对应的需求项，可以归属于某个具体的业务活动中；也可以变成新增的用例，甚至是新增的业务事件。

数据、非功能、规则类变更：对于这类的变更则需要考虑它影响的范围，它可能只影响一个业务活动（用例），也可能影响一个业务事件。

确定需求变更的影响范围示例

其次，选择正确的评价者。

按上面的方法确定了变更的影响范围之后，选择正确的评价者，并将接受的需求变更通知到所有相关的人员。

选择正确的评价者示例

然后，对变更做出是否接受评价。

常见的评价角度包括：

对目标的贡献度：也就是对于系统的总体目标有没有直接贡献，如果有通常是肯定接受的。

对Stakeholder关注点的贡献度：也就是对于系统的Stakeholder的利益是否有直接的贡献。

对现有业务的影响程度：通常是对于规则类变更而言的，评估新的规则会对业务产生什么样的影响。

“变更分析：是否接受”示例

对于接受了的需求变更项，通常还需要确定优先级，通常将直接继承其影响的用例（业务活动），对于新增的用例则从业务价值和发生频率的角度综合评价。

“变更分析：优先级判断”示例

“变更分析：优先级判断”示例

②技术影响分析

对于修改型的变更：罗列出会影响哪些人工制品，包括数据库表、字段、界面窗体、控件，类、方法；在这个方面要想做得比较精确，就必须借助于“需求跟踪”，具体来说就是“需求项”与“人工制品”的跟踪。

对于新增型的变更：可以采用类比法进行，从已经实现的（也就是已有工作量记录的）功能中找一个与其相当的，以得出一个大致准确的工作量估计。

对于技术影响度的分析还有一个很重要的方面，那就是对原有架构、原有人工制品的影响，这个任务通常是由架构师完成的。通过这些评估之后，也会得出“是否接受”、“优先级如何”之类的决策。

③项目影响分析

完成业务影响分析和技术影响分析之后，通常还需要进行项目影响度的分析，具体来说，就是基于前面的工作量分析，考虑是否对整个项目的时间、进度、成本产生较大的影响，并在这个基础上做出最后的决策。

④是否打破基线

原则上不打破基线，也有几种常见的例外：

出现了影响生产的需求（通常是维护阶段），或者需求变更项的优先级比待开发的所有需求项的优先级都更高。打破基线通常采用置换法，也就是从基线中换回一个工作量相当的任务，将其放到下一次迭代中。

出现了对前面假设有巨大影响的需求：暂停迭代，重新考虑基线。

工作量比较小，重要性或与开发中的需求的关联性很强：加入基线。

三、变更管理要点二：统一平台

• 变更管理平台应用要点

对变更进行分类、再分类，是管理变更的重中之重。变更进行不断地分类，还能够帮助我们意识到“错在哪里”，“为什么错了”，以及“变化点在哪里？ “有什么规律”。

14.软件需求最佳实践笔记 | 需求跟踪

一、需求跟踪的基本概念

需求跟踪是将单个需求和其他系统元素之间的依赖关系和逻辑联系建立跟踪，这些元素包括各种类型的需求、业务规则、系统架构和其他设计组件、源代码模块、测试用例等。

需求跟踪涉及5种类型的跟踪链：从用户原始需求向前跟踪到软件需求，从软件需求向前跟踪到下游工作产品；从下游工作产品向后回溯到软件需求，从软件需求向后回溯到用户原始需求；以及软件需求到软件需求的跟踪。

需求跟踪的收益体现在以下六个方面：

审核：跟踪能力信息可帮助审核确保所有需求被应用。

变更影响分析：跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。

维护：可靠的跟踪能力信息使得维护时能够正确、完整地实施变更，从而提高生产率。

项目跟踪：认真记录跟踪能力数据，可以获得计划功能当前实现状态的记录。

再设计：可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。

重复利用、减少风险、测试。

• 用户需求到软件需求的跟踪

这类跟踪的工作量规模中等，对于项目管理的好处很明显，建议有时间尽量实现此类跟踪。

目的：保证所有的用户原始需求都得到满足。

好处：1)开发人员在实现时能够精确地定位到相关的原始需求；2)可以为软件需求是否必要提供第一手的证据；3)容易找到需求之间的矛盾和歧义。

具体手段：将一句话表示的用户原始需求直接归并到软件需求的组织单元“用例”中。

• 软件需求到软件需求的跟踪

这类跟踪的工作量规模较小，对于需求管理的好处十分明显，此类跟踪是最应该建立的。

主要内容：包括1)项目目标、Stakeholder关注点到软件需求的跟踪；2)相关软件需求之间的跟踪。

目的：确保项目目标、Stakeholder关注点被实现。

好处：1)更好地理解软件需求的实现意义；2)更好地处理软件需求之间的逻辑相关性。

具体手段：为项目目标、Stakeholder关注点创建唯一编号，通过表格或链接法实现跟踪。

• 软件需求到下游工作产品的跟踪

软件需求到下游工作产品（系统架构和其他设计组件、源代码模块、测试用例以及帮助文件等）的跟踪，这类跟踪对于变更管理的好处十分明显，但工作量规模巨大，此类跟踪应该慎用。

目的：维护软件需求与设计元素、测试元素之间的关联关系。

好处：1)在针对变更的技术影响分析时，能够得到更加精确的评估结果；2)可以更好地隔离变更的影响。

具体手段：手动更新或者通过配置管理软件来实现更新。

二、需求跟踪的操作方法

要对需求进行跟踪，必须对每个需求定义一个唯一的标识，并且要以前后统一的方式进行标识，这样才能够保证在整个项目中没有歧义地引用它。在实际的需求跟踪过程中，主要有表格法和链表法两种策略；

注：需求管理工具Rational Requisite pro采用的就是表格法，Telelogic DOORS采用的就是链表法。

[表格法]用户原始需求到软件需求的跟踪矩阵

[表格法]软件需求到下游工作产品的跟踪矩阵

[链表法]软件需求到软件需求的跟踪矩阵

15.软件需求最佳实践笔记 | 总结

一、SERU过程框架的理论基础

Subject Area可以理解为子系统，更强调业务分析，非功能分解；Use Case可以理解为功能模块，只不过它更强调用户视角，而非功能分解。但这两者之间是存在鸿沟的，很难有效地将子系统分解成具体场景级的功能模块。

二、SERU过程框架全景图

用虚线将3个主要的阶段划分开，从左边开始数的第一部分是“需求定义”阶段，第二部分是“理清需求框架和脉络”阶段，第三部分是“填充需求细节”阶段。

需求分析工作任务集(20+3)

• 需求定义阶段

核心工作：

1)判断系统的规模，决定是否划分成不同的主题域；

2)若需要，则根据业务特点（可从分管领导找线索）划分主题域；

3)讨论每个主题域的范围，可用上下文关系图表示；

4)针对每个主题域，列出业务事件、报表类型列表。

主要产物：

1)构件图，用来表示主题域之间的关系，通常只有1张；

2)上下文关系图，表示主题域的范围，张数与主题域个数相等；

3)业务事件列表、报表类型列表。

主要访谈对象：中高层用户代表。

重要信息：

1)组织结构图、分管领导，有助于主题域划分；

2. 部门职责说明，有助于主题域间服务接口的标识。

其他提示：

这个阶段所花的时间是比较简短的，不求标识出全部的业务事件和报表类型；重点在于从宏观层面理解业务，标识出最主要的业务事件和报表。

剪裁说明：

1)对于规模较小的系统，不必划分主题域；

2. 对于涉及原系统的项目，可能标识出新主题域和原有主题域。

• 理清需求框架和脉络阶段

核心工作：

1)针对每个业务事件进行流程、业务实体、使用场景分析；

2. 针对每类报表进行业务实体、使用场景分析；
3. 将前面标识出来的所有场景（用例）进行抽象，得到用例模型；
4. 将前面业务实体分析获得的领域模型片段进行合并与抽象。
5. 对设计约束与质量属性进行分析

主要产物：

1)活动图（或数据流图、跨职责流程图），用来表示业务流程；

2. 领域类图片段，表示每个业务流程、报表类型涉及的业务实体；
3. 用例模型片段，表示每个业务流程中的业务活动、具体报表项；
4. 领域模型：按主题域对领域类图片段进行合并与抽象；
5. 用例模型：按主题域对用例模型片段进行合并与抽象；
6. 部署图：用来描述软、硬件环境方面的设计约束。

主要访谈对象：中层用户代表。

上阶段产物应用：

1. 业务事件、报表类型列表作为访谈计划的线索；

2)业务事件、报表类型列表作为需求组织的二级目录。

其他提示：

这个阶段主要是搭框架，不要涉及太深的内容；目标不在于标识所有用例、所有的领域类，而是标识出最重要的部分。另外，在本阶段完成后将 对需求进行基线划分。

• 填充需求细节阶段

核心工作：

1)针对每个用例（B、R、I)类进行捕获、分析；

2. 对流程图上标识的相关文档进行分析，完成领域类的细节填充；
3. 在架构师的支持下，完成技术类用例的描述；

主要产物：

1)业务类用例描述，包括事件流、相关需求、UI原型、规则约束；

2. 报表类用例描述，包括报表概述、报表内容和输入/输出格式；
3. 接口类用例描述，包括使用者概述、内容与格式、实现约束；
4. 领域类描述：包括数据窗口分析、组成与格式、计算规则；

主要访谈对象：操作层（及小部分中层）用户代表。

上阶段产物应用：

1)根据上阶段得出的用例模型，按基线安排调研与细化；

2)根据用例所关联的领域类，安排领域类的分析与细化。

其他提示：

对于技术类用例而言，建议由架构师进行组织，细化的方法可以自 由地确定。另外，如果需求人员时间比较紧张，可以考虑在关键用例细化完成之后，由开发人员接手其他用例的细化工作。

二、需求实践要点概述

• 需求定义勿忽视

需求定义严格来说是项目立项的工作，在进行需求开发时，定义应该已经完成了。但实际上这方面的工作经常存在偏差，因此需要进行补课。补课的内容主要包括两方面：

项目目标：目标决定范围，没有对业务目标进行分析，就难以控制范围；企业级的目标（也就是系统要解决企业什么问题、创设什么机会）有时很难定义，但stakeholder的关注点这一级的目标是十分重要的，必须在项目过程中逐渐整理出来。

项目范围：直接落实在功能模块上是不现实的，即使整理出来也很难达成共识；而采用业务驱动的方法标识范围，说明系统涉及哪些事、哪些人则是更好的项目范围确定方法。

• 需求捕获要科学

需求捕获活动是需求分析的基础，其质量的优劣直接影响到需求开发的最终结果；其科学性主要体现在以下几个方面：

需求捕获是主动行为：需求分析员应该以业务驱动的分解结构作为主线，以需求捕获的主导者的身份展开定向的需求捕获工作。

需求捕获是“剥洋葱”而不是“切洋葱”：捕获时切忌“一刀切到底”，一次访谈就从流程到活动，又从活动到界面、字段细节；而是从宏观到微观，先找到头绪（主题域、业务事件)，后理清框架和脉络（即结构框架的领域模型、行为脉络的用例模型），然后再填充细节。

需求捕获需要科学地组织不同的捕获方法：不同的捕获方法具有不同的优缺点，适用于不同的时机。

• 需求分析要业务

需求分析的核心在于“分解、抽象和消除歧义”，成功的关键在于理解业务领域，因此重心应该放在对业务事件的分析、业务术语的整理上，而不要急于考虑系统的实现。需求分析人员应该把一双脚都从开发团队中迈出来，这样才能：

增加业务人员参与的可能：只有当需求过程是业务驱动的，业务人员才可能更好地参与到需求开发过程中。

更好地理解问题域：这样才能够更好地了解问题、发现问题和解决问题。

• 需求建模要实用

模型的本质是简化现实、简化交流的工具，不要让模型成为交流的障碍。在建模时应该强调：

重在交流：模型是交流工作，不要独立建模，不要刻意追求正式化程度很高的模型，不要刻意增加模型的复杂度。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

和解决问题。

• 需求建模要实用

模型的本质是简化现实、简化交流的工具，不要让模型成为交流的障碍。在建模时应该强调：

重在交流：模型是交流工作，不要独立建模，不要刻意追求正式化程度很高的模型，不要刻意增加模型的复杂度。

[外链图片转存中…(img-WxsUMvO5-1715733012098)]
[外链图片转存中…(img-8fs6GuX0-1715733012098)]
[外链图片转存中…(img-qm95RTdy-1715733012099)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取