?物有本末，事有終始。知所先后，則近道矣。對軟件開發而言，軟件需求乃重中之重。必先之事重千鈞，不可或缺如日辰。

汽車行業由于有方法論和各種標準約束，對軟件開發有嚴苛的要求。ASPICE指導如何審核軟件開發，雖然沒有明確定義如何去開發，但是ASPICE的Guideline和Essential文件中給出很多參考。本文則詳細闡述如何編寫軟件需求，同時介紹軟件需求的必要屬性。本文用SRS(Software Requirement Specification)代替軟件需求設計規格書。

軟件需求描述軟件的期望行為。由于軟件在現代汽車電子控制單元的重要性持續增長，軟件需求分析通常包含類似于系統需求的產物。然而，無論如何，規格書SRS都是強制并且不可或缺的。

1. 軟件需求分類

• Heading標題

軟件需求工程師用來結構化軟件需求規格書SRS，即將SRS按照功能進行分類，并針對功能設置標題，譬如：主動泄放、上下電管理、離合器控制等。

• Information?信息

軟件需求工程師用來指示額外信息，僅作參考，譬如：BMS的SOC算法公式，很難在軟件測試驗證，在編寫需求時可以將此作為額外信息輸入給軟件工程師，設為Information的item無需被軟件測試驗證。

• Functional Safety Requirement?功能安全需求

軟件需求工程師設置用來表征該需求是功能安全相關，相應地，需求屬性必須包含ASIL等級這些ISO26262要求的屬性。

• Functional Requirement功能需求

軟件需求工程師用來表征軟件期望行為（區別功能安全需求）。

1. 陳述識別一個產品或者流程應產生什么結果（行為或者結果）。

2. 一個系統或系統組件應執行的需求。

• Nonfunctional Requirement?非功能需求

軟件需求工程師應用來指示描述軟件行為期望質量。與功能需求相比，該屬性描述軟件期望。這些期望無法達到預期不嚴重而且可以被接受。這不適用于功能/信息安全相關的重要的質量準則。性能屬性:軟件性能需求描述不是軟件要做什么而是如何去做。（通常是軟件和系統測試無法或很難測試，譬如：ECU應在接受制動信號后，20ms內給出制動響應、變化率等）。一般包含以下：

• 設計約束

• 性能要求

• 質量要求? ? ? ?

? 2. 軟件需求屬性

2.1 軟件屬性之驗證準則 Verification Criteria

Verification criteria define the qualitative and quantitative measures for the verification of a requirement. Verification criteria demonstrate that a requirement can be verified within agreed constraints, and are the input to test cases.?

驗證準則為一條需求的驗證定義定性和定量的措施。驗證準則描述了一條需求在達成一致的約束范圍內被驗證，并且是測試用例的輸入。

Verification criteria are necessary especially for non-functional requirements or to understand the preconditions for the test of a single or a set of requirements. It is used to answer “Under which condition, the requirement will be fulfilled?”. It will limit the verification condition, range and criteria. So, take the below into account:

對非功能性需求，或者為了理解單個需求或一系列需求的測試的前提條件，驗證準則是極其必須的。被用來回答“在什么條件下，需求被滿足？”會限制驗證條件、范圍和準則。因此，考慮以下：

1. Add verification criteria into SRS as the input of the subsequent test cases. 在SRS中增加驗證準則，作為后續測試用例的輸入。

2. Do not define verification criteria for some specific requirement if the description of this requirement could support to write test case. 針對一些特殊的描述可以用來支持寫測試用例需求，無需定義驗證準則。

2.2 Create Verification Criteria?創建驗證準則

The verification criteria shall cover the following aspects:?

驗證準則應覆蓋以下方面：

1.Identification of the requirement to be verified?被驗證的需求的識別（提煉）

2.Verification method?驗證方法

3.Verification environment?驗證環境

4.Preconditions and special conditions (e.g. winter diesel)?前提和特殊條件

5.Success criteria?成功準則

Identifying a verification method or verification step (e.g. software test, system test) is necessary, but insufficient for the verification criteria. If special test methods, environments, additional information or constrains are needed to be conducted or to be considered by the verification then this special information has to be documented.

識別驗證方法或者驗證步驟（例如：軟件測試，系統測試）是必要的，但對驗證準則而言，不夠充分。如果特殊的測試方法、環境、額外的信息或者約束需要被實施，或者被驗證考慮，那么這個特殊信息必須被文檔化。

Verification criteria need to cover all requirements and can be defined for a single requirement or for groups of requirements.

驗證準則需要覆蓋所有的需求，而且能夠為單個需求或者多組需求被定義。

