优亿链收录网_自动秒收录外链

一份汽车软件需求的生成过程


文章编号:770 / 更新时间:2024-03-12 12:26:54 / 浏览:

一份汽车软件需求的生成过程

一份汽车软件需求的生成过程

尽管ASPICE并不是绝对的标准,但我们可以作为讨论框架。今天讲的是软件需求

生成软件需求的4个步骤

抛开理论,面对一个真实项目时,首先该思考的是如何一步一步展开工作。

1.1?分析系统需求和系统架构中与软件相关的部分

软件需求并非凭空而创,它的源头是系统,我们在这步要做的就是将软件的部分剥离出来。

这是一个看文档、分析、沟通、讨论的过程。

1.2编写软件需求

经过一番脑力与paper工作后,我们会得到一份软件需求,按详略程度,可能是针对完整集成软件的,也有针对具体实现层面的软件组件的。

1.3建立基线

走完第二步,不能算完。

软件需求是后续一系列工作的基础,我们得定个基准,也就是基线或baseline。

在Doors之类的工具里的话,基线是通过系统直接建立的。如果使用office,至少要有个版本管理。

1.4对基线进行review

review也是必要的,毕竟这份文档涉众多,还是后续的源头。

如果review发现了问题,修改后应再次打基线。至此,一份软件需求文档正式生成。

下面我们看里面的一些细节。

一份软件需求的4个基本属性

我们经常喜欢用word来写需求。

word的段落式描述和多级标题会带来较好的顺序阅读体验,但非条目化和无属性拆分,这会让后续的筛选、追溯、修改、统计、查阅多有不便。

所以,尤其我们有需求管理工具支持时,最好拆分多个属性,这里提供4个最基本的。

我们把整本需求拆分为很多条后,会知道有些条不是需求,或者是不同类型的需求,大体可分为如下类型:

标题:这基本就等同于word里的各级标题,这是基本要求,不用多解释。

用例:用例也是需求,但它作为承接系统需求和架构(如MBSE里的UseCase图)的环节,会写得不很“技术”、写得很“故事”,也就是外行和领导都能看得懂的,而这对于交流很必要。

功能需求:功能需求是最名正言顺的需求,描述了由某个软件组件实现的功能,并且从软件外部看,它是可观察的或可测试的。

功能需求经常会写得与更高一层级的需求、设计重复,这时,就需要我们做好裁剪。

组件需求:进一步的架构设计和开发,可能需要更细化的需求,即软件组件需求。

当然,架构设计与决策也伴随着组件的划分和需求的分配,这与组件需求是相互依托的。

非功能需求:提到非功能需求,我们最容易联想到性能需求,但不仅仅于此。整体来看,非功能需求可分为两大部分:质量特性和结构性需求。

质量特性基本可以参考ISO/IEC25010里质量模型的划分,如图。

结构性需求可以理解为架构催生的,比如,接口需求。

定义:可用来对一些专业名词进行说明、澄清。

备注:一些提示或解释,主要为了增加可读性。

需求是动态变化的,所以其状态会迁转。

Reviewed(已评审):需求已经完成评审,可以进行问题处理和决策了。

Approved(已批准):需求已经完成批准,准备好导入执行了。

Implemented(已执行):需求已经执行,软件组件已释放。

Rejected(被拒绝):需求暂不计划执行,或者技术上不可行。

2.3验证标准

写需求时就考虑验证,这是V模型的一个显著特点。

需求工程师经常不愿意写这一部分,一者总觉得不好写,二者觉得是测试的活儿。

我们分别看这两个抱怨。

实际上,感觉验证标准不好写恰好反映了这部分工作的必要性。当你觉得很难简单描述清楚怎么去验证,这条需求就应该被返工,比如,重新描述、拆分、合并等。

那么,这是测试的活儿吗?也不合适,很显然,测试用例要比验证标准复杂得多。这里主要为了让需求工程师保证需求是可测的。

此外,也应提示验证阶段和方法。比如,单元测试、组件测试、需求测试、集成测试、评审。

汽车有很多改款配置,软件也有很多分支。配置组合背后往往伴随着软件需求的复用关系。

于是,编写软件需求时,复用及配置工作很是必要。

我们可以增加配置属性来共用一版需求,而配置可以是车型项目,也可以是硬件配置。

然后,在有某条需求的配置处标记yes,或者可标定或软件参数化的部分也可标记具体参数值。

