一、軟件架構如何能夠滿足ASPICE流程

架構的用途是把整個產品劃分為更為細節的板塊：軟件、硬件、通信等。在這個基礎上軟件整體將按照用途、功能等細分下去。軟件模塊的細分程度是盡可能把相互依賴的部分放置在一個模塊中，模塊與模塊間只有前后執行順序、調度優先級等比較獨立的關系。建立一個外部流動變量較少，相互依存影響較輕、可替換性適當的劃分。一方面，這樣劃分得到的模塊后續其他項目的復用價值最大，另一方面，將不同模塊交給不同工程師進行開發中相互扯皮的情況也將減少。

在這個基礎上，可以進行模塊調度和接口的測試，因為這些測試不依賴與模塊功能是否實現。硬件底層驅動、通信等的測試也需要在這個階段進行，已保證整個系統的基底是有效而完整的。

同時由于軟件模塊已經實現了劃分，不同模塊的職責已經明確，可以十分明確地系統需求分撥到各個模塊上。

這里需要關注的是什么是軟件需求，比如說我們現在有一個電控液壓剎車（后續參數全部瞎編的，千萬別較真），那么假定整車重量空載為1.4噸，滿載1.6噸，要求在干燥的水泥路面上80車速以下全剎車實現5秒內剎停，最大剎車距離不超過100米。選定液壓剎車系統為某某品牌某某型號，提供最大200Mpa液壓剎車力，延遲1s，工作電壓350V，工作電流1.5a等（再次說明，我對剎車一點都不懂，以上都是瞎扯淡的數據，很可能還各種錯誤）。

延伸閱讀：

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

名列前茅種是產品必須具備的性能、功能的實現可行性，已有移植、市場采購、自行開發，都可以。但是需要考慮最終實現這些需要多少時間、成本、占用的人力物力。

第二種是產品期望實現的需求，則在名列前茅種情況的基礎上，需要篩選出可行性和成本能接收的需求與客戶進行討價還價。

名列前茅種情況更多的是在于這個項目我們到底做不做、有沒有能力接下來，第二種情況更多是在于后續合同中我們該要多少錢，做這個項目是否劃得來。

也就是說客戶需求那里溝通到一定程度后，進行的刪減（比如說有些功能不能實現，有些功能需要更改指標，有些功能需要加錢等）后，這個才能算項目開展的系統需求。