Verification criteria have the following characteristics:?驗證準則有以下特性：

• Be unambiguously assigned to a requirement.?被準確地分配給一條需求

• The requirement is thus verifiable or can be evaluated. 需求是可驗證的或者能夠內評估

• Verification criteria define the qualitative and quantitative criteria for determining a requirement has been implemented successfully.?為了決策一條需求被成功執行，驗證準則定義了定性和定量的準則。

• They cover conditions under which a requirement can be tested. 覆蓋需求能夠被測試的條件。

• Show that a requirement can be verified under agreed boundary conditions.

表明在同意的邊界條件下，需求能夠被驗證。

舉例如下：

Requirement #1:?ECU shall be able to identify whether EEPROM is corrupted. ECU應能夠識別EEPROM是否損壞。

Verification criteria for Requirement #1:?The status of EEPROM whether corrupted can be found by a checksum calculation by the diagnostic service “readCheckSumStatus”, related DTC could be reported. EEPROM是否損壞的狀態可以通過診斷服務“readCheckSumStatus”的checksum計算被檢測，然后上報相關DTC。

2.3 Verification Method 驗證方法

Verification method includes: 驗證方法包括：

1. test class (test) 測試類（單元測試、靜態測試、資源占用率測試，功能測試，滲透性測試等等）
2. non-test class (e.g. inspections, peer reviews, audits, analysis (FMEA, FTA), simulation, walk-through,) 非測試類（例如：審查、同行評審、審核、分析（FMEA,FTA）,仿真）

Generally, for functional requirementsà Test class method. For non-functional requirementsà non-test class method. For example:

1. Non-functional requirement: cyclomatic complexity of software function < 10.
2. Verification method: use static analysis tool (QAC/ParaSoft).
3. All the requirements have to be verified.

總體而言：對功能性需求à 測試類方法。對非功能性需求à 非測試類方法。例如：

1. 非功能性需求: 軟件功能的圈復雜度 < 10.
2. 驗證方法: 使用靜態分析工具(QAC/ParaSoft).

All the requirements have to be verified. 所有需求都必須被驗證。

---

3. 軟件需求編寫規則

Software requirements have to be granular and understandable. Unclear or generic requirements have to be clarified with the system requirement owner.

軟件需求必須顆粒化和易于理解。不清晰的或者概括性的需求必須和系統需求所有者澄清。

The emphasis of the requirement specification is clarifying ‘do what’ instead of ‘how to do’. ‘how to do’ is a matter in the software design and implementation phase. When writing the software requirements, we shall comply with the following rules:

需求重點在于闡述“做什么”而不是“如何做”。“如何做”屬于軟件設計實現階段。當編寫軟件需求時，我們要遵守以下規則：

1. Correctness 正確性
2. Unambiguousness 確定性
3. Completeness 完整性
4. Consistency 一致性
5. Ranked for Importance or Stability 重要性和穩定性
6. Verifiability 可驗證性
7. Traceability 追溯性
8. Technical feasibility 技術可行性
9. Atomicity 原子性
10. The former 1) necessity and 2) clear boundaries are deleted here.

---

3.1 Correctness 正確性

A SRS is correct only if every requirement stated therein is one that the software shall meet. There is no tool or procedure that ensures correctness. The SRS should be compared with any appliable superior specification (such as a system requirements specification), with other project documentation, and with other applicable standards, to ensure that it agrees. Alternatively, the customer or user can determine if the SRS correctly reflects the actual needs. Traceability makes this procedure easier and less prone to error.

只有當SRS中規定的每個需求都是軟件應滿足的需求時，它才是正確的。沒有任何工具或過程可以確保正確性。應該將SRS與任何適用的上層規范（例如系統需求規范）、其他項目文檔和其他適用的標準進行比較，以確保它們是一致的。或者，客戶或用戶可以確定SRS是否正確地反映了實際需求。可追溯性使這個過程更容易，更不容易出錯。

3.2 Unambiguousness 確定性

A requirement is unambiguous only if every requirement stated therein has only one interpretation. At a minimum, this requires that each characteristic of the final product be described using a single unique term. In cases where a term used in a particular context could have multiple meanings, the term should be included in a glossary where its meaning is made more specific. The SRS should be unambiguous both to those who create it and to those who use it. However, these groups often do not have the same background and therefore do not tend to describe software requirements the same way. Representations that improve the requirements specification for the developer may be counterproductive in that they diminish understanding to the user and vice versa.

