这是来源于ASPICE 3.1的一张追溯图，非常流行。尽管ASPICE并不是绝对的标准，但我们可以作为讨论框架。今天讲的是软件需求。
一、生成软件需求的4个步骤
抛开理论，面对一个真实项目时，首先该思考的是如何一步一步展开工作。
1.1 分析系统需求和系统架构中与软件相关的部分
软件需求并非凭空而创，它的源头是系统，我们在这步要做的就是将软件的部分剥离出来。这是一个看文档、分析、沟通、讨论的过程。
1.2 编写软件需求
经过一番脑力与paper工作后，我们会得到一份软件需求，按详略程度，可能是针对完整集成软件的，也有针对具体实现层面的软件组件的。
1.3 建立基线
走完第二步，不能算完。软件需求是后续一系列工作的基础，我们得定个基准，也就是基线或baseline。
在PingCode、Doors之类的工具里的话，基线是通过系统直接建立的。如果使用office，至少要有个版本管理。
1.4 对基线进行review
review也是必要的，毕竟这份文档涉众多，还是后续的源头。如果review发现了问题，修改后应再次打基线。至此，一份软件需求文档正式生成。下面我们看里面的一些细节。
二、一份软件需求的4个基本属性
我们经常喜欢用word来写需求。
word的段落式描述和多级标题会带来较好的顺序阅读体验，但非条目化和无属性拆分，这会让后续的筛选、追溯、修改、统计、查阅多有不便。
所以，尤其我们有需求管理工具支持时，最好拆分多个属性，下面将提供4个最基本的，在PingCode（点击可跳转）这类工具中，你可以自定义需要的属性。
2.1 类型
我们把整本需求拆分为很多条后，会知道有些条不是需求，或者是不同类型的需求，大体可分为如下类型：
标题：这基本就等同于word里的各级标题，这是基本要求，不用多解释。
用例：用例也是需求，但它作为承接系统需求和架构（如MBSE里的Use Case图）的环节，会写得不很“技术”、写得很“故事”，也就是外行和领导都能看得懂的，而这对于交流很必要。
比如，用户输入账号密码登录，如通过验证，系统进入主页，否则，提示错误。
功能需求：功能需求是最名正言顺的需求，描述了由某个软件组件实现的功能，并且从软件外部看，它是可观察的或可测试的。
功能需求经常会写得与更高一层级的需求、设计重复，这时，就需要我们做好裁剪。
组件需求：进一步的架构设计和开发，可能需要更细化的需求，即软件组件需求。
当然，架构设计与决策也伴随着组件的划分和需求的分配，这与组件需求是相互依托的。
非功能需求：提到非功能需求，我们最容易联想到性能需求，但不仅仅于此。整体来看，非功能需求可分为两大部分：质量特性和结构性需求。
质量特性基本可以参考ISO/IEC 25010里质量模型的划分，如图。
结构性需求可以理解为架构催生的，比如，接口需求。
定义：可用来对一些专业名词进行说明、澄清。
备注：一些提示或解释，主要为了增加可读性。
2.2 状态
需求是动态变化的，所以其状态会迁转。
- Proposed（被提议）：需求已被编辑完成，可以进行review了。
- Reviewed（已评审）：需求已经完成评审，可以进行问题处理和决策了。
- Approved（已批准）：需求已经完成批准，准备好导入执行了。
- Implemented（已执行）：需求已经执行，软件组件已释放。
- Rejected（被拒绝）：需求暂不计划执行，或者技术上不可行。
2.3 验证标准
写需求时就考虑验证，这是V模型的一个显著特点。
需求工程师经常不愿意写这一部分，一者总觉得不好写，二者觉得是测试的活儿。
我们分别看这两个抱怨。
实际上，感觉验证标准不好写恰好反映了这部分工作的必要性。当你觉得很难简单描述清楚怎么去验证，这条需求就应该被返工，比如，重新描述、拆分、合并等。
那么，这是测试的活儿吗？也不合适，很显然，测试用例要比验证标准复杂得多。这里主要为了让需求工程师保证需求是可测的。
此外，也应提示验证阶段和方法。比如，单元测试、组件测试、需求测试、集成测试、评审。
2.4 配置
汽车有很多改款配置，软件也有很多分支。配置组合背后往往伴随着软件需求的复用关系。
于是，编写软件需求时，复用及配置工作很是必要。
我们可以增加配置属性来共用一版需求，而配置可以是车型项目，也可以是硬件配置。
然后，在有某条需求的配置处标记yes，或者可标定或软件参数化的部分也可标记具体参数值。
以上描述了一些基础的软件需求属性示例，可做参考。但我们实际项目中，可以根据需要增加很多其他的类别。
三、一份好软件需求的特点
需求是自然语言描述的，这让我们很难量化评价其好坏，且提供几个特性做参考：
- 完整性
- 可行性
- 可验证性
- 不含糊性
- 一致性
- 正确性
- 可理解性
- 可修改性
为了尽量实现这些特性目标，我们可以尝试按照如下的“公式”来书写。
即“在什么前提条件（逻辑条件或事件发生或时间段）下，什么系统（或组件）必须（或应该或将会，英文中常分别用具备法律强制意义的shall、可以有争论空间的should及一般性描述的will来对应）能够（或通过什么流程）实现什么目标以及其他细节”。这会反映出前提、主体、强制性、方式及目标这些基本信息。
四、软件需求的评审
第一小节的最后一个步骤是评审，这里做一个扩充。评审是我们解决个体能力不足的几乎唯一的手段，其主要涉及两部分：谁来评审和如何评审。
5.1 谁来评审
软件开发是个团队合作的过程，而需求更是几乎所有人都要关注的，我们要让团队来评审（角色定义可参考《汽车电子软件组织的“角色”大起底》）。具体来看，不同角色要有不同的评审侧重点:
- Feature Owner：确保软件需求满足更高层级的系统需求和系统架构设计。
- 软件架构：确保需求范围正确，满足内部guideline（对需求质量的定义），并遵循产品roadmap。
- 软件开发：确保需求是可理解的，并且可以被组件实现。
- 软件测试：关注需求的可理解性和可测试性。
5.2 如何评审
评审范围可以是全部内容，也可以是增量或变更评审。如果选择增量或变更评审，要注意检查它们对软件需求及下游架构其余部分的影响。
进一步地，我们给出一些checklist供参考。
1.是否遵循以下书写需求的规则：
- 必须清楚地确定主体；
- 每个需求都是“原子”级别的；
- 每项需求都应说得明确不含糊；
- 尽可能定量地表述需求；
- 描述系统在所有条件（如初始化、休眠、断电、正常运行、过压、欠压等）下的行为；
- 避免冗余和琐碎；
- 使用一致的术语；
2.在适当的地方使用非语言描述，如流程图。
3.不同的软件需求之间没有矛盾，以及与高层级需求与设计之间没有矛盾？
4.软件需求是否能够覆盖及满足所追溯的需求与设计？
5.是否都使用内部标准术语？
6.需求是否有机会调整为复用现有设计？
7.实现这些需求是否有任何风险？
8.时间相关事件的时间要求及公差是否定义？
9.是否描述了不同硬件之间存在的差异？
10.验证标准和验证方法是否明确？
11.是否有必要的需求属性被遗漏？
小 结
本文从以下几个方面进行了简要解读：
- 生成需求的4个步骤（分析、编写、打基线、评审）。
- 需求所包含的4个基本属性（类型、状态、验证标准、配置）。
- 一份好需求的8个特点（完整性、可行性、可验证性、不含糊性、一致性、正确性、可理解性、可修改性）。
- 写好需求的公式（前提、主体、强制性、方式及目标）。
- 需求评审的4个角色及评审侧重点。
- 需求评审的9条checklist。
从很多经验看下来，一个做得烂的项目基本都有一套混乱的需求。当想要治理项目时，几乎都应该从需求开始。
文章授权转载自公众号：水轻言
