需求編寫十佳經驗

【IT168 技術文章】

    需求表述不善可帶來毀滅性影響，其所引起的多米諾效應可致使耗時返工、延期交付及預算超支，嚴重的還可形成業務違規甚至人員傷亡。

    近年來，隨着ISO9000、CMM/CMMI、六西格碼等國際標準逐步引入中國，「需求管理」正成爲中國當前工程應用和商業熱域的熱點。目前，有關需求管理的實踐大量應用於軟件開發工程等領域，軟件開發團隊在開始一個新的項目以前，會經過詳細的用戶需求調研準確捕獲了用戶需求並彙總分析後，再進行下一步的設計與實施工做，以免因未能正確識別用戶的真正需求而致使不斷返工和工做成本增長。

    對於從事軟件工程的程序員們來講，在進行項目開發以前建立和管理良好的需求是很是重要的第一步，同時也是一項挑戰。需求表述不善可帶來毀滅性影響，其引起的多米諾效應可致使耗時返工、延期交付及預算超支，嚴重的還可形成業務違規甚至人員傷亡。所以，開發團隊須要首先有效定義和管理需求，才能確保在保證進度和控制預算的同時，產品可以知足用戶所需。

    良好需求的特徵　　　　　　　　　　　　含義

    正確(Correct)　　　　　　　　　　　　 技術可行，內容合法

    完整(Complete)　　　　　　　　　　　　可以表達一個完整的想法

    清晰(Clear)　　　　　　　　　　　　　 不模棱兩可，不易被誤導

    一致性(Consistent)　　　　　　　　　　不與其它需求相沖突

    可驗證性(Verifiable)　　　　　　　　　可驗證系統可以知足用戶須要

    可追蹤性(Traceable)　　　　　　　　　 可惟一識別並進行跟蹤

    可行性(Feasible)　　　　　　　　　　　可在預期成本和計劃進度內完成

    模塊化(Modular)　　　　　　　　　　　 可單獨變動而不會形成較大影響

    獨立於設計(Design-independent)　　　　不包括項目設計和實現的細節、計劃信息等

    本文旨在闡述良好需求描述的特徵，並介紹有助於更好地編寫軟件工程需求說明文檔的十佳經驗，以幫助軟件開發團隊可以更快更好地取得投資收益。

    高質量需求的特徵

    首先的問題是，何爲良好的需求？通常而言，一項編寫良好的需求描述，應該包含如下特徵（見表1）:

    同時，一項需求描述應該用一個包含主語和謂語的完整句子來表述，使用「應該」「必須」等詞來代表其強制性，使用「能夠」等詞來指明可選性。一個完整的需求還應寫明預期達成的目標，幷包含質量的達標標準或其它可測量的指標。

    提升需求編寫質量的十佳經驗

    在明確了何爲良好的需求以後，如下介紹十個能夠幫助開發團隊編寫出更好的需求描述的方法，加速軟件工程投資回報率。

    經驗1:將需求結構化(Structuring)

    每一項需求既不能被重複描述也不能被遺漏，訣竅之一是將需求結構化。需求組織應具備良好的結構，以增進理解，同時避免出現重複和忽略的狀況。同時，須具有對需求的向上和向下的追溯能力以後，團隊纔可以評估需求的覆蓋範圍。結構化組織需求是控制和改善需求質量的第一步。

    經驗2:把握好用戶須要(customer needs)、項目需求(requirments)和合同文本(contractual documents)之間的互動關係

    用戶須要是指軟件的使用者對於軟件所能實現的功能的指望及操做便利性上的要求;軟件工程項目中的需求，則是將這些用戶須要經過特定的描述方法從新表述爲程序開發者能夠識別並據此工做的說明性語句。

    一個項目需求一般會比用戶的某項須要在描述上更加共性化，以便知足多個用戶的須要。此外還常常會有一份工做合同來約束開發團隊和軟件使用方之間的工做關係。開發團隊要把握好這三個因素之間的互動關係，把它們互相關聯起來進行有機的管理，這能大大提升項目成功的概率。

    經驗3:重視非功能性需求(Constraints)

    對於編寫需求說明書而言，涉及法規聽從和提升軟件系統質量的非功能性需求（又稱約束條件，Constraints）一樣重要，它們一般包括軟件的性能、界面和可維護性等方面。

    編寫良好需求應包含對約束條件的覆蓋，緣由是一旦以下領域（例如，性能、可靠性和易用性等）在開發完成後出現缺陷，一般都沒法在系統中對其進行從新設計。所以，在項目初期將全部類型的非功能性需求考慮在內，可幫助開發團隊大幅提升項目成功的概率。

    經驗4:將需求可視化(Visualization)

    大多數需求分析人員發現建模有助於直觀化文字形式的需求。不管是在白板上繪圖、使用Microsoft PowerPoint演示工具，仍是僅僅在腦海中構建一個模型，均可視爲一種建模方法。以上這種圖型化的文檔應與文字形式的需求描述一塊兒統一管理，以確保一致性、可跟蹤性和變動控制能力。可視化需求建模提供了一種與客戶及最終用戶溝通的簡單而有效的方法，經過該方法可較容易地掌握客戶和最終用戶的需求。此外，圖型化還有助於闡明需求，增進軟件項目全部相關人員之間的溝通與協做。

    經驗5:使需求具有可測試性(Testable)

    產生良好需求的另外一種行之有效的方法，就是從初期就確保每一個需求具有明確的可驗證性，這種作法不只有助於爲項目後續階段作好準備，還能夠幫助編寫者保持正確的思路。

    對於非功能性需求此規則也一樣適用，例如，對於「軟件必須具備高可用性」這種表述的需求咱們沒法進行測試，而改寫成明確的「普通用戶應可以在3分鐘內生成一個報告」就使該需求具有了可驗證性。

    經驗6:在客戶需求和開發能力之間找到平衡

    許多狀況下，較少的需求數量有助於產生更加優秀的需求描述。軟件工程項目不可能實現既採納和知足企業全部用戶的需求、營銷理念和商業計劃，同時還符合預算並能定期交付。項目經理必須找到客戶需求和開發能力之間的平衡點，肯定可爲客戶帶來最大價值，並幫助企業提高創新能力的那些需求，而不是一味地試圖知足用戶全部需求。

    經驗7:管理好需求變動

    大多數軟件工程項目中，來自用戶的需求常常會發生變化。隨着項目的進展，開發團隊要保持清醒的頭腦、按照工程要求作出相應調整，並響應不斷變化的市場形勢和客戶須要。僅僅編寫出完美的首版需求描述是不夠的，若是未能對需求的變動過程進行恰當管理，那麼控制不善的變動即可能致使系統和軟件功能缺失、返工以及利潤損失。開發團隊應該實施可靠的、可重複的變動控制流程，藉助Telelogic DOORS?、Telelogic Change?等工具，實施成熟的變動管理解決是一個良好途徑。

    經驗8:善於利用監測與跟蹤工具

    複雜的項目都要求實現自動數據收集功能和簡便的報告流程，以簡化項目管理工做。一樣地，項目經理和全部利益相關者都應擁有計量和趨勢的「管理面板」，該面板可幫助他們快速監視項目活動（如，進展、增加和實際需求的變更等）。

    項目經理應將其主要精力放在制定決策上，而不是放在手動收集數據和編制報告方面。更爲重要的是，必須高水準地顯示主要需求的監視信息，從而使用戶可以根據異常狀況實施管理，並迅速查明故障區域。若是某需求或整個子系統變動頻繁，則表示應就該需求對客戶進行二次調查。若是執行階段出現大規模返工的狀況，則表示原始需求表述不妥。跟蹤和分析趨勢是CMMI第4級和第5級的主要內容，經過這些活動，企業的需求編寫質量可獲得持續改善。

    經驗9:創建範例知識庫(Knowledge Database)

    提升需求質量的另外一有效途徑是創建範例知識庫，並參考其中的典型範例。知識庫內容應該包括:良好需求和文檔的正、反面示例，以往項目中可反映團隊在特定領域內專門知識的良好（和不良）需求。爲了使開發團隊能夠更好的參考，知識庫中的需求案例應具有明顯的積極或消極意義，而非中規中矩的。經過知識庫示例開發團隊能夠參考以往的經驗、吸收教訓，避免重蹈覆轍，進而提升需求編寫的質量、一致性和完整性。

    經驗10:正確的重用以往優秀需求

    當以前項目的已編寫的良好需求適用於當前狀況時，不要單純地將原有需求直接複製。從新使用以往需求的正確方法是繼續維持兩個需求之間的聯繫，如一般打上re-use標記。此標記使分析人員可以隨時查找到原始需求，以檢查需求分解分配等信息。經過靈活的方法從新用以往需求，開發團隊能夠得到技能、經驗和知識的共享。

    編寫好的需求說明是一個開發項目最爲重要的活動之一，優秀的需求描述能夠改善並加速項目的投資回報。就好像「垃圾輸入，垃圾輸出(garbage in, garbage out)」所代表的那樣，若是前期用戶需求收集得不明確，那麼後期的開發過程註定生產錯誤的產品。開發團隊能夠經過經驗提高需求編寫質量。此外，經過應用業界領先的Telelogic DOORS等需求管理工具，能夠優化項目開發的溝通和協做的過程，提高軟件項目過程質量。