只有當其中所述的每個需求只有一種解釋時，需求才是明確的。至少，這需要使用一個唯一的術語來描述最終產品的每個特性。如果在特定上下文中使用的術語可能具有多種含義，則應將該術語包含在其含義更具體的術語表中。對于創建者和使用者來說，SRS都應該是明確的。然而，這些小組通常沒有相同的背景，因此不傾向于以相同的方式描述軟件需求。為開發人員改進需求規范的表示可能適得其反，因為它們減少了對用戶的理解，反之亦然。

The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to be understood. Example

1. BMS shall set “SwtHvCtrK21==High” to cut off the HV positive contactor once upon the cell voltage is ≥700V when charging.

需求是以這樣一種方式陳述的，因此它只能以一種方式解釋。要求表述簡單，易于理解。例子充電時：

1. 當電池電壓≥700V時，bms應控制SwtHvCtrK21==High來切斷高壓主正接觸器K1。

3.3 Completeness 完整性

An SRS is complete only if it includes the following elements:

1. All significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces. In particular, any external requirements imposed by a system specification should be acknowledged and treated.
2. Definition of the responses of the software to all realizable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to both valid and invalid input values.
3. Full labels and references to all figures, tables, and diagrams in the SRS and definition of all terms and units of measure.
4. No “To Be Determined” (TBD) labels. If there is a section containing a TBD it must also contain: a description of the conditions causing the TBD (e.g., why an answer is not known) so that the situation can be resolved, a description of what must be done to eliminate the TBD, who is responsible for its elimination, and by when it must be eliminated.

SRS只有包含以下要素才算完整：

1. 所有重要需求，無論是與功能、性能、設計約束、屬性或外部接口有關。特別是，系統規范強加的任何外部需求都應該得到確認和處理。
2. 定義軟件對所有可實現類型的輸入數據在所有可實現類型的情況下的響應。注意，指定對有效和無效輸入值的響應是很重要的。
3. SRS中所有數字、表格和圖表的完整標簽和參考資料，以及所有術語和計量單位的定義。無待定（待定）標簽。如果有一個包含TBD的部分，它還必須包括：對導致TBD的條件的描述（例如，為什么答案不知道），以便解決這種情況，必須采取什么措施來消除TBD，誰負責消除它，以及必須在什么時候消除它。

3.4 Consistency 一致性

Consistency refers to internal consistency. If an SRS does not agree with some higher-level document, such as a system requirements specification, then it is neither consistent nor correct. An SRS is internally consistent only if no subset of individual requirements described in it conflicts. The three types of likely conflict in an SRS are as follows:

一致性是指內部一致性。如果SRS與一些上級文檔（如系統需求規范）不一致，那么它既不一致也不正確。只有當其中描述的單個需求子集不沖突時，SRS才是內部一致的。SRS中可能出現的三種沖突類型如下：

1. Conflict among specified characteristics of real-world objects.

• The format of an output report may be described in one requirement as tabular, but in another as textual.
• One requirement may state that all lights should be green, while another may state that all lights should be blue.

2. Logical or temporal conflict between two specified actions.

• One requirement may specify that the program add two inputs, but another may
  specify that the program should multiply them.
• One requirement may state that “A” must always follow “B,” while another may
  require that “A and B” occur simultaneously.

3. Two or more requirements may describe the same real-world object but use different terms for that object. For example, a program’s request for a user input may be called a “prompt” in one requirement and a “cue” in another. Standard terminology and definitions use promotes consistency.

4. 現實世界對象的特定特征之間的沖突。

• 輸出報告的格式可以在一個要求中描述為表格，但是在另一個作為文本的。
• 一項要求可能要求所有的燈都是綠色的，而另一項要求可能要求所有的燈都是藍色的。

5. 兩個指定動作之間的邏輯或時間沖突。

1. 一個要求可以指定程序增加兩個輸入，但另一個要求可以指定程序應該將它們相乘。
2. 一項要求可能規定“A”必須始終緊跟“B”，而另一項要求可能要求“ A和B ”同時發生。

6. 兩個或多個需求可能描述相同的現實世界對象，但對該對象使用不同的術語。例如，程序對用戶輸入的請求在一個需求中可能被稱為“提示”，而在另一個需求中可能被稱為“暗示”。標準術語和定義的使用促進了一致性。

3.5 Ranked for Importance or Stability 基于重要性或穩定性排序

An SRS is ranked for importance and/or stability if each requirement in it has an identifier that indicates either the importance or stability of that particular requirement. Typically, requirements that relate to a software product are not equally important. Some requirements may be essential, especially for life-saving applications, while others may be desirable.

如果SRS中的每個需求都有一個標識符，表明該特定需求的重要性或穩定性，則SRS根據重要性和/或穩定性進行排名。通常，與軟件產品相關的需求并不同等重要。有些需求可能是必要的，特別是對于救生應用程序，而其他需求可能是可取的。

