需求調研表
專案
名稱
專案
代號
調研
物件
調研
日期
需求調研根據
檔名（及時間）
√立項專案名稱（及時間）
使用者/執行維護人員提出（請註明）
需求型別
√ 新建專案在建專案補充現有系統運維
使用者
範圍
管理員： 1-2 人，負責配置系統相關資訊。
高階使用者： *** 處人員，主要進行立項、督查、彙總等工作。
一般使用者：總行各司局所有人員（包括借調人員和行政秘書）、 ** 家分支行辦公室人員、各直屬企事業單位辦公室（待定）
調研目的及內容
初步討論系統功能
業務
內容
系統 /功能主要目的或內容（包括確定系統 /功能邊界）
q1：系統主要功能
完成 q2：系統主要使用者
**司局綜合處、各處工作人員（包括行政秘書和借調工作人員）。
業務描述（組織結構、流程、角色、業務規則、主要業務特點等）
q1：系統可分為哪些角色？
re：管理員、高階使用者、綜合處（分辦人員）、承辦人員、查詢人員。
q2：系統的資料量大約有多少？
re：每年大約
5000件。
q3：系統是否需要歸檔，是否需要編號？
re：每兩年清空一次資料庫，將歷史資料移到歷史資料庫中。可在立項時自動生成流水號「督
[2006]xx
號」。（待定）
q4：督查的業務流程:
re：1、檔案分類：
督辦處對各類檔案進行分類，確定是否立項，或確定為閱知件。（閱知件將作為編寫刊物的依據） 2
、督察處
/秘書處分辦:
對於需要立項督辦的檔案或事宜，督辦處或秘書處進行督查立項後，傳送給辦理司局綜合處處長和督辦專員。要求支援同時傳送多個司局。通常都有主辦司局和協辦司局，對於沒有主辦司局的情況，由督辦處向廳主任匯報後決定。
3、司局綜合處分辦：
分辦司局綜合處收到督辦立項單後，報司局長審批後發給分辦處處長，再由處長傳送給承辦人。
4、事件處理：
承辦人可根據具體情況選擇擬稿發文或直接在督辦立項單上填寫辦理資訊和辦理進度。
如擬稿發文，則由承辦人將發文的相關資訊（如檔名稱，事件處理狀態等）填寫到督辦立項單中。當該檔案處於流轉過程中時，督辦單中事件辦理狀態填寫為「檔案流轉中」；檔案辦結後，修改狀態為「已辦結」（要求督查人員可檢視發文流轉的路徑和狀態），並將督辦單返回督查處。
如無需行文，直接填寫督辦單，則需提交本司局綜合處進行審核，核稿後返回督查處。 （1
）此處需要制度規範：分辦司局綜合處要對本司局內所有人員填寫的辦理資訊進行核稿。 （2
）系統為各承辦人與分辦司局綜合處開闢不同區域，以供填寫辦理情況等相關資訊。（各綜合處意見是否覆蓋承辦人意見有待確定） 5
、事項辦結
督辦處收到承辦人或分辦司局綜合處返回的督辦單後，需要對辦理資訊進行彙總後填寫在辦理情況一欄中。並將該督辦立項單歸檔，以此作為生成督辦刊物的依據。
q2：系統首頁的資訊如何顯示？
re：系統首頁資訊顯示分為兩大類，左側為選單區，可根據使用者許可權控制顯示。右側為工作區，根據使用者的身份不同，顯示的資訊有所不同。 1、
高階使用者
選單區包括檔案分類、立項、分辦、彙總、辦結等功能鍵。並能夠瀏覽所有檔案，並能夠區分優先順序。
工作區內容包括待辦檔案和在辦檔案兩類： （1
）待辦檔案：包括「已經過處理」和「未經過處理」兩類，分兩個區域顯示。
「未經處理」中包含從收文系統中同步過來的a類、
c類、d類收文資訊；（包括檔名以及正文）
「已經過處理」中已立項中包括當前使用者還沒開啟的從分辦司局綜合處或承辦人返回的督辦單。 （
2）在辦檔案：包括
已立項但是未歸檔的督辦立項單
正在處理（包括分類、
填寫立項資訊，彙總資訊等操作）的事項。
功能區 1、
對於分辦到各司局正在
一般使用者的首頁資訊顯示包括：
1、待辦檔案：當前使用者還沒開啟的從督查處傳送的督辦立項單。
2、在辦檔案：當前使用者已經開啟但是還未辦理完畢發給督查處的督辦立項單。
q3：如何處理重要事項？
re：在全部檔案瀏覽中設定「我的關注事項」
我的關注事項可理解為使用者的乙個單獨的資料夾，高階使用者可在立項時直接將督查立項設為我的關注事項，也可在辦理過程中將某個或某些督辦事項設為我的關注事項。
q3：主辦和協辦的意見填寫方式？
re：協辦司局填寫意見需要根據協辦司局的個數靈活生成相應個數的意見框，供協辦司局填寫辦理情況。同時，可在辦理情況框中引入
word
、excel
型別的附件。
q4：系統的查詢方式？
re：查詢分為兩種，一種為不帶統計的查詢，可根據文號和督辦號等要素進行查詢。另一種為統計查詢，查詢後要根據模板格式生成相應的統計結果。
q5：督辦立項中填寫的辦理時限有什麼用？
re：可用於定期提示承辦人。先設為提前五天提示所有分辦人員。
立項、彙總、辦結等操作）中的檔案。 2
、一般使用者
選單欄中包括辦理事項、修改資訊以及檢視進度等。
工作區主要為
待辦和在辦事項。
相關系統 /功能（相似功能 /系統，系統間關係、介面）
q1：與其它哪些系統有關係？
re：（1）
（2）文書處理系統（作為文書處理系統的辦文依據，其中部分行發文、廳發文由督查處核稿，文號通常為銀函銀辦函） （3
）電子公文傳輸系統：可給分支行傳輸《重要事項督察情況》等檔案（等待辦公廳付主任審批） （4
）小oa
系統會議管理子系統：可引入會議紀要，然後人工分別立項。
q2：系統檔案是否蓋章？
re：無需蓋章。
其他要求（系統效能、歷史資料處理、現有資源情況、相關法規或規則等）
q1：現有處理方式如何？
re：由收文系統匯出
excel
表，生成督辦單，再通過電子郵件傳送司局，通過**等方式人工督辦。
q2：如何處理歷史資料？
re：可將兩年內紙質檔案匯入系統作為初始化資料。
q3re：有工作手冊、督查管理辦法。
q4：如何確保系統安全？
re：根據不同安全級別分別定義。a類、
d類文的密級與收文系統相同。
絕密件只顯示標題和領導批示，再由督辦處根據情況處理領導批示。
相關文件
工作手冊
相關模版
（表單等）1
、 2、 3
、查詢統計格式模版
介面
要求
展示方式：√通過瀏覽器安裝客戶端
參照文書處理系統的展示方式。
配色風格
參照文書處理系統的配色風格。
版式：√三欄式兩欄式√目錄樹內容分割槽
介面內容及其分布：（欄目名稱及位置等）
已辦：在辦 針對每一件事情，使用不同顏色變化。已辦結（藍色），正在辦理（紅色）閱知件（黃顏色）（閱知件不需要督辦，備案，放在專門的庫裡面，在製作刊物時需要用到。）
其他：（是否需要
/flash）
其他
要求
待確定問題： 1、
工作計畫（完善制度） 2、
對於由多個司局協同辦理的是否均存在主辦單位？
使用者
確認
使用者確認本次調研內容符合能夠反映使用者需求。簽名：
參與調研人員
使用者方：
信管中心：
開發或整合方：
需求調研分析
case的乙個基本思想就是提供一組能夠自動覆蓋軟體開發生命週期各個階段的整合的 減少勞動力的工具。case工具由許多部分組成,一般我們按軟體開發的不同階段分為上層case和下層case產品。上層或前端case工具自動進行應用的計畫 設計和分析,幫助使用者定義需求,產生需求說明,並可完成與應用開發相關...
需求調研和分析雜記
老調牙的調子，需求調研和分析是系統成敗的關鍵，如何做調研和分析的方法非常多，就從業務的角度來說，難度並沒有坊間傳言的那麼大，涉及到政治，那就是另外一回事情了，這裡不討論。那如何進行呢？1 首先確定系統的大致範圍 目標 即做什麼 do what 這個時候的目標當然是粗粒度的，就是所謂大的用例 和如何做...
需求調研總結
以前零零散散的做過一些需求調研的工作，但是都是打醬油似的，對需求調研的乙個流程還是不清楚 經過這段時間和使用者關於乙個模組的二次開發的討論，對需求調研的工作算是有了乙個大致的了解。一 需求調研準備 1 文件方面 彙總相關的文件資料，對專案要有個基本輪廓的認識，需求調研模板，需求調研問題列表相關的資料...