前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的人員需求分析報告主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：人員需求分析報告范文

引言是對這份軟件產品需求分析報告的概覽，是為了幫助閱讀者了解這份文檔是如何編寫的，并且應該如何閱讀、理解和解釋這份文檔。

1.1 編寫目的

說明這份軟件產品需求分析報告是為哪個軟件產品編寫的，開發這個軟件產品意義、作用、以及最終要達到的意圖。通過這份軟件產品需求分析報告詳盡說明了該軟件產品的需求規格，包括修正和(或)發行版本號，從而對該軟件產品進行準確的定義。

如果這份軟件產品需求分析報告只與整個系統的某一部分有關系，那么只定義軟件產品需求分析報告中說明的那個部分或子系統。

1.2 項目風險

具體說明本軟件開發項目的全部風險承擔者，以及各自在本階段所需要承擔的主要風險，首要風險承擔者包括：

任務提出者;

軟件開發者;

產品使用者。

1.3 文檔約定

描述編寫文檔時所采用的標準(如果有標準的話)，或者各種排版約定。排版約定應該包括：

正文風格;

提示方式;

重要符號;

也應該說明高層次需求是否可以被其所有細化的需求所繼承，或者每個需求陳述是否都有其自己的優先級。

1.4 預期讀者和閱讀建議

列舉本軟件產品需求分析報告所針對的各種不同的預期讀者，例如，可能包括：

用戶;

開發人員;

項目經理;

營銷人員;

測試人員;

文檔編寫入員。

并且描述了文檔中，其余部分的內容及其組織結構，并且針對每一類讀者提出最適合的文檔閱讀建議。

1.5 產品范圍

說明該軟件產品及其開發目的的簡短描述，包括利益和目標。把軟件產品開發與企業目標，或者業務策略相聯系。

描述產品范圍時需注意，可以參考項目視圖和范圍文檔，但是不能將其內容復制到這里。

1.6 參考文獻

列舉編寫軟件產品需求分析報告時所用到的參考文獻及資料，可能包括：

本項目的合同書;

上級機關有關本項目的批文;

本項目已經批準的計劃任務書;

用戶界面風格指導;

開發本項目時所要用到的標淮;

系統規格需求說明;

使用實例文檔;

屬于本項目的其它己發表文件;

本軟件產品需求分析報告中所引用的文件、資料;

相關軟件產品需求分析報告;

為了方便讀者查閱，所有參考資料應該按一定順序排列。如果可能，每份資料都應該給出：

標題名稱;

作者或者合同簽約者;

文件編號或者版本號;

發表日期或者簽約日期;

出版單位或者資料來源。

2. 綜合描述

這一部分概述了正在定義的軟件產品的作用范圍以及該軟件產品所運行的環境、使用該軟件產品的用戶、對該軟件產品己知的限制、有關該軟件產品的假設和依賴。

2.1 產品的狀況

描述了在軟件產品需求分析報告中所定義的軟件產品的背景和起源。說明了該軟件產品是否屬于下列情況：

是否是產品系列中的下一成員;

是否是成熟產品所改進的下一代產品;

是否是現有應用軟件的替代品(升級產品);

是否是一個新型的、自主型的產品。

如果該軟件產品需求分析報告定義的軟件系統是：

大系統的一個組成部分;

與其它系統和其它機構之間存在基本的相互關系。

那么必須說明軟件產品需求分析報告定義的這部分軟件是怎樣與整個大系統相關聯的，或者(同時)說明相互關系的存在形式，并且要定義出兩者之間的全部接口。

2.2 產品的功能

因為將在需求分析報告的第4部分中詳細描述軟件產品的功能，所以在此只需要概略地總結。僅從業務層面陳述本軟件產品所應具有的主要功能，在描述功能時應該 針對每一項需求準確地描述其各項規格說明。如果存在引起誤解的可能，在陳述本軟件產品主要功能的作用領域時，也需要對應陳述本軟件產品的非作用領域，以利 讀者理解本軟件產品。

為了很好地組織產品功能，使每個讀者都容易理解，可以采用列表的方法給出。也可以采用圖形方式，將主要的需求分組以及它們之間的聯系使用數據流程圖的頂層圖或類圖進行表示，這種表示方法是很有用的。

參考用戶當前管理組織構架，了解各個機構的主要職能，將有助于陳述軟件產品的主要功能。

2.3 用戶類和特性

確定有可能使用該軟件產品的不同用戶類，并且描述它們相關的特征。往往有一些軟件需求，只與特定的用戶類有關。描述時，應該將該軟件產品的重要用戶類與非重要用戶類區分開。

用戶不一定是軟件產品的直接使用者，通過報表、應用程序接口、系統硬件接口得到軟件產品的數據和服務的人、或者機構也有他們的需求。所以，應該將這些外部需求視為通過報表、應用程序接口、系統硬件接口附加給軟件產品的附加用戶類。

2.4 運行環境

描述了本軟件的運行環境，一般包括：

硬件平臺;

操作系統和版本;

支撐環境(例如：數據庫等)和版本;

其它與該軟件有關的軟件組件;

與該軟件共存的應用程序。

2.5 設計和實現上的限制

確定影響開發人員自由選擇的問題，并且說明這些問題為什么成為一種限制。可能的限制包括下列內容：

必須使用的特定技術、工具、編程語言和數據庫;

避免使用的特定技術、工具、編程語言和數據庫;

要求遵循的開發規范和標準

例如，如果由客戶的公司或者第三方公司負責軟件維護，就必須定義轉包者所使用的設計符號表示和編碼標準;

企業策略的限制;

政府法規的限制;

工業標準的限制;

硬件的限制

例如，定時需求或存儲器限制;

數據轉換格式標淮的限制。

2.6 假設和約束(依賴)

列舉出對軟件產品需求分析報告中，影響需求陳述的假設因素(與己知因素相對立)。如果這些假設因素不正確、不一致或者被修改，就會使軟件產品開發項目受到影響。這些假設的因素可能包括：

計劃使用的商業組件，或者其它軟件中的某個部件;

假定產品中某個用戶界面將符合一個特殊的設計約定;

有關本軟件用戶的若干假定(例如：假定用戶會熟練使用SQL語言。);

有關本軟件開發工作的若干假定(例如：用戶承諾的優惠、方便、上級部門給予的特殊政策和支持等。);

有關本軟件運行環境的一些問題;

此外，確定本軟件開發項目對外部約束因素所存在的依賴。有關的約束可能包括：

工期約束;

經費約束;

人員約束;

設備約束;

地理位置約束;

其它有關項目約束;

3. 外部接口需求

通過本節描述可以確定，保證軟件產品能和外部組件正確連接的需求。關聯圖僅能表示高層抽象的外部接口，必須對接口數據和外部組件進行詳細描述，并且寫入數 據定義中。如果產品的不同部分有不同的外部接口，那么應該把這些外部接口的全部詳細需求并入到這一部分實例中。

注意：必須將附加用戶類的特征與外部接口需求加以區分，附加用戶類的特征描述的是通過接口取得軟件產品的數據和服務的人的需求;而外部接口需求描述的是接口本身的需求。

3.1 用戶界面

陳述需要使用在用戶界面上的軟件組件，描述每一個用戶界面的邏輯特征。必須注意，這里需要描述的是用戶界面的邏輯特征，而不是用戶界面。以下是可能包括的一些特征：

將要采用的圖形用戶界面(GUl)標準或者產品系列的風格;

有關屏幕布局或者解決方案的限制;

將要使用在每一個屏幕(圖形用戶界面)上的軟件組件，可能包括：

選單;

標準按鈕;

導航鏈接;

各種功能組件;

消息欄;

快捷鍵;

各種顯示格式的規定，可能包括：

不同情況下文字的對齊方式;

不同情況下數字的表現格式與對齊方式;

日期的表現方法與格式;

計時方法與時間格式;

等等。

錯誤信息顯示標準;

對于用戶界面的細節，例如：一個特定對話框的布局，應該寫入具體的用戶界面設計說明中，而不能寫入軟件需求規格說明中。

如果采用現成的、合適的用戶界面設計規范(標準)，或者另文描述，可以在這里直接說明，并且將其加入參考文獻。

3.2 硬件接口

描述待開發的軟件產品與系統硬件接口的特征，若有多個硬件接口，則必須全都描述。接口特征的描述內容可能包括：

支持的硬件類型;

軟、硬件之間交流的數據;

控制信息的性質;

使用的通訊協議;

3.3 軟件接口

描述該軟件產品與其它外部組件的連接，這些外部組件必須明確它們的名稱和版本號以資識別，可能的外部組件包括：

操作系統;

數據庫;

工具;

函數庫;

集成的商業組件

說明：這里所說的“集成的商業組件”，是指與系統集成的商業組件，而不是與軟件產品集成的商業組件。例如：中間件、消息服務，等等。

描述并且明確軟件產品與軟件組件之間交換數據或者消息的目的。描述所需要的服務，以及與內部組件通訊的性質。確定軟件產品將與組件之間共享的數據。如果必 須使用一種特殊的方法來實現數據共享機制，例如：在多用戶系統中的一個全局數據區，那么就必須把它定義為一種實現上的限制。

3.4 通訊接口

描述與軟件產品所使用的通訊功能相關的需求，包括：

電子郵件;

WEB瀏覽器;

網絡通訊標準或者協議;

