軟體需求分析與管理的十個問題

軟體需求分析與管理的十個問題

1.需求工作涉及到哪些內容

首先需求包括了產品需求，使用者需求，軟體需求。產品需求關注的是產品的標準化和通用化，會對收集到的使用者需求進行分類和最佳化，結合業界標準系統模型進行抽象並通用化。使用者需求反映的是使用者面臨的問題域，根據問題域使用者期望的能夠達到的解決效果；而對於軟體需求則是用軟體工程的語言結構化和文檔化的對使用者需求和產品需求的描述。

需求工作涉及到需求開發和需求管理。需求開發涉及到需求調研，需求收集，需求分析，需求開發等工作，其中的重點有商務程序，資料字典，商務規則，介面原型。對於基於物件導向的開發方法則涉及到業務用例，系統用例(涉眾，基本流，擴充流，商務規則，介面，操作)等諸多內容。需求管理工作涉及到需求的狀態管理，變更管理，需求的跟蹤，需求的驗證和確認等重要內容。

在我們需求分析和開發中，最容易忽視的主要有兩點，一個就是缺乏需求分析和開發的過程，把使用者需求直接作為了軟體需求，沒有需求建模和抽象的過程。另外一點就是對於效能，安全，易用性，可維護性和擴充性等非功能性需求沒有考慮，導致開發出來的系統是一個不好用的半成品。CMMI把需求管理放到2級，需求開發放到3級，實際上真正的提高需求人員的需求分析和開發能力才是解決需求問題之道。需求分析開發做不好，需求變更或追蹤管的再好也沒有用處，在這點上一定不能本末倒置。

2.做好需求分析需要具備哪些知識

需求分析崗位主要承擔的是系統分析員的工作，做需求分析的人員要有軟體工程基礎知識的積累，而且最好有一定的軟體開發經驗積累。自己做過設計開發工作的才能夠體會到如何才能夠把系統做好，如何更好的把軟體需求和後續實現更好的銜接起來。有一本《軟體需求》的書講的很系統，從事需求工作的都值得仔細閱讀。對於採用物件導向的需求開發和分析方法的，一定要熟悉RUP統一過程和用例分析和建模。

對於管理軟體都離不開其涉及到的業務領域，因此要做好需求分析工作必須要熟悉管理軟體所涉及到的業務領域，對業務領域相關的標準模型進行分析和研究，對業界的一些標準和最佳實務進行熟悉。比如做供應鏈管理系統和軟體應該熟悉業界標準的SCOR模型，做ERP的應該結合現在的業界比較大的廠商的ERP產品進行學習，對於研發管理系統可以結合PACE和IPD等等。只有熟悉了業務領域才可能在需求調研和分析的時候提供很多有建設性的意見，或者說需求分析人員不是被使用者牽著走，而是真正的可以引導使用者。

3.需求分析的步驟和輸出有哪些

開始首先是需求的收集，需求收集可以通過調查表，訪談，業界標準，會議討論溝通等多種方式進行。需求收集第一是要能夠很好的描述現狀，第二是要搞清楚使用者的期望。同時一定要弱化使用者期望系統怎麼做，因為使用者並不熟悉系統實現和內部原理，我們的軟體需求不僅僅考慮的是功能的實現，還需要考慮需求複用，業務抽象，可擴充和配置等多方面的問題。

收集回來的需求就需要開始進行分析工作，分析包括了動態行為分析和待用資料分析。動態行為分析涉及到用例分析，商務程序和活動輸入輸出的分析，資料流分析，業務操作規則分析。待用資料分析設計到業務對象建模，資料字典，組織圖，許可權等分析。在這一個階段的重點就是需求的系統化和結構化，最好要體現到規範的文檔中。在軟體開發過程中我們最強調的需要文檔化的輸出就是需求文檔和總體設計方案文檔。

