鄭藍
摘 要:隨著飛機系統工程的廣泛應用以及“制造商-供應商”模式的發展,飛機需求成為決定飛機研制成本及進度的重要因素。需求成為各級設計人員要求下級或供應商設計系統的依據,那么需求本身質量的好壞就顯得極為關鍵。該文首先給出了飛機需求用語約定,以幫助快速識別需求。隨后對飛機需求進行了分類,從這幾方面進行考慮,能夠保證需求的完整性。再次提出了飛機需求本身的編寫原則。最后根據這些原則,提出可操作的書寫注意事項和高質量需求檢查單。
關鍵詞:需求類型 編寫原則 書寫技巧 檢查單
中圖分類號:G71 文獻標識碼:A 文章編號:1674-098X(2015)06(a)-0085-02
飛機研制是一項產品極其復雜,技術難度很大,質量要求最高的龐大的系統工程[1]。飛機需求作為飛機研制的設計輸入,需求是否正確、完整直接影響設計研發活動的有效性和研發產品的質量,它指明了系統開發所需要和必須完成的每一件事,明確了所有設計應該提供的功能和必然受到的制約[2]?,F在隨著對SAE ARP4754A的認識程度越來越高,國內飛機制造商對飛機需求管理的工作越重視。較多文獻圍繞著需求管理的“V”過程以及平臺的開發進行研究,而該文將圍繞需求編寫本身的質量進行介紹,從需求的類型、編寫的一般原則和書寫的注意事項等方面進行總結,為飛機需求編寫的高質量提供參考。
1 用語約定
飛機需求的編寫應有嚴格的用語約定,可以讓人清晰的閱讀出一份需求文檔中哪一句是需求,哪一句是簡單的陳述:“應”用于表達一條強制性的需求;“應當”用于定義一個被強烈推薦的行為,此行為并非強制性的,不用于表達需求;“可以”用于定義一個被允許的行為。不用于表達需求;“將”用于表達一個意愿或事實。不用于表達需求。
2 需求的類型
對飛機需求進行分類,實際上是要求設計人員從這幾方面進行考慮,這樣能夠保證所出需求不會被遺忘,在后續的確認中可以將重復的需求刪除。
2.1 非功能性需求
非功能性需求是那些與飛機功能分配無關的需求,一般包括過程需求、供應商需求和其他與設備直接相關的需求。
示例:
系統部件不“應”鍍鎘。
2.2 功能需求[3]
根據ARP 4754A《民用飛機與系統研制指南》,以下的功能需求類別需要在不同的研制階段活動中考慮。功能需求是以“……應……”句型表達的飛機或系統級功能。
示例:飛機“應”具備減速能力。
安全性需求
安全性需求來自于安全性評估過程,例如飛機級FHA、PASA、系統級FHA和PSSA過程等。安全性需求一般包含獨立性需求、概率可用性和完整性要求、無單點失效準則、研制保證等級等。
示例:
剎車系統“應”提供與正常剎車相獨立的備用剎車。
在爬升、巡航和下降飛行階段,高于25000英尺服務門意外打開的概率“應”小于1E-9每飛行小時。
功能性需求
功能性需求是指在具體條件下獲得系統預期性能所需要的需求。功能性需求分為以下幾種:
客戶需求
客戶需求隨飛機型號、系統特定功能或者系統類型不同而變化。需求包括運營商的預期載荷、航路系統、使用經驗、維護概念和所期望的特性。
示例:
飛機“應”有三種客艙布置構型:混合級、全經濟級和高密度級。
飛機“應”提供每排4個座位(2座椅+過道+2座椅)的公務艙構型。
使用需求
使用需求定義了飛行機組與功能系統之間、維護人員與飛機系統之間、其它飛機支持人員與相關功能及設備之間的接口。活動、決定、信息需求和時間形成了主要的使用需求。定義使用需求時需要考慮正常和非正常情況。
示例:
飛機“應”具備可以在飛機客艙或駕駛艙內調節客艙溫度的能力。
飛機“應”提供手動控制應急燈的能力。
性能需求
性能需求定義了使得功能或系統對飛機和其運行有用的特性。除了定義預期的性能類型外,性能需求還包括功能的一些細節,如:精度、保真度、范圍、解析度、速度和響應時間。
示例:
飛機“應”保證在客艙中心線上任意兩個位置的溫度差不超過4.5°C。
飛機“應”確保在整個飛行包線內,不考慮飛行員或自動駕駛的輸入,傾斜角不會超過33度。
物理和安裝需求
物理和安裝需求與系統的物理特性和飛機環境相關,包括:尺寸、安裝要求、動力、冷卻、環境限制、可見度、接近方式、調整、搬運和存儲。生產限制也在需求中起作用。
示例:
飛機“應”確??团摽諝馀欧趴诎惭b在地板上。
飛機“應”在機翼前緣和前起落架上安裝著陸燈。
維修性需求
維修性需求包括計劃和非計劃維修需求,并且與具體的安全性相關功能有關。失效探測率或者故障隔離率等因素也很重要。需求也需定義外部試驗設備的信號和連接。
示例:
飛機“應”具備測試所有閱讀燈的能力。
接口需求
接口需求包括:物理系統與項目的互聯,以及確定的信息交互的相關特性。接口包括所有輸入和輸出的定義,應詳盡表述信號的特征。接口文件中的接口信息應完整的描述信號特征并能追述到相關的需求。
示例:
飛機電源系統“應”給駕駛艙照明提供正常和應急電源。
空氣管理系統“應”向機載維護系統提供其健康和構型狀態。
補充審定需求
根據適航規章要求或為了表明對適航規章的符合性,可能需要補充功能、特性或執行要求。此類需求應與適航當局協商確定。endprint
衍生需求
衍生需求來源于設計過程本身,所以衍生需求與上層需求不相關。
3 需求的一般原則
好的需求一般要應滿足以下原則[4]。
3.1 具體
需求必須確切地說明需求所要求的內容,需求的具體性應包括以下幾方面。
(1)清楚明確。需求表述無歧義,清楚明確地表達需求以保證任何閱讀需求的人對需求的理解與解釋是唯一的。同時,必須明確應開展哪些工作以滿足該條需求、具體由誰或者系統適用于該條需求。
(2)一致性。在用以描述系統或者概念的需求文件中應采用相同的專業術語。
(3)需求層級恰當。需求是對于設計者(或者實施人)的要求。編制需求應注意需求層級是否恰當??蛻粜枨罂赡軄碜圆煌瑢蛹?,如果用戶給出的需求限定了具體的設計工作,就需要判斷該條需求是否定義的恰當。當編制需求時,需求應被傳遞至下一個層級的需求而非更低層級(除非是使用合理的客戶需求)。定義恰當層級的需求只將事物作為一個類似“黑盒”的整體,描述該“黑盒”按預期將會以何種形式呈現。需求應定義在該層級需要完成的內容,但不應定義如何需求內容的實現方式。
3.2 可量度
每一條需求必須在一定程度上通過標準的方法來驗證(試驗,分析,相似性或設計)。客戶可以用類似“飛機航程應該盡量長”。這是一條正當的需求,但卻是一條無法驗證的需求。對于這樣的需求,需要通過權衡分析以確定可以驗證的最大航程。最理想的情況下,每一條測試需求均可通過一個單獨的試驗得到驗證。如果一條需求需要多個試驗方能得到驗證,即應該將該條需求分解為多條需求??梢酝ㄟ^單個試驗驗證多條需求,但是這取決于是否可以將多條需求歸類或者合并。當完成系統的架構設計時,系統各個層級的需求在測試階段均有其對應層級的驗證試驗。如有必要定義子系統級的需求以描述系統,那么也應開展相應的子系統級需求驗證。必須建立明確的標準用以衡量每條需求實現的情況。這些標準常被成為測試準則或者接受準則,如若未明確定義上述準則將無法證明需求的滿足情況。
3.3 可實現
有必要請設計人員參與需求定義的工作,參與需求定義的設計人員必須有足夠的專業知識以判斷需求是否可實現。對于簽署了子合同開發部件的情況,則需要要求子合同相關部件的設計人員參加需求定義的工作。同時,邀請生產單位和用戶參加需求定義工作也可有效保證需求的可實現性。每一條需求必須和行業標準中的相關內容一致。一般情況下,需求必須滿足相關適用的政府、行業和產品標準、規范以及接口等內容。
3.4 現實的
為保證需求的現實性,需求本身必須是代表一個目標。所有的團隊愿意并且有能力去實現這個目標。為實現某個需求,我們可以找到很多技術上可行的想法,但是每個解決方案均有不同的成本。因此,關鍵問題不是我們隨意找到一個技術上可行的方案,而是需要找到一個我們能夠承受其成本的解決方案。
3.5 可追蹤
必須保證每條需求可以追溯至該需求的來源。每一條用戶需求必須可以追溯至相應的用戶。同樣地,每一項功能與特征也需要鏈接至最初的用戶需要。因此,也必須建立每一條需求與后續的設計、實施以及試驗之間的鏈接關系。
4 需求的書寫技巧
4.1 需求語句分析
每一條單獨的需求語句必須包含一個主語、一個謂語和一個賓語,如果需要,也可增加其他補充語句。
主語是即將滿足或執行需求的產品或責任單位。
謂語應以標準的格式出現,“應+動詞”。
賓語則是一段什么必須進行的描述。
狀語描述的是需求發生需要的條件。
定語是對主語或賓語的補充說明。
4.2 提高需求書寫質量的指南
語法正確。
不要出現錄入、拼寫或者標點的錯誤。
需求應被安排至文檔中合適的位置。
避免使用長句和復雜句。
避免使用復合句(如使用類似“和”,“但是”這樣的詞語)。應將句子分割為短句。
避免使用沒有實際意義的詞。
使用強烈的,主動的,準確的動詞。
使用明確的詞語代替藝術化的、有修飾涵義的詞語。
避免一些沒用的介詞。
避免在描述同一事物時,使用不一樣的詞,如“禁止”“不被允許”。
盡量避免使用無法驗證的、模糊的詞語,如適當的、合適的、大概、和/或、最大化、最小化、部分的、充足的等。
應盡量避免使用縮略語。縮略語應該盡量避免,因為可能會影響到需求讀者對需求的理解。如果必須出現縮略語,則所有縮略語必須列在需求文檔的正文之前。
4.3 需求中插圖和表格的使用
一條需求如需用插圖或表格表達,則插圖或表格的內容只能與此條需求相關。
盡管對理解系統工作有幫助,原理圖一般不能作為需求。原理圖既沒有完整的數據流和控制流,也不能提供準確的邊界或者接口。
插圖或表格應代表一個性能在不同條件下的數值。典型的包括差值數值的表格,包線圖等。
4.4 高質量需求檢查單
當編寫需求時,以下檢查單問題需要被考慮:
需求是否含有并只含有一個助動詞“應”?
需求是否包含多個特性要求,是否列為多個獨立的需求更好?檢查復雜的需求,這些需求可能可以分解為別的需求。
需求是否不清楚?
需求所在層級是否正確?
物理上是否可以實現需求?
在項目的約束下是否可以實現需求?
需求是否描述了在哪兒執行、誰來執行、執行的程度,而不是描述怎樣執行?
需求是否包含明確的公差?
需求是否可以通過檢查評審、分析、建模、試驗、展示或相似性的方法進行驗證?一般否定的表達“不應”比較難以驗證,需要檢查。
需求是否可以正確連接至父輩?
是否需要其他需求滿足父輩需求?
需求的來源是否正確?
衍生需求是否有來源?
需求的假設是否正確?
多個相似需求的內容是否真的合適?檢查這些需求,它們可能可以合并一條需求。
需求是否與其他需求沖突?
需求是否是多余的?
5 結語
該文對飛機需求的分類源于SAE ARP4754A規范,通過此分類情況對需求進行編排可使需求組的表達更加清晰,本文還對高質量需求的語句表達形式進行了規范,形成的需求檢查單可以作為需求確認檢查過程的標準。隨著對飛機需求的理解加深,對高質量需求本身的規范性將進一步加強,使得需求的表達更加清晰無誤。
參考文獻
[1] 季建琴.民用飛機需求管理技術研究與應用[J].科技視界,2012(9):55-57.
[2] 鄭占君.商用飛機研制需求管理技術研究[J].航空科學技術,2013(2):50-51.
[3] SAE ARP4754A.Guidelines for development of civil aircraft and systems [S].2010-12.
[4] 郭博智,李浩敏.大型客機設計中的需求管理[J].民用飛機設計與研究, 2013(4):1-5.endprint