信息系統(tǒng)需求管理方案_第1頁
信息系統(tǒng)需求管理方案_第2頁
信息系統(tǒng)需求管理方案_第3頁
信息系統(tǒng)需求管理方案_第4頁
信息系統(tǒng)需求管理方案_第5頁
已閱讀5頁,還剩12頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領

文檔簡介

1、【精品文檔】如有侵權(quán),請聯(lián)系網(wǎng)站刪除,僅供學習與交流信息系統(tǒng)需求管理方案.精品文檔.需求管理方案擬制人朱良超日期2018.05.02審核人日期批準人日期修改記錄日期版本作者/修改者修改內(nèi)容審核人2018.05.07V1.1朱良超完善需求管理流程及相關人員分工2018.05.11V1.2朱良超修改整體流程,補充需求管理措施。2018.05.22V1.3朱良超增加需求評審階段成果,需求上線階段增加客戶確認,形成閉環(huán)。目 錄1. 概述11.1 現(xiàn)狀分析11.2 目的11.3 適用范圍12. 崗位與職責23. 需求流程說明33.1 需求分類33.2 需求管理流程及制度53.2.1 整體流程53.2.2

2、 需求收集63.2.3 需求匯總初步分析73.2.4 需求評審分析83.2.5 需求開發(fā)103.2.6 需求測試113.2.7 需求上線123.2.8 需求變更124. 需求管理措施145. 過程及成果資料141. 概述1.1 現(xiàn)狀分析目前項目需求管理的過程中,在需求收集、流程設置、工作效率等方面存在著一些問題,導致需求得不到及時有效的解決、項目推進緩慢、客戶滿意度降低等。比較常見問題如下: 需求提出時,不夠細化、完全,不能完整、準確的反映客戶的實際需求。 沒有考慮整體性和關聯(lián)性,有些需求只適用于個別分支機構(gòu);需求上存在理解差異,待功能交付后,用戶提出所見非所求,造成需求、bug爭論不休,需求

3、變更及bug修復頻繁,影響系統(tǒng)穩(wěn)定并造成成本消耗。 需求提交方式多樣,有很多口頭或郵件交流內(nèi)容,存在需求過于簡單描述不清。 沒有劃定需求的優(yōu)先級,需求進度難以控制,過多的爭論造成了臨時事務增多, 需求提出后,經(jīng)過一段時間的開發(fā),后續(xù)無人跟蹤。1.2 目的為了更規(guī)范更有效的管理需求工作,保證需求工作的可控性,明確各階段的工作內(nèi)容、處理流程、參與人員以及相關干系人的職責,特制定本管理辦法,相關人員必須嚴格按照本辦法執(zhí)行新需求相關工作。1.3 適用范圍本制度適用的讀者包括:主要干系人:項目經(jīng)理、需求管理員、開發(fā)負責人相關干系人:實施人員、技術支持人員、開發(fā)人員、項目管理專員。2. 崗位與職責主要干系

4、人職責:角色主要職責項目經(jīng)理1. 負責需求收集,與甲方溝通、確認需求相關事宜并編寫需求文檔。2. 配合開發(fā)人員提供業(yè)務知識的支持。3. 參與需求評審分析。4. 根據(jù)需求評審意見,及時修改需求文檔,并發(fā)給需求相關干系人。5. 維護需求信息、跟進需求變更以及需求處理進展,定期向相關領導匯報。6. 負責需求測試,制定需求測試計劃,分配測試任務,對系統(tǒng)功能進行測試確認。7. 測試存在問題的及時反饋開發(fā)負責人和需求管理員,并跟進解決情況,完成之后重新進行測試。8. 內(nèi)部測試完成之后負責與甲方溝通,進行測試,完成需求結(jié)果確認。9. 負責需求上線。需求管理員1. 負責定期收集匯總、整理分類各項目提報的需求并

5、進行審批,與提交人及總公司人員進行溝通確認。2. 組織項目經(jīng)理、開發(fā)人員等召開需求評審會議,從架構(gòu)、業(yè)務、技術、風險等方面對業(yè)務需求的內(nèi)容和實現(xiàn)方式進行全面評估,并提出評估意見,確定需求解決方案。3. 負責收集開發(fā)負責人反饋的需求解決計劃,并及時告知各項目經(jīng)理。4. 跟蹤需求解決進展情況,協(xié)調(diào)項目組與開發(fā)人員相關事宜的溝通。5. 負責與總公司人員溝通需求,跟蹤總公司需求解決進度。6. 定期到各項目組與客戶方進行溝通,了解現(xiàn)場問題,收集需求。7. 負責需求開發(fā)結(jié)果的確認。開發(fā)負責人1. 參與需求評審,從技術角度對需求實現(xiàn)方式、風險等進行評估,確定技術路線。2. 負責向需求管理員反饋開發(fā)計劃3.