需求分析階段還有一個重點的產出就是原型和DEMO，為了更好的和使用者溝通並挖掘需求，我們需要將我們理解後的想法更加形象的講述給使用者，所以原型就顯得額外重要。不管是否是拋棄的原型，都需要客戶看到的原型和最終實現的系統基本一致，因此原型開發需要投入一定的時間，並根據客戶回函的資訊不斷修正。在原型中多投入些時間，就會多減少一份後期需求變更引起的返工時間。軟體原型是降低需求變更風險的有效方法。

4.需求的抽象和建模體現在哪些方面
 
首先要理解需求分析和設計的目的在於滿足現狀並適應變化。要想適應變化則業務建模和需求抽象就是必須的。當我們瞭解到業務的組織圖和流程經常面臨變動和調整的時候，我們就需要考慮引入標準的組織圖模型，許可權模型和工作流程模型。這些模型的引入使業務和需求的變動變化為通過系統的靈活配置來適應。軟體系統要適應變化不是從設計階段開始的，而是我們的軟體需求本身就需要適應變化。

需求的抽象包括了對業務物件模型的抽象，對商務規則的抽象，對流程的抽象。其中最重要的就是由業務對象抽象形成的概念性模型，由流程抽象形成的資料互動模型。對於一些快速軟體開發平台理解到的對象建模，流程建模，組織圖和許可權建模，商務規則建模，BPEL商務程序編排恰好就是需求抽象的最主要內容。

要做好需求抽象必須具備兩方面的知識，第一是真正的對所涉及到的業務領域及其標準模型足夠理解，其二是對軟體系統分析和架構設計有較多的經驗積累。只有同時具備這兩方面知識才能夠做好需求建模工作。

5.需求的驗證和確認包括哪些事情

我們可以再簡單理解下驗證和確認的區別，對於判斷最終開發出來的系統是否和使用者想要的東西是一致的過程叫確認，對於你理解和描述的需求和我當初的想法是否是一致的過程叫驗證。需求的驗證封裝括了很多的內容，涉及到軟體開發中上下遊相關人員的參與。首先你結構和文檔化後的需求需要使用者來驗證是否和他們的想法是一致的，是否把使用者的真實意圖描述清楚了，以保證需求本身的正確性。對於後續設計開發階段的人員也需要對需求進行評審以保證需求的可實現性，確認需求描述是否清楚，是否是可以實現的，對於業務對象，流程和規則是否存在不可實現的模糊描述詞語。對於測試人員，則主要是確認需求是否是可測試的，是否在需求描述中引入了較多的易用，較好，應該等不確定和不可測試的詞語。對於大型的軟體項目，如果有專門的產品化標準和UI組的話，還需要對需求的易用性和產品互動等方面進行評估，以評價整個軟體系統的產品化。

確認主要是軟體系統已經開發完成後交付給使用者後驗收的時候，使用者確認系統是否實現了當初的需求。為了保證確認過程的順利，就必須重視需求驗證的過程，需求驗證不僅僅是需求階段對需求文檔的評審，還需要關注設計，開發等各階段對需求的實現情況的驗證。

6.為什麼要做需求管理，需求管理組件括哪些工作?

需求管理就是IT項目中的範圍管理，需求管理是整個IT項目的源頭，IT項目的估算，計劃，後續的跟蹤控制，驗證和確認等各項工作都是跟需求密切相關的。因此為了保證項目的進度，品質和成本的目標的順利實現，保證專案計劃的嚴肅性和可執行性；為了保證軟體系統最終開發的產品正是客戶期望的產品，必須要做好需求管理工作。

需求管理工作應該是需求全生命週期的管理，從使用者原始需求的提出，到最終形成軟體產品後使用者對需求實現情況的驗證以形成閉環流程。因此我們需要跟蹤和瞭解到需求狀態的演變過程。大型的項目軟體生命週期模型較為複雜，一個需求的實現會經過使用者需求，軟體需求，總體設計，詳細設計，開發和單元測試，整合測試，系統測試和驗收測試多個環節，在這個過程中需要建立需求追蹤以確認需求和中間階段產生的工作產品的一致性。另外變更管理是需求管理的另外一個重點，需求在經過評審確認後需要基準並受到控制，當出現需求變更的時候必須進行相應的需求影響分析以確認對需求變更的處理方式，當變更工作量影響較大的時候還需要調整並重新基準專案計劃。