Note:

1. The requirement description shall be concise and unambiguous.
2. Use active voice: describing who does what instead of that will happen.
3. Use attributives as little as possible: for example, words used as modifiers are usually adjectives. Attributive means uncertainty, especially for the verification standard description of non-functional requirements, the principle is transforming the qualitative description into the quantitative description.
4. Use the modal verb ‘shall’ as mandatory requirement (i.e. ‘system shall…’ or ‘controller shall…’), followed by an action, instead of words like could, may, etc.
5. Use natural language and diagram as a combination method to improve the readability, completeness and maintainability of the requirements. A certain grammatical structure can be applied to specify requirements, two structures are listed below:
6. [Condition][Subject][Action][Object][Constraint of Action]??????? Example: When signal x is received[Condition], the system[Subject] shall set[Action] the signal x received bit[Object] within 2 seconds[Constraint of Action].
7. [Subject][Action][Constraint of Action]???? Example: The invoice system[Condition] shall display pending customer invoices[Action] in ascending order of invoice due date[Constraint of Action]
8. When there are two Actions in the requirement, it means that this requirement is not singular and it requires to be split.

注意：

1. 需求描述應簡明、明確。
2. 使用主動語態：描述誰做了什么，而不是將會發生什么。
3. 盡量少用定語：例如，用作修飾語的詞通常是形容詞。屬性意味著不確定性，特別是對于非功能需求的驗證標準描述，其原則是將定性描述轉化為定量描述。
4. 使用情態動詞“shall”作為強制性要求（即“system shall…”或“controller shall…”），后面跟著一個動作，而不是像could， may等詞。
5. 使用自然語言和圖表相結合的方法，提高需求的可讀性、完整性和可維護性。可以采用一定的語法結構來指定要求，下面列出了兩種結構：
6. [Condition][Subject][Action][Object][動作約束]示例：當接收到信號x [Condition]時，系統[Subject]應在2秒內設置[Action]接收到的信號x位[Object][動作約束]。
7. [主題][操作][操作約束]示例：發票系統[條件]應按發票到期日升序顯示待處理的客戶發票[操作][操作約束]
8. 當需求中有兩個動作時，表示該需求不是單一的，需要拆分。

---

4. 需求分析方法

4.1 工具和方法

軟件需求可以維護在ALM系統中，譬如：doors，codeBeamer等，JIRA適合互聯網行業，并不合適顆粒度較細的汽車級控制器開發。同時可以使用 UML、Visio 和 EA 作為輔助工具進行軟件需求分析，方法如下：

• 例圖
• 序列圖
• 活動圖
• 狀態圖

注：SRS 將以文字和圖表兩種形式完成，以使軟件架構師和軟件開發工程師進一步理解 SRS。

4.2 具體分析方法

從系統分析方面來看，需求分析方法可以分為四類：

• 功能分解法。
• 結構分析法。
• 信息建模方法。
• 面向對象分析方法。

在 ecu 的軟件開發過程中，當采用功能分解和結構分析方法時，通常將 UML 應用于軟件需求分析中。

在分析過程中，同步編寫符合 2.3 規則的文本化需求，并按照以下方法對需求進行結構化描述：?

• 功能用例的定義。
• 操作場景和順序分析。
• 根據功能用例進行結構功能分解。
• ecu 軟件接口分析與描述。

文本需求對于具體細節是有效的，但當需要提供需求的相互關系和上下文時，則無效。因此，圖或模型（用例、UML、Simulink 模型）是軟件需求規范中促進可讀性和完整性所必需的部分。

分析過程完成后，就可以得到軟件需求和接口需求。

4.3 對運行環境的影響

對運行環境影響的分析，既包括對范圍內軟件的影響，也包括對其他軟件部件、其他系統或整車考慮以下可能部件的影響：

• 接口

1. 信號及信號質量
2. 電壓和電流

• 環境

1. 溫度
2. EMC

• 性能

1. 接口響應時間（信號響應、采樣時間、周期時間、總線負載、信號延遲、抖動）
2. 微控制器響應時間（處理時間）

• 資源

1. RAM / ROM 內存使用情況
2. EEPROM / DataFlash 內存使用情況

軟件/系統交互的其他系統或系統元素（如硬件），構成軟件/系統的操作環境。它可以被看作是“固定的”。

---

未完待續。。。

---

參考文章

1. 軟件需求開發管理-軟件需求分類和驗證準則
2. 軟件工程：軟件需求之需求編寫規則
3. 軟件工程：軟件需求之需求分析方法