编者按：
1）本文首先发表于知乎，文章地址为：https://zhuanlan.zhihu.com/p/517184422?utm_source=wechat_timeline&utm_medium=social&utm_oi=728115212745449472&utm_campaign=shareopn
2）本文结合示例，论述了处于不同层次需求的关系，这个关系正是困扰了很多项目工程师的问题，很有借鉴意义。
流程体系的部署总有许多地方需要平衡，以团队管理为例，如果在5-6人的团队中进行分层管理，不单无益于提升效率反而会增加内耗；相似的，在需求管理的场景，如果只有5-6页由同一个人维护的需求，为了分层而拆分成两篇文档分开维护，也会带来不必要的浪费。即便在行业标准的aspice中定义的分层，在实际的项目落地也是有一定的灵活性的。
以下是aspice v3.1标准中对于“双向可追溯性和一致性”的图例，从sys.1的利益相关方需求（stakeholder requirements）到sys.2的系统需求（system requirements），然后从sys.2的系统需求（system requirements）再到swe.1的软件需求（software requirements），是一个自上而下的关系。
来自aspice3.1标准
然而在现实的项目中，来自客户的需求很可能是包含了具体的技术细节甚至参数定义逻辑判定的内容，这时如果为了满足流程，在系统需求和软件需求重复的拷贝相同的内容就变得毫无意义了。更务实的做法是应当直接把客户需求直接链接到软件需求，而为了确保追溯性的全覆盖再把下游的细化软件需求链接到上游更概要的系统需求中。
相对于纯理论的介绍放在实际的场景中进行分析会更加容易理解，这里就以aeb（主动刹车）功能为例看看需求的分层。
样例参考链接：自动驾驶的石头：自动驾驶时代的aeb(主动刹车)系统（https://zhuanlan.zhihu.com/p/392547080）
在以上的例子里，客户需求、系统需求、软件需求这三者是满足自上而下的清晰脉络的，可以进行直接关联。而当客户需求本身已经包含了技术细节时，情况可能会有所不同，可以看看如下场景。
这里“客户需求2”里，对预填充（prefill）的激活条件已经细化到了软件层面的具体实现，并且给出了变量名和阈值，可以直接作为软件需求的条目使用，因而可以直接链接到“软件需求2”，甚至直接拷贝就能使用作为下游的详细设计输入。而此处，如果单纯地直接从sys.1链接到swe.1会导致sys.2的追溯缺失，为了确保需求的追溯性，“软件需求2”可以链接到“系统需求2”包含了预填充（prefill）这一内容概要介绍的需求条目中，而“系统需求2”又可以链接到“客户需求1”中客户对整体aeb功能的要求概述里。以上例子画图表示便是：
因此，为满足产品功能，实现100%功能覆盖的追溯性是不可妥协的，而实现手段上需要考虑现实情况，需求文档的体量很小如前面说的只有5-6页由同一个人维护的需求文档，其中系统需求和软件需求完全可以在同一篇文档里维护，不过放在不同的章节里罢了，并借助需求管理工具可以将其中的wi（work item工作项）进行链接追溯。
下面列举sys.2-系统需求分析和swe.1-软件需求分析这两个过程域的输出工作产品，可见两者是高度重合的，唯一的区别只在“17-12系统需求规范”与“17-11 软件需求规范”这一项上。因此，在实际项目人员紧缺的情况下，这两个过程域的工作产品输出可以在一定程度上重合，但需要分清界限：
涉及“17-12 系统需求规范”的内容归属系统
涉及“17-11 软件需求规范”的内容归属软件
这对于后续界定验证职责、问题根因分析至关重要。
至于这两类的需求，前面举了aeb的例子管中窥豹，如下给出aspice中【工作产品特性】附录表中对两者的描述给出参考。
这样的分类在实际的落地中根据实际情况会有不同考量，如需求的粒度、非功能需求的完备性、具体的分工等等，需要实践的积累才能日渐成熟。如果实在弄不清的话，只要记住——涉及软件实现细节的归属软件需求，否则归属系统需求，系统需要适度控制对软件细节的控制欲，扮演好产品经理的角色以满足客户需求为第一要务。
本文转载自网络,ag真人官方网的版权归原作者所有,如侵犯您的权益请联系wyl860211@qq.com,我们将第一时间删除。