數據交互用電子表格;

必須定義相關的：

消息格式;

通訊安全或加密問題;

數據傳輸速率;

同步和異步通訊機制;

4. 系統功能需求

需要進行詳細的需求記錄，詳細列出與該系統功能相關的詳細功能需求，并且，唯一地標識每一項需求。這是必須提交給用戶的軟件功能，使得用戶可以使用所提供 的功能執行服務或者使用所指定的使用實例執行任務。描述軟件產品如何響應己知的出錯條件、非法輸入、非法動作。

如果每一項功能需求都能用一項，也只需要用一項測試用例就能進行驗證，那么就可以認為功能需求已經適當地進行描述了。如果某項功能需求找不到合適的測試用例，或者必須使用多項測試用例才能驗證，那么該項功能需求的描述必然存在某些問題。

功能需求是根據系統功能，即軟件產品所提供的主要服務來組織的。可以通過使用實例、運行模式、用戶類、對象類或者功能等級來組織這部分內容，也可以便用這些元素的組合。總而言之，必須選擇一種是讀者容易理解預期產品的組織方案。

用簡短的語句說明功能的名稱，例如：“4.1系統參數管理”。按照服務組織的順序，逐條闡述系統功能。無論說明的是何種功能，都應該針對該系統功能重復敘述4.1~ 4.3這三個部分。

可以通過各種方式來組織這一部分內容，例如采用：使用實例、運行模式、用戶類、對象類、功能等級等，也可以采用它們的組合。其最終目的是，讓讀者容易理解 即將開發的軟件產品。一般來說，每個使用實例都對應一個系統功能，因而按照使用實例來組織內容比較容易讓用戶理解。

對應一些被共享的獨立使用實例，可以定義一些公用系統功能。

必須特別注意的是，在2.2節“產品的功能”中描述的全部需求，以及它們的規格說明;必須在某個系統功能描述中有所反映，而且不應重復。

4.1 說明和優先級

對該系統功能進行簡短的說明，并且指出該系統功能的優先級是：高、中、還是低。需要的話，還可以包括對特定優先級部分的評價，例如：利益、損失、費用和風險，其相對優先等級可以從1(低)到9(高)。

4.2 激勵/響應序列

列出輸入激勵(用戶動作、來自外部設備的信號或者其它觸發)并且定義針對這——功能行為的系統響應序列，這些序列將與使用實例中相關的對話元素相對應。

描述激勵/響應序列時，不僅需要描述基本過程，而且應該描述可選(擴充)過程，包括例外(引起任務不能順序完成的情況稱為例外)。疏忽了可選過程，有可能影響軟件產品的功能;如果遺漏例外過程，則有可能會引發系統崩潰。

如果采用流程圖來描述激勵/響應序列，比較容易讓用戶理解。

4.3 輸入/輸出數據

列出輸入數據(用戶輸入、來自外部接口的輸入或者其它輸入)并且定義針對這些輸入數據的處理(計算)方法，以及相應地輸出數據，描述對應區別：輸入數據和輸出數據。

當有大量數據需要描述時，也可以分類描述數據，并且注明各項數據的輸入、輸出屬性。

對于每一項數據，均需要描述：

數據名稱;

實際含義;

數據類型;

數據格式;

數據約束;

對于復雜的處理方法，僅僅給出算法原理是不夠的，必須描述詳細的計算過程，并且列出每一步具體使用的實際算式;如果計算過程中涉及查表、判斷、迭代等處理方法，應該給出處理依據和相關數據。如果計算方法很簡單，也可以將其從略，不加描述。

5. 其它非功能需求

在這里列舉出所有非功能需求，主要包括可靠性、安全性、可維護性、可擴展性、可測試性等。

5.1 性能需求

闡述不同應用領域對軟件產品性能的需求，并且說明提出需求的原理或者依據，以幫助開發人員做出合理的設計選擇。盡可能詳細地描述性能需求，如果需要，可以針對每個功能需求或者特征分別陳述其性能需求。在這里確定：

相互合作的用戶數量;

系統支持的并發操作數量;

響應時間;

與實時系統的時間關系：

容量需求

存儲器;

磁盤空間;

數據庫中表的最大行數。

5.2 安全措施需求

詳盡陳述與軟件產品使用過程中可能發生的損失、破壞、危害相關的需求。定義必須采取的安全保護或動作，以及必須預防的潛在危險動作。明確軟件產品必須遵從的安全標準、策略、或規則。

5.3 安全性需求

詳盡陳述與系統安全性、完整性問題相關的需求，或者與個人隱私問題相關的需求。這些問題將會影響到軟件產品的使用，和軟件產品所創建或者使用的數據的保 護。定義用戶身份認證，或備授權需求。明確軟件產品必須滿足的安全性或者保密性策略。也可以通過稱為完整性的質量屬性來闡述這些需求。一個典型的軟件系統 安全需求范例如下：“每個用戶在第一次登錄后，必須更改他的系統預置登錄密碼，系統預置的登錄密碼不能重用。”

5.4 軟件質量屬性

詳盡陳述對客戶和開發人員至關重要的在軟件產品其它方面表現出來的質量功能。這些功能必須是確定的、定量的、在需要時是可以驗證的。至少也應該指明不同屬性的相對側重點，例如：易用性優于易學性，或者可移植性優于有效性。

5.5 業務規則

列舉出有關軟件產品的所有操作規則，例如：那些人在特定環境下可以進行何種操作。這些本身不是功能需求，但是他們可以暗示某些功能需求執行這些規則。一個 業務規則的范例如下：“進行達到或者超過10，000，00元人民幣的儲蓄業務時，必須通過附加的管理員認證。”

列舉業務規則時，可以根據規則的數量，選取合適的編目方式。

5.6 用戶文檔

列舉出將與軟件產品一同交付的用戶文檔，并且明確所有己知用戶文檔的交付格式或標準，例如：

安裝指南

紙質文檔，16開本;

用戶手冊

紙質文檔，16開本;

在線幫助

電子文檔，與軟件產品一同分發、配置;

使用教程電子文檔，與軟件產品一同分發、配置。

6. 詞匯表

列出本文件中用到的專業術語的定義，以及有關縮寫的定義(如有可能，列出相關的外文原詞)。為了便于非軟件專業或者非計算機專業人士閱讀軟件產品需求分析 報告，要求使用非軟件專業或者非計算機專業的術語描述軟件需求。所以這里所指的專業術語，是指業務層面上的專業術語，而不是軟件專業或者計算機專業的術 語。但是，對于無法回避的軟件專業或者計算機專業術語，也應該列入詞匯表并且加以準確定義。

7. 數據定義

數據定義是一個定義了應用程序中使用的所有數據元素和結構的共享文檔，其中對每個數據元素和結構都準確描述：含義、類型、數據大小、格式、計量單位、精度 以及取值范圍。數據定義的維護獨立于軟件需求規格說明，并且在軟件產品開發和維護的任何階段，均向風險承擔者開放。

如果為軟件開發項目創建一個獨立的數據定義，而不是為每一項特性描述有關的數據項，有利于避免冗余和不一致性。但是卻不利于多人協同編寫需求分析報告，容 易遺漏數據，也不方便閱讀。因此還是建議為每個特性描述有關的數據項，匯總數據項創建數據定義，再根據數據定義復核全部數據，使得它們的名稱和含義完全一 致。必須注意的是，為了避免二義性，在匯總數據項時應該根據數據項所代表的實際意義匯總，而不是根據數據項的名稱匯總。

在數據定義中，每個數據項除了有一個中文名稱外，還應該為它取一個簡短的英文名稱，該英文名稱應該符合命名規范，因為在軟件開發時將沿用該英文名稱。可以使用等號表示數據項，名稱寫在左邊，定義寫在右邊。常見數據項的描述方式如下：

原數據元素

一個原數據元素是不可分解的，可以將一個數量值賦給它。定義原數據元素必須確定其

含義、類型、數據大小、格式、計量單位、精度以及取值范圍。采用以星號為界的一行

注釋文本，描述原數據元素的定義。

選擇項

選擇項是一種只可以取有限離散值的特殊原數據元素，描述時一一枚舉這些值，并用方

括號括起來寫在原數據元素的定義前。在兩項離散值之間，使用管道符分隔。

組合項

組合項是一個數據結構或者記錄，其中包含了多個數據項。這些數據項可以是原數據元

素，也可以是組合數據項，各數據項之間用加號連接。其中每個數據項都必須是數據定

義中定義過的，結構中也可以包括其它結構，但是絕對不允許遞歸。如果數據結構中有

可選項，使用圓括號把該項括起來。

重復項

重復項是組合項的一種特例，其中有一項將有多個實例出現在數據結構中，使用花括號

把該項括起來。如果知道該項可能允許的范圍，就按“最小值：最大值”的形式寫在花

括號前。

8. 分析模型

這是一個可選部分，包括或涉及到相關的分析模型，例如：

數據流程圖;

類圖;

狀態轉換圖;

實體-關系圖。

第2篇：人員需求分析報告范文

關鍵詞：網站建設；項目管理

中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2008)22-617-02

隨著互聯網的迅猛發展，網站建設業已興起，越來越多的網站任務需要專門的網絡公司來完成。在計算機專業的教學與實踐中，網頁設計、網站建設與規劃、網站管理與維護等課程成為學生的首選課程，而且成為學生擇業、就業的一個主要方向。

