從本質上講，所有的模型都是錯的，但有些模型是有用的。
——George E. P. Box
SAFe需求模型
為了支持將精益和敏捷開發的好處帶給大型企業，或帶給構建更復雜系統的小型企業，SAFe提供了一個可擴展的需求模型，該模型展示了一種表達系統行為的方法：史詩（Epics）、能力（Capabilities）、特性（Features）、故事（Stories）、非功能需求（NFR，Nonfunctional Requirements）等等。如圖1所示，每一個工作項都以不同的方式表示。
例如，特性（feature）是由短語（phrase）、收益假說（benefit hypothesis）和驗收標準（acceptance criteria）來描述；故事（story）由用戶發言陳述（user-voice statement）和驗收標準（acceptance criteria）來闡述。
這些工件主要是用基于精益-敏捷開發（Lean-Agile development）的新范式來取代傳統的系統和需求規格說明書（requirements specifications），同時也是為了幫助團隊避免過早關注一個點的解決方案、避免在學習過程的開始就選擇具體的需求和設計。相反，它們鼓勵為基于意圖而非具體內容的涌現認知留下空間。
此外，還包括屬性（attributes）、驗收指南（acceptance guidelines）和測試（testing）的模式和關系，以支持同樣適用于世界上最重要系統的NFRs。
總的來說，這是一個綜合的模型，如圖1所示。
大多數從業者只需要這些條目中的一部分。例如，敏捷團隊主要采用用戶故事、故事驗收測試（story acceptance tests）和NFRs。然而，每個元素的設計都是為了在SAFe的各個層面提供適量的行為表達和測試。
這篇指導文章適用于那些需要知道如何將其作為一個系統一起運作的顧問和SAFe專家，以及那些圍繞SAFe提供工具（在這里語義必須是明確的）的人。
如果這個模型看起來很復雜，那是因為當代大規模軟件和系統的開發是很復雜的，即使使用敏捷開發也是如此。如果一個元素是不需要的，那么就不需要使用它。然而，那些正在建立世界一流的企業解決方案的團隊和項目可能可以應用這些元素中的大多數。
了解更多
Last update: 10 February 2021
