需求是項目成敗的關鍵，管理好需求，處理好需求的那些事，至關重要。。
人是解決問題的，工具可以更好的幫你記錄和反饋你解決事情的能力。
Trufun服務目標——國產最專業UML建模工具、需求管理工具、ALM管理工具等
規範軟件開發過程 優化軟件開發流程
保證軟件開發質量 提高軟件開發效率
西安楚凡科技有限公司（Trufun）是全球領先的軟件開發行業應用生命週期管理（ALM）和CASE工具解決方案提供商，倡導"實用、簡潔"的產品理念，擁有業內領先的國產中文UML建模工具，國產中文需求管理工具，國產中文MDA工具等一系列產品。支持軟件開發的整個生命週期，涵蓋需求獲取、需求分析、分析設計、軟件開發、軟件測試、軟件部署等環節。
1. 需求分析
在完成需求獲取所得到的記錄與資料的分析與整理後，項目經理應組織軟件的需求分析工作，建立各需求元素之間的關係，明確分配給軟件的需求、需求的分類、需求的優先級等。
需求分析的方法種類繁多，但常見的需求分析方法主要是結構化分析方法和基於用例的需求分析方法。
Trufun 工具是兩種分析方法都可以支持的。
1.1. 結構化分析方法
結構化分析方法的主要特點是“自頂向下、逐層分解”，它把系統看作一個過程的集合體，利用圖形等半形式化的描述方式表達需求，對問題進行分析，描述工具有：
l 數據流圖（Data Flow Diagram，DFD）：數據流圖是一種圖形化的系統模型，它在一張圖中展示信息系統的主要需求，即輸入、輸出、處理過程、數據存儲。
l 數據字典（Data Dictionary，DD）：數據字典技術是一種有效表達數據格式的手段，它是對所有與系統相關的數據元素的一個有組織的列表和精確、嚴格的定義，從而使用戶和系統分析員對於輸入、輸出、存儲成分和中間計算機有共同的理解。
l 結構化語言：結構化語言是結構化編程語言與自然語言的有機結合，可以採用順序結構，分支機構、循環結構等機制，來說明加工的處理流程。
l 判定表和判定樹：判定表是一種處理邏輯的表格表示方法，其中包括決策變量，決策變量值、參與者或公式；而判定樹則使用像樹枝一樣的線條對過程邏輯進行圖表化的描述。判定表和判定樹用來描述複雜決策邏輯，要遠遠優於使用結構化語言。
l 實體-關係圖（Entity RelationshipDiagram，E-R圖）：E-R圖可以用來描述數據的存儲需求，包括數據實體，數據實體的屬性以及它們之間的關係等。
結構化分析方法從總體上看是一種強烈依賴數據流圖的自上而下的建模方法，它不僅是需求分析計劃，也是完成需求規格化的有效技術手段，使用結構化分析方法時可遵循下列活動：
１） 建立系統的物理模型
首先，畫出系統得數據流圖，說明系統的輸入、輸出數據流，說明系統的數據流情況，以及經歷了哪些處理過程。在這個數據流圖中，可以包括一些非計算機系統中數據流及處理過程的名稱，如部門名、崗位名、報表名等。這個過成可以幫助分析人員有效地理解業務環境。
２） 建立系統的邏輯模型
在物理模型建立之後，接下來的工作就是畫出相對於真實系統的等價邏輯數據流圖。將所有自然數據流圖轉換爲等價的邏輯流。
３） 劃清人機界限
最後，確定在系統邏輯模型中，哪些部分將採用自動化完成，哪些部分仍然保留手工操作，從而清晰的劃清系統的範圍。
1.2. 基於用例的分析方法
從定義中我們得知用例是由一組用例實例組成的，用例實例也稱爲“使用場景”，是用戶使用系統的一個實際的、特定場景。用例是應用程序開發中的一個關鍵技術，主要用來捕獲系統的高層次（High Level）用戶功能性需求。用例分析技術是一種需求合成技術，它利用現有的需求獲取技術從客戶、原有系統、文檔中找到需求，記錄下來，然後從這些零散的需求、特性中進行整理、提煉，從而建立用例模型。
使用用例分析方法時可遵循以下步驟：
1) 識別系統參與者，確定誰會直接使用該系統。參與者是同系統交互的所有事物，該角色不僅可以由人承擔，還可以是其它系統、硬件設備、甚至是時鐘。
2) 合併需求獲得用例。找到所有參與者之後，根據需求獲取所得到的用戶需求，定義每個參與者希望系統做什麼，參與者希望系統作的每件事將成爲一個用例。
3) 繪製用例圖。將所識別的參與者以及所定義的用例通過用例圖的形式整理出來，以獲得例模型的框架。
4) 細化用例描述。用例描述包括以下幾個部分：
l 用例名稱；
l 用例參與者；
l 用自然語言對用例進行簡要的描述；
l 描述參與者何時使用該用例，即用例的觸發條件；
l 描述在一般情況下，參與者使用該用例時會發生什麼事情，即用例的基本過程；
l 在基本過程的基礎上，考慮一些可變情況，把他們創建爲擴展用例；
2. 需求定義
需求定義的目的是根據需求獲取和需求分析的結果，進一步定義軟件需求，產生《需求規格說明書》。
2.1. 標識需求
爲了確保需求的易跟蹤、易修改，需求分析師應通過需求編號的方式唯一標識每一個軟件需求，明確需求的跟蹤粒度，並體現於需求規格說明書
2.2. 定義需求的優先級
需求分析師應確定每個需求的優先級並寫入需求規格說明書，需求的優先級的評價
標準如下：
|
級別定義 |
判斷標準 |
採取措施 |
|
高 |
滿足以下任意一條時： １） 需求實現的緊急程度爲特急或緊急 ２） 國家或行業法律法規、標準要求的，客戶明確要求的,滿足正常業務必須的。 |
對於這些需求在項目實施過程中需重點投入資源，優先實現，只有在這些需求上達成一致意見，軟件纔會被接受；必須完美地實現。通常這類需求在當前版本必須實現。 |
|
中 |
滿足以下任意一條時： １） 客戶隱含要求，對正常業務影響程度不大 ２） 需求實現的緊急程度爲中 ３） 支持必要的系統操作，實現這些需求將增強產品的性能，是產品最終所要求的。 |
這些需求必須被實現，但如果項目實施中出現進度、資源等方面的衝突時，如果有必要，可以延遲到下一版本；需要付出努力，但不必做得太完美。 |
|
低 |
滿足以下任意一條時： １） 功能或質量上的附加功能； ２） 實現這些需求會使產品更完美，若不實現也不影響產品的功能與性能，屬於錦上添花； ３） 需求實現的緊急程度爲低； |
實現或不實現均可；可以在項目組有較足夠的時間時考慮這些需求的實現 |
優先級的定義有利於幫助項目組在項目的範圍、進度、資源、預算等相關制約因素之間產生衝突時，能夠正確地對需求實現的範圍或實現的優先程度做出取捨。一個實現這種權衡的方法是：當接受一個新的高優先級的需求或者其它項目環境變化時，刪除低優先級的需求，或者把它們推遲到下一版本中去實現。
2.3. 編寫《需求規格說明書》
需求分析師在需求分析過程中根據分析步驟逐步編制形成《需求規格說明書》。編寫需求規格說明書應遵循以下規則：
l 相關的需求都得到了識別與描述，以確保需求的完整性；
l 各個需求之間不衝突，算法之間不相互矛盾，以確保需求的一致性；
l 正確描述系統需求，引用的資料有正規的出處，以確保需求的正確性；
l 定義必要的術語，適當結合圖形、結構圖等方式進行描述，以確保需求無二義性；
l 使用較好的文檔結構與需求標識，使需求能夠方便地與其它工作產品相對應，以確保需求易於追溯；
l 確保所描述的需求可以通過適當的手段得到驗證，即需求的可測試性；
l 考慮了各個層次的需求，確定了需求的優先級，以確保需求的可行性。
《需求規格說明書》可以包括但不侷限於：
l 需求描述約定
l 系統概述，如系統功能、業務描述、數據流程描述、用戶的特點、運行環境要求、設計與實現上的限制等
l 功能需求描述
l 非功能性需求，如系統性能要求、***備份與恢復要求、系統日誌等。
l 外部接口說明，如軟硬接口、通信接口等
l 其它需求描述
l 功能列表等
3. 需求確認
需求確認是指項目組和客戶（或客戶代表）共同對《需求規格說明書》進行評審，雙方對需求達成共識後做出承諾。需求確認包含兩個重要工作：“需求評審”和“需求承諾”。
3.1. 需求評審
應對所形成的需求文檔進行評審，以便作爲下一階段工作的基礎。需求評審的方式分爲“技術評審會議”。
項目組根據需求分析的進展情況，採用“組內評審”的方式分階段對需求分析的階段成果進行評審，分階段評審可以將原本需要進行的大規模評審拆分成各個小規模的評審，降低了需求返工的風險，提高了評審的質量。組內評審要求：
l 評審組長：項目經理；
l 評審組成員：需求分析師、系統分析師、測試工程師，適當邀請組外專家參與；
l 輸入：《需求規格說明書》初稿
l 輸出：會議紀要
l 檢查單：需求評審檢查單
項目組只有在完成組內評審、並完成問題修改與驗證後，方可向公司提出技術評審會議申請。當需要召開技術評審會議時，由項目組向項目管理部門提出需求技術評審申請和組內評審會議紀要，項目管理部門完成文檔規範性、完整性檢查，並確認已經通過內部評審後，提交評審管理部門，由評審管理部門組織按“技術評審會議”的方式實施需求評審。技術評審會議要求如下：
l 評審組織部門：評審管理部門
l 評審組成員：
a) 項目組代表
b) 測試組代表
c) 公司的技術專家與業務專家
d) 實施組代表
e) 客戶或客戶代表
f) 系統關聯組代表
g) QA工程師
l 輸入：需求規格說明書以及相關文檔
l 輸出：評審報告
l 檢查單：需求評審檢查單
關於“技術評審會議”的要求詳見《評審規程》。
3.2. 需求承諾
項目經理將評審通過的《需求規格說明書》提交給客戶（或客戶代表）、系統關聯項目組進行確認，確認的方式可以是以下方式之一：
l 直接簽字：由承諾方在評審報告上直接簽字或蓋章確認
l 郵件方式：由項目經理將《需求規格說明書》與評審報告通過郵件發送給接收方，並明確確認通過的準則（如：如果在一週內未予以回覆則默認爲確認通過）；
l 發送會議紀要函：如果承諾方參加了評審會議並在會上達成了共識，則可以編制會議紀要在紀要中描述參加評審的人員、評審的結論等，並通過紀要函的方式發送給承諾方。
3.3. 建立需求基線
項目的需求規格說明書經過評審與確認後，應根據《配置管理過程》的要求建立需求基線。
4. 需求變更
對一個軟件項目來說，無論最初的需求分析有多麼明確，開發過程中的需求變化也還是不可避免的。這主要有以下幾種原因：
1. 軟件所應用的外部環境發生變化；
2. 隨着用戶對軟件的熟悉和應用，又提出新的需求；
3. 項目組進行需求分析時未能徹底分析用戶的需求，或分析錯誤；
4. 用戶在開始時不能很全面的知道所需軟件的功能。
4.1. 需求變更申請
需求變更由變更申請人通過填寫《軟件變更申請表》向項目組提出進行。
當項目組接收到項目管理部門的《軟件變更申請表》時，應先根據要求進行需求的評估，判斷需求的類型、分析需求變更影響到的範圍、估算需求實現的工作量（含需求、設計、編碼、測試、用戶文檔編寫）、預計可以完成的時間等內容。若估算的開發工作量大於10人月時，項目組可以根據《項目立項過程》的要求向項目管理部提出項目立項申請；若小於10人月，且評估結果與申請部門達成共識，則開發項目組根據《計劃變更規程》實施變更，若無法達成共識，則提交研發部進行最終裁定。
4.2. 需求變更的實施
項目組根據《計劃變更規程》中的要求實施變更。
在變更完成後，若需要發佈新的需求基線，項目組應根據《配置管理過程》中“基線發佈”的要求重新建立需求基線，並通知相關的人員。
5. 需求跟蹤
對一個軟件項目來說，當需求確定下來以後，應該保證在軟件設計過程中每個需求都被實現，且項目的其它工作產品與需求保持一致。因此，一個比較好的方法就是建立一種需求雙向跟蹤機制。雙向跟蹤即：
l 正向跟蹤：當發生需求變更時，通過從需求向後追溯到下游相關工作產品，可分析出這些關聯項是否需要變更，從而達到追溯的目的；
l 逆向跟蹤。通過從下游工作產品回溯到需求，可分析需求是否得到滿足，從而達到回溯的目的。
進行需求雙向跟蹤的一個簡單的方法是建立一個映射，從需求到設計，從設計到編碼，以及從編碼到測試用例，把每個需求都映射到對應的位置。這個映射可以用需求跟蹤矩陣來實現。
5.1. 建立需求跟蹤矩陣
當《需求規格說明書》通過評審之後，項目經理應組織根據確定的需求跟蹤的粒度編制《需求跟蹤矩陣》。項目經理指定人員對需求跟蹤矩陣進行個人複查，確保跟蹤粒度合理、跟蹤項適用。
5.2. 需求跟蹤矩陣的維護與使用
隨着軟件設計、編碼、以及測試開發的不斷推進，項目經理應指定專人在項目的各個階段產品形成時，將相關的信息填入需求跟蹤矩陣，建立階段工作產品與需求的對應關係，並由項目經理指定人員對其完整、正確、一致性進行確認。對於已納入需求跟蹤矩陣的相關工作產品產生的變更，則由項目經理在每次變更完成後根據變更修改需求跟蹤矩陣的對應關係，在每個里程碑時由項目經理指定人員負責對跟蹤矩陣的完整、正確、一致性進行確認。
在項目實施過程中，項目組可以利用需求跟蹤矩陣實施相關的控制，如：
l 利用需求跟蹤矩陣，審覈所有定義的需求是否已經在相關產品中得到實現；
l 當發生需求變更時，可以利用需求跟蹤矩陣受需求變更影響的其它工作產品，確保不忽略每個受到影響的系統元素；
l 當相關的工作產品產生變更時，可以向前追溯到與其相關的需求與其它工作產品，從而判斷是否需要對這些關聯產品進行變更；
在開發過程中，可以對所有定義的需求的當前開發狀態進行跟蹤。
Trufun SDP提供了滿足從軟件開發的全生命週期支持，從專業的需求管理開始到UML分析設計、編碼開發、軟件測試等環節，並且可以實現從需求的一一對應。