6、負責需求開發(fā)所有工作的溝通、協(xié)調(diào)管理。4. 負責需求開發(fā)進度、成員管理。5. 負責或參與需求所有成果的審批。6. 參與或指定開發(fā)人員協(xié)助需求提交人員與甲方對于需求的溝通、確認。相關干系人職責:角色主要職責實施人員1. 協(xié)助項目經(jīng)理進行需求收集。 2. 配合開發(fā)人員提供業(yè)務知識的支持。3. 需要時參與需求評審分析。4. 協(xié)助項目經(jīng)理進行需求測試。5. 協(xié)助項目經(jīng)理進行需求上線。技術支持人員1. 需求收集階段協(xié)助項目經(jīng)理與甲方對于需求的溝通、確認。幫助項目經(jīng)理分析、確定業(yè)務需求。2. 必要時提供技術支持,配合項目經(jīng)理完成測試環(huán)境的搭建。開發(fā)人員1. 協(xié)助項目經(jīng)理與甲方對于需求的溝通、確認。幫助項目

7、經(jīng)理分析、確定業(yè)務需求。2. 負責需求開發(fā)的具體實現(xiàn)。3. 當項目經(jīng)理對需求確認不通過時,按照反饋結(jié)果對需求進行修改。項目管理專員1. 參與需求評審分析,從項目進度、質(zhì)量等方面進行評審分析。3. 需求流程說明3.1 需求分類按照需求內(nèi)容大致可分為:需求類型需求類型定義功能性需求新業(yè)務功能已有系統(tǒng)中沒有此功能,需要在原有基礎上新增功能功能改進當前系統(tǒng)已經(jīng)有此功能,因組織架構(gòu)、制度規(guī)范、業(yè)務處理流程等發(fā)生變化,需要對現(xiàn)有系統(tǒng)的某些功能進行優(yōu)化調(diào)整需求變更系統(tǒng)功能上線前,要在原有需求的基礎上增加、修改或刪除需求內(nèi)容,但需求內(nèi)容的變動會引起成本增長過大、對現(xiàn)有業(yè)務影響較大、或可能存在風險、合規(guī)等問題系

8、統(tǒng)問題系統(tǒng)現(xiàn)有功能可以正常使用,但是性能、安全、底層處理邏輯和架構(gòu)等即將或者未來可能成為業(yè)務進一步擴張的瓶頸界面類需求前端頁面設計、開發(fā)、更新修改及維護。非功能性需求不直接與系統(tǒng)的具體功能相關的一類需求。例如:安全性、可擴展性、響應時間、交付要求等。按照優(yōu)先級可分為:需求類型需求類型定義采取的措施立即解決1、 系統(tǒng)必須實現(xiàn)的,沒有其功能就無法完成正常的日常工作及業(yè)務處理。2、 嚴重影響系統(tǒng)要求或基本功能的實現(xiàn),且沒有辦法更正。對于這類需求在項目實施過程中需重點投入資源,優(yōu)先實現(xiàn)。高級優(yōu)先1、嚴重影響系統(tǒng)要求或基本功能的實現(xiàn),但存在合理的更正辦法。2、國家或行業(yè)法律法規(guī)標準、政府下文要求的。3、

9、事先已經(jīng)約定的功能。4、不重要但做了會產(chǎn)生極佳效果。對于這類需求在項目實施過程中需重點投入資源,優(yōu)先實現(xiàn)。正常排隊1、 使用者操作不便等對正常業(yè)務影響不大的。2、實現(xiàn)這些需求將增強系統(tǒng)的性能3、系統(tǒng)最終所要求的如果項目實施中出現(xiàn)進度、資源等方面的沖突時,可與客戶溝通延遲到下一版本。低級優(yōu)先1、系統(tǒng)附加功能2、使系統(tǒng)更完美,屬于錦上添花。根據(jù)項目時間進行安排,排在最后。3.2 需求管理流程及制度3.2.1 整體流程整體流程示意圖:需求管理主要分為6個階段:需求收集、需求匯總初步分析、需求評審分析、需求開發(fā)、需求測試、需求上線。需求開發(fā)的管理流程:3.2.2 需求收集3.2.2.1 主要參與人員項

