任務資訊管理系統需求分析說明書案例參考

2021-03-04 00:14:12 字數 4186 閱讀 3875

技術檔案

檔名稱:任務管理系統需求說明書

專案名稱:任務管理系統

共頁(包括封面)

作者本文詳細描述任務管理系統的需求,表述的需求資訊要求明確、無二義性。開發方與軟體使用者充分溝通需求,最終形成此文件。此文件是後續軟體開發的依據。

任務管理系統是乙個xx與xx電氣新技術****產學研合作專案,專案由xx機電新技術****提出,由xx承擔開發任務。

本文使用了表 1.1所顯示的面向使用者的術語、定義,包括通用詞語在本文件中的專用解釋。

表 1.1 術語/定義

表 1.2所列為本文用到的縮略語。

表 1.2 縮略語

本文使用了表 1.3所列為本文用到的參考資料。

表 1.3 參考資料

任務資訊管理系統的目前使用者為xx公司電氣事業部,電氣事業部使用成功後可能會在xx公司推廣。

xx公司電氣事業部目前的任務主要有2類:常規工作任務和臨時性工作任務。

針對臨時任務布置資訊很多時候是處於一種開放狀態,缺少任務資訊的修正、回饋、和統計分析。而日常職責規定的常規工作,雖然可以通過標準化的檔案固化下來並形成《常規工作計畫表》作為一種制度來執行,也需要主管在百忙之中花很多時間去檢查完成情況。

tims系統要求工作管理資訊能夠規範錄入,任務資訊流向可以選擇,任務資訊依據輕重排序,可以設定資訊提醒,任務完成情況可以評估、任務完成情況依據選擇項進行統計輸出、工作量進行評估。

tims專案的需求主要由xx公司電氣事業部提出,因此本文件是與xx公司電氣事業部互動後形成的需求定義,系統的功能和使用特點優先滿足xx公司電氣事業部的需求,若系統後續由於在xx公司全面推廣而引入的新需求,則不在本文件考慮範圍之內。

本文件經雙方確認後,開發方依據本文件進行下階段工作。若中途需求發生變更則xx公司需及時告知開發方,若因xx公司原因引入的需求變更造成開發方工作量的大幅增加,具體解決方案雙方另行協商。若需求變更引入的工作量不大,開發方應盡量配合。

xx公司電氣事業部的組織架構如圖4-1。

圖4-1 電氣事業部組織架構

tims系統面向整個電氣事業部使用,圖4-1給出了電氣事業部的詳細組織。

系統的使用者是xx公司的員工,員工在現實邏輯中分屬不同的部門並具有相應的工作許可權。系統許可權分配時與員工的組織架構並無對應關係。tims系統的許可權需求有2層含義。

1.針對系統功能設定使用者的操作許可權。

2.針對使用者可以設定檢視哪些任務的許可權。例如可以設定某使用者檢視生產部的所有任務資訊;設定使用者a可以檢視使用者b及使用者c的任務資訊。

tims主要對任務資訊進行管理,實現任務資訊的標準化管理。tims系統關於任務處理的用例圖如圖4-2。

圖4-2 系統用例圖1

圖4-3 系統用例圖2

詳細的功能需求說明請參見本文件後續章節。

針對tims系統中任務可能的流程進行分析。為方便理解,對應圖4-4進行表述。

圖4-4 人員組織架構示例圖

流程設計思想:

tims系統採用資訊閉環的思想,即任務由任務發布者發布出去,任務最終也在任務發布者處結束,圖4-5簡單的表示了這一思想,同時也概括了任務在tims系統中的處理流程。

圖4-5 tims系統任務處理流程圖

任務下達採用逐級的層次方式,任務的反饋採用逐級向上的方式。

例如下達任務給製造組的z3時,任務發布者x應該將任務發布給製造組的主管z0,由主管z0在自己的主管範圍內分配該任務,而最終的任務接收者是z3。若z3提交完成情況和延期申請,則先提交至z0,z0根據實際情況決定是否提交以及如何提交給x。x最終決定是否同意延期以及對任務完成情況進行評價。

具體任務處理規則說明如下:

1.關於任務發布者

1)預設的情況下,任務只能由組織的主管發布,且不能越級發布。例如生產部主管s0只能給g0、j0、z0發布任務。假若最終任務t由z1承擔,那麼是s0向z0下達任務,z0再將任務t分配給z1。

2)系統可以設定使用者可向哪些人員發布任務。

例如:可以設定計畫組的j1向z0、g0發布任務;

可以設定s0向k0、l0發布任務。

3)可以設定使用者直接向具體人員發布任務。

例如:可以設定j1直接向d2發布任務。正常的發布順序應該是j1->z0->d0->d2。

系統自動記錄任務相關人員z0、d0,任務延期、提交完成情況由任務承擔者d2直接提交給任務發布者j1,但自動設定z0、d0同意延期和提交完成情況。

2.關於任務的分配和分解

1)若任務的接收者是組織的主管,則可以將任務分配給其組織的直接下屬。例如製造組的主管z0可以將任務分配給z1、z2、z3,當然也可以分配給自己,但不能將任務分配給d1,需要將任務先分配給d0,由d0再在自己的組織進行同樣方式的分配。(說明:

圖4-3中製造組主管z0直接下屬是z0、z1、z2、z3、d0)。

2)任務接收者接收到任務t後,可以將任務分解為若干子任務t1…tn,然後發布給本組織的員工。

