關於需求分析，業界上一直說的比較多的是軟體需求分析，但是工作以來，做bi相關的工作一段時間，發現bi更多的需求會是報表需求分析（當然，其實報表需求可以是乙個很大的專案也可以是一些小專案，大專案與小專案其實需求分析過程都差不多，只是相對來講，小專案可能會更簡單一些）。下面就這段時間對報表的需求分析一些總結和看法發表一下。歡迎拍磚:）
需求分析一般包括三個階段，我的理解，報表需求分析也不例外包含但不限於：
此塊一般由需求分析師或者專案經理來做，主要是了解使用者的業務需求（必要的業務需求說明電子文件），包括專案背景，專案目的意義，專案的要求等。報表需求就要特別的了解報表指標，指標的口徑，報表的維度，報表的粒度，報表的樣式，報表的功能，報表的優先順序，報表的更新頻率，以及報表的使用人員等。
一般大的專案，都不可能一次就溝通就能了解使用者的需求，需要不斷迭代的了解；所以，在第一次專案需求會議啟動之後，需求分析師要了解業務方對接的人員， 以及明確溝通機制，告知業務方在整個專案過程中會需要他們的協助，在需求分析時可以保持良好的溝通。另外，有一點很重要，對於甲方公司的業務，在專案啟動時，要徵求領導（至少有人力資源說話權的）的意見，在得到自己領導的同意後才開始做深入的需求分析，不然一來浪費時間；二來後期工作會帶來很大的阻力（因為領導可能覺得不重要）；三來業務方會覺把整個事情怪罪在需求分析人員身上等等；
此塊包括需求文件的整理，以及需求可行性的分析，以及需求分析；
主要是根據溝通，要將需求文件做一些規範化，對於報表的需求，要對指標口徑，需求範圍，報表樣式等做基本的梳理；需求輸出階段作為乙個方向性的指導文件；明確需求要做什麼。
2.需求可行性的分析：
需要根據需求考慮資料量的大小，更新的頻率要求，資料的支援（bi的報表需要要考慮是否有相關資料，一般bi的資料都是**於業務系統，當然也有一些是需要自己採集的，如**日誌，爬蟲，行業環境的資料等），從而要考慮etl工具，報表工具，伺服器效能是否支援等問題。需求可行性分析決定哪些需要做，哪些不能做，哪些暫時做不了等問題。
3.需求分析：
這一步是最體現需求分析人員功力的一步；整個精華就在這裡了；當然，其實需要需求分析人員的地方也就是在這裡。因為業務方可能比較熟悉業務，但是他們不了解技術，而技術可能技術能力很好，但是不了解業務，技術與業務就無法很好的溝通，而需求分析人員就是他們之間的橋梁（後續會發表一下我對需求分析人員的要求的看法，歡迎參與討論），把整個專案銜接起來；
首先，需求分析需要需求分析人員挖掘真實需求；
其實人與人的溝通的傳遞不可能是100%的， 此步需要需求分析去挖掘使用者真實的需求；
其次，需求分析需要需求分析人員過濾，整合需求；
業務方表達需求，描述需求的時候可能存在歧義，也可能存在一些重複多餘的需求，此步需要需求分析人員分析以及理解，並解釋反饋給業務方，形成共識；
再次，需求分析應該從技術的角度出發，也要同時從業務的角度出發，來深入了解業務方的需求；
剛說了業務人員不了解技術，所以需求分析師需要從業務的角度，來探索業務方所說的需求；另外也要從技術的角度，來分析業務的需求；
最後，需求分析需要從需求理論滿足分析業務方等等；
從需求金字塔來講，需求自下而上，可分成3個層次；基本需求，期望型需求，興奮型需求；這個很能體現需求分析人員對業務的了解的能力；
當然，基本需求是最重要，也是要最先能滿足的，其次是期望型的需求；最後才是興奮型的需求；
簡單打個比方：比如說業務方需要做的一張報表是每日的銷售，另外一張報表是每日的流量報表，需求分析能做，即能滿足基本需求；但是在了解的過程中，發現其實每日的報表他們主要是供給管理人員看趨勢使用，但是他們運營人員還想能及時監控資料的轉化，因為目前的階段，他們的產品以及市場的運營對實時的統計很有需要；而分析人員了解報表有小時的功能，而且這個功能也不會太難做，需求人員提出可以做這個小時級別的報表給他們使用；這個可以理解為期望型的需求；最後，需求分析根據自己對業務的了解，還發現一些不錯的業界指標可以供市場，產品運營使用，更能支援他們的業務；這樣即可以說是達到了興奮型的需求，因為這是業務方根本沒想到的東西；當然，一般來講，我們不可能每次都能做到興奮型的需求；能滿足基本需求的情況下，我們做到期望型的需求已經很不錯了。
需求至少輸出以下文件：
1.需求說明文件（包括需求背景，需求分析，需求詳細介紹)
2.報表需求文件（可以是原型，可以是excel，可以是word，但是要包含梳理規範化的報表，指標，口徑，功能，樣式，更新頻率等）
針對報表需求，不限於以上三點，報表方面的需求分析更多的還要承擔以下工作（合理與否，大家可以各抒己見）
1.與etl，報表開發人員溝通，確定etl的排期，報表的排期，整個專案的排期；
2.跟內部人員協商好後，才告知業務方專案計畫，並每隔一段時間做一次進展匯報（一定要先跟內部溝通好時間才能告知業務方，並告知屆時需要他們配合資料驗證，報表驗收工作）；
3.專案開發過程中，可能會遇到一些溝通中沒有考慮到的問題，這個時候可能涉及到需求變更，就比較麻煩了，當然也是時有的事；此時需要需求分析人員增長經驗，並要溝通好雙方，達成協議，明確問題的重要性，並確定什麼時候解決；
4.專案開發完成，進入測試階段，測試人員需要了解測試的報表需求，需求分析要協調，最好能在與開發溝通的時候，叫上測試一起參與，做個基本的了解，有助於減輕後期的工作；
5.專案完成後，需要協調驗收；其實這一步在實際應用過程中，經常很麻煩，這個涉及到資料質量的問題。業務方不知道怎麼驗收，也比較難確定報表的資料是否正確；而測試其實對報表的資料質量也是比較難測試的，測試更多的可能只是對於報表的功能測試。本人在這一步也是時常遇到麻煩，只能要求etl人員自測，報表人員自測給力些，再加上自己去做一些基本的驗證；大家如果有好的方法歡迎指教。
6.報表的維護，由於業務一般都是會在變化的，可能隨之而來的也會包括相關指標的邏輯變化，這個需要需求分析人員的關注和與業務方保持溝通；等等；
關於需求分析
以下是抄別人的，特註明 1 弄清楚三件事 業務流 企業工作流程，比如如何填寫乙個 等 控制流 權力關係，因為這決定將來的許可權，比如簽字級別 資料與操作者的關係等 資料流 就是資料資訊的格式 流轉過程，比如乙個單據是怎麼流轉處理的，這決定將來的資料規劃 2 一定要盡量理解使用者業務，吃透使用者的業務...
需求分析的介面需求 需求分析
本篇不是為業務分析人員寫的，不會細緻講解需求分析的方方面面，業務分析師可以看徐鋒的 軟體需求最佳實踐 或者王海鵬翻譯的 掌握需求過程 本篇立足於架構師視角，講解需求分析過程中應了解的過程和方法，以及需要特別關注的點。開發者拿到的往往是乙個個的方案，方案來自於需求，那麼開發者拿到的需求是怎麼來的？乙個...
關於需求分析1
研究生期間做過很多的小管理類專案,對於管理類專案的需求分析,有個體會.個人感覺需求,首先要明確系統的服務物件,要滿足並超出其預期才會有好的結果,服務物件就是系統管理的流程的制定者.雖然看起來很簡單,其實很容易出現意外.依然記得當年本科資料庫的課程設計,老師要求大家做乙個訂票的系統,2個角色,旅客和售...