10、目經(jīng)理、實施人員、技術支持人員3.2.2.2 工作內(nèi)容及要求(1) 項目經(jīng)理針對用戶提出的需求,采用訪談、會議、問卷等形式收集基礎信息(包括相關支持文件,例如會議紀要、下發(fā)文件等)(2) 從業(yè)務方面判斷是否合理,若不合理應第一時間告知用戶,并解釋清楚原因?;蚴欠治雠袛嘣撔枨笫欠窨梢酝ㄟ^系統(tǒng)已有的其他功能來實現(xiàn)。(3) 按照模板編寫需求文檔(需求描述要求清晰、全面,對于文字難以描述的可采用示意圖、原型設計等方法)。(4) 按照項目組需求確認單樣式填寫需求確認單,并由甲方簽字確認。(5) 每周三12點之前匯總本項目需求(含相關支持材料)發(fā)送至需求管理員郵箱。緊急需求可立即發(fā)送需求管理員郵箱并電話告

11、知。(6) 項目經(jīng)理及時將新需求錄入jira系統(tǒng)提交至需求管理員,并上傳由客戶簽字的需求確認單及其它相關支持材料。緊急需求可提交jira之后立即電話告知需求管理員。備注:項目組內(nèi)的具體工作流程,項目經(jīng)理根據(jù)實際情況進行制定。3.2.2.3 成果資料需求確認單、需求文檔、問題確認單3.2.3 需求匯總初步分析3.2.3.1 主要參與人員需求管理員3.2.3.2 工作內(nèi)容及要求(1) 每天對各項目提報的需求進行收集匯總、分類整理形成需求匯總表。(2) 進行審批,對填寫不符合要求、描述不清楚的及時退回各項目經(jīng)理。(3) 判斷需求是否合理,若不合理及時告知項目經(jīng)理,項目經(jīng)理應第一時間告知用戶,并解釋清

12、楚原因?;蚴欠治雠袛嘣撔枨笫欠窨梢酝ㄟ^系統(tǒng)已有的其他功能來實現(xiàn)。(4) 聯(lián)系總公司相關人員,詢問公司系統(tǒng)版本是否已經(jīng)實現(xiàn)該功能或類似功能。(5) 每天將經(jīng)過審批之后的需求在jira上及時提交給開發(fā)負責人,每周四將經(jīng)過分析確認的各項目組的需求匯總發(fā)送至開發(fā)負責人郵箱。(6) 若開發(fā)負責人對需求有疑義,需求管理員組織項目經(jīng)理、開發(fā)負責人等相關干系人召開需求評審會議,確定需求解決方案。3.2.3.3 成果資料需求匯總表3.2.4 需求評審分析需求分析總體流程如下:3.2.4.1 主要參與人員項目經(jīng)理、開發(fā)負責人、需求管理員根據(jù)具體情況可通知技術支持人員、開發(fā)人員、項目管理專員等相關干系人參會。3.2

13、.4.2 工作內(nèi)容及要求(1) 需求管理員組織人員對需求設計從技術和業(yè)務方面進行可行性分析,對業(yè)務邏輯、業(yè)務流程等進行評估。若出現(xiàn)以下幾種情況可退回項目經(jīng)理:技術層面: 與其他需求有重復的。 需求中有不合理事項的。 需求不明確需做補充的。業(yè)務層面: 與目前的業(yè)務操作流程、運營有矛盾的。 業(yè)務流程未理順,業(yè)務規(guī)則未明確或者沒有體現(xiàn),有可能導致上線后,無法正常進行業(yè)務運作,或者存在運營風險的。若出現(xiàn)以下幾種情況需發(fā)送給部門領導進行審批。技術層面: 需對系統(tǒng)結(jié)構(gòu)進行大規(guī)模改造的。 涉及系統(tǒng)架構(gòu)變更的。 當前技術無法實現(xiàn)的。業(yè)務層面: 需大規(guī)模的更改原有的業(yè)務流程,增加大量人工后續(xù)處理成本。(2) 項

14、目經(jīng)理根據(jù)需求評審結(jié)果完善需求文檔,形成最終需求。(3) 分析總公司系統(tǒng)是否已經(jīng)實現(xiàn)該功能或類似功能,若已實現(xiàn)由需求管理員負責與總公司相關人員進行溝通獲取升級包。(4) 如果總公司版本未實現(xiàn)該功能,需討論分析并確定該需求是本地設計開發(fā)還是總公司設計開發(fā)。若為總公司開發(fā),由需求管理員及時將需求提交到jira系統(tǒng)并與總公司人員聯(lián)系,確定完成時間。(5) 開發(fā)負責人確認需求的實現(xiàn)方式,評估需求的開發(fā)工作量,確定需求開發(fā)完成時間及開發(fā)人員,形成解決方案,并在jira系統(tǒng)中備注解決計劃。3.2.4.3 成果資料解決方案、需求文檔、需求匯總表3.2.5 需求開發(fā)3.2.5.1 主要參與人員開發(fā)負責人、開發(fā)

