軟件項目需求分析與管理的十大疑問

軟件項目需求管理是指一個爲系統的需求進行啓發、組織、建檔的系統方法，一個創建和維護客戶和項目團隊之間關於變動系統需求所達成的一致性的過程。軟件需求分析就是把軟件計劃期間創建的軟件可行性分析求精和細化，分析各類可能的解法，而且分配給各個軟件元素。需求分析是軟件定義階段中的最後一步，是肯定系統必須完成哪些工做，也就是對目標系統提出完整、準確、清晰、具體的要求。那麼，在實際管理工做中，會有哪些疑問呢？

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

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

需求工做涉及到需求開發和需求管理。需求開發涉及到需求調研，需求收集，需求分析，需求開發等工做，其中的重點有業務流程，數據字典，業務規則，界面原型。對於基於面向對象的開發方法則涉及到業務用例，系統用例(涉衆，基本流，擴展流，業務規則，界面，操做)等諸多內容。需求管理工做涉及到需求的狀態管理，變動管理，需求的跟蹤，需求的驗證和確認等重要內容。

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

2.作好需求分析須要具有哪些知識

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

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

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

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

收 集回來的需求就須要開始進行分析工做，分析包括了動態行爲分析和靜態數據分析。動態行爲分析涉及到用例分析，業務流程和活動輸入輸出的分析，數據流分析， 業務操做規則分析。靜態數據分析設計到業務對象建模，數據字典，組織結構，權限等分析。在這一個階段的重點就是需求的系統化和結構化，最好要體現到規範的 文檔中。在軟件開發過程當中咱們最強調的須要文檔化的輸出就是需求文檔和整體設計方案文檔。

需求分析階段還有一個重點的產出就是原型和DEMO， 爲了更好的和用戶溝通並挖掘需求，咱們須要將咱們理解後的想法更加形象的講述給用戶，因此原型就顯得額外重要。不論是否是拋棄的原型，都須要客戶看到的原 型和最終實現的系統基本一致，所以原型開發須要投入必定的時間，並根據客戶反饋的信息不斷修正。在原型中多投入些時間，就會多減小一份後期需求變動引發的 返工時間。軟件原型是下降需求變動風險的有效方法。

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

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

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

5.需求的抽象和建模體如今哪些方面

首 先要理解需求分析和設計的目的在於知足現狀並適應變化。要想適應變化則業務建模和需求抽象就是必須的。當咱們瞭解到業務的組織結構和流程常常面臨變更和調 整的時候，咱們就須要考慮引入標準的組織結構模型，權限模型和工做流模型。這些模型的引入使業務和需求的變更變化爲經過系統的靈活配置來適應。軟件系統要 適應變化不是從設計階段開始的，而是咱們的軟件需求自己就須要適應變化。

需求的抽象包括了對業務對象模型的抽象，對業務規則的抽象，對流程的抽象。其中最重要的就是由業務對象抽象造成的概念模型，由流程抽象造成的數據交互模型。對於一些快速軟件開發平臺理解到的對象建模，流程建模，組織結構和權限建模，業務規則建模，BPEL業務流程編排剛好就是需求抽象的最主要內容。

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

6.爲何要作需求管理，需求管理包括哪些工做?

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

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

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

7.需求變動管理重要性體如今哪裏?有哪些具體的內容

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

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

8.需求是否必需要文檔化，其意義體如今哪裏?

作人員多方溝通的基礎，使你們對需求有一致的理解並依據該文檔開展各項工做。即時是對於敏捷軟件開發，咱們也須要對用例場景描述，CRC卡片等文檔化下來以方便溝通。

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

9.需求優先級的做用，如何評估需求優先級?

需求優先級的做用在於項目管理和用戶滿意度提高的須要。一個系統上線後常常出現狀況就是每每常用的功能都集中在20%的功能上不少功能使用不多。需求優先級讓咱們更好的把握重點和分配資源，真正的把20%最重要的需求，常用的需求作好作精，只有這樣纔可以真正的提升用戶滿意度和達到項目目標。

需 求優先級對於用戶每每最有發言權，但當一個系統涉及到多個業務部門和組織結構的時候，不免出現各個用戶都站在本身的立場來看待需求的優先級和緊急程度的問 題。可是一個需求究竟對效率提高，成本的減小，相關週期的縮短起到了多大的貢獻和做用卻沒有衡量。所以對需求優先級的評估應該考慮引入價值工程的概念，一 個需求的優先程度應該體如今需求實現後可以產生的價值和節約的成本。

10.中小型軟件開發項目團隊需求開發和管理工做的重點在哪裏

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

對於中小型團隊首先是要意識到需求工做的重要性，制定需求文檔和DEMO界面規範，對需求進行文檔化和結構化。其次是對開發完成的需求須要獲得用戶，實現人員，測試等多方的評審和承認。最後是需求文檔化後該工件須要經過各類配置管理工具進行管理，需求完成後及時歸檔和受控，需求的變動須要受到管理而不是隨意的。