通過網絡技術專業建設、課程設計和畢業設計，尤其是對網絡公司的項目實施、網站建設過程的跟蹤，我們發現，越來越多的問題出現在網站建設過程中，而且帶有普遍現象，例如：網絡公司不能按期完成制作，網站不能使客戶滿意，設計費用超出預算，網站維護不及時等等。

對各種問題及其產生過程進行仔細分析，不難發現，主要原因有以下幾點：

1)輕視項目進度監督，公司不重視項目管理，只著重抓合同，忽視開發進程，導致不能按期交付網站作品；

2)忽視客戶的需求變化，網絡公司在項目承接和建設中只考慮客戶提出的具體要求，對潛在需求及未來發展的分析不足，與客戶溝通不夠，導致客戶滿意度不高；

3)沒有保留歷史文檔作參考，技術人員只注重程序、網頁的保存，忽略了文檔是軟件的一個重要組成部分，往往導致修改維護費時費力、費用超支、客戶不滿意；

4)忽視不斷的測試和修改。公司對項目的跟蹤不夠，過分依賴于項目驗收；

5)沒有使用專業的項目管理軟件，主要依靠主觀決策、行政命令。

有沒有一個比較好的解決辦法可以減少失誤、控制和管理網站建設過程呢？

網站建設是一個復雜的系統工作，可以看作一個項目來管理。項目管理是研究在時間和資金一定的條件下，如何通過科學地計劃、控制和組織達到既定目標的科學。對網絡公司來說，項目管理就是對網站建設項目的全過程管理，是一個動態的過程。

通過深入研究項目管理理論，結合項目實施中的具體經驗，針對網站建設的特點和重點，在專業教學中不斷實施、補充、完善后，我們整理出一套以項目管理方式實施的、切實可行的網站建設管理和控制的方法，稱之為網站建設項目管理。

網站建設項目管理是網站建設項目的管理和控制方法，要根據特定的規范，在預算范圍內按時完成網站開發任務。這是一種特殊的、標準的操作程序，能夠強化管理，改善經營機制，提高網站質量，促進資金合理運用，降低經營風險，提高經濟效益。

網站建設項目管理的實行，不但使客戶得益，保護投資，而且使網站制作行業趨向于規范化，效益提升，更使從業人員得益，包括項目經理、網頁設計師、程序員、網頁編輯人員和測試員等。

要提高計算機專業學生的網站建設綜合水平，教學中應該強化課程設計，模擬項目的具體實施過程，把學生分組后再分成客戶、網絡公司甲乙雙方，按照網站項目從洽談到提交完成的順序，指導學生分布實施網站建設項目管理。

1 客戶需求分析

一個優秀的網站建設項目是建立在對客戶需求的詳細了解、分析、研究的基礎上的，通常需要經過以下二個過程完成：

1.1 成立項目小組

網絡公司在接到客戶的網站業務咨詢后，雙方有關人員要不斷接洽和了解，通過基本的可行性討論，初步達成網站建設協議，這時要指導學生進行項目立項。

比較好的做法是在學生小組中成立一個專門的項目小組，成員分派項目經理、網頁設計人員、程序員、測試員、編輯/文檔人員等必需人員。項目小組成立后應該首先明確每個人的職責，實行項目經理責任制，這樣能有效實施監管，保障項目順利進行。

1.2 需求分析報告

網站建設項目首先需要客戶提供一個完整的需求分析報告。

很多客戶對自己的需求并不是很清楚，需要不斷引導，幫助他們分析。

經常出現的狀況是，詢問客戶做網站的目的，客戶回答“沒什么，別的公司有，我也得有！”。這就需要技術人員耐心說明，仔細分析，挖掘出客戶潛在的真正需求。

要配合客戶寫一份詳細、完整的需求分析報告會花很多時間，也是很費力的，但這樣做是值得的，而且一定要讓客戶滿意，簽字認可。把好這一關，就可以杜絕很多因客戶需求不明確或雙方理解偏差而造成的失誤和無效勞動，進而避免項目失敗。

高質量的網站必然有一份優秀的需求分析報告，這就要求項目小組從實際出發，通過實地調研、用戶座談、匯總歸納、系統分析等多角度入手，至少達到以下要求：

正確性，每個功能模塊都必須清楚地描述出交付客戶時應具備的功能；

可行性，確保在當前的資金、開發能力和系統環境下可以實現客戶的每個需求；

必要性，提出的功能是否必須交付，是否可以推遲實現的時間，是否可在削減開支時“砍”掉；

簡明性，為了使雙方的理解一致，必須把意思表達清楚，最好不要使用專業術語；

檢測性，項目開發完畢，客戶應該如何根據提出的需求進行檢測，檢測方法必須是簡單、可行的。

2 系統設計

2.1 網站總體規劃設計

完成客戶的需求分析報告以后，緊接著并不是直接開始制作，而是需要對項目進行總體規劃設計、詳細設計，拿出一份完整的網站建設方案給客戶。

總體規劃設計是項目建設非常關鍵的一步，是為即將建設的網站提出一套完整的設想，要依據需求分析報告確定網站需要實現的功能、網站開發軟件、硬件環境、人力資源、時間、需要遵循的規則和標準等。

總體規劃設計對網站的功能完善、安全可靠、性能先進至關重要，報告至少應包括網站的欄目和版塊、網站的功能和應具備的相應的程序、網站的鏈接結構、數據庫的概念設計、網站的交互性和用戶友好設計等。

2.2 網站建設方案

總體規劃設計報告完成后，通常需要給客戶提供一個網站建設方案。

很多網絡公司在接洽業務時就被客戶要求提供方案，但那時的方案一般比較籠統，而且是在客戶需求不是十分明確的情況下提交的，往往和實際制作后的結果有很大的差異。因此，應該盡量取得客戶的理解，在明確需求并進行總體規劃設計后再次提交網站建設方案，這樣對雙方都有好處。

網站建設方案應該包括有關的圖表、圖片、網頁設計草圖等，一般應具備以下內容：

1)客戶分析，實事求是地剖析客戶的現狀與發展，尤其要挖掘客戶的潛在需求，為客戶需求說明書奠定基礎；

2)網站的目的和目標，由此產生功能模塊的設計和形象設計；

3)網站形象說明，從藝術的角度分析，一般需要美編對客戶進行較深入的了解，結合客戶公司的產品和企業理念進行設計；

4)網站的欄目、版塊和結構，最好提供簡介明了的結構圖；

5)網站內容的安排、相互間的鏈接關系，尤其要注意知識產權問題，還要注意鏈接網站的安全問題；

6)使用的軟件、硬件、技術分析說明，要突出技術的先進性與實用性，要考慮實際應用效果，不要一味求新、求異；

7)開發時間進度表，在用戶能夠接受的基礎上，要留有一定的時間富裕度，以避免突發事件的影響；

8)網站宣傳推廣方案，要做好與客戶的商務部門的聯系；

9)網站維護方案，要明確區分免費維護期、收費維護期的費用、升級費用等，界定維護期和維護響應時間；

10)制作費用，要兼顧雙方的財務制度，并與合同相吻合；

11)本公司簡介，包括公司理念，成功的作品，技術、人才說明等內容。

方案通過客戶的認可，簽訂正式合同（一般由銷售經理或項目經理起草）后才可以開始著手建設網站，但這還不是真正意義上的制作，還要進行詳細設計。

3 網站詳細設計

總體設計階段以比較抽象、概括的方式提出解決問題的方法，詳細設計階段的任務就是把解決問題的方法具體化。

網站詳細設計是公司的內部技術資料，主要是針對程序開發而言，卻不是真正地編寫程序，而是由項目經理組織項目小組設計出程序的詳細規格說明，其作用類似于工程領域中工程師經常要使用的工程藍圖，應該包含必要的細節，如程序界面、表單、模塊接口、需要的數據等等。

本階段務必規定統一的軟件接口，以避免增加程序鏈接、調試的工作量。

4 項目實施

4.1 整體形象設計

網頁設計師負責設計網站的整體形象和首頁。整體形象設計包括標準字、標準色彩、Logo、廣告語等。首頁設計包括版面、色彩、圖像、動態效果、圖標等風格設計及banner、菜單、標題、版權等模塊設計。

首頁一般要設計2-3個不同的風格，完成后方便客戶選擇。一定要注意的是，在客戶確定首頁風格之后，務必請客戶簽字認可。這樣，客戶以后一般不會再對版面的風格做大的改動，否則將被視為二次設計。

4.2 程序開發與網頁制作

詳細設計、整體形象設計得到客戶確認以后，程序員根據詳細設計進行編程，網頁設計師開始制作網頁。

需要提醒項目小組的是，測試人員要隨時測試網頁與程序，發現Bug后立刻記錄并反饋給有關技術人員進行修改，一定不要等到完全制作完畢后再測試，那樣會浪費大量的時間和精力。

項目經理要經常了解項目的進度，協調、溝通程序員與網頁設計師的工作。

4.3 網站調試與完善

網站初步完成以后，要上傳到服務器，對網站進行全范圍的測試，包括速度、兼容性、交互性、鏈接正確性、程序健壯性、超流量測試等，發現問題應記錄下來，交項目小組及時解決。

（下轉第623頁）

（上接第618頁）