15、人員3.2.5.2 工作內(nèi)容及要求開發(fā)負責人:(1) 每天及時登錄jira系統(tǒng),收集需求管理員發(fā)送的需求,從技術方面進行可行性分析,并判斷該功能是否會影響已有的業(yè)務功能,若存在問題應及時告知需求管理員,由項目經(jīng)理對需求進行變更并告知甲方,如無問題需在2個工作日內(nèi)向需求管理員反饋開發(fā)計劃并在jira系統(tǒng)中注明。(2) 對于有疑義的,聯(lián)系需求管理員組織需求評審分析會議,從業(yè)務、技術角度對需求實現(xiàn)方式、風險等進行評估,并制定解決計劃。(3) 制定需求開發(fā)計劃,分配需求開發(fā)人員,確定技術方案。(4) 及時向需求管理員反饋開發(fā)計劃。開發(fā)人員:(1) 根據(jù)需求評估通過的需求文檔及開發(fā)計劃按時進行設計開發(fā),

16、并在jira中備注解決進展情況。(2) 如果涉及到對數(shù)據(jù)庫結(jié)構(gòu)的變動修改,應及時更新維護數(shù)據(jù)庫結(jié)構(gòu)說明書。(3) 編碼完成后,開發(fā)人員需進行編譯部署、單元測試。(4) 將開發(fā)成果提交開發(fā)負責人審核確認。(5) 無問題之后在jira上轉(zhuǎn)交測試人員。3.2.5.3 成果資料數(shù)據(jù)庫設計說明書(更新)、部署文檔、更新說明、需求更新包(包含數(shù)據(jù)腳本)3.2.6 需求測試3.2.6.1 主要參與人員項目經(jīng)理、實施人員3.2.6.2 工作內(nèi)容及要求(1) 制定需求測試計劃,分配測試任務,對系統(tǒng)功能進行測試。(2) 測試若存在問題及時反饋開發(fā)負責人和需求管理員,在jira中備注測試情況,并跟進解決情況,完成之

17、后重新進行測試。(3) 內(nèi)部測試完成之后,向甲方提出測試申請,由甲方人員進行系統(tǒng)測試,完成需求結(jié)果確認。3.2.6.3 成果資料測試報告、系統(tǒng)用戶操作手冊(更新)3.2.7 需求上線3.2.7.1 主要參與人員項目經(jīng)理、實施人員、開發(fā)人員3.2.7.2 工作內(nèi)容及要求(1) 項目經(jīng)理與甲方溝通,提起上線申請。(2) 對數(shù)據(jù)庫及應用程序進行備份。(3) 系統(tǒng)升級上線,并進行上線驗證。(4) 若上線驗證失敗,則將上線版本從生產(chǎn)環(huán)境中回退,需求轉(zhuǎn)入開發(fā)流程。(5) 維護更新系統(tǒng)操作手冊,上線之后3個工作日內(nèi)針對適用人員進行操作培訓。(6) 項目經(jīng)理負責與客戶確認需求最終結(jié)果,由甲方人員在需求確認單上

18、進行簽字確認并上傳jira,關閉需求,進行需求歸檔。(7) 需求管理員跟進確認結(jié)果,重要需求需要需求管理員直接與甲方人員進行確認。3.2.7.3 成果資料需求確認單、需求匯總表3.2.8 需求變更需求變更:指開發(fā)人員受理需求后,需增加、修改、刪除需求內(nèi)容的現(xiàn)象。需求變更流程圖如下:3.2.8.1 主要參與人員項目經(jīng)理、需求管理員、開發(fā)負責人3.2.8.2 工作內(nèi)容及要求(1) 項目經(jīng)理根據(jù)需求變更內(nèi)容填寫需求變更文檔。(2) 按照項目組需求確認單樣式填寫需求變更,并由甲方簽字確認。(3) 需求變更后重新提交jira系統(tǒng)。(4) 需求管理員進行審批,不通過退回至項目經(jīng)理,通過之后判斷是否屬于重大需求變更。(5) 重大需求變更需求管理員組織項目經(jīng)理、開發(fā)負責人及相關干系人召開需求評審會,確定解決方案。(6) 開發(fā)負責人2個工作日內(nèi)制定開發(fā)計劃

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論