這(zhè)是(shì)來(lái)源于ASPICE 3.1的(deα£∑)一(yī)張追溯圖，非常流行(xíng)。

盡管ASPICE并不(bù)是(shì)絕對(↔"↔duì)的(de)标準，但(dàn)我們可(kě)以作(zuò)為(wèi)討(tǎo)論框架。今天講的(de)是(shì)軟件(jiàn)需求。

1

生(shēng)成軟件(jiàn)需求的(de)4個(gè)步驟

抛開(kāi)理(lǐ)論，面對(duì)一(yī)個(gè)真實項目時(shí)，首先該思考的£±(de)是(shì)如(rú)何一(yī)步一(yī)步展開(kāi)工(gōng'$♥♥)作(zuò)。

1.1 分(fēn)析系統需求和(hé)系統架構中與軟件(jiàn)相(xiàng)關的‌ε(de)部分(fēn)

軟件(jiàn)需求并非憑空(kōng)而₽₹♣"創，它的(de)源頭是(shì)系統，我們在這(zhè)步要(→¥ yào)做(zuò)的(de)就(jiù≤★↕)是(shì)将軟件(jiàn)的(de)部分(fēn)剝離(lí)出來(lái)。

這(zhè)是(shì)一(yī)個(gè)看(kàn)文(wén)檔、分"Ω☆(fēn)析、溝通(tōng)、討(tǎo)論的(de) §過程。

1.2 編寫軟件(jiàn)需求

經過一(yī)番腦(nǎo)力與pape ™>r工(gōng)作(zuò)後，我們會(huì)得(de)到(dàσ☆✘✔o)一(yī)份軟件(jiàn)需求，按詳略程度，可(kě)能(néng)是(shì)針對(d¥∑>↓uì)完整集成軟件(jiàn)的(de)，也(yě)有(yǒu)針對(d÷ε uì)具體(tǐ)實現(xiàn)層面的(de)軟件(jiàn)組件(jiàn)的(de)。

1.3 建立基線

走完第二步，不(bù)能(néng)算(suàφ ∑☆n)完。

軟件(jiàn)需求是(shì)後續一(yī)系列工(gōng)作(zuò)的(de)基礎≥÷÷λ，我們得(de)定個(gè)基準，也(yě)就(jiù)是(shì)基線或baseline。

在Doors之類的(de)工(gōng)具裡(lǐ)的£ ∏(de)話(huà)，基線是(shì)通(tōng)過系統直接建立的(de)。如(rφ ú)果使用(yòng)office，至少(shǎo)要(yào)有(yǒ♦₽>u)個(gè)版本管理(lǐ)。

1.4 對(duì)基線進行(xíng)review

review也(yě)是(shì)必要(yào)的(de)，畢竟這(zhè)份文("↑wén)檔涉衆多(duō)，還(hái)是(shì)後續的(de)源頭。

如(rú)果review發現(xiàn)了(le)問(wèn)題，修改後應再次打基™&線。至此，一(yī)份軟件(jiàn)需求文(wén)檔正式生(shēng)γπ成。

下(xià)面我們看(kàn)裡(lǐ)面的(de)一(yī)些(xδ₽iē)細節。

2

一(yī)份軟件(jiàn)需求的(de)4個¶β(gè)基本屬性

我們經常喜歡用(yòng)word來(lái)寫需求。

word的(de)段落式描述和(hé)多(duō)級标™₽♠£題會(huì)帶來(lái)較好(hǎo)的(de)順序閱讀(dú)體(tǐ)驗，但(dàn)非條目化(huà)和(hé)無屬性拆分(fēn)，這(zhè)會(huì)讓後續的(de)篩選、追溯、修改、統計(jì)、查閱多(duō)有(yǒu)不(bù)便。

所以，尤其我們有(yǒu)需求管理(lǐ)工(gōng)具支持時(shí)，最÷δ好(hǎo)拆分(fēn)多(duō)個(gè)屬性，這(zhè)裡≤δ≠(lǐ)提供4個(gè)最基本的(de)。

2.1 類型

我們把整本需求拆分(fēn)為(wèi)很(hěn)多(‍φduō)條後，會(huì)知(zhī)道(dà≠→  o)有(yǒu)些(xiē)條不(bù)是(shì)需求，或者是(s&←↓hì)不(bù)同類型的(de)需求，大(dà)體(tǐ)可(kě)分(fēn)為(wèi)£≤₽ε如(rú)下(xià)類型：

• 标題：這(zhè)基本就(jiù)等同于word裡(lǐ)的(de)各級标題，這(zhè)是(shì)基本要(yào)求，不(bù)用(yòng)多(du↕™ō)解釋。

• 用(yòng)例：用(yòng)例也(yě)是(shì)需求，但(dàn)它作(zuò)為(wèi)承λ™φ接系統需求和(hé)架構（如(rú)MBSE€→裡(lǐ)的(de)Use Case圖）的(de)環節，會(huì)寫得(¶ §↔de)不(bù)很(hěn)“技(jì)術(shù)”βε₹♥、寫得(de)很(hěn)“故事(shì)”，也(yě)就(jiù)是(shì)外(wài)行(xíng)和(hé)領導都(dōu♦÷↓π)能(néng)看(kàn)得(de)懂(dǒng)的(de)，而這(zhè)對(duì)于γ<交流很(hěn)必要(yào)。

  
  

  比如(rú)，用(yòng)戶輸入賬号密碼登錄，如(rú)通(tōnλ∏>✘g)過驗證，系統進入主頁，否則，提示錯(cuò)誤。

• 功能(néng)需求：功能(néng)需求是(shì)最名正言順的(de)需€• •求，描述了(le)由某個(gè)軟件(jiàn)組件(jiàn)實現(xiàn)的(de)功₩↓ε能(néng)，并且從(cóng)軟件(jiàn)外( ↔wài)部看(kàn)，它是(shì)可(kě)觀察的(de)或可(kě)測試的(de♥땧)。

  功能(néng)需求經常會(huì)寫得(de)與更高(gāo)一(yī)層級的(de)需求、設計(j♦☆ €ì)重複，這(zhè)時(shí)，就(jiù)需要(yào)我↑÷÷們做(zuò)好(hǎo)裁剪。

• 組件(jiàn)需求：進一(yī)步的(de)架構設計(jì)和(∑♥λhé)開(kāi)發，可(kě)能(né§≤ng)需要(yào)更細化(huà)的(de)需求，即軟件(jiàn)組件(jiàn)需求。

  
  

  當然，架構設計(jì)與決策也(yě)伴随著(zhe)組件(jiàn)的(de)劃分(fēn)和(hα☆é)需求的(de)分(fēn)配，這(zhè)與組件(jiàn)需求是(shì)相(xiàng)互依托的(de)。

• 非功能(néng)需求：提到(dào)非功能(néng)需求，我們最容易聯想到(dào)性能(néng)需求，但(d $αàn)不(bù)僅僅于此。整體(tǐ)來(lái)看(kàn)，非功能(néng)需求可(kě)分(fēn)為 σ¥(wèi)兩大(dà)部分(fēn)：質量特性和(hé)結構性需求。

  
  

• 質量特性基本可(kě)以參考ISO/IEC 25010裡(lǐ)質量模型的(de)劃分(fēn)，如(rú)圖。

    結構性需求可(kě)以理(lǐ)解為( ₽φ₽wèi)架構催生(shēng)的(de)，比如(rú)，接口需求。

• 定義：可(kě)用(yòng)來(lái)對(duì)∑≥一(yī)些(xiē)專業(yè)名詞進行(xíng)說(shuō)明(míng)、澄清。

• 備注：一(yī)些(xiē)提示或解釋，主要(yào)為(wèi)了(le)增加可(kě)讀(dú)性。

2.2 狀态

需求是(shì)動态變化(huà)的(de)，所以其狀态​↓♠↕會(huì)遷轉。

• Proposed（被提議(yì)）：需求已被編輯完成，可(kě)以進行(xíng)π∏review了(le)。

• Reviewed（已評審）：需求已經完成評審，可(kě)以進行(xíng)問(wèn)題處理(l'<'×ǐ)和(hé)決策了(le)。

• Approved（已批準）：需求已經完成批準，準備好(hǎo)導入執行(xí÷‍ng)了(le)。

• Implemented（已執行(xíng)）：需求已經執行(xíng)，軟件(jiàn)組件(jiàn)已釋放(fàng)。

• Rejected（被拒絕）：需求暫不(bù)計(jì)劃執行(xíng)，或者<♥技(jì)術(shù)上(shàng)不(bù)可(kě)行(xíng)。

2.3 驗證标準

寫需求時(shí)就(jiù)考慮驗證，這(zhè)是(shì)V模型的(de)一(yī)個(gè)顯著特點。

需求工(gōng)程師(shī)經常不(bù)願意寫這(zhè)一(yī)部分(fδ♠ēn)，一(yī)者總覺得(de)不(bù)好(hǎo)寫，二者覺得→↑(de)是(shì)測試的(de)活兒(ér)。

我們分(fēn)别看(kàn)這(zhè♠®β)兩個(gè)抱怨。

實際上(shàng)，感覺驗證标準不(bù)好÷₽&(hǎo)寫恰好(hǎo)反映了(le)這(zhè)部分(¥$÷®fēn)工(gōng)作(zuò)的(de)必要(yào)β$™性。當你(nǐ)覺得(de)很(hěn)難簡單描述清楚怎麽去(qù)驗證，這(zhè)條需φ←₩求就(jiù)應該被返工(gōng)，比如(rú)，重新描述、拆分(fēn)、合并等。

那(nà)麽，這(zhè)是(shì)測試的(de)↑→λ活兒(ér)嗎(ma)？也(yě)不(bù)合适，很(hěn)顯然，測試用(yòng)例要(yà'×o)比驗證标準複雜(zá)得(de)多(duō)。這(zhè)裡(lǐ)主要(yào)為(w ±$↕èi)了(le)讓需求工(gōng)程師(shī)保證需求是(shì)可(kě)測的(de)。

此外(wài)，也(yě)應提示驗證階段和(hé)方法。比如(rú)，單元測試、組件(jiàn)測試、需求測試、集成測試、評審。

2.4 配置

汽車(chē)有(yǒu)很(hěn)多(duō)改款配置，軟件(jiàn)也(yě)有(yǒ★••u)很(hěn)多(duō)分(fēn)支。配置組合背後往往伴随著(zh≥α×≠e)軟件(jiàn)需求的(de)複用(yòng)↓‌∑關系。

于是(shì)，編寫軟件(jiàn)需求時(shí)，複✔γ用(yòng)及配置工(gōng)作(zuò)很(hěn)是(shì)必要(yào)。

我們可(kě)以增加配置屬性來(lái)共用(>©​>yòng)一(yī)版需求，而配置可(kě)以是(shì)車(chē)型項目，也(yě)可(kě)以是(shì)硬件(jiàn)配置。

然後，在有(yǒu)某條需求的(de)配置處标記yes，或者可(kě>✘λ&)标定或軟件(jiàn)參數(shù)化(huà)的(de)部分(fē£¶γn)也(yě)可(kě)标記具體(tǐ)參數(shù)值。

以上(shàng)描述了(le)一(yī)些(↑≠xiē)基礎的(de)軟件(jiàn)需求屬性示例 €，可(kě)做(zuò)參考。但(dàn)我們實際項目中，可(kě)以根據需要(yào)增>≠加很(hěn)多(duō)其他(tā)的(de)類别©‍。

3

一(yī)份好(hǎo)軟件(jiàn)需求的(de)特點

需求是(shì)自(zì)然語言描述的(de)，這(zhè)讓我們很(hěn)難量化(h↕"☆​uà)評價其好(hǎo)壞，且提供幾個(gè)特性做(zuò)參考：

• 完整性

• 可(kě)行(xíng)性

• 可(kě)驗證性

• 不(bù)含糊性

• 一(yī)緻性

• 正确性

• 可(kě)理(lǐ)解性

• 可(kě)修改性

為(wèi)了(le)盡量實現(xiàn)這(zhè)些(xiē)特性目标，我們可(kě)以嘗↑∑αΩ試按照(zhào)如(rú)下(xià)的(de)“公式”來(lá↑ i)書(shū)寫。

 

即“在什(shén)麽前提條件(jiàn)（邏輯條件(jiàn)或事(shì)件(jiàn)發生(shēng)或時(shí)間(jiānββ)段）下(xià)，什(shén)麽系統（或組件(jiàn)）必須（或應該或将會(huì)，英文(wén)'β 中常分(fēn)别用(yòng)具備法律強制(zhì)意義的(de)shall、可(kě)以有(yǒu)争論空(kōng)間(jiān)的(de)should及一(yī)般性描述的(de)will來(lái)對(duì)應）能(néng)夠（或通(tōng≠ )過什(shén)麽流程）實現(xiàn)什(shén)麽目标以及其他(tā)細節”。

這(zhè)會(huì)反映出前提、主體(tǐ)、強制(zhì)性、方式及目标這(zhè)些(xiē)基本信息。

4

軟件(jiàn)需求的(de)評審

第一(yī)小(xiǎo)節的(de)最後一(yī)個(gè)步驟是(shì)評審，這(α♦zhè)裡(lǐ)做(zuò)一(yī)個(gè)擴充。

評審是(shì)我們解決個(gè)體(tǐ)能(néng)力不(bù)足的↓​×(de)幾乎唯一(yī)的(de)手段，其主要(yào)涉及兩部分(fēn)：誰來(lái)評審和(hé)如(rú)何評審。

4.1 誰來(lái)評審

軟件(jiàn)開(kāi)發是(shì)個(gè≤≠)團隊合作(zuò)的(de)過程，而需求更¥× 是(shì)幾乎所有(yǒu)人(rén)都(dōu)要(yào→±ε≥)關注的(de)，我們要(yào)讓團隊來(lái)評審（角色定義可(kě)參考《汽車(chē)電(diàn)子(zǐ)軟件(jiàn)≥≤←組織的(de)“角色”大(dà)起底》）。

具體(tǐ)來(lái)看(kàn)，不(bù)同角色要(yào)有(yǒu)不(bù)同的(d©↔e)評審側重點:

• Feature Owner：确保軟件(jiàn)需求滿足更高(gāo)層級的(de)系統需求和(hé)系統架構設計(jì)。

• 軟件(jiàn)架構：确保需求範圍正确，滿足內(nèi)部guideline（對(duì)需求質量的(de)定義），并遵循産品roadmap。

• 軟件(jiàn)開(kāi)發：确保需求是(shì)可(kě)理(lǐ)解的(de)，并且可(kě)以被組件(jiàn)實現(xiàn)。

• 軟件(jiàn)測試：關注需求的(de)可(kě)理(lǐ)解性和(hé)可(kě)測試性。

4.2 如(rú)何評審

評審範圍可(kě)以是(shì)全部內(nèi)容，也(yě)可(kě)以是(shì)增量或變更評審。如(rú)果選擇增量或變更評審，要(yào)注意檢查它們對(duì)軟件(★≈<jiàn)需求及下(xià)遊架構其餘部分(fēn)的(de)影(yǐng)響。

進一(yī)步地(dì)，我們給出一(yī)些(xiē)chec←‍β'klist供參考。

• 是(shì)否遵循以下(xià)書(shū)寫需求的(de)規則：

• 必須清楚地(dì)确定主體(tǐ)；

• 每個(gè)需求都(dōu)是(shì)“原子(zǐ)”級别的(de)；

• 每項需求都(dōu)應說(shuō)得(de)明(míng)确不(bù)含糊；

• 盡可(kě)能(néng)定量地(dì)表述需求；

• 描述系統在所有(yǒu)條件(jiàn)（如(rú)初始"σ化(huà)、休眠、斷電(diàn)、正常運行(xíng)、過壓、欠壓等）下(xià)的(deφ​)行(xíng)為(wèi)；

• 避免冗餘和(hé)瑣碎；

• 使用(yòng)一(yī)緻的(de)術(shù)語；

• 在适當的(de)地(dì)方使用(yòng)非語言描述，如(rú)流程圖。

• 不(bù)同的(de)軟件(jiàn)需求↔✔γ 之間(jiān)沒有(yǒu)矛盾，以及與高(gāo)層級需求與設計(jì)之間(jiān)沒有(yǒu)矛盾？

  
  

• 軟件(jiàn)需求是(shì)否能(néng)夠覆蓋及滿足所追溯的(de)需求與設計(jì)？

  
  

• 是(shì)否都(dōu)使用(yòng)內(nèi)部标準術(shù)語？

  
  

• 實現(xiàn)這(zhè)些(xiē)需求是(shì)否有(yǒu)任何風(fēng)險？

  
  

• 需求是(shì)否有(yǒu)機(jī)會(huì)調整為(wèi)複用(yòng)現(xiàn)有(yǒu)設計(jì)？

  
  

• 時(shí)間(jiān)相(xiàng)關事(shì)件(jiàn)的(de♣¶γ)時(shí)間(jiān)要(yào)求及公差是(shì)否定義？

  
  

• 是(shì)否描述了(le)不(bù)同硬件(jiàn)之間(jiān)存在的(de)差異？

  
  

• 驗證标準和(hé)驗證方法是(shì)否明(míng)确?

  
  

• 是(shì)否有(yǒu)必要(yào)的(de)需×↑求屬性被遺漏?

......

5

全文(wén)小(xiǎo)結

本文(wén)從(cóng)以下(xià)幾♣ 個(gè)方面進行(xíng)了(le)簡要(yào)解讀(dú)：

• 生(shēng)成需求的(de)4個(gè)步驟（分(fēn)析、編寫、打基線、評審）。

• 需求所包含的(de)4個(gè)基本屬性（類型、狀态、驗證标準、配置）。

• 一(yī)份好(hǎo)需求的(de)8個(gè)特點（完整性、可(kě)行(xíng)性、可(kě)驗證性、不(bù)含β 糊性、一(yī)緻性、正确性、可(kě)理(lǐ)解性、可(kě≈​)修改性）。

• 寫好(hǎo)需求的(de)公式（前提、主體(tǐ)、強制(zhì)性、方式及目标）。

• 需求評審的(de)4個(gè)角色及評審側重點。

• 需求評審的(de)9條checklist。

6

寫在最後

從(cóng)很(hěn)多(duō)經驗看(k₹​àn)下(xià)來(lái)，一(yī)個(gè)¶π≥"做(zuò)得(de)爛的(de)項目基本都(dōu)有(yǒu)一(yī)套混亂的(de)需求。<∑當想要(yào)治理(lǐ)項目時(shí)，幾乎都(dōu)應該從(có£β★≠ng)需求開(kāi)始。

轉自(zì)汽車(chē)電(diàn)子(zǐ)與軟件(jiàn)