網站項目是一個不斷充實和完善的過程，文檔必須詳細記錄并保存，通過不斷發現問題、解決問題、修改補充文檔，使網站建設流程趨向于規范化，趨向于合理性。

4.4 網站宣傳推廣

網站宣傳推廣方案可以獨立進行，也可以與企業宣傳活動同步進行，一般采用與企業的策劃、公關及商務宣傳活動同期、同時進行，可以一舉多得。

網站宣傳推廣的方法有多種，設置適當的META標簽、登錄搜索引擎、發表新聞稿件、使用Email郵件列表、廣告條交換、付費廣告等，這些方法的使用一定要事先與客戶溝通，得到客戶的確認。

至此，網站項目建設完畢，項目小組將有關網址、使用操作說明、驗收要求及相關文檔等內容提交客戶進行驗收。如果客戶需要，還應另行簽訂網站維護合同。

4.5 網站管理與維護

網站成功推出是長期維護工作的開始，與客戶簽訂網站維護合同后，公司應該指派專門的技術人員或固定的文員負責響應全部或大部分客戶的網站維護工作。

1) 及時響應客戶反饋，可以采取Email自動回復方式，在1-3個工作日內（具體可與網站建設方案中的維護響應時間一致，必須與合同一致）解決問題，然后再次回復客戶，并征求客戶意見；

2) 網站流量統計分析和相應對策，客服人員要關注客戶網站的使用，發現問題及時處理，并對客戶提出有價值的建議；

3) 盡量推廣和使用所設計的網址，包括在客戶的宣傳材料、產品介紹、名片、電子郵件上注明客戶網址，與客戶溝通后一般會得到積極響應；

4) 網站內容的及時更新和維護，要注意內容的合理性、合法性和觀賞性，要與客戶的發展和商務活動相結合。

5 網站建設應遵循的規范

網站建設項目管理要求制定一系列的規范：目錄規范、文件命名規范、接口規范、尺寸規范、首頁head區代碼規范、連接結構規范等，并在項目實施中嚴格遵循。

在逐步建立網站建設項目管理規范的基礎上，最終要形成網絡公司統一的網站建設規范，為下一步的網站建設項目提供統一的技術標準，這樣，就能夠在未來的網站建設、維護中節省大量的時間和人財物，極大地提高公司的經濟效益與社會美譽度。

參考文獻：

第3篇：人員需求分析報告范文

關鍵詞：軟件工程；需求分析與管理

中圖分類號：TP311文獻標識碼：A文章編號：1007-9599 (2010) 15-0000-01

The Requirements Analysis and Management of Software

Huang Degui

(Communications Information Branch,Zhanjiang Port(Group)Co.,Ltd.,Zhanjiang524019,China)

Abstract:In the process of software development requirements analysis and management,there are some problems.This paper analyzes the problems and issues reference for these recommendations and solutions.

Keywords:Software engineering;Requirements analysis and management

在軟件項目開發過程中，需求分析與管理十分重要。但在實際的軟件項目開發的需求分析與管理過程中存在一些問題，如果不重視這些問題，往往導致項目開發進度延期、超出項目預算甚至項目開發失敗。

在軟件工程理論中，需求分析是指構建一個新的系統或者完善現有系統時，確定系統的目標、范圍、功能需求和非功能性需求等方面所涉及的工作。

需求分析是軟件工程的一個關鍵過程，也是軟件項目開發的一個關鍵階段。軟件需求分析人員需要準確、清晰和形象的表達和描述用戶的真實需求。需求分析階段的工作是否準確和充分、提交的軟件需求說明書是否完善和規范、需求管理的方法是否正確將直接影響和決定整個項目開發是否能夠按照時間進度和在項目預算范圍內完成。

在項目開發過程中，經常出現如下情況：軟件需求分析人員描述的用戶需求不完整、用戶需求經常發生變化、軟件需求分析人員與系統設計人員的溝通障礙、開發人員邊做需求分析邊做開發、用戶需求管理混亂、缺少專業的需求分析與管理工具等。這些情況的出現使整個項目管理風險加大、系統代碼返工率高、項目團隊士氣日益低下和用戶對項目開發進度的抱怨越來越多，最終可能導致整個項目開發失敗。

軟件需求分析人員描述的用戶需求不完整主要原因：一種情況是沒有專職的軟件需求分析人員，兼職的軟件需求分析人員同時擔當該模塊的設計及開發，導致需求分析沒有真正從業務的角度來考慮，而是從技術實現的角度考慮。有的即使有專職的軟件需求分析人員，該軟件需求分析人員也不具備該行業的業務知識和經驗，對行業術語不了解，有的甚至聘用剛剛畢業的學生去做需求分析，導致整個需求分析不準確甚至出現偏差。另外一種情況是專職的軟件需求分析人員沒有系統的學習和掌握軟件需求分析的基本方法、原則和技巧，了解的業務需求不能準確直觀的表達和描述，編制的軟件需求說明書過于簡單和形式化，導致項目開發的其他人員不能很好的理解用戶需求，有的甚至要重新做軟件需求分析。

為詳細和準確的描述用戶需求，需要注意以下幾個方面：

首先需要由專職的人員擔任需求分析工作，而且軟件需求分析人員需要系統的學習和掌握需求分析的基本方法、原則和技巧。例如獲取業務需求常用的方法有用戶訪談、速記、談話錄音、會議紀要等；其中用戶訪談的要點包括確定訪談的時間、訪談的對象、設計用戶訪談計劃并提前發送給用戶等；速記要求軟件需求分析人員能夠快速準確的記錄用戶描述的業務需求和業務流程。談話錄音和會議紀要是為了更準確記錄用戶描述的業務需求，便于分析和理解用戶需求；軟件需求分析人員最好具備該行業的業務經驗和知識或者聘請該行業的業務專家指導，這樣有助于軟件需求分析人員準確分析和理解行業術語、行業業務需求和行業業務流程。

其次，描述的軟件需求說明書內容應該包括系統的目標、范圍、功能需求、非功能性需求和系統界面原型等方面。非功能性需求主要包括系統界面的可用性、易用性、操作便捷、時間效率高、出錯率低和操作系統需要的專業領域知識少等方面；系統界面原形是指使用專業界面原形工具（Axure等）或者直接使用開發工具（Visual Studio等）編制系統的初始用戶界面，便于軟件需求分析人員、系統設計人員和開發人員更直觀和形象的與用戶溝通和明確需求。非功能性需求和系統界面原形在需求分析階段非常重要，我們在項目開發過程中應該注重非功能性需求和系統界面原形。

最后，對于軟件需求分析人員編制的軟件需求說明書要做好需求驗證工作，參加需求驗證工作的成員應該包括項目組所有成員、該行業的業務專家和最終用戶。在需求驗證會議上提供的需求驗證材料應該簡單、清晰、直觀和明確，不能籠統的提供一些復雜的業務流程及繁瑣的文字說明。在需求驗證會議上可以通過情景模擬和系統界面原形的方式演示。情景模擬是根據不同業務角色模擬整個業務辦理的情況。系統界面原形能讓用戶切身感受到系統的界面效果，便于直觀、形象的溝通和交流業務細節和業務流程。

在項目開發過程中，用戶需求發生變化的情況經常出現。我們不能避免和逃避用戶需求變化情況的出現，但應該控制和管理用戶需求變化，應該有需求變更的流程、需求變更的團隊、需求變更的平臺、需求變更的影響分析以及固定的需求變更周期。對于用戶提出的需求變更，我們首先應該做好詳細的記錄，然后將需求變更的記錄通過需求變更的流程提交給需求變更團隊評估和確認，最終在需求變更的平臺中反映出來，同時要做好需求變更的影響分析報告并及時反饋給用戶。需要注意的是對于需求變更我們要有固定的需求變更周期，不能用戶有需求變更馬上要求項目團隊及時更改系統，這樣會加大項目管理的風險和影響項目團隊的士氣。

第4篇：人員需求分析報告范文

因此，很多企業都會利用Hadoop實現數據存儲，再通過其他工具實現對大數據的高速捕獲和實時分析。這里，我們將通過艾瑞咨詢集團的一個真實案例，解讀一下敏捷BI如何和Hadoop進行互補，幫助其實現互聯網大數據分析的。

定制化項目效率低下

艾瑞咨詢集團（iResearch）是一家專注于網絡媒體、電子商務、網絡游戲、無線增值等新經濟領域，深入研究和了解消費者行為，并為網絡行業和傳統行業客戶提供市場調查研究和戰略咨詢服務的專業市場調研機構。

目前，艾瑞咨詢集團可以向企業提供線下報告和軟件兩種定制化咨詢報告服務。但是，企業客戶的定制化需求非常多變，艾瑞咨詢集團生成一份線下報告交付周期需要3至4周，提供軟件的交付周期則需要半年。再加上項目所需人工成本升高、迭代周期延長，艾瑞咨詢集團往往不敢承接太多定制化項目。

通過調研，筆者發現了艾瑞咨詢集團的真正需求：根據時間維度和網站匯總對用戶的來源地區、來路域名、頁面訪問次數、停留時間、有效訪問次數、跳出率、回訪者、新訪問者、回訪次數和回訪相隔天數等相關數據進行統計分析，并且還能夠在動態添加條件之后，通過對監測用戶行為獲得的數據進行分析，以最終得出更加詳細、清楚的用戶行為習慣。