對於整個需求調研，分析和需求開發，評審確認的過程也需要進行管理。在這個過程中的一個重點就是對需求輸出的文檔需要得到使用者，項目組設計開發人員的共同確認和承諾。

7.需求變更管理重要性體現在哪裡?有哪些具體的內容

使用者不斷的提交需求修改，項目進度無任何保證不斷延期；由於一次需求的修改導致原來本來穩定的系統出現各種原來沒有想到的錯誤和異常；這些都是需求管理存在缺陷的表象。需求管理的重要性就體現到專案計劃的嚴肅性和可執行性，以保證項目目標的實現。通過引入了需求變更管理後，使軟體需求文檔成為一份大家都共同承諾和作為依據參考的文檔，這個文檔需要在設計，開發，測試等多種角色之間充分傳遞和共用。另外通過需求管理工作，使每個人意識到變更對項目的影響和變更的代價，反向去促進需求開發品質的提高。

需求變更管理包括了變更請求的提出，CBB委員會對需求進行影響分析確認是否變更，設計開發負責人確認需求變更將影響到的模組和代碼和具體修改方法，開發人員對變更進行修改和測試，最後再有變更請求人對需求變更滿足情況進行驗證。對於變更的影響分析一般需要項目組的開發負責人進行，大型項目可以依靠需求管理中建立的需求追蹤進行分析，但根據實踐需求追蹤在影響分析中的作用還不明顯。

8.需求是否必須要文檔化，其意義體現在哪裡?

SRS需求文檔是整個軟體開發過程中最重要的一份文檔，無論項目的大小個人的意見是關於需求文檔都需要考慮正常化和文檔化。這份文檔是使用者，專案經理，需求，設計開發，測試人員多方溝通的基礎，使大家對需求有一致的理解並依據該文檔開展各項工作。即時是對于敏捷軟體開發，我們也需要對用例情境描述，CRC卡片等文檔化下來以方便溝通。

再次強調溝通，特別是面對面的溝通是資訊傳遞最高效方式，但是當一個資訊是需要在軟體開發整個生命週期的不同階段，由不同角色人員多次使用的時候，就必須文檔化。而需求文檔恰好屬於這種類型。

9.中小型軟體Team Dev需求開發和管理工作的重點在哪裡?

對於中小型的項目團隊一定要使用輕量級的方法論和過程，過程是為了實現目標服務的，過程的目的是為瞭解決現在的問題和可能的問題。不在這個範圍內做的過程，規則或工作都不會產生價值和意義。

對於中小型團隊首先是要意識到需求工作的重要性，制定需求文檔和DEMO介面規範，對需求進行文檔化和結構化。其次是對開發完成的需求需要得到使用者，實現人員，測試等多方的評審和認可。最後是需求文檔化後該工件需要通過各種組態管理工具進行管理，需求完成後及時歸檔和受控，需求的變更需要受到管理而不是隨意的。

10.需求優先順序的作用，如何評估需求優先順序?

需求優先順序的作用在於專案管理和使用者滿意度提升的需要。一個系統上線後經常出現情況就是往往經常使用的功能都集中在20%的功能上很多功能使用很少。需求優先順序讓我們更好的把握重點和分配資源，真正的把20%最重要的需求，經常使用的需求做好做精，只有這樣才能夠真正的提高使用者滿意度和達到項目目標。

需求優先順序對於使用者往往最有發言權，但當一個系統涉及到多個業務部門和組織圖的時候，難免出現各個使用者都站在自己的立場來看待需求的優先順序和緊急程度的問題。但是一個需求究竟對效率提升，成本的減少，相關周期的縮短起到了多大的貢獻和作用卻沒有衡量。因此對需求優先順序的評估應該考慮引入價值工程的概念，一個需求的優先程度應該體現在需求實現後能夠產生的價值和節約的成本。