#### 軟件開發過程中需求分析與管理的內容與重要性
* * * * *
1. 需求工作涉及哪些方面？
首先，需求包括產品需求、用戶需求和軟件需求。產品需求涉及產品的標準化和通用化。它將對用戶需求進行分類和優化，并結合行業標準系統模型進行抽象和概括。用戶需求的是面向用戶域反映存在的問題，根據問題域解決用戶期望的效果；而軟件需求是指軟件工程中的結構化語言和文檔，是用戶需求和使用需求的產品描述。
需求工作包括需求開發和需求管理。需求開發包括需求研究、需求收集、需求分析、需求開發和其他工作，其中的重點是業務流程、數據字典、業務規則、接口原型。對于面向對象的開發方法，它涉及到業務用例、系統用例（利益相關者、基本流、擴展流、業務規則、接口、操作等）。需求管理包括需求狀態管理、變更管理、需求跟蹤、需求的驗證和確認等。
在我們的需求分析和開發中，最容易忽略的有兩個要點，一是缺乏需求分析和開發過程，用戶需求直接作為軟件需求，沒有需求建模和抽象過程。另一點是，沒有考慮到非功能性需求，如性能、安全性、易用性、可維護性和可擴展性，從而導致半成品開發不完善。CMMI把需求管理放在2個層次，把需求發展放在3個層次。事實上，它通過提高需求人員的需求、分析和開發能力，真正解決了需求問題。需求分析和開發不好，改變需求或跟蹤管道是無用的。
2. 什么樣的知識，你需要做需求分析
需求分析工作主要是系統分析員的工作。需要分析的人員應具備軟件工程基礎知識的積累，最好有一定的軟件開發經驗。我已經做了設計和開發工作，在我明白如何做好系統之前，需要明白如何更好的完成軟件需求和后續更好的收斂。有一本叫做“軟件需求”的書，非常有系統性，所有需要工作的人都值得仔細閱讀。對于面向對象的需求開發和分析方法，一定要熟悉RUP統一過程和用例分析和建模。
對于軟件不能管理沒有涉及的業務領域，做需求分析工作必須要熟悉所涉及的業務領域的管理軟件，分析和研究了標準模型的相關業務，一些行業標準和最佳實踐的熟悉。如供應鏈管理系統和軟件應該熟悉行業標準的SCOR模型，ERP產品應結合當前行業比較大的廠家進行學習和開發管理系統可以結合的步伐和IPD研究。只有當你熟悉了商業世界，你才能在需求研究和分析方面提供很多建設性的建議，或者要求分析師不是由用戶主導，而是能夠真正引導用戶。
3. 需求分析的步驟和輸出是什么？
首先，收集需求，通過問卷調查、訪談、行業標準、會議、討論、溝通等方式收集需求。需求采集首先是能夠很好地描述現狀，其次是了解用戶的期望。同時我們必須削弱系統用戶期望做的，因為用戶不熟悉系統和內部原理，我們不僅要考慮軟件要求實現的功能，還需要考慮服務重用，抽象的需求，可擴展性和對問題的許多方面的配置。
需求的收集從分析開始，包括動態行為分析和靜態數據分析。動態行為分析包括用例分析、業務流程和活動輸入輸出分析、數據流分析、業務操作規則分析。靜態數據分析與設計對業務對象建模、數據字典、組織結構、權限等分析。在這個階段，重點是需求的系統化和結構化，最好是在標準文檔中。在軟件開發過程中，我們最突出的文檔輸出需求是需求文檔和總體設計文檔。
需求分析階段以及對輸出的重點是原型和演示，為了更好地與客戶溝通和挖掘需求，我們需要了解我們的想法之后，更多地將圖像給用戶，所以原型是很重要的。不管原型是否被拋棄，客戶所看到的原型與最終的系統基本一致，因此原型開發需要時間，并根據客戶的反饋不斷修改。在原型中投入更多的時間將減少由于后期需求變更而導致的返工時間。軟件原型技術是降低需求變更風險的有效途徑。
4. 需求抽象和模型是什么？
首先，了解需求分析和設計是為了滿足當前的形勢和適應變化而設計的。為了適應變化，業務建模和需求抽象是必要的。當我們理解企業的組織結構和業務流程經常面臨變化和調整時，需要考慮標準組織結構模型、權威模型和工作流模型的引入。這些模型的引入改變了業務和需求的變化，通過系統進行靈活的配置。軟件系統必須適應變化，這是因為我們的軟件需求本身需要適應變化。
需求的抽象包括業務對象模型的抽象、業務規則的抽象和流程的抽象。其中最重要的是業務對象抽象的概念模型和過程抽象形成的數據交互模型。對于一些快速軟件開發平臺，對象建模、過程建模、組織結構和權限建模、業務規則建模和BPEL業務流程編排正是需求抽象的主要內容。
【摘要】要做需求必須具備兩方面的知識，一是對業務領域涉及的和標準模型的真正理解，另一方面是對軟件系統設計經驗的分析和建設。只有具備這兩方面的知識，才能更好地進行需求建模。
5. 驗證和驗證的要求是什么
我們可以區分驗證簡單的了解，為開發是否和用戶想要的東西是一致的過程稱為確認最終的判斷體系，你的理解和描述的需求和我是否一致的過程驗證的想法。需求驗證涉及大量內容，涉及上游和下游利益相關者參與軟件開發。首先，您的結構化和文檔化需求要求用戶驗證它們是否符合他們的想法，以及是否清楚地描述了用戶的真實意圖，以確保需求本身的正確性。對于以后階段的設計開發人員還需要對需求進行審核，以確保需求的實現，確認需求描述是否清晰，是否能夠實現，對于業務對象、流程和規則都不能實現模糊詞的存在。對于測試人員來說，主要是確保需求是可測試的，以及是否引入了更容易使用、更好、更不確定和可測試的術語。對于大型軟件項目，如果有特定的產品標準和UI組，需要易于使用和產品交互等，以評估整個軟件系統產品。
確認主要是在軟件系統開發完成后交付給用戶，用戶確認系統是否實現了原來的需求。為了保證流程的順利進行，必須注意需求驗證的過程，驗證不僅是需求文檔審核階段的需求，還需要注意設計，實現需求驗證的開發階段。
6. 為什么要做需求管理、軟件需求管理包括什么？
需求管理的范圍是IT項目，需求管理是整個IT項目的源頭，IT估算、項目計劃、跟蹤和后續控制、驗證和驗證工作與需求密切相關。因此，為了保證項目計劃的順利實施，質量和成本目標，確保項目計劃和軟件開發執行的嚴肅性；為了保證最終產品最終滿足客戶的期望，必須做好需求管理工作。
需求管理應該是在整個項目生命周期的管理過程當中，從用戶的原始需求，到最終形成軟件產品，用戶需求的驗證，形成一個完整的閉環過程。因此，我們需要追蹤和了解需求狀態的演變。
大型復雜軟件項目的生命周期模型，需要通過實現用戶需求，總體設計，詳細設計，單元測試，集成測試，系統測試和開發、多環節的驗收測試，在這個過程中需要建立明確的需求可追溯性，并且要保證中間階段的工作產品的一致性。
除了需求管理，變更管理是另一個關鍵性的需求，經審查確認后建立基線并控制需求變更，當需求改變時，必須對需求分析進行確認，處理需求變更需要用戶、項目組、設計人員和開發人員的共同認可和承諾。調整和重新建立基線之后，項目計劃也需要做相應的改變。
對于整個需求的研究、分析和需求的發展，認證過程也需要管理。這個過程中的一個要點是，需求輸出文檔。
7. 需求變更管理的重要性是什么？
用戶繼續提交修改項目時間表的需要，沒有任何保證的時間延遲；系統由于需求的變化導致原先穩定的所有都沒有想到錯誤和異常；這些都是需求管理缺陷的出現。需求管理的重要性，反映項目計劃的嚴肅性和可執行性，以保證項目目標的實現。通過引入需求變更管理，使軟件需求文檔成為大家共同的承諾，并作為參考文檔，要求本文檔在設計、開發、測試等各種角色之間充分傳遞和共享。此外，通過需求管理工作，使每個人都認識到變化對項目的影響和成本的變化，反過來促進了需求質量的發展。
需求變更管理包括了變更請求，CBB委員會進行分析，確認需求的變化，設計和開發負責人確認需求的變化會影響到的模塊和代碼，開發人員修改和變更測試具體的修改方法，另一個人的改變需要改變以適應形勢為了驗證。對于發展變化的影響分析，項目團隊負責大型項目，可以建立需求管理，在需求跟蹤分析，但根據實際需要跟蹤在分析的影響效果并不明顯。