以上描述了一些基础的软件需求属性示例,可做参考。但我们实际项目中,可以根据需要增加很多其他的类别。

一份好软件需求的特点

需求是自然语言描述的,这让我们很难量化评价其好坏,且提供几个特性做参考:

可验证性

不含糊性

可理解性

可修改性

为了尽量实现这些特性目标,我们可以尝试按照如下的“公式”来书写。

即“在什么前提条件(逻辑条件或事件发生或时间段)下,什么系统(或组件)必须(或应该或将会,英文中常分别用具备法律强制意义的shall、可以有争论空间的should及一般性描述的will来对应)能够(或通过什么流程)实现什么目标以及其他细节”。

这会反映出前提、主体、强制性、方式及目标这些基本信息。

软件需求的评审

第一小节的最后一个步骤是评审,这里做一个扩充。

评审是我们解决个体能力不足的几乎唯一的手段,其主要涉及两部分:谁来评审和如何评审

5.1?谁来评审

软件开发是个团队合作的过程,而需求更是几乎所有人都要关注的,我们要让团队来评审(角色定义可参考《汽车电子软件组织的“角色”大起底》)。

具体来看,不同角色要有不同的评审侧重点:

FeatureOwner:确保软件需求满足更高层级的系统需求和系统架构设计。

软件架构:确保需求范围正确,满足内部guideline(对需求质量的定义),并遵循产品roadmap

软件开发:确保需求是可理解的,并且可以被组件实现

软件测试:关注需求的可理解性和可测试性。

5.2如何评审

评审范围可以是全部内容,也可以是增量或变更评审。如果选择增量或变更评审,要注意检查它们对软件需求及下游架构其余部分的影响

进一步地,我们给出一些checklist供参考。

是否遵循以下书写需求的规则

必须清楚地确定主体;

每个需求都是“原子”级别的;

每项需求都应说得明确不含糊;

尽可能定量地表述需求;

描述系统在所有条件(如初始化、休眠、断电、正常运行、过压、欠压等)下的行为;

避免冗余和琐碎;

使用一致的术语;

在适当的地方使用非语言描述,如流程图。

不同的软件需求之间没有矛盾,以及与高层级需求与设计之间没有矛盾?

软件需求是否能够覆盖及满足所追溯的需求与设计?

是否都使用内部标准术语

实现这些需求是否有任何风险

需求是否有机会调整为复用现有设计

时间相关事件的时间要求及公差是否定义?

是否描述了不同硬件之间存在的差异?

验证标准和验证方法是否明确?

是否有必要的需求属性被遗漏?

全文小结

生成需求的4个步骤(分析、编写、打基线、评审)。

需求所包含的4个基本属性(类型、状态、验证标准、配置)。

一份好需求的8个特点(完整性、可行性、可验证性、不含糊性、一致性、正确性、可理解性、可修改性)。

写好需求的公式(前提、主体、强制性、方式及目标)。

需求评审的4个角色及评审侧重点。

需求评审的9条checklist。

写在最后

从很多经验看下来,一个做得烂的项目基本都有一套混乱的需求。当想要治理项目时,几乎都应该从需求开始。

原文标题:一份汽车软件需求的生成过程

众泰汽车被经销商实名举报骗取新能源补贴

又一款不冒烟不起火不爆炸的电池来了!

FF将通过并购在纳斯达克上市,贾跃亭洗去“污名”?

吉利蔚来们会是汽车芯片赛道的黑马吗?

燃油车终结者:比亚迪超级混动,续航突破1200公里

新特汽车新车上线官网,新品AEVs首露真容

大众收购国轩高科已获批?将成控股股东

7.8万充电桩投资背后,还带动了什么

SAP宁德时代能源数字化解决方案白皮书下载

2019年新能源汽车行业展望与挑战

2018年OFweek新能源汽车行业年终盘点

OFweek(第二届)中国人工智能产业大会智能汽车论坛


相关标签: 汽车软件

本文地址:https://www.uel.cc/article/c5f842cbebb4327405a3.html

上一篇:垃圾渗滤液处理节能增效技术措施探讨...
下一篇:为什么选择激光穿孔技术?...

发表评论

温馨提示

做上本站友情链接,在您站上点击一次,即可自动收录并自动排在本站第一位!
<a href="https://www.uel.cc/" target="_blank">优亿链收录网_自动秒收录外链</a>