一、软件架构如何能够满足ASPICE流程

架构的用途是把整个产品划分为更为细节的板块：软件、硬件、通信等。在这个基础上软件整体将按照用途、功能等细分下去。软件模块的细分程度是尽可能把相互依赖的部分放置在一个模块中，模块与模块间只有前后执行顺序、调度优先级等比较独立的关系。建立一个外部流动变量较少，相互依存影响较轻、可替换性适当的划分。一方面，这样划分得到的模块后续其他项目的复用价值最大，另一方面，将不同模块交给不同工程师进行开发中相互扯皮的情况也将减少。

在这个基础上，可以进行模块调度和接口的测试，因为这些测试不依赖与模块功能是否实现。硬件底层驱动、通信等的测试也需要在这个阶段进行，已保证整个系统的基底是有效而完整的。

同时由于软件模块已经实现了划分，不同模块的职责已经明确，可以十分明确地系统需求分拨到各个模块上。

这里需要关注的是什么是软件需求，比如说我们现在有一个电控液压刹车（后续参数全部瞎编的，千万别较真），那么假定整车重量空载为1.4吨，满载1.6吨，要求在干燥的水泥路面上80车速以下全刹车实现5秒内刹停，最大刹车距离不超过100米。选定液压刹车系统为某某品牌某某型号，提供最大200Mpa液压刹车力，延迟1s，工作电压350V，工作电流1.5a等（再次说明，我对刹车一点都不懂，以上都是瞎扯淡的数据，很可能还各种错误）。

延伸阅读：

二、系统需求的可行性和成本估算

名列前茅种是产品必须具备的性能、功能的实现可行性，已有移植、市场采购、自行开发，都可以。但是需要考虑最终实现这些需要多少时间、成本、占用的人力物力。

第二种是产品期望实现的需求，则在名列前茅种情况的基础上，需要筛选出可行性和成本能接收的需求与客户进行讨价还价。

名列前茅种情况更多的是在于这个项目我们到底做不做、有没有能力接下来，第二种情况更多是在于后续合同中我们该要多少钱，做这个项目是否划得来。

也就是说客户需求那里沟通到一定程度后，进行的删减（比如说有些功能不能实现，有些功能需要更改指标，有些功能需要加钱等）后，这个才能算项目开展的系统需求。