因此，艾瑞咨詢集團迫切需要一種更加敏捷、高效的大數據分析工具提升定制化業務的效率。

大數據面前：敏捷BI PK傳統BI

在解決艾瑞咨詢集團面臨的難題時，傳統BI的做法是，IT人員事先根據需求分析進行建模，建好二次表或打Cube并提前匯總好數據，業務人員才能在前端查看到分析結果的報表。雖然這種做法很成熟，但是解決不了艾瑞咨詢集團的難題。

首先，業務人員查看的報表相對靜態，分析的維度和度量的計算方式已在建模時預先設定好，不能更改。例如，定好了求和或求平均數，再想改成求方差必須再去修改模型。

其次，分析需求變更時，業務人員不能直接調整報表，需要IT人員重新建模或修改已有分析模型，耗時較長，響應速度較慢。

最后，有些企業的數據量很小，也需要按照此流程和架構來進行大費周折的數據分析。

造成這些問題的本質原因是，過去的技術架構針對海量數據的計算能力不足，企業用戶需要通過建模、二次表、Cube提前進行數據運算匯總。

艾瑞咨詢集團希望為企業客戶提交這樣一份分析報告，不僅能看還能動態分析。對于艾瑞咨詢集團來說，數據展現應該是起點而不是終點。看到了數據，要能交互式分析、深入向下挖掘，要能發現問題并找到答案，還要能采取行動。與數據交互的過程要足夠快，如果用戶每次點擊需要等三五分鐘才出結果，就無法進行交互分析。

并且，分析報告應能讓非IT部門的同事直接在分析平臺上做出來。不能把所有的分析報告需求都提交到IT部門，這樣會嚴重增加IT部門的工作負擔。同時，敏捷BI的實施和操作要簡單化，讓業務人員可直接使用。

同時，分析報告需求經常需要牽涉到數據層的改動，需要IT部門去改進數據層和業務層，傳統BI平臺需要一兩個月才能完成模型梳理。敏捷BI無需事先建模，可以在分析過程中靈活調整分析維度和報表展現，需求變更可以在一天之內響應，提升企業的洞察力決策力。

與傳統BI的重量建模、統一視圖不同，敏捷BI采取輕量建模、N個視圖的方法，不建二次表和Cube，數據導入后可以直接進行分析，并且業務人員可以實時調整分析的維度和度量的計算方式，極大地增加了靈活性，真正做到和數據對話。

既然有這么便捷的方式，為何傳統BI不采用這種架構呢？那是因為，傳統技術架構沒有引入大數據技術，面對海量數據無法在用戶點擊后的幾秒內就展現企業客戶需要的分析結果，因此必須通過建模提前把數據匯總好，才能保證分析報表展現時的速度。

因此，實現敏捷BI的前提是采用新架構處理數據，其涉及的技術包括分布式計算、內存計算、列存儲、庫內計算等。敏捷BI可以通過更低的成本、更短的上線周期，快速讓企業洞察到數據的含義和價值。

業務效率數倍提升

深入研究艾瑞咨詢集團要分析的數據，筆者發現，艾瑞咨詢集團每天要分析的數據量達幾千萬條，且不同企業客戶的分析需求各不相同。因此，復雜多變的多維度分析需求對分析工具的分析性能提出了更高的挑戰，而傳統的數據庫和Hadoop架構已經無法滿足高性能和即時分析的需求。

為此，艾瑞咨詢集團考察過國外一些知名的產品，但是當他們獲知產品的價格和后續的服務費用之后只能放棄。而國內大多數的分析工具大多是上一代BI，需事先建模再進行分析，難以應對靈活的多維度分析變化需求，且針對大數據量的處理能力不能滿足要求。

最終，艾瑞咨詢集團選擇了永洪敏捷BI技術。當艾瑞咨詢集團將三個月的細節數據（約50億條）導入敏捷BI系統，直接就可以展現出定制分析報告。對比原先基于Excel和SQL編程的分析方法，艾瑞咨詢集團的業務效率獲得數倍的提升：線下報告交付周期從3至4周縮短至小于1周，軟件交付從半年縮短至一個月。

同時，艾瑞咨詢集團原來由于擔心需求變化導致沒有能力交付的很多項目被收入囊中。采用敏捷BI工具后，艾瑞咨詢集團可以在幾天內快速搭建原型向客戶展示，任意的需求變更都可以一周內調整完畢。這種快速原型試錯的方式，使得艾瑞咨詢集團有能力承接很多此類項目。

由于業務效率的極大提升，有能力承接更多的項目，艾瑞咨詢集團的收入空間也出現了數倍的增長。與此同時，艾瑞咨詢集團的客戶滿意度也穩步提升。

不僅如此，為了提供更加直觀可交互的分析報告，提升企業用戶體驗，艾瑞咨詢集團基于敏捷BI工具，構建了一個新型SaaS平臺。艾瑞咨詢集團把企業客戶用Hadoop架構存儲的數據，通過敏捷BI提供的接口導入到數據集市內，然后通過敏捷BI快速呈現出結果。

事實上，Hadoop和敏捷BI都有各自適用的不同業務場景，兩者是相互補充的關系。當前，很多企業都采用Hadoop實現數據的存儲，然后把Hadoop數據導入敏捷BI基于分布式內存計算的高性能數據集市中，之后再進行數據可視化分析。鑒于現在Hadoop在企業的應用相當廣泛，永洪敏捷BI產品也支持Hadoop數據源的連接。

第5篇：人員需求分析報告范文

關鍵詞：網絡 設計 實驗 應用

一、引言

隨著計算機技術以及網絡技術的迅速發展，擁有計算機、應用網絡已經成為人們生活中的重要組成部分。網絡應用型人才被社會廣泛歡迎，探索培養網絡應用型人才的有效方法成為擺在計算機相關專業教育部門的課題。

二、社會網絡人才需求狀況

在我國，越來越多的政府機構和行業企業都開始依賴網絡技術進行各自的生產、經營和管理。可以說，沒有網絡，就無法進入真正的計算機時代；沒有網絡，企業就無法實現信息化。由此看來，網絡化已經成為現今社會競爭和發展的關鍵因素，計算機網絡技術人才的培養，也隨之成為當前網絡化建設的當務之急。就目前的狀況來看，實施網絡化建設的部門嚴重缺乏從事網絡系統的構建、運行和維護等工作的專業網絡技術人員。全國的高等院校每年為社會輸送區區幾萬計算機網絡專業的畢業生，而整個社會需要的卻是數以百萬計的具有專業技能的網絡技術人員，人才供應能力遠遠小于實際的社會需求。

三、高校網絡人才培養情況

一直以來，高等院校的學歷教育偏重于網絡技術的基本理論和基礎知識的傳授，缺乏網絡技術應用的實際操作技能和經驗，無法滿足所在單位對網絡技術人員的工作要求。這就造成了一種現象，一方面，用人單位求賢若渴；另一方面，畢業生的就業困難，這已經成為了一種嚴重并且普遍的社會問題。

網絡技術是理論和實踐結合十分緊密的一門學問，網絡技術人才市場，越來越關注技術人員的實際經驗和動手操作能力。學生也有迫切接觸社會、提高工作技能的需求。因此，針對高等院校中普遍存在著理論強、實踐弱的現象，很多高校組建了網絡實驗室，在網絡實驗室里提供了真實的網絡環境，可以讓學生親自動手調試、配置網絡，從而讓學生直觀、全方位地了解各種網絡設備和應用環境，真正加深對網絡原理、協議、標準的認識。通過在網絡實驗室的學習，能真正提高學生的網絡技能和實戰能力，同時具有扎實的理論基礎和較強的實踐動手能力，

（一）開展網絡設計性實驗的意義

網絡實驗室雖然提供了一個很好的實驗平臺，但學校平常上課的時候，是一節實驗課講一個具體的實驗，比如這節課講VLAN劃分，下節課講動態路由。學生可能每節課都學得不錯，可是到了學期結束的時候，他們整體運用所學知識解決問題的能力如何，就不清楚了。開展設計性實驗是解決這一問題的好辦法。

設計性實驗，是指給定實驗目的要求和實驗條件，由學生自行設計實驗方案并加以實現的實驗。在網絡實驗室中開設設計性實驗，能夠綜合以往所學的基礎理論知識和單項實踐技能，通過貼近實際的設計題目，一方面，增強了學生解決實際問題的能力；另一方面，在一定程度上也積累了實踐經驗。

（二）網絡設計性實驗的實施方案

為使網絡設計性實驗達到培養應用型人才的初衷，制定了切實可行的實施方案。

首先，明確實驗目的。即通過了解不同網絡的需求和功能，研究網絡的布線方案等環節，寫出網絡的總體需求分析報告，繪制網絡結構圖，進行布線選型和設備選型，確定IP地址分配方案以及網絡管理方案，并在模擬環境下進行測試。

其次，合理擬定設計題目。經過對目前各行各業網絡應用狀況的認真考察和研究，共設題目五個，分別是：校園網絡設計、智能小區網絡設計、政府辦公網絡設計、企業網絡設計和校園公共機房網絡設計。五個題目的內容大致包括了目前網絡組建的幾種不同的應用形式，學生可以了解各種條件下的網絡在需求上的特點，對建網初期最重要的需求分析有了更深刻的認識。

