一、前言
如何將「需求」表達為清晰、準確的文本，這裡面還是有很多學問的。
本文在系統工程的框架內，結合國際系統工程學會 INCOSE 發布的指南，對如何編寫需求提供解讀。如各位讀者能結合飛機設計的工程實踐，則效果更好。
此外，在全球一體化和主製造商-供應商合作模式的背景下，我們所接觸的「需求」通常以英文呈現，本文的示例也採用英文表達，但其基本原理在各種語言之間應該是相通的。
二、為什麼要把需求文本化？
首先，需要明確一點：對於需求定義，自然語言（文本）不是一種完美的表達方式。
尋常的自然語言表達，難以保證表述清晰、準確、無歧義。因此近年來，出現了SysML建模方法、表格模板方法等一些替代措施，用來表述需求。
但這些方法也有缺陷，他們覆蓋的範圍和概念有限，且存在表達、追溯、管理等諸多問題。
根據全球航空製造業的實踐情況，文本化的需求仍是必要的，其優勢主要體現在：
對於表達的概念或對象，沒有任何範圍限制；其句型和語法結構，可以實現有效追溯。
三、兩個概念
需求層級
需求存在於系統工程的多個層級，ARP4754A中的V模型也表達了類似觀點。從最高層級的航空公司等客戶需求，到最底層級的軟硬體設備需求，需求的表達也越來越具體、越來越詳盡。
在最高層級，理想的需求不應該指定具體的實現方案（應允許多種設計）；而在最低層級，需求的表述，反而需要限定在一個非常具體的解決方案。
需求的分配和分解
Allocation and Decomposition
隨著設計的開展，需求自上而下進行傳遞，這一過程包括兩個方面：分配和分解。
需求的分配存在於各個層級之間，例如從飛機級分配到系統級。一旦完成分配，就可以將其分解為多個需求（需求分解是設計過程的重要組成）。
分配/分解的需求與源需求之間，應保持雙向追溯關係。
四、需求特點 Characteristics
特點1：必要的
Necessary
每一條需求都應該是必要的
需求都是有成本的，不必要的需求會導致非增值的工作、額外的成本和不必要的風險。
如果一條需求移除後仍可滿足目標、或此需求的目標已被其他需求滿足、或此需求的作者不能說明其合理性，則這條需求是不必要的。
特點2：獨立於實現
Implementation Independent
需求用於說明什麼是必需的，而不說明用什麼來滿足
用「實現的表達方式」來寫需求，可能會忽略更好的實現方案，而真正需要解決的問題可能無法得到正確識別，進而影響下一層級需求定義。
因此，對於一條寫好的需求發問：「為了什麼目的」？如果需求是以實現的方式表達的，那麼問題的答案，可能才是真正的需求。
特點3：明確的
Unambiguous
一個需求只能有一種解釋
需求的意圖必須由編寫者、設計人員以及V&V人員以同樣的方式理解。以下方法可以減少歧義：
使用正確的語法；使用統一定義的術語和縮略語；使用精確的量詞和限定詞；使用約定的語言形式；使用主動語態，不含形容詞、副詞、代詞；使用適當的非文本表示，如圖形或表格等。
特點4：完整的
Complete
需求本身的表述應是完整的
雖然充分理解一條需求可能需要閱讀上下文或其引用的文件，但需求本身應該是一個完整的句子，不需要其他語句就能理解其基本含義。
單條需求的理解不依賴於其他需求，可以提高需求分解、分配、確認和驗證等工作的有效性。
特點5：指向單一
Singular
一條需求只涉及一個中心思想
將需求限制在一個功能、特性或約束上，避免使用「和（and）」引入多個關注點。
單條需求只涉及一個關注點，可以提高需求分解、分配、確認和驗證等工作的有效性。
特點6：可行的
Feasible
需求應該是可行的、可實現的
在現有技術和工程方法的基礎上，對成本、進度、技術難度和風險進行評估，避免出現需求無法實現的情況（例如100%的籤派可靠度要求，1E-100/FH的安全性指標等）。
特點7：可驗證
Verifiable
需求必須可驗證，否則無法判斷它是否得到正確實現
不同類型的需求可以採用不同的驗證方法，這將影響需求的編寫方式。例如對於功能性需求，通常需要通過試驗來驗證其功能正常。因此在編制需求時，其功能表徵（行為）應表達清楚。
特點8：正確的
Correct
需求應正確地反映利益攸關方的期望
需求中所表達的功能、性能要求應該是正確的。
需求在分解或推導時，應基於對更高層級需求的正確解釋和理解。分析過程如引入假設，則這些假設也應得到確認。
特點9：合規的
Conforming
需求的格式，應符合需求編寫規則，符合公司使用的標準規範
所有需求都遵從同一格式要求時，需求本身就更易於編寫、理解、評審。
五、需求編寫規則 Rules
規則1：需求編寫要精確
Precision
使用定冠詞
例如使用 「the」 而不是 「a」，以避免歧義。
錯：The system shall provide a time display.
對：The system shall display the Current_Time.（Current_Time需在術語表中定義）
使用主動語態
執行動作的實體應該是主語。
錯：The Identity of the Customer shall be confirmed.
對：The Accounting_System shall confirm the Identity of the Customer.（Accounting_System等需在術語表中定義）
主語與其層級匹配
例如系統需求應該為 「The system shall ...」，子系統需求應該是 「The subsystem shall ...」。
使用術語表中定義的術語
自然語言含義豐富，一個詞可能有多種理解。在需求中，含義的模糊會導致歧義和驗證困難。而術語表則規定了特定單詞的特定含義。
避免使用不精確的量詞
例如 「some」、 「many」、 「almost」、 「close to」、 「sufficient」、 「approximately」、 「appropriate」、 「reasonable」，同時應指定其單位和數值範圍。
錯：The Flight_Information_System shall display the current altitude to approximately 1 meter resolution.
對：The Flight_Information_System shall display Current_Altitude plus or minus 1 meter.
避免使用副詞
因為副詞常常導致需求含義模糊、不可驗證。
錯：The Flight_Information_System shall usually be on line.
對：The Flight_Information_System shall have an Availability of at least xx% over a period of at least yy hours.
避免使用形容詞
因為形容詞常常導致需求含義模糊、不可驗證。
錯：The Flight_Information_System shall display the Tracking_Information for relevant aircraft.
對：The Flight_Information_System shall display the Tracking_Information of each Aircraft located less than or equal to 20 kilometers from the Airfield.
避免使用免責條款
例如 「as much as possible」、「where possible」、「if practicable」。因為其常常導致需求含義模糊、不可驗證。
錯：The GPS shall, where there is sufficient space, display the location of the User_Location.
對：The GPS shall display the User_Location.
避免使用開放式條款
例如 「including but not limited to」、「etc.」、「and so on」。因為常常導致需求含義模糊、不可驗證。
錯：The ATM shall display the Customer Account_Number, Account_Balance, and so on.
對：The ATM shall display the Customer Account_Number.
對：The ATM shall display the Customer Account_Balance.
對：The ATM shall display the Customer .......
規則2：需求編寫要簡潔
Concision
避免多餘的不定詞
應避免使用 「... be able to...」、「... be capable of ...」。
錯：The Weapon_Subsystem shall be able to store the location of all Ordnance.
對：The Weapon_Subsystem shall store the location of all Ordnance.
使用獨立的子條款
需求有一個描述基本功能和需要的主句，其他場景、性能、約束可以作為主句的補充條款。
錯：The Navigation_Beacon shall provide Augmentation_Data for 8-20 meters accuracy at least 99.7% of the time to each Maritime_User during Harbor/Harbor Approach (HHA) maneuvering.
對：The Navigation_Beacon shall provide Augmentation_Data to each Maritime_User engaged in Harbor/Harbor_Approach_maneuvering (HHA), at an accuracy of 8-20 meters at least 99.7% of the time.
規則3：需求編寫應無歧義
Non-ambiguity
使用正確的語法
尤其是多種語言之間需要翻譯時。
錯：The Weapon_Subsystem shall storing the location of all ordnance.
對：The Weapon_Subsystem shall store the location of all Ordnance.
使用正確的拼寫
拼寫錯誤將導致混淆。
錯：The Weapon_Subsystem shall store the location of all ordinance.
對：The Weapon_Subsystem shall store the location of all Ordnance.
使用正確的標點
不正確的標點會導致需求中子條款的混淆。
錯：The Navigation_Beacon shall provide Augmentation_Data to each Maritime_User, engaged in Harbor/Harbor_Approach_maneuvering (HHA) at an accuracy of 8-20 meters at least 99.7% of the time.
對：The Navigation_Beacon shall provide Augmentation_Data to each Maritime_User engaged in Harbor/Harbor_Approach_maneuvering (HHA), at an accuracy of 8-20 meters, at least 99.7% of the time.
點評：逗號錯誤，會使人誤以為accuracy與maneuver有關，而不是與Augmentation_Data有關。
使用正確的連詞
例如不使用 「both X and Y」，而使用 「X and Y」；不使用 「X and/or Y」，而是將其分為兩條需求；不使用 「/」 符號，以避免多種理解。
規則4：需求指向應單一
Singularity
使用單句
需求應是一個簡單的肯定性陳述句（一個主語，一個動詞，一個賓語），並可由相關從句限定。
避免使用組合句型
應避免使用 「and」、「then」、「unless」、「but」、「as well as」、「however」、「whether」、「meanwhile」、「otherwise」，建議編寫多條需求。
錯：The user shall either be trusted or not trusted.
對：The Security_System shall categorize each user as one of the following: Trusted, Not_Trusted.
避免闡述需求目的
需求中不應包含目的等信息，應避免使用 「in order to」、「so that」、「thus allowing」，這些信息可以放在需求的 Rationale 一欄。
錯：The Database shall store Account_Balance information until it is at least 10 years old in order to satisfy the demands of the auditors.
對：The Audit_System shall store Account_Balance information relating to at least the last 10 years.
避免使用從屬文本
例如括號中的多餘信息，這些信息可以放在需求的 Rationale 一欄。
錯：The Control_Unit shall disconnect power from the Boiler when the water temperature exceeds 85 °C (usually towards the end of the boiling cycle.)
對：The Control_Unit shall disconnect power from the Boiler when the water temperature exceeds 85 °C.
對列表中的每一項編寫需求
避免模稜兩可的概括。
錯：The software packages (i.e., the HLT algorithm, the selection control, the data access) shall be documented for the maintainer.
對：The maintenance documentation shall include descriptions of each HLT algorithm.
對：The maintenance documentation shall include descriptions of the selection control.
對：The maintenance documentation shall include descriptions of the data access.
當需求中描述的行為異常複雜，可以指向獨立的圖、表、模型等。
錯：The control system shall close Valves A and B within 5 seconds of the temperature exceeding 95 °C and within 2 seconds of each other.
對：When the Product temperature exceeds 95 °C, the Control System shall close Input Valves as specified in timing diagram 6.
規則5：需求應完整
Completeness
避免使用代名詞
應避免使用 「it」、 「this」、 「that」、 「he」、 「she」、 「they」、 「them」，必要時可以重複專有名詞。
錯：The controller shall send the driver his itinerary for the day.
對：The Controller shall send the Driver_Itinerary for the day to the Driver.
避免通過閱讀標題才能理解需求
需求本身應該是完整的，不應該通過閱讀標題，才能完成對需求的理解。
標題示例：Alert Buzzer Requirements
錯：It shall sound for no longer than 20 minutes.
對：The Alert Buzzer shall sound for no longer than 20 minutes.
規則6：需求應可實現
Realism
避免使用無法實現的理想值
錯：The system shall have 100% availability.
對：The system shall have an Availability of greater than or equal to 98%.
規則7：需求應明確適用的條件
Conditions
明確需求所適用的條件
有時需求僅在某些條件下適用，這種情況下應在相關需求中寫明該條件，不能讓讀者從上下文中去推斷。
錯：In the event of a fire:
Power to all electromagnetic magnetic fire door catches shall be turned off.
All security entrances shall be set to Free_Access_Mode.
All fire escape doors shall be unlocked.
對：In the event of a fire, the Security_System shall turn off power to all electromagnetic magnetic fire door catches.
In the event of a fire, the Security_System shall set all security entrances to the Free_Access_Mode.
In the event of a fire, the Security_System shall unlock all fire escape doors.
如給出條件列表，應清晰表明是滿足任一條件即可，還是滿足全部條件才行。
錯：The Audit_Clerk shall be able to change the status of the action item when:
- the Audit _Clerk originated the item;
- the Audit _Clerk is the actionee;
- the Audit _Clerk is the reviewer.
對：The Audit_System shall allow the Audit_Clerk to change the status of the action item when any one of the following conditions hold:
- the Audit _Clerk originated the item;
- the Audit _Clerk is the actionee;
- the Audit _Clerk is the reviewer.
或者
對：The Audit_System shall allow the Audit_Clerk to change the status of theaction item when all of the following conditions hold:
- the Audit _Clerk originated the item;
- the Audit _Clerk is the actionee;
- the Audit _Clerk is the reviewer.
規則8：需求應唯一
Uniqueness
對需求進行分類
分類後容易檢查和識別需求的重複、衝突、丟失等問題。
每項要求只表達一次
對於同一要求，應避免存在多種表達。例如：
The system shall provide report of financial transactions.The system shall provide a financial report.
二者有重複，前者是後者的子集。
規則9：需求應考慮容差
Tolerance
需求中涉及數值時，應考慮其容差，定義可接受值的範圍。
錯：The Pumping_Station shall maintain the flow of water at 120 liters per second for 30 minutes.
對：The Pumping_Station shall maintain a flow of water at 120 ±10 liters per second for at least 30 minutes.
規則10：需求應可量化
Quantification
需求中應使用具體可量化的目標
應避免使用 「fast」、「maximum」、「minimum」、「optimum」、「nominal」、「best practices」、「user-friendly」 等。
錯：The system shall use minimum power.
對：The system shall limit the power consumption to less than 50% of the current solution.
使用確定的時間限制
應避免使用 「eventually」、「at last」 等不確定的時間關鍵詞。
錯：Continual operation of the pump shall eventually result in the tank being empty.
對：The Pump shall remove at least 99% of the Fluid from the Tank in no more than 3 days of continuous operation.
規則11：需求應可追溯
Traceability
每一條需求應該有唯一編號。即使此需求被刪除，其編號也不應被其他需求重複使用。
在父需求和子需求集之間，應建立追溯關係。其目的是確保子需求的必要性/充分性，建立各層需求之間的分配/分解關係，並清晰表明方案是如何滿足需求的。
父子之間的追溯關係可以是多對多，例如一條子需求可以同時追溯到多條父需求。
每一條需求都應連結到相關的 V&V 活動、V&V 證據，以確定每一條需求是正確的，或已得到滿足。
如一條需求需要指向另外一份文件，建議只引用文件編號，以增強可讀性。引用文件的版本、標題等信息可以在專門章節裡集中列出。
六、結尾
OK，寫出一條完美的需求，你覺得難嗎？嗯，難嗎？
相關文章，點擊閱讀：
SAE ARP4754A之「八大過程」、「七大計劃」，了解一下！商用飛機高度複雜產品的研發管理飛機和系統設計 「雙V」 是什麼？「確認」 和 「驗證」 有區別嗎？SAE ARP4754A 初探與入門！SAE ARP4761 初探與入門！
參考文獻：INCOSE-TP-2010-006-01 Guide to Writing Requirements