以下是抄別人的，特註明：
1、弄清楚三件事：業務流（企業工作流程，比如如何填寫乙個**等）、控制流（權力關係，因為這決定將來的許可權，比如簽字級別、資料與操作者的關係等）、資料流（就是資料資訊的格式、流轉過程，比如乙個單據是怎麼流轉處理的，這決定將來的資料規劃）；
2、一定要盡量理解使用者業務，吃透使用者的業務才能轉化為你的計算機系統設計，否則就算你設計了也不一定能夠符合要求，那就要返工了，敏捷開發中之所以關心 story ，也是這個原因；
3、為了快速達到與客戶有共同語言和相互理解（就是你理解他的業務，他理解你的程式設想），可以通過介面原型方法直觀地、有統一性地去研討，幾輪下來基本就可以了，而且還能讓使用者在參與的過程中體會快樂，併聯略感情；
4、忌諱現場程式設計，容易導致客戶變成設計師，牽著程式設計師走，那可就慘了，但要定期與客戶溝通，否則客戶會擔心，同樣會出問題（一般每2周一次為好）；有 bug 的程式不要讓使用者看到！
關於需求分析1
研究生期間做過很多的小管理類專案,對於管理類專案的需求分析,有個體會.個人感覺需求,首先要明確系統的服務物件,要滿足並超出其預期才會有好的結果,服務物件就是系統管理的流程的制定者.雖然看起來很簡單,其實很容易出現意外.依然記得當年本科資料庫的課程設計,老師要求大家做乙個訂票的系統,2個角色,旅客和售...
關於「專案需求分析」
專案需求規格說明書 我相信，對於每乙個寫過專案的人來說都不陌生，在這裡我想通過以下幾點向大家一起分享我在寫需求分析這個過程中的一些想法和感受 1 什麼是 專案需求分析 還記得剛開始學習c語言時，老師會給我們布置一些課後作業，當時的我就是，一邊看題，一邊編寫 覺得完成這道題就ok啦，這個時候老師就會說...
需求分析 關於報表統計類的需求分析
關於需求分析，業界上一直說的比較多的是軟體需求分析，但是工作以來，做bi相關的工作一段時間，發現bi更多的需求會是報表需求分析 當然，其實報表需求可以是乙個很大的專案也可以是一些小專案，大專案與小專案其實需求分析過程都差不多，只是相對來講，小專案可能會更簡單一些 下面就這段時間對報表的需求分析一些總...