再次，根據各設計題目的應用特點，分別策劃各設計任務的背景條件。如校園網題目的背景為“一所學校有6棟5層樓宇，平均每棟樓宇有節點150個，具有一般校園網絡的基本需求，其中教務管理節點30，分布在6棟樓宇的不同樓層；另外某臺分布層交換機上連接有提供學習資料的服務器，以及學生宿舍樓和教工宿舍樓，學校規定學生只能訪問學習資料服務器，但不能訪問教工宿舍樓。”等，使題目的設計更真實，針對性更強。

最后，完成設計方案。要求學生根據各自題目的具體要求，了解相關網絡的建設情況，寫出網絡的總體需求分析報告，確定網絡邏輯結構并繪制網絡結構圖，進行布線選型和設備選型，根據情況進行IP地址設計（劃分的原則、方法及地址列表），寫出網絡管理方案（要注重網絡安全的考慮），在模擬環境下測試關鍵技術的網絡連通情況，并練習使用專業網絡測試議進行線路測試。

在這個設計性實驗方案中，學生需根據任務背景中的一些特殊組網要求，在網絡實驗室的實驗條件下進行連接配置，由于所設計的關鍵技術實驗內容都是一些網絡建設過程中的常見問題，所以對提高學生解決實際問題的能力有一定益處。整個過程突出了實用性和操作性。

（三）網絡設計性實驗的實施效果

通過網絡設計性實驗的實施，一方面提升了學生的網絡專業技術技能，使學生對各種常見網絡的搭建環境有了直接的認識，掌握了不同環境要求下的組網方法。從學生的反饋可以看出，95%以上的學生認為，通過這樣的設計性實驗達到了理論聯系實際的目的，真正了解了網絡組建的步驟，增強了實踐操作技能。另一方面提高了學生的就業競爭力，比如企業中的網絡技術人員要承擔網絡設計、系統集成、綜合布線、系統測試等類工作，大的企業會設立不同的崗位，各自分派專人負責，而中小企業往往要求一崗或一人身兼數職。經過網絡設計性實驗的學習，學生掌握了網絡建設工程中從需求分析、物理設計、邏輯設計，到設備選型、布線施工、網絡安全設計、網絡管理方案，再到測試驗收等建設網絡各環節的流程及其設計方法，對于未來的求職從業來說，從技能的訓練方面會有更多的優勢，從擇業的范圍上會有更多的適應性。

四、結束語

在社會對于網絡專業人員迫切需求的前提下，在高校相關專業理論教學的基礎上開展網絡設計性實驗，能有效地提高學生的網絡設計和操作技能，對于應用型人才的培養起到了促進作用。

參考文獻

胡勝紅，《網絡工程原理與實踐教程》，人民郵電出版社，2005

張鳳翔，《局域網組建與維護》，上海交通大學出版社，2004

蔣麗，《局域網、企業網實現》，電子工業出版社，2003

第6篇：人員需求分析報告范文

1.1建設原則

安全生產信息系統建設應遵循以下幾個基本的原則:與其它的業務系統相比，安全生產信息系統定制性更高，要根據單位的實際情況以及各不同層級用戶的業務流程，來規劃應用系統和功能模塊。因此，在建設過程中，要充分結合企業系統每層級用戶的具體需求。安全生產信息系統建設是一項復雜的系統工程，基本涵蓋了企業安全管理的所有內容。因此，在進行安全生產信息系統建設時，必須做好總體規劃，分階段、分層級、分重點推動，避免出現“全盤端，全盤亂”的情況。安全生產信息系統建設除了涉及集團內各個部門，還牽涉到與下屬成員單位之間的溝通與對接。因此，采取自上而下的建設模式，有利于各方面的協調，保證項目建設進度和組織項目實施。企業信息資源的有效整合，成為當前信息化建設的主流。安全生產信息系統作為企業信息化戰略的組成部分，在建設中必須要遵守標準化、規范化的要求，從而更好的為企業信息資源的整合打下基礎。

1.2建設方法

目前，企業建設安全生產信息系統歸結起來，主要有以下三種方法:企業安排內部的或招聘新的信息系統專業人員開發自己的信息系統。自主開發方式的優點包括:①有利于與用戶協調，減少需求的不確定性;②開發人員可以經常性地與用戶部門進行交流，因此項目的可控性較好，用戶的適應性也比較理想。缺點包括:①系統性及質量較難保證，開發周期比較長;②開發環境相對比較封閉，不利于推動組織變革;③需要較多的信息開發人員，實際的開發投入不一定會減少。由企業和委托方共同開發，兩者的配合與互補是取得成功的關鍵。一般情況下，以外部力量為主，內部力量為輔，前者重點放在技術問題上，后者重點放在與用戶的聯系與協調上。合作開發可揚長補短，是目前較普遍采用的開發方式。通過合作開發，企業可在實踐中培養出一批信息管理人員，這比自己摸索或外送培訓都要好得多。外包是一種為了抓好自己的核心業務而將非核心業務委托外部機構來完成的新模式。外包開發優點包括:①比較經濟和實惠，成本較低;②服務質量和開發進度有保證。缺點是:①存在信息系統的控制權問題;②信息系統中的商業秘密安全性問題;③對外包服務商有較強的依賴性。

2典型建設流程

根據筆者多年來為企業提供信息化解決方案的經驗，企業安全生產信息系統建設的基本流程如圖1所示。

2.1總體規劃

對于安全生產信息系統的開發設計工作來說，總體規劃是不可或缺的。受信息系統項目本身特點的影響，安全生產信息系統項目的開發是一項復雜的系統工程。在建設過程中，由于各類人員之間的協調工作不到位，往往容易導致做大量的修改工作，甚至有些系統集成后，修改工作量太大，無法進行修改而被迫宣布重新再來。因此，只有在統一的總體規劃指導下，這種分散的功能模塊，才能被有機結合起來，構成一個有效的大系統。總體規劃的一般步驟主要包括:①準備系統建設前期基礎性材料，如安全管理組織架構、業務流程梳理等;②開展安全管理現狀調研;③提出安全生產信息系統建設總體目標;④提出系統的總體框架和各子系統構成;⑤按照輕重緩急，確定各子系統的開發優先順序;⑥制定建設進度安排和預算;⑦編制系統建設實施工作方案。

2.2需求分析

據統計資料顯示，在信息系統建設失敗案例中，超過90%以上都要歸結于需求分析不深入。因此，需求分析的質量對安全生產信息系統開發的影響是深遠的、全局性的，高質量需求對軟件開發往往起到事半功倍的效果。需求分析做得好，那么項目就相當于做完了一半，好的需求分析會為項目的順利開發奠定基礎，減少大量開發成本，減小開發風險。在開展需求分析時，可以從以下四個方面進行:①人的分析。主要分析企業是否具備安全生產信息系統建設方面的相關人才、合作方的建設能力是否滿足需要等;②物的分析。主要分析企業是否具備了開展安全生產信息化建設的物質條件，如基礎的網絡條件、硬件設備條件等。③環境的分析。主要分析企業各層級人員對安全生產信息化的需求、態度等。④管理的分析。主要分析企業在管理制度、機構和措施等方面，是否能保障安全生產信息化建設順利開展。

2.3系統設計

安全生產信息系統的系統設計主要包括總體設計和詳細設計兩個方面，如圖2所示。安全生產信息系統的系統設計應充分體現企業的參與，特別是在總體設計及子系統設計環節，需要企業指定專門的人員負責與系統開發方進行溝通交流，確保系統設計科學、實用，滿足企業日常安全管理工作的需求。

2.4組織實施

系統的組織實施主要由系統開發方來完成，主要包括以下幾個方面的內容:①代碼開發。完成軟件系統的代碼編寫工作。②系統測試。組織測試人員，對完成的系統進行測試、完善循環流程。③系統安裝。在企業信息平臺上，安裝經過測試的系統，并進行企業培訓。④系統轉換。經過一段時間的試運行后，在試運行系統與正式系統之間進行轉換。

2.5運行評估

系統正式投入運行后，對企業安全管理工作而言，安全生產信息化建設工作才正式開始。因此，企業必須組織相關專業人員，定期對系統運行情況進行評估(見圖3)，發現運行中出現的問題，聯系開發方進行解決，保證系統穩定、可靠運行。

3系統建設案例

3.1企業基本情況

該企業為大型集團型企業，集團的安全管理架構為“集團－二級單位－基層單位”三級管理模式，共有二級單位29家，基層單位178家，員工7萬余人。

3.2系統總體架構

通過對該企業進行的5次近3個月的需求分析，完成了安全生產信息系統建設需求分析報告，確定了如圖4所示的系統功能框架。

3.3系統實現

經過系統設計、測試、試運行、正式運行等流程后，最終的系統實現如圖5所示。

4結論

第7篇：人員需求分析報告范文

關鍵詞:管理信息系統 需求分析報告 系統可行性分析報告 系統設計報告 用戶使用說明書

筆者曾長期從事計算機的開發與應用，對于計算機在管理上的應用、計算機在辦公自動化方面的應用、計算機數據庫的開發、計算機網絡的開發與應用，都進行過具體的設計工作。從事《管理信息系統》的教學工作中，非常希望把自己以往的工作經驗及教訓傳授給學生，借此誠懇地希望有關專家給與批評指正。

一、《管理信息系統》的課程特色：

《管理信息系統》的課程特色主要有以下幾點：

1、綜合性強，牽涉學科較多

