[需求管理-10]：功能规范内容与撰写流程
Posted 文火冰糖的硅基工坊
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了[需求管理-10]：功能规范内容与撰写流程相关的知识，希望对你有一定的参考价值。
目录
3.1 组件（子系统级）用户场景 -- 子系统架构师或子系统的需求分析师 - 系统用户场景分解
3.2 组件（子系统级）需求 -- 子系统架构师或子系统的需求分析师
3.3 组件（子系统级）消息接口 -- 子系统架构师或子系统的需求分析师
第1章 需求规格说明书与功能规范的异同
（1）相同点
- “需求规格说明书”与“功能规范”都是用于描述“需求”的。
- “需求规格说明书”与“功能规范”都是描述客户的希望和需求。
（2）不同点
- 范围大小不同：“需求规格说明书”更多的用于描述客户对一个项目、一个产品的的需求规范，而“功能规范”主要用于描述某个功能详细的规范要求。
- 立足点不同：“需求规格说明书”主要是站在用户的角度来阐述需求；“功能规范”站在系统和目标系统的角度看用户对自身有哪些需求。
第2章 功能规范撰写的总体流程
2.1 什么是功能规范撰写的流程
在组织中，功能规范撰写的撰写有自己独立的流程，从启动到撰写再到结束，有一个独立的生命周期管理流程。该流程定义了功能规范的通用流程。它将适合于所有DU（开发单位）和技术领域。
2.2 功能规范撰写流程的职责
功能规范开发或撰写过程包括：
（1）完善和明确功能需求的范围(scope)
（2）分析该功能需求对其他功能需求的影响与交互 (interaction)
（3）分析其他功能需求对自身的影响和依赖关系 (dependency)
（4）对新功能进行全面的分析和拆解 (senario）
（5）把功能需求拆分成逻辑上独立的多个子功能 (split)
（6）对新功能对外的接口全面的分析 （interface）
（7）对外部网元的影响分析
（8）对新功能内部的实现进行详细的分析与定义（design）
功能规范文档记录上述过程的分析结果。
2.3 什么时候启动功能规范CFAM撰写流程？
它与客户业务需求筛选流程紧密相连，当客户业务需求筛选流程决定该业务需求值得实施，指定建议的软件发布版本后，就可以启动“功能规范撰写的流程”。
如下图所示：
2.4 哪些人参与功能规范撰写流程
在大型组织内，功能规范撰写的撰写并不是有一个人来完成的，也不是有一个职能团队来完成的。而是在众多的特定技术领域挑选部分相关的技术专家和技术人员临时组成一个“规范撰写”团队共同完成的 。到底选择哪些技术领域的专家来组件这个临时的团队呢？
这取决于客户业务需求筛选流程，客户业务需求筛选流程已经标识了某一个业务需求对组织内的目标系统的哪些功能技术领域造成影响，基于这些信息，将组建功能规范撰团队。
为了组建功能规范撰写团队，组织内部需要预先把每个受影响技术领域进行分类，得到SFS（System Function Specfic）类别, 每个类别都有一组的技术专家组成。
每个受影响的技术领域，都会派一个或多个代表参加功能规范撰团队，每个代表对属于自身技术领域范围内的功能规范的内容负责，包括定义、合作撰写以及评审。如下图所示：
（1）功能需求的负责人FOT leader：
他负责组织功能规范的撰写（需求）、软件编码实现（开发）、需求的验证测试（测试）。
（2）功能规范撰团队：负责功能规范的撰写和评审
- 功能规范撰的负责人
- 功能规范撰的协作人
- 功能规范撰的评审人
- 功能规范撰的审批人
通常情况下，受影响最大的技术领域承担功能规范撰团队的负责人。
一旦团队组建，就可以着手功能规范的撰写了。
2.5 项目相关文档
- PPT：功能影响点分析、启动会议、检查点总结
- Word：阶段性需求规范的输出
- Pdf：阶段性需求规范的输出
- Excel：性能分析、项目计划
- xml：OAM配置文件（承载配置数据）
- 需求文档管理系统：需求规范文档的存储
- Web Server：需求规范文档的查阅
第3章 功能规范的切分方法
3.1 概述
一个复杂系统的功能规范并不是一蹴而就的，而是需要经过多方、分阶段完成的，这中间可能会经过几个月的时间。为此，可以把功能规范的撰写再进一步细分成几个子流程。几个子流程的划分可以基于功能规范的内容来进行。
3.2 功能规范的切分方法
功能规范的内容内容有几种组织方式：
一种划分方法是按子功能模块来划分，如子功能模块1、子功能模块2、子功能模块3；
另一种按照自顶向下的拆分的过程来划分。这种方法，反应了由粗到细，由浅入深，由外向里的逻辑阶段。
这里我们采用后一种方法：自顶向下的拆分：
先把目标系统分层两大层次：
（1）System级，又称系统级，展现的是目标系统对外呈现的各种纵向的功能。
（2）Entity级，有称为组件级，展现的是目标系统内部的各个横向的功能组件的功能。
在上图中：
（1）在系统层面
- 功能被纵向切分成：子功能1、子功能2、子功能3、子功能4这四个子功能。
- 每个子功能又进一步的被切分成一个个独立的用户场景。
（2）在Entity层面
- 整个系统被水平切分成4个分层组件：如L1/L2/L3/platform
- 不同的纵向切分的用户场景（用户需求），对系统内部的分层组件的影响程度是不同的。有些有影响，有些没有影响。
第4章 功能规范的内容组成
于是，功能规范的内容可以分为如下几个大的章节：
第1章节：定义功能需求的范围
（1）描述功能的范围
（2）确保工程师对功能理解与产品经理的理解保持一致
（3）描述基于用户故事的功能
（4）确定新功能对系统组件的影响（影响意味着指出差异点）
- 对系统系统架构的影响点
- 对现有系统级需求的影响点
- 对现有系统外部接口的影响点
- 对现有系统部署方案的影响点
- 对现有系统性能和容量的影响点
- 对现有系统内部组件的影响点
（5）把用户故事（User story）切分成一个个的子功能
（6）描述与其他功能的依赖关系
（7）描述约束条件和限制条件
（8）描述哪些功能不在这个功能的范围内
（9）描述网络配置信息
用户故事的格式如下：
As a role, I want goal/desire so that benefit
第2章节：定义功能需求的系统级需求（按照逻辑功能划分）
所谓系统级需求，就是把目标系统，如基站，路由器等作为研究的对象，对其呈现出来的外部行为以及与其他网元的交互，按照其逻辑功能进行定义和规范。并把切分的子功能映射到不同的组件级的组件上。
我们从两个维度来阐述系统级需求：
2.1 系统级用户场景 -- 系统级架构师或系统级需求分析师
用户场景是指用户在不同时间、地点、环境下引发的不同情形、行为或需求，其实就是指用户在某个环境中会触发并完成某个任务。
（1）用户场景分析的四要素
用户：产品的目标用户群体越垂直、越精准越好。
时间：用户可能会使用产品的时间。
地点：用户可能会使用产品的地点。
任务：用户会使用产品来达成什么目的，需要哪些步骤的操作。
（2）每一个用户场景，都是一个可测试的验收标准。
（3）存在3种类型的业务场景
- 基本（功能的正常操作）
- 错误/异常（返回异常或错误信息，对于复杂的功能，需要进行“设计失效模式影响分析”）
- 与其他功能交互：依赖关系和交互关系（相对于前种场景，这种场景是比较复杂的）
（4）描述用户场景的手段和方法
- 架构化的用例表格
- 流程图（主要用于描述操作步骤，而不在于描述与外部的交互）
- 消息序列图（最有效、最常用的方式，描述多个节点之间的交互）
- 基于UML的用例图、活动图或序列图
- 其他有效的图形表示
- 纯文本描述（不直观）
（5）用户场景（User Case）的主要内容
- 描述性标题
- 用户场景的目标描述
- 用户场景类型（即基本、错误/或功能交互）
- 负责触发用户场景的参与者：
- 前提条件描述：
-- 触发用户场景之前系统的状态
-- 触发用户场景必须满足的条件列表
- 操作流程
-- 用户场景的触发条件
-- 触发后的一系列的动作顺序（可以通过纯文本或消息时序图描述）
--由给定动作触发的与参与者的响应交互，
--异常处理流程与转换条件
- 后置条件描述：
-- 完成用户场景流后系统的状态。
2.2 系统级详细需求 -- 系统级架构师或系统级需求分析师
系统级详细需求是在系统级用户场景的基础之上，针对每个业务场景，每个技术领域的技术专家各自定义属于本技术领域的系统级详细的需求。
系统级详细需求可以单独标记的系统级详细需求，这种需求，并非以业务场景的方式存在，而是以“要求”的方式存在。比如“支持xxxx算法”， “支持xxx功能”等。
系统级详细需求，也都是一个可测试的验收标准。
（1）功能需求
- 静态需求或动态需求
- 消息流或算法规范
（2）非功能性需求
- 性能指标
- 容量指标
- 可靠性指标
- 响应时间指标
- 等等
（3）OAM网管参数
- 大量的新功能都需要通过网管来配置参数，以增加其灵活性。
- 除了配置参数，还有告警、计数、状态指示等
2.3 对外消息接口 -- 系统级架构师或系统级需求分析师
- 对外的消息消息定义与内容（如RRC消息等....）
第3章节：定义功能需求的组件级的需求（按照物理分层划分）
系统级需求是把目标系统作为操作对象，并在此基础之上，先定义出用户场景，然后基于用户场景定义功能性需要和非功能性需求。
组件级需求是把系统内部物理架构的功能组件作为子系统，作为操作对象，并在先定义出子系统的用户场景，然后基于子系统的用户场景定义子系统的功能性需要和非功能性需求。
为了更好的有效的管理整个系统，一个大型复杂的系统通常会被分割成多个不同功能的子系统或多个不同层次的子系统 。每个子系统有各自不同的需求工程师和软件研发人员以及各自的技术专家。在大型系统中，系统级工程师和子系统级工程师被严格的精细化分工。
除了子系统（组件）级与系统级在层次上不同之外，子系统对需要的定义与系统级需求的定义方式是类似的，也采用了三个方面来描述子系统的需要，也称为entity level的需求。
在这里就有一个问题：
各个子系统如何知道系统级用户场景和系统级需求对自己的子系统是有影响的？
这就需要有这么一个角色，能够识别出每个系统级的用户场景和系统级需求对不同子系统是否有影响，至于影响多大，由各个子系统的专家自己去分析。
承担这个角色的人由三种类型：
（1）系统工程师，他们熟悉每个子系统的外部行为
（2）系统架构师，他们熟悉每个子系统的外部行为
（3）子系统架构师组合：他们熟悉各自子系统的内部行为，他们组合在一起，共同讨论，各自识别系统级需要对子系统的影响。
如下所示：
3.1 组件（子系统级）用户场景 -- 子系统架构师或子系统的需求分析师 - 系统用户场景分解
同系统级用户场景，差别仅仅在于
（1）针对的是子系统（组件）。
（2）每个子系统都有自己独立的用户场景。
3.2 组件（子系统级）需求 -- 子系统架构师或子系统的需求分析师
（1）针对的是子系统（组件）。
（2）每个子系统都有自己独立的需求。
（3）基于子系统的用户场景的进一步分解。
3.3 组件（子系统级）消息接口 -- 子系统架构师或子系统的需求分析师
（1）针对的是子系统（组件）。
（2）每个子系统都有自己独立的接口，接口的定义以消息的接收方定义。
（3）基于子系统的用户场景的进一步分解。
第5章 流程检查点
5.1 需求文档的层次与检查点的对应关系
（1）检查点1：CP1
- 第1章节 功能范围
- 第2.1章节 系统级用户场景
（2）检查点2：CP2
- 第2.2章节 系统级用户需求（功能和非功能性需求） -- 源于系统级用户场景
（3）检查点3：CP3
- 第3.1 章节 Entity级用户场景 -- 源于系统级用户场景
- 第3.2 章节 Entity级功能需要（功能和非功能性需求）-- 源于系统级用户需求
（4）检查点4：CP4
- 第4章节 Entity级模块概要设计（HLD）
- 第5章节 Entity级模块详细设计 （LLD） =》 流程图、算法
5.2 逐步切分过程
5.3 开发流程与质量保证
（0）启动前的准备工作
- 功能影响点分析
- 分配相关人力资源
- 指定负责人
- 准备启动前的材料
（1）功能规范撰写活动的启动
- 功能范围概述
- 前序依赖文档
- 团队成员 （系统架构师、系统工程师、软件架构师、测试架构师）
- 目标发布版本
（2）定义功能范围 - 第1章节
- 见第1章节
（3）定义系统级用户场景与系统级异常分析 -- 第2.1章节
- 见第2.1章节
（4）检查点1 (Definition of Done)
- 团队是否已就功能的范围、限制、对其他功能的依赖性、用户案例、子功能、架构上重要的需求和系统级用户场景已经达成共识。
- 是否召开检查点1的评审会议
- 有什么严重的问题没有得到解决？
- 是否召开并记录了系统级异常处理分析与设计会议？
- 是否有文件检查点1的申明
（5）分析和定义系统级详细需求 -- 第2.2章节
- 第2.2章节
（6）检查点2
- 团队验证是否已就功能的系统级用户场景和详细需求达成共识？
- 是否安排的正式的需求文档评审会议？
- 是否对所有意见进行评估并最终决定是否接受？
- 评审参与人员是否充分？
- 评审后的文档是否正确及时更新，以反映评审的结果？
- 审查协议可用吗？
-
是否已决定进行架构和设计审查？
（7）分析和定义Entity级用户场景分解和Entity级测试验收标准 - 第3.1章节
（8）分析和定义Entity级需求 -- 第3.2章节
（9）检查点3
- 任务完成状态
- 相关人员的评审意见得到了解决 （系统工程师、软件架构师、测试架构师、开发工程师）
- 没有属于本阶段悬而未绝的问题
（10）概要设计 - 第4章节
（11）详细设计 - 第5章节
（12）检查点4
- 任务完成状态
- 相关人员的评审意见得到了解决 （软件架构师、测试架构师、开发工程师、测试工程师）
- 没有属于本阶段悬而未绝的问题
以上是关于[需求管理-10]：功能规范内容与撰写流程的主要内容，如果未能解决你的问题，请参考以下文章