一、軟體開發過程框架圖：
大師的這個開發過程框架圖，是乙個模型，對我這個剛剛準備工作的學生很有幫助。
二、需求分析評審的感受：
1.需求分析報告一定不能脫離業務調研報告，永遠要基於調研的內容來，不要閉門造車，憑著自己的想象在做。
2.需求分析的目的一定要寫的符合實際一些，不然會給團隊的架構師挖坑。
3.一定不能粗製濫造，將業務調研報告裡面的組織結構圖直接拿過來作為需求分析裡面的功能結構圖，必須要經過合理的分析，不能盲目的而使用。
4.文件結構一定要清晰，邏輯一定不可以混亂。
5.在畫用例圖的時候一定要學會uml語言，並且經錯使用，熟練的掌握。
6.領域類圖一點更要學好，對任何的東西該顯示的一定要顯示粗來，不要因為篇幅太大就不顯示了。
7.用做客戶驗收標準的需求分析報告，必須告知具體的指標，效能的描述一定要精確，響應時間，速度，占用資源多少等等資料一定要詳細的列出。
三、讀關於需求分析的討論後體會與初期收穫
1.需求分析報告中的圖的繪製順序：學習業務調研報告編寫——>學習用例規劃——>學習用例描述——>學習用例及參與者關係描述——>學習領域類圖——>學習非功能需求的書寫。
2.業務調研的時候先從使用者容易理解的部分開始入手，，先從一些簡單的內容開始，比如使用者的部門有哪些，職位有哪些，組織結構，每個崗位處理的檔案資料是什麼，他們之間的關係是什麼等。分類記錄好，一定要把專業和業務分開。在第一次溝通以後，一定要了解使用者現在在做什麼，然後就可以容易的了解使用者以後想做什麼，想怎麼做。怎樣來實現更好的內容。調研完畢後整理調研報告的靜態結構。
（1）然後繪製單位的組織結構圖，一般宜採取直線型結構；
（2）對部門的職責進行描述一般宜採用**形式；
（3）對某個崗位的職責也需要詳細的描述，便於挖掘使用者的需求，明白崗位之間的關係；
（4）整理原始資料，主要是整理出哪些崗位職工需要用到哪些資料，做好分類；
（5）畫動態的業務流圖，描述的是單位的人員之間的業務關係；部門之間的業務流程圖稱為頂層流程圖，針對崗位之間業務流程圖稱之為底層流程圖。業務流程圖的格式有很多種，最通用的就是泳道式業務流程圖；
（6）非業務調研指的就是在企業現有業務執行的基礎上，需要對客戶進行進一步的溝通，了解一些業務之外的特殊情況。比如客戶執行地地域性、部門變動性、其實就是一些不是業務的東西，但是一旦變動了就會影響業務或者說這個系統的使用，使用者操作等的相關性的問題。
（7）最後就是做乙個總結，這個總結針對開發技術的選型有重大的意義。
個人感想之「需求分析」
所謂 需求分析 是指對要解決的問題進行詳細的分析，弄清楚問題的要求，包括需要輸入什麼資料，要得到什麼結果，最後應輸出什麼。可以說，在軟體工程當中的 需求分析 就是確定要計算機 做什麼 要達到什麼樣的效果。可以說需求分析是做系統之前必做的。在軟體工程中，需求分析指的是在建立乙個新的或改變乙個現存的電腦...
結隊作業之需求分析
由於學校圖書館位置與自習室經常被佔滿，許多學生沒有佔到座位，導致只能在宿舍學習。沒在在合適氛圍下進行學習的直接後果 學習效率底下。學校中總有人起早貪黑就為了去圖書館或者自習室佔乙個位置學習，位置的競爭給大部分熱衷於學習的學生帶來許多困擾，特別是要奮戰考研的大三大四學生們，沒佔到座位導致自己一天的計畫...
專案開發心得之需求分析
專案開發心得之需求分析收藏 前一篇講述了我在這個 專案開發上人力資源配置的一些經驗，有了人員配置的初步安排剩下的前期工作就是就是招人和需求分析，如果等人員到位，需求分析還沒來，那進來的人員都只有等著啦。這篇我就主要說說我在這個專案中進行需求分析的一些經驗和做法。1.1 需求從哪來？就我個人經驗來說，...