牽涉學科有《管理信息系統》綜合了管理學、工程學、數學、計算機科學、電子通訊等學科的相關知識等。比如：在系統的整體構建時要體現管理科學的藝術性，要針對現有系統所存在的問題，提出解決的方案，解決方案要符合管理科學的要求；在具體構建《管理信息系統》時，要體現工程學的嚴密性，符合軟件工程建設的規范，各階段性文檔的形成要經過嚴格的認證，系統的結構要模塊化以便于調試與維護，也便于系統開發的分工合作；在建立系統的邏輯模型時，要學會使用數學的方法，把一個現實世界的問題轉化為一個數學模型，以便于計算機的實施；在信息管理上，使用計算機的相關知識，建立數據庫，把信息集中起來管理，為共享數據提供技術保障；為了滿足不同地域的人們對信息共享的需求，《管理信息系統》較多地使用計算機網絡技術、電子通訊技術來實現信息的傳遞。

2、理論性強，學生易懂，難掌握

往往是上課聽明白了，下課又糊涂了，知其然，不知其所以然。《管理信息系統》偏重于理論層面的研究，而我們的學生基本不具備社會實踐經驗，對于企業或信息機構基本上是一無所知，不理解為什么要采取這樣或那樣的管理策略，這就要求教師在教學時一定要理論聯系實際，要多距離，通過實例的講解讓學生理解學科的科學性與基本知識，要求做到教師舉一，學生反三。

二、《管理信息系統》的教學難點

《管理信息系統》的教學難點第一是難掌握，主要表現在不會用；第二是相關知識點太多，學生知識面不夠。對于第二點，如果在制定教學計劃時，相關課程的教學已經完成，應該是沒有問題的。《管理信息系統》的相關課程有：計算機基礎知識、計算機網絡、計算機數據庫。我們的教學嘗試主要是針對第一點來討論的。

三、教學嘗試

為了解決《管理信息系統》教學中，學生易懂難掌握的特點，在教學中我們要求學生運用所學知識完成如下報告：1、需求分析報告，2、可行性分析報告，3、系統設計報告，4、用戶使用說明書；參考格式如下：

1、×××需求分析報告格式

一、提要：要求說明項目名稱、項目用途、項目簡介

二、項目背景：要求說明項目作者、用戶、項目所需軟硬件環境、項目開發目的

三、參考資料：書名、作者、出版社、出版時間

四、定義：對文中術語、簡稱給與說明

正文：

一、系統現狀的描述及現系統的不足之處（重點是不足之處，這是項目立項、產生需求的根本）

二、解決問題的方案（建立解決問題的新系統的邏輯模型或者稱為數學模型，要求不光有文字敘述還有原理圖/示意圖的輔助說明）

三、前景及展望（可以分別從長期、中期、短期進行展望）

正文部分要求敘述清楚，表達準確，在系統現狀的描述中可以附相關的談話記錄、調查問卷、現系統運作的相關文檔資料；要求學員學會調研項目需求，為下面的系統開發打下基礎。

2、×××系統可行性分析報告格式

一、提要：要求說明項目名稱、項目用途、項目簡介

二、項目背景：要求說明項目作者、用戶、項目所需軟硬件環境、項目開發目的

三、參考資料：書名、作者、出版社、出版時間

四、定義：對文中術語、簡稱給與說明

正文：

一、系統的描述（指新系統的方案）

二、系統的經濟可行性分析：

1、系統的投資：

a、基建、裝潢的費用

b、儀器、設備的購置費用，儀器、設備折舊

c、人員工資

d、辦公費用，其他費用

2、毛利潤：

3、凈利潤：毛利潤-各項費用

4、投資回報：分一年期，三年期，五年期及以后期

5、投資回報率

三、系統的技術可行性分析

1、系統設計的概略圖

2、系統的設計方案

3、系統的原理圖

4、關鍵技術說明

四、系統的社會環境可行性分析（主要從社會習俗、道德、人文背景方面進行分析）

五、系統的法律可行性分析（與現行法律法規有無違背）

六、可選擇的其他系統方案（如果有，列出具體方案，然后比較方案之間的優缺點）

七、結論（系統可行或者是不可行）

3、××× 系統設計報告格式

一、提要：要求說明項目名稱、項目用途、項目簡介

二、項目背景：要求說明項目作者、用戶、項目所需軟硬件環境、項目開發目的

三、參考資料：書名、作者、出版社、出版時間

四、定義：對文中術語、簡稱給予說明

正文

一、系統設計說明

二、系統的功能結構圖（靜態）

三、系統的數據流程圖及數據字典（動態）

四、系統的程序流程圖（針對每個模塊編寫）

五、系統的測試用例（針對每個模塊編寫）

六、系統的聯調方案

七、系統的維護（主要說明維護要求）

八、用戶界面的設計（輸入、輸出）

九、用戶培訓

十、附原程序清單（學生做練習時可以略，只寫標題然后注明略）

4、×××系統用戶使用說明書格式

一、提要：要求說明項目名稱、項目用途、項目簡介

二、項目背景：要求說明項目作者、用戶、項目所需軟硬件環境、項目開發目的

三、參考資料：書名、作者、出版社、出版時間

四、定義：對文中術語、簡稱給與說明

正文:

一、系統說明

二、系統安裝

三、系統的運行

四、系統的主要功能介紹

五、系統常見故障及處理方法

六、技術支持及聯系方式

通過四個報告的編寫，首先是讓學生了解《管理信息系統》開發的過程及具體開發系統的方法；其次是使學生學會具體開發工作中的細節，如用戶需求調查，可行性研究的調查及系統設計方案的編寫；第三是使學生熟練地掌握數據流程圖及數據字典的編寫方法，學會使用模塊化設計的方法自頂向下層層進行系統分解，最后產生系統的功能模塊圖；第四是使學生掌握每個模塊的程序流程圖的設計方法。這樣《管理信息系統》的幾個主要的開發工具都得到了練習。

四、教學效果

通過教學嘗試，我們驚喜地發現，學生對本課程的理解加深了，學習興趣提高了，師生之間的互動增強了。從學生交上來的報告可以看出：學生的思維開闊了，看問題的角度更加清晰；有的報告已經具備了一定的實用性。比如說：有的學生建議把學生的食堂改為定餐管理的方法，學校把每天的菜單編號公布，學生通過計算機網絡定餐，食堂使用計算機統計定餐后烹制，這樣就避免了浪費；另外定餐后還可以送飯上門，這樣也緩解了學生就餐時餐位不夠的矛盾。還有的學生設計了火車票、汽車票網上訂購系統，用以解決寒暑假期學生購票難的問題等等。盡管學生的設計不盡如人意，可是通過練習學生的思維活躍了，好的點子不斷涌現。

五、教學總結

通過教學嘗試，我們增強了讓學生理論聯系實際的信心，對于《管理信息系統》的教學起到了很好的輔助作用。今后我們認為應該不斷地總結經驗，完善教學手段，讓《管理信息系統》的教學更加生動、活潑、受到學生的歡迎；對于學生能力的培養，提高就業技能起到更好的作用。

參考文獻：

1、《信息管理系統》，中央廣播電視大學出版社，主編：侯炳輝 副主編：劉世峰

2、《管理信息系統基礎與開發技術》，人民郵電出版社，主編：陳承歡、彭勇

第8篇：人員需求分析報告范文

關鍵詞：成本控制；成本控制決策支持系統

1 引言

當今，企業競爭環境瞬息萬變，能否快速和正確地做出反應并制定相應策略，是企業取得市場競爭優勢的關鍵。隨著企業規模不斷擴大，內部數據迅猛增加，管理人員分析數據，利用分析結果輔助決策的需求越來越大。通常，生產型企業都具有制造環節復雜、產品周期長等特點，容易形成信息分割、信息重復采集等弊端，造成信息量大，支持決策不佳的窘境。自上世紀八九十年代開始，就有人開始探索利用決策支持技術進行企業生產成本控制，如Michael J.A.Berry等人探索了基于DM的企業生產成本控制DSS的分析與設計；胥悅紅，顧培亮等人將神經網絡理論應用于產品的成本預測，探討了一種基于BP神經網絡模型的產品成本估計模式；彭永洪研究了以BOM（物料清單）為基礎，通過市場層次、產品層次、零部件層次規劃建立ERP系統目標成本決策模型。PHILIPS公司從2000年開始一直在探索適合自己的成本控制管理系統[1] 。雖然專家學者和企業的研究已經取得了顯著的成果，但市場化的生產成本控制決策支持系統產品還較少。

企業急切盼望提高決策的質量和穩定性。在企業資源計劃中，成本管理數據的統計是比較齊全的，他們基本都有連續的收集和整理，并且有統一單位，使用起來比較方便。本文通過分析ERP基礎數據，輔助決策工作，為完善決策支持系統進行了嘗試性的研究。

2 成本控制決策支持系統的需求分析

市場變化日益頻繁，依靠人工計算產品成本所耗用的時間較長、結果簡單，據此進行結構和趨勢分析比較困難；用手工很難算出每筆訂單的成本，企業不能充分了解現有生產情況。而在ERP系統中，已經收集了大量的統一格式的基礎數據，因此構建基于ERP信息的生產成本控制決策支持系統，可以有效支持生產成本控制。