3.關於發布任務

1)任務接收者可以有多個,必須設定乙個主任務接收者。任務主接收者體現在任務的實際協調上。

2)任務接收者可以是組織的主管,也可以不是。如果是組織的主管則可以分配任務和分解任務。

3) 任務的第一接收人是指最初接收到任務的員工。例如x發布任務給z0,z0再分配任務給z3。那麼z0為任務第一接收人,z3為任務的承擔者。

4)任務第一接收人在接收到任務後必須決定是否接收任務。只有在接收了任務後,才能進行後面的分配任務和分解任務操作。若不同意接收任務則拒絕任務。

5)任務的第一接收人有多個的情況,例如s0給z0和j0發布任務t。

(1)主管z0和主管j0必須作出是否接收任務的判定。

若z0拒絕了任務t,則s0處理z0的拒絕資訊,可以打回或者接受z0的拒絕。 若s0因為z0的拒絕而修改了任務資訊,則需要通知j0,如果j0之前已經接收了任務,則可以針對修改後的任務資訊再次進行拒絕或者接收操作。

(2)只有z0和j0都接收了任務,則任務t的狀態為進行狀態。

(3)只有任務狀態為進行狀態z0和j0才能分配任務。

4.關於任務反饋

1)任務是逐級下達,任務反饋則是逐級匯報。

2)以x發布任務給z0,z0又將任務分配給z1、z2為例。

(1)z1可以向所有任務相關人員(z0、x、z1、z2)傳送資訊。

(2)z1、z2若要申請延期,則只能向任務分配者z0申請。

(3)z0收到z1或者z2的延期申請後,處理此延期申請。z0根據整個任務的進度情況,來人為判斷z1或者z2的延期是否對整個任務造成延期,若對整個任務不造成延期,不需要向x提出延期申請;若對整個任務造成延期,可以向任務發布者x提交延期申請。任務發布者x最終決定任務是否延期。

(4) z1、z2向對應的任務分配者提交完成情況,z1、z2的工作由z0評價,z0最終彙總z1、z2的任務完成情況,向x提交完成情況。x根據任務第一接收人提交的完成情況進行評價,同時對整個專案進行評價。

5.關於任務完成情況及評價

1)由任務發布者決定任務的完成狀態。

(1)如果所有第一接收人在任務期限內都確認完成了任務,任務發布者給出每個任務接收的評價後,設定任務為完成。

(2)如果第一接收人沒有申請延期,但確認完成任務時間晚於任務期限,則系統自動設定為非正常延期完成。

(3)若任務在期限內沒有完成,或者說任務已經不可能完成,任務發布者可以設定任務為未完成。

(4)若有第一接收人申請了延期,且延期理由合理,任務發布者同意延期,並修改任務期限。應設定任務為正常延期完成。

(5)若有第一接收人申請了延期,但延期理由不合理,任務發布者不同意延期。應設定任務為非正常延期完成。

1.任務第一接收人只有乙個

圖4-6任務發布流程1

流程說明:

1) x發布任務給製造組的主管z0,同時將任務抄送s0,由於任務是初始傳送給z0,z0必須決定是否接收才能進行後續操作。

2) z0接收任務後,可以將任務分配給自己,也可以分配給製造組內使用者,如圖4-3所示,z0將任務分配給d0和z2,而d0是工段1的主管,他仍然可以將分配到自己的任務繼續向下屬分配,d0將任務分配給了d1。

3) d1的延期申請、完成情況均直接提交給其任務分配者d0,由d0對其完成情況進行評價。d0若認可了d1的延期申請,則由d0向z0提交延期申請,若z0同意了d0的延期申請,則向x提交延期申請,最終可否延期由x決定,x若同意延期則更改任務完成期限。

4)由d1向d0提交完成情況,d0對d1的完成情況進行評價;由d0向z0提交完成情況,z0對d0的完成情況進行評價;由z0向x提交完成情況,由x對z0的完成情況進行評價。

5)每個任務第一接收者都要提交自己的完成情況,任務發布者評判每個任務接收者的完成情況,最後給出整個任務的完成情況評價。

2.任務第一接收人有多個

學生資訊管理系統需求分析說明書

三 需求規格說明書 1 引言 1 1.1編寫目的 1 1.2專案背景 2 1.3定義 2 1.4參考資料 2 2 任務概述 3 2.1目標 3 2.2執行環境 3 2.3條件與限制 3 3 資料描述 4 3.1靜態資料 4 3.2動態資料 4 3.3資料庫介紹 4 3.4資料詞典 5 3.5資料採集...

賓館資訊管理系統需求分析說明書

日期 2010 10 19 目錄1.引言 3 1.1 專案背景 3 1.2 專案目標 3 2.系統工作原理 4 3.賓館業務處理系統 4 3.1事務處理 8 3.1.1賓館退訂房資訊管理 10 4.e r圖 18 開發軟體名稱 賓館資訊管理系統 產品設計者 學生 使用者 賓館工作人員及客人 伴隨著我...

人事資訊管理系統需求分析說明書

需求分析 1介面要求 1 介面內容 主題突出 操作方便 術語和行文格式統 一 規範 明確。選單布局合理,傳遞資訊準確。2 介面功能人性化,操作簡單,能被所有使用者快速接受。2功能要求 本員工資訊管理系統的主要面向某個企業內部的人事資訊管理人員和在職人員開發的人事資訊管理系統,規範 完善的基礎資訊設定...