淺析計算機軟體專案管理中的需求分析
General 更新 2024年11月05日
論文關鍵詞:需求分析 使用者方干係人 專案經理 需求分析員
論文摘要:計算機軟體專案管理中的需求分析是提高軟體質量的基礎也是決定一個軟體專案成敗的關鍵。本文介紹了在需求分析研究中探索出的一些有效措施。
眾觀國內計算機軟體業的發展，除遠不如歐美等西方發達國家外，與人均GDP不及我國的印度相比也相距甚遠，軟體業的劣勢正嚴重製約著我國IT業的發展。我國軟體業的劣勢表現在自主開發的成熟軟體不多，而開發的大量軟體工程專案***如ERP等***存在缺陷或完全開發失敗。目前，國家正在加大對軟體工程的研究和對軟體工程人才的培養。根據資料顯示，屬於需求分析造成軟體設計的錯誤和缺陷約佔軟體失敗的6400，而屬於程式程式碼的錯誤僅佔軟體失敗的360a，資料表明需求分析是提高軟體質量的基礎也是決定一個軟體專案成敗的關鍵。通過對軟體專案管理知識的系統學習並結合近年來自己參與部分軟體專案實施的經驗，介紹在需求分析研究中探索出的一些有效措施。
專案使用者方干係人，指所有可能受到專案結果重大影響的人，即專案的風險承擔者，他可能是專案的受益者，也可能是專案的受害者。因此，應當從專案的啟動開始，需求分析員及其專案成員就要分清專案使用者方干係人包含哪些人和組織，通過溝通協調對他們施加影響，驅動他們對專案的支援，調查並明確他們的需求和願望，減小其對專案的阻力，以確保專案獲得成功。
有些專案在做需求調查時，由於受進度要求等客觀因素影響，需求分析員與建設單位的技術部門交流較多，向業務管理部門和實際使用者調查不夠深入，造成軟體試用後不得不再對需求做較大調整，“從頭再來”的部分比例很高，大大超過進度要求時間。因此，熟悉專案使用者方干係人全貌是進行需求調查的第一步，也是需求調查的基礎。在定製開發專案的專案使用者方干係人中，最重要的是建設單位中的人事組織、業務關係。最好是能夠用組織結構圖畫出相關單位的組織結構;還應當在相關單位組織結構圖基礎上畫出全體專案使用者方干係人結構圖，以便更好更全面地進行需求調研分析;用責任矩陣確定各部分的調研物件;建立調研物件通訊錄以保證調研及分析期間及時的溝通。
軟體開發專案的目的就是要實現專案使用者方的需求，專案使用者方的需求包含明確的和隱含的，也可以分為NEED, WANT, WISH等不同的層次。如果對專案所有使用者方干係人沒有進行足夠的溝通和影響，使其儘可能地參與專案，則會出現客戶方相關責任人不明確或對範圍和需求責任心不強，提出的需求具有隨意性，專案前期對需求的確認不夠積極，或者是多個使用者代表各說各話、昨是今非，專案後期需求變化隨意等現象，這就會造成專案範圍的蔓延，進度的拖延，成本的擴大，甚至專案的完全失敗。
各種使用者對系統具有不同的要求，如一個沒有經驗的使用者關心繫統是否簡單易用，對於高階使用者則關心產品的易用性和高效性。因而需要對使用者進行分類，每一個使用者類將有自己的一系列功能和非功能要求。在專案中，要儘早為產品確定並描述不同的使用者類，這樣就能從每一個重要的使用者類代表中獲取不同的需求。
專案需求具有雙面性***使用者與開發商***和多面性***專案中各干係人***，因此，專案經理和系統整合者應瞭解使用者干係人需求，使用者干係人也應瞭解技術方面的需求，兩者缺一不可。正確的需求獲取需要了解需求的來源、使用者的分類、使用者的代表性、使用者需求誰說了算數等因素。開發人員和專案經理要有足夠的耐心聆聽使用者的講述，要足夠詳細地瞭解每一個細節。專案管理者要善於將需求分類、歸類，善於將需求文件化，並有所查詢標記。
3視覺化需求調研，引導各種客戶挖掘他們的需求
有的客戶因為自己缺乏計算機知識，無法提出完整準確、隱含的或潛在的需求。若這些需求不能滿足將導致使用者的不滿。因此需求調研分析人員應善於想使用者所想，不但要確定明確的需求，還要善於用啟發的方式與使用者探討隱含的或潛在的需求，並結合各種調研分析技術挖掘超出客戶期望的令人興奮的需求。這就要求需求調研分析員要儘快完整地熟悉相關業務，從而能夠站在使用者的立場看待軟體需求，想使用者所想，做好業務與計算機之間的橋樑。利用視覺化需求調研的方法可以很好地啟發使用者深人挖掘潛在的需求。視覺化需求調研就是使用圖表等工具來啟發引導使用者清楚地敘述需求，並且使需求更加全面完善。
對於高層領導，可以提供系統總體框架圖;對於業務管理人員，可以用業務流程圖來描述新舊系統的業務流程;對於客戶中的技術人員，可以用資料流圖、實體關係圖或UMI中的各種圖形對系統進行各種角度的描述;而對於業務管理人員、客戶中的技術人員、以及各層次各流程中的使用者，畫出使用者介面圖來進行需求挖掘，是個比較有效的溝通方式。
這裡特別說明一下使用者介面的重要性。使用者介面的設計按理來說是軟體設計的責任，當然客戶自己對介面有特別提出要求的除外。但是，如果把它提前到需求調研時與客戶進行討論，則可以大大改善需求調研的效果。因為這時客戶對於將來的系統還沒有一個形象上的概念，或者有一個模糊的預想的概念需要表述、驗證、明晰化、完善化，以筆者的經驗，畫出使用者介面草圖與客戶進行討論，可以大大激發他們提供更為準確全面的需求。原來收集資料，描述業務，說明系統模型到了山窮水盡的時候，這種方法可以達到柳暗花明又一村的效果。
4詳細描述各項業務，以便讓所有客戶確認
儘可能全面詳細地調查並且描述原有系統和使用者希望將來系統具有的各項業務的流程，並將這些業務流程文件化後與客戶進行討論，對描述錯誤或不準確不精確的進行修改，最終讓客戶進行確認。從近年來開發的軟體看，對業務處理過程瞭解的完整性和準確性非常重要。雖然對資料來說都是SIDUT***查增刪改傳***，但具體業務都是分為若干步驟，每個步驟都有其業務名稱，同一步驟可能對多個數據集進行不同操作，需要調查瞭解清楚才能設計出適合使用者業務特點和習慣的軟體，使開發出來的軟體更受歡迎。當然在進行軟體概要設計時，要儘量排除業務流程的制約，即把流程中的各項業務節點工作作為獨立的物件，充分考慮他們與其他各種業務物件的介面，在流程之間通過業務物件的相互呼叫實現其業務流程，這樣，在業務流程發生有限的變化時，就能夠比較方便地修改系統程式而實現新的需求。
對於各項業務的調查可以通過對以下資料的收集整理分析來完成，這些資料來自各種各樣的專案使用者方干係人:遵循的標準、組織發放的工作手冊、作業流程、有關業務的上級通知、有關業務的辦事指南、辦理業務時需要填寫的登記表、各種相關的統計報表及通過其他途徑收集的類似系統的介紹、技術資料等等。
5對專案使用者方干係人的願望進行平衡
不同的專案使用者方干係人其願望和追求的目標往往相差甚遠，因此對專案使用者方干係人的願望進行平衡可能是非常重要而又相當困難的事情。例如:我曾在參與的某醫院計算機管理系統專案中，遇到醫院管理層希望能夠採集儘可能多的資訊項以便對資料進行多種多樣的統計分析，同時為了對資訊進行有效控制而增加一些審批流程;而門診、藥房等對外辦公的基層視窗則因為客流速度的壓力希望減少資訊項的輸人量;甚至有些不良的基層部門由於害怕建立透明度高的資訊系統會影響他們的利益而消極地應付，即所謂反需求;而客戶的客戶***就診的病人***則希望相關機構能夠簡化工作流程，加快辦事速度，增加診斷情況和就診費用的透明度;甚至專案組本身因為技術、資源、進度等原因，需要對一些功能進行優先順序排序和取捨。雖然不是所有人的需求都是可以滿足的，特別是消極的反需求是不能接受的，但他們的需求都是應當考慮全面並進行平衡的。
如果不同的使用者方干係人有不一致的需求，那麼必須決策出滿足哪一類使用者方干係人的需求更為重要。瞭解可能使用產品的客戶種類的資訊和他們的用法與產品的業務目標的關係如何，將有助於決定哪一個使用者類所佔份額更大。如果系統分析人員提出的需求與開發者所想要開發的系統發生衝突時，通常由於系統分析人員作為客戶的代理人，市場需求具有更重的分量，但是，系統分析人員不能一味地遷就客戶需求。
不同的使用者方干係人可能都要求產品按照他們各自的喜好來設計。運用專案的業務目標來決定哪些是你最關心的客戶，非核心客戶的需求可以安排在下一個版本中開發。當開發者想像的產品與客戶需求衝突時，通常應該由客戶作出決策，然而，不要陷人“客戶總是對的”的陷阱中去，現實中，客戶並不總是對的。
6強調實現專案需求的層次遞進性
瞭解該系統或者該專案使用者所能夠提供的最小的工程費用。當預計經費不能支援時，應當考慮將專案分期實施。在系統上、技術上對使用者進行引導性建議，使使用者瞭解整合商所要進行的工作，瞭解整合商是為了幫助使用者實現他的需要、達到使用者的目的，而不僅僅是為了賺錢，使用者更瞭解整合商，也更瞭解自己的系統，有利於以後的專案合作、工程實施和系統維護。
分析使用者曾用系統模式、資料結構和庫模式，看是否保持、共用、轉換，這涉及保護使用者投資的問題。根據現在工作業務流情況確定現有的工作模式，還應兼顧將來可能會發生的變化、擴充套件、新規定，及與同國際接軌可能的帶來的變化。考查工程實施環境是否有保證，尤其是網路工程，必須在需求調查時充分了解使用者領域的實施環境，當不具有實施環境時，要求進行配套設計和環境改造。
7編寫需求文擋和進行需求評審與其他專案小組成員協作完善系統需求
文件資料是整合商重要的財富，貫穿於系統整合和專案開發的整個過程，其中包括法律文件、技術文件、資料文擋。文擋要求完整性、一致性、可修改性、可跟蹤性。
以原來的需求為基礎的工作完成後，要修補需求錯誤需要大量的工作，研究表明:比起在需求開發階段由客戶發現的一個錯誤，然後更正這一錯誤需要多花到倍的時間。因此，需要進行需求評審。需求審查結束的標準為:已經明確闡述了審查員提出的所有問題、已經正確修改了文件、修訂過的文件已經進行了語法檢查、所有TBD問題都已經解決、文件歸檔。
需求文件完成之後，並不是把它扔給後面的設計人員就了事了。作為專案組其他成員，對需求的有效性也起到某種程度的驗證作用。雖然軟體專案的生命週期按照各種開發模型有不同階段的劃分，但每個階段的結束不是簡單地把階段工作成果塞給下一階段的成員就可以了。特別是高科技的軟體開發專案，上一階段的工作成果往往要通過多次的溝通才能更為清晰地被下一階段成員接受，其有效性、合理性也要被下一階段的工作所檢驗，通過檢驗有時也有必要對上一階段的工作結果進行相應的調整，需求分析也是如此。因此，無論是同一階段不同人員之間，或是不同階段人員之間都應根據需要相互協作，相互配合，共同完成軟體開發任務。
淺談高校計算機實驗室的管理與維護
淺論教學策略在資訊科技理論課中的探究
論文摘要:計算機軟體專案管理中的需求分析是提高軟體質量的基礎也是決定一個軟體專案成敗的關鍵。本文介紹了在需求分析研究中探索出的一些有效措施。
眾觀國內計算機軟體業的發展，除遠不如歐美等西方發達國家外，與人均GDP不及我國的印度相比也相距甚遠，軟體業的劣勢正嚴重製約著我國IT業的發展。我國軟體業的劣勢表現在自主開發的成熟軟體不多，而開發的大量軟體工程專案***如ERP等***存在缺陷或完全開發失敗。目前，國家正在加大對軟體工程的研究和對軟體工程人才的培養。根據資料顯示，屬於需求分析造成軟體設計的錯誤和缺陷約佔軟體失敗的6400，而屬於程式程式碼的錯誤僅佔軟體失敗的360a，資料表明需求分析是提高軟體質量的基礎也是決定一個軟體專案成敗的關鍵。通過對軟體專案管理知識的系統學習並結合近年來自己參與部分軟體專案實施的經驗，介紹在需求分析研究中探索出的一些有效措施。
專案使用者方干係人，指所有可能受到專案結果重大影響的人，即專案的風險承擔者，他可能是專案的受益者，也可能是專案的受害者。因此，應當從專案的啟動開始，需求分析員及其專案成員就要分清專案使用者方干係人包含哪些人和組織，通過溝通協調對他們施加影響，驅動他們對專案的支援，調查並明確他們的需求和願望，減小其對專案的阻力，以確保專案獲得成功。
有些專案在做需求調查時，由於受進度要求等客觀因素影響，需求分析員與建設單位的技術部門交流較多，向業務管理部門和實際使用者調查不夠深入，造成軟體試用後不得不再對需求做較大調整，“從頭再來”的部分比例很高，大大超過進度要求時間。因此，熟悉專案使用者方干係人全貌是進行需求調查的第一步，也是需求調查的基礎。在定製開發專案的專案使用者方干係人中，最重要的是建設單位中的人事組織、業務關係。最好是能夠用組織結構圖畫出相關單位的組織結構;還應當在相關單位組織結構圖基礎上畫出全體專案使用者方干係人結構圖，以便更好更全面地進行需求調研分析;用責任矩陣確定各部分的調研物件;建立調研物件通訊錄以保證調研及分析期間及時的溝通。
軟體開發專案的目的就是要實現專案使用者方的需求，專案使用者方的需求包含明確的和隱含的，也可以分為NEED, WANT, WISH等不同的層次。如果對專案所有使用者方干係人沒有進行足夠的溝通和影響，使其儘可能地參與專案，則會出現客戶方相關責任人不明確或對範圍和需求責任心不強，提出的需求具有隨意性，專案前期對需求的確認不夠積極，或者是多個使用者代表各說各話、昨是今非，專案後期需求變化隨意等現象，這就會造成專案範圍的蔓延，進度的拖延，成本的擴大，甚至專案的完全失敗。
各種使用者對系統具有不同的要求，如一個沒有經驗的使用者關心繫統是否簡單易用，對於高階使用者則關心產品的易用性和高效性。因而需要對使用者進行分類，每一個使用者類將有自己的一系列功能和非功能要求。在專案中，要儘早為產品確定並描述不同的使用者類，這樣就能從每一個重要的使用者類代表中獲取不同的需求。
專案需求具有雙面性***使用者與開發商***和多面性***專案中各干係人***，因此，專案經理和系統整合者應瞭解使用者干係人需求，使用者干係人也應瞭解技術方面的需求，兩者缺一不可。正確的需求獲取需要了解需求的來源、使用者的分類、使用者的代表性、使用者需求誰說了算數等因素。開發人員和專案經理要有足夠的耐心聆聽使用者的講述，要足夠詳細地瞭解每一個細節。專案管理者要善於將需求分類、歸類，善於將需求文件化，並有所查詢標記。
3視覺化需求調研，引導各種客戶挖掘他們的需求
有的客戶因為自己缺乏計算機知識，無法提出完整準確、隱含的或潛在的需求。若這些需求不能滿足將導致使用者的不滿。因此需求調研分析人員應善於想使用者所想，不但要確定明確的需求，還要善於用啟發的方式與使用者探討隱含的或潛在的需求，並結合各種調研分析技術挖掘超出客戶期望的令人興奮的需求。這就要求需求調研分析員要儘快完整地熟悉相關業務，從而能夠站在使用者的立場看待軟體需求，想使用者所想，做好業務與計算機之間的橋樑。利用視覺化需求調研的方法可以很好地啟發使用者深人挖掘潛在的需求。視覺化需求調研就是使用圖表等工具來啟發引導使用者清楚地敘述需求，並且使需求更加全面完善。
對於高層領導，可以提供系統總體框架圖;對於業務管理人員，可以用業務流程圖來描述新舊系統的業務流程;對於客戶中的技術人員，可以用資料流圖、實體關係圖或UMI中的各種圖形對系統進行各種角度的描述;而對於業務管理人員、客戶中的技術人員、以及各層次各流程中的使用者，畫出使用者介面圖來進行需求挖掘，是個比較有效的溝通方式。
這裡特別說明一下使用者介面的重要性。使用者介面的設計按理來說是軟體設計的責任，當然客戶自己對介面有特別提出要求的除外。但是，如果把它提前到需求調研時與客戶進行討論，則可以大大改善需求調研的效果。因為這時客戶對於將來的系統還沒有一個形象上的概念，或者有一個模糊的預想的概念需要表述、驗證、明晰化、完善化，以筆者的經驗，畫出使用者介面草圖與客戶進行討論，可以大大激發他們提供更為準確全面的需求。原來收集資料，描述業務，說明系統模型到了山窮水盡的時候，這種方法可以達到柳暗花明又一村的效果。
4詳細描述各項業務，以便讓所有客戶確認
儘可能全面詳細地調查並且描述原有系統和使用者希望將來系統具有的各項業務的流程，並將這些業務流程文件化後與客戶進行討論，對描述錯誤或不準確不精確的進行修改，最終讓客戶進行確認。從近年來開發的軟體看，對業務處理過程瞭解的完整性和準確性非常重要。雖然對資料來說都是SIDUT***查增刪改傳***，但具體業務都是分為若干步驟，每個步驟都有其業務名稱，同一步驟可能對多個數據集進行不同操作，需要調查瞭解清楚才能設計出適合使用者業務特點和習慣的軟體，使開發出來的軟體更受歡迎。當然在進行軟體概要設計時，要儘量排除業務流程的制約，即把流程中的各項業務節點工作作為獨立的物件，充分考慮他們與其他各種業務物件的介面，在流程之間通過業務物件的相互呼叫實現其業務流程，這樣，在業務流程發生有限的變化時，就能夠比較方便地修改系統程式而實現新的需求。
對於各項業務的調查可以通過對以下資料的收集整理分析來完成，這些資料來自各種各樣的專案使用者方干係人:遵循的標準、組織發放的工作手冊、作業流程、有關業務的上級通知、有關業務的辦事指南、辦理業務時需要填寫的登記表、各種相關的統計報表及通過其他途徑收集的類似系統的介紹、技術資料等等。
5對專案使用者方干係人的願望進行平衡
不同的專案使用者方干係人其願望和追求的目標往往相差甚遠，因此對專案使用者方干係人的願望進行平衡可能是非常重要而又相當困難的事情。例如:我曾在參與的某醫院計算機管理系統專案中，遇到醫院管理層希望能夠採集儘可能多的資訊項以便對資料進行多種多樣的統計分析，同時為了對資訊進行有效控制而增加一些審批流程;而門診、藥房等對外辦公的基層視窗則因為客流速度的壓力希望減少資訊項的輸人量;甚至有些不良的基層部門由於害怕建立透明度高的資訊系統會影響他們的利益而消極地應付，即所謂反需求;而客戶的客戶***就診的病人***則希望相關機構能夠簡化工作流程，加快辦事速度，增加診斷情況和就診費用的透明度;甚至專案組本身因為技術、資源、進度等原因，需要對一些功能進行優先順序排序和取捨。雖然不是所有人的需求都是可以滿足的，特別是消極的反需求是不能接受的，但他們的需求都是應當考慮全面並進行平衡的。
如果不同的使用者方干係人有不一致的需求，那麼必須決策出滿足哪一類使用者方干係人的需求更為重要。瞭解可能使用產品的客戶種類的資訊和他們的用法與產品的業務目標的關係如何，將有助於決定哪一個使用者類所佔份額更大。如果系統分析人員提出的需求與開發者所想要開發的系統發生衝突時，通常由於系統分析人員作為客戶的代理人，市場需求具有更重的分量，但是，系統分析人員不能一味地遷就客戶需求。
不同的使用者方干係人可能都要求產品按照他們各自的喜好來設計。運用專案的業務目標來決定哪些是你最關心的客戶，非核心客戶的需求可以安排在下一個版本中開發。當開發者想像的產品與客戶需求衝突時，通常應該由客戶作出決策，然而，不要陷人“客戶總是對的”的陷阱中去，現實中，客戶並不總是對的。
6強調實現專案需求的層次遞進性
瞭解該系統或者該專案使用者所能夠提供的最小的工程費用。當預計經費不能支援時，應當考慮將專案分期實施。在系統上、技術上對使用者進行引導性建議，使使用者瞭解整合商所要進行的工作，瞭解整合商是為了幫助使用者實現他的需要、達到使用者的目的，而不僅僅是為了賺錢，使用者更瞭解整合商，也更瞭解自己的系統，有利於以後的專案合作、工程實施和系統維護。
分析使用者曾用系統模式、資料結構和庫模式，看是否保持、共用、轉換，這涉及保護使用者投資的問題。根據現在工作業務流情況確定現有的工作模式，還應兼顧將來可能會發生的變化、擴充套件、新規定，及與同國際接軌可能的帶來的變化。考查工程實施環境是否有保證，尤其是網路工程，必須在需求調查時充分了解使用者領域的實施環境，當不具有實施環境時，要求進行配套設計和環境改造。
7編寫需求文擋和進行需求評審與其他專案小組成員協作完善系統需求
文件資料是整合商重要的財富，貫穿於系統整合和專案開發的整個過程，其中包括法律文件、技術文件、資料文擋。文擋要求完整性、一致性、可修改性、可跟蹤性。
以原來的需求為基礎的工作完成後，要修補需求錯誤需要大量的工作，研究表明:比起在需求開發階段由客戶發現的一個錯誤，然後更正這一錯誤需要多花到倍的時間。因此，需要進行需求評審。需求審查結束的標準為:已經明確闡述了審查員提出的所有問題、已經正確修改了文件、修訂過的文件已經進行了語法檢查、所有TBD問題都已經解決、文件歸檔。
需求文件完成之後，並不是把它扔給後面的設計人員就了事了。作為專案組其他成員，對需求的有效性也起到某種程度的驗證作用。雖然軟體專案的生命週期按照各種開發模型有不同階段的劃分，但每個階段的結束不是簡單地把階段工作成果塞給下一階段的成員就可以了。特別是高科技的軟體開發專案，上一階段的工作成果往往要通過多次的溝通才能更為清晰地被下一階段成員接受，其有效性、合理性也要被下一階段的工作所檢驗，通過檢驗有時也有必要對上一階段的工作結果進行相應的調整，需求分析也是如此。因此，無論是同一階段不同人員之間，或是不同階段人員之間都應根據需要相互協作，相互配合，共同完成軟體開發任務。
淺論教學策略在資訊科技理論課中的探究