成本控制流程由料、工、費驅動，結合庫存信息，以及在產品信息，進行成本歸集和成本控制分析。在生產成本控制決策支持系統中，決策者可以調用ERP中的基礎資料，比如：原材料消耗信息、工資信息、應付福利費信息、累計折舊信息、無形資產信息等等。輸送到決策支持系統，并按照一定的成本歸集方法進行成本歸集和成本分析，從而提高決策活動質量。

成本控制工作主要包括：產品成本計算、標準成本計算、預測訂單成本、計算成本差異、訂單盈利分析、成本信息之間相關性分析等等。

2.1 產品成本計算

產品的成本受許多因素影響，其中主要由料、工、費組成。本文選取構成成本的主要因素，比如：外購物料單價、自制物料單價、工時、產量、工作率等。物料采購情況影響產品成本計算，產品成本對成本差異分析產生進一步影響，從而影響成本差異分析報告，影響決策質量。

2.2 標準成本計算

標準成本方案設置影響標準成本的計算。標準成本又會影響成本差異分析和訂單成本預測，從而間接影響成本差異分析報告和成本定價決策。

2.3 預測訂單成本

根據產品成本計算模型，可以預測出訂單的成本，訂單成本與生產過程實際成本比較，進一步進行定價決策和訂單盈利分析、預測。預測訂單成本有效地幫助管理者預測盈利空間，使生產、銷售工作持續穩定。

2.4 計算成本差異

分析實際成本與預測產品成本之間的差異，生成成本差異報告。成本差異分析主要受到標準成本和實際成本的影響。

2.5 訂單盈利分析

進行訂單成本預測與訂單實際發生適時比較，分析差異，快速實現訂單盈利分析，并產生訂單盈利分析報告。

3 成本控制決策支持系統的結構

經過對生產成本控制流程進行分析，提出了基于ERP基礎的生產成本控制決策支持系統結構。

圖4.4 成本控制DSS功能結構

3.1 人機交互接口

人機交互接口主要處理兩類信息錄入，分別是ERP內部的信息轉入服務、外部信息錄入工作。信息錄入接口模塊要結合知識管理服務對不完整的信息進行簡單處理，并且對信息進行歸集和分類存入數據庫；生產過程內外環境信息查詢功能，能提供ERP中銷售信息、采購信息、庫存信息、財務狀況信息、質量信息、人員情況信息等的綜合查詢；能夠對信息查詢和知識共享做出響應。

3.2 運算處理部分

根據DSS的信息和決策者的要求，進行處理運算。運算處理部分包括：產品成本計算合法性檢驗、產品成本計算、標準成本計算、成本差異計算、預測訂單成本。

3.3 信息分析

信息分析模塊是對信息錄入模塊的結果進行深層次處理。生產計劃分析是根據生產情況、材料供應情況、倉庫儲存情況進行評估，進而對生產計劃做出決定的依據。因素之間相關性分析是對構成生產成本的因素進行分析，找出各個因素之間是否有相關性，從而降低成本分析的難度，達到控制和降低成本的目的。成本差異分析包括量差分析和價差分析，從中找出成本差異的原因，為提高成本控制水平提供依據。訂單盈利分析是適時比較訂單預測成本和實際發生成本，分析差異，快速實現訂單盈利分析。

3.4 成本控制決策

決策者根據決策支持系統信息和運算處理結果以及信息處理分析結果，進行成本控制決策。成本控制決策包括：成本計算策略選擇、標準成本設置方案選擇、定價決策、訂單盈利分析決策、生產計劃制定。

3.5 成本控制績效評估

成本控制績效評估是根據生產計劃執行情況，生產合同完成效果，以及生產策略選擇的正確與否，以及采購部門和銷售部門進行綜合評價，是改進DSS的必要步驟，并對數據庫、模型庫、規則管理庫中信息產生影響，是再次生成生產成本控制信息和修正成本控制策略的重要依據。

參考文獻

[1]魏士銀，制造業成本控制方法和實施的探索，D，首都經濟貿易大學，2008，6.

第9篇：人員需求分析報告范文

關鍵詞：企業管理；內部控制；信息化；采購管理

中圖分類號：F270.7 文獻標識碼：A 文章編號：1001-828X（2012）12-00-01

一、管理信息系統在采購過程中的實現

企業以贏利為目的采購物資、服務等用于生產經營活動，由此決定了企業采辦要面臨一定的采購風險，為有效地控制采購風險，必須建立一系列內部控制規則從而實現對采購風險的有效控制；對于石油企業所處的能源行業，采購支出一般占整體營業額的30%-50%左右，采購管理是石油企業尤其是集團企業內部控制中最為重要的一環，根據企業戰略規劃及管理要求建立采辦管理模式，在此基礎上設立現代的采購管理制度，并通過管理信息系統等信息化的手段將采購管理制度、管理流程貫徹到每一個過程與控制節點，成為現代石油企業實現采購內部控制的重要途徑。下述將就國內某石油公司構建采購管理信息系統的實現過程，力求在采購管理信息系統與采購內控管理的有機結合方面作探索。

（一）采購管理信息系統建設的組織

采購管理信息系統與采購內部控制制度的建立是企業采購管理的兩個重要子系統，其相互獨立而又相互關聯，實施起來牽扯到企業管理的各個部門及各個層次，需要大家的共同配合，因此兩個子系統的實施必須有企業最高領導者的深入理解與支持，必須成立一個最高領導負責的組織機構，調動各方面的資源，保證系統的順利進行。

采購管理信息系統建設組織機構的建立，要考慮企業的規模與當前企業的管理現狀，信息化建設項目多為階段性項目，因此其建設一般模式是項目組建設模式，即組織機構多為項目組、項目部等形式，通過項目運作，待項目完成成熟后移交到企業內部信息化部門或專業運行維護機構進行運行維護。現在石油企業多為集團化企業，集團下設多個分公司，項目組的組成要以集團內位于核心管理層的采購部門及信息管理部門人員為主，其中要包括管理信息系統的策劃分析人員、程序員等及采購管理人員。項目組一般由集團總經理、CEO或級別相當的人員擔任項目經理，以此確保采購管理信息系統的順利推動。

（二）系統需求調研與企業采購管理流程重塑

在內控管理上為適應采購管理信息系統，企業管理工作必須逐步完善以下工作：　管理工作的程序化；管理業務的標準化；表單、記錄及報表文件的統一化；基礎數據資料的完善化和代碼化。這樣才能實現通過采購管理信息系統對企業管理節點、過程及流程的有效控制，避免風險，確保內控原則的落實。

采購信息系統項目組首先要對企業的發展戰略及采購戰略有一個了解，對企業的組織機構進行分析，確定企業目前的采購管理模式。系統需求調研與企業采購管理流程的重新塑造主要采用調研問卷、走訪座談及查看資料三種形式結合。

調研問卷的內容包括企業目前的組織機構、采購管理模式、采購管理流程、采購管理人員及采購從業人員關注的問題等進行初步的了解，調研問卷的發放范圍應確保覆蓋全部采購部門，其他采購相關部門也應有一定的覆蓋面。

“過程方法”是組織內諸過程的系統的應用，連同這些過程的識別、相互作用及管理。在采購管理流程重新塑造中應用“過程方法”，就是要按照：采購管理過程的識別、采購管理流程的梳理、流程改造、形成新的采購管理流程，這樣一個軌跡去逐步推進。在各個階段的工作中貫穿始終的原則是：以“過程方法”為核心思想，做到“縱向到底，橫向到邊”。對企業所屬所有分支機構的采購過程、流程進行充分辨識。繪制企業整體的采購管理流程圖，考慮控制環境、控制活動兩個內控因素，各風險點的控制。對流程進行優化、合并，形成新的采購管理流程。并以此為依據，重新以體系化、標準化的形式編寫采購管理制度，統一記錄表格及統計報表的格式。形成采購管理信息系統應用的基礎。

在“體系化”采購管理制度應用的基礎上，將采購管理風險點、過程控制及流程控制等內部控制貫穿在整個需求分析報告中，涵蓋以下具體內容：采購管理流程的業務描述、功能需求、數據需求、性能需求及運行需求。需求分析報告作為采購管理信息系統實施的基礎性文件，編寫完成后，經過項目組初步審核，經公司主管采購業務領導審核并批準。

（三）系統程序及結構特點

下圖為采購信息管理系統總體設計的邏輯模型。

采購管理信息系統采用B/S的架構模式，方便該管理信息系統的部署、維護和升級工作。在軟件業務流程上，根據采購管理信息系統特點定制了“工作流”引擎，其具有組織機構設置靈活，能實現復雜多變的流程設置。在管理信息系統電子化流程時，把采購管理的流程分拆成若干各關鍵工作過程，由系統把這些關鍵工作過程串聯起來，對于單個工作過程根據需要穿插以審批“工作流”，這樣就形成了對采購各管理流程的信息化實現。“工作流”推動的模式在實際應用中收到了很好的效果，提高采購效率在18%左右。

二、結束語

隨著企業信息化的進程不斷推進，采購管理水平的不斷提高，會不斷地改進和重寫管理流程。這也給管理信息系統的不斷提升提供了一個新的問題，如何開發出一套應用性更強、軟件業務重組更開闊的管理信息系統解決方案。隨著企業信息化水平的提高，軟件工程的不斷進步，相信企業管理信息系統將會與企業的內控結合的更加緊密，為企業內控管理，風險管理起到更大的作用。

參考文獻：