8個主要內容「軟件需求分析說明書主要包括哪些內容」

對於需求分析說明書（又名需求規格說明書），有很多剛入行的小白對此有很多的迷惑，在這裡我就接着多年的工作經驗，並拿出曾經給負責的一個項目撰寫的需求分析說明書來作為案例給大家展示一下，寫得不好，其中也有很多欠缺之處，願朋友們看過之後能夠給出很好的批評，咱們在這裡相互學習、共同進步！

第一章引言

1. 修訂記錄

2. 撰寫目的

本需求分析說明書主要以剖析的方式對“XXXXXXX管理平台”做全面細緻的用戶需求分析，明確所要研發的系統應具有的模塊、功能與界面內的詳細需求，以供業主能夠確認項目的基本功能和具體性能，和業主達成一個立場，從而形成一致的理解和確定，是系統分析人員及後續的系統設計人員能夠更加清楚地了解用戶的具體需求，使得後面的設計、研發工作的基礎。

本說明書的預期讀者是：項目管理人員、系統設計人員、研發人員、文案、測試人員、業主。

3. 需求背景

3.1 所建議開發系統的名稱

XXXXXXX管理平台

3.2 參與方信息

XXXX信息科技有限公司

3.3 背景及必要性

近年來，隨着經濟社會和城市建設的快速發展，市政基礎設施行業發展越來越快，投資規模也越來越大。

市政工程項目具有規模大、作業人員多、材料設備種類繁多、工序複雜、環境複雜、管理條線多、管理強度大、質量與安全隱患大等特點，使得工程項目管理要求及難度非常大。

目前相比製造、金融等行業，建築業的信息化程度整體較低。傳統的依靠人力來處理信息的管理方法已很難實現精細化、高效的項目管理，更無法適應建築業快速發展的要求。因此，建築企業紛紛進行信息化建設，通過信息技術的應用來強化企業的集約化管理，基於信息化系統的協同工作來提升項目的管理水平。

走在信息化前沿的各大企業，均將信息產業作為新興業務板塊，投入大量資源成立獨立的公司以助力集團的數字化轉型，進而驅動主營業務的發展。

如寶鋼集團1996年就成立了寶鋼軟件公司，發展至今寶信軟件在工信部發布的2018年中國軟件業務收入前百家企業名單中排名第35位，為企業提供IT規劃諮詢、MES、ERP、BI等管理信息化整體解決方案以及個性化的軟件定製服務。

行業內，華東建築集團股份有限公司也於2018年底成立了華建數創（上海）科技有限公司，着力建設“互聯網+設計”、“數字化+建築”、“智慧化+工程”等三大業務引擎，意圖發展成為工程行業互聯網平台公司。

信息化已成為各大建築企業發展戰略的重要組成部分，加強信息化基礎設施建設，推進管理信息系統升級換代，推動多方協同工作與數據共享，探索大數據技術的集成應用，已成為本行業發展的必然趨勢。

3.4 集團建設工程項目信息化管理現狀

3.4.1 項目信息化管理系統使用現狀

在平台規劃之前，我們首先對上海隧道、路橋集團和市政集團三家子公司在建工程項目的信息系統使用情況進行了調研。

從調研結果可以看出來，政府主管部門和業主對於項目管理信息化的要求不斷提高，我們也應該相應地提升項目管理的信息化和智能化程度。

各子公司和項目經理對於信息化管理存在迫切需求，都在嘗試開發或購買相關的信息管理系統來提高管理的能力和效率。

但目前不管是集團還是子公司，都沒有統一的管理規定和開發標準，系統的應用深度參差不齊。眾多的系統架構各異，數據也難以共享。同時各級的管理單位均有數據填報要求，項目沒有實現業務數字化，數據都要人工進行分頭填報，填報工作量大，存在多頭填報、上報數據質量無法保證等問題。

3.4.2 集團現有項目管理系統基礎

對於集團而言，項目管理已經有了一定的信息化基礎，開發和全面推廣了XX系統、XXXX平台、XXXXXX系統和XXX平台，取得了顯著的效果，但使用中也暴露了一些不足，主要體現在：

XX系統經過幾年的推廣使用，培養了項目用戶的使用習慣，形成了日報、周報、月報審閱制度，涵蓋了項目信息、項目籌劃、進度、風險、安全等重要管理功能。但XX系統是從上級監管的角度開發，以項目數據填報的形式為主，沒有提供給項目經理進行業務管理的功能。每個項目只能通過項目經理的賬號來進行所有數據的填報，無法將工作分解給項目相應的管理人員。而多數項目經理將數據填報工作分配給信息員，上報數據的完整性和準確性都有待提高。同時，XX的開發時間較早，受底層框架限制，再進行功能的擴展如新增項目成本管理、動態評估等功能非常困難；
XXXX系統和XXXXXX系統都是針對項目安全管理開發的專項應用系統。這兩個系統與XX系統相互獨立，建管與安全分離，數據沒有聯通。通過XX系統和XXXX系統抓取的安全隱患和整改情況無法直接同步到XX系統，項目上需要再次人工填報；
XXXXX平台採購系統逐步將項目大宗材料採購行為整合到了平台上，材料採購是項目管理的重要方面，與成本管理、供應商管理均有密切關係，目前該系統也是獨立的，沒有進行對接和整合。

因此，本項目擬融合集團現有系統功能，建立統一的集團建設工程管理體系和監管平台；開發項目端，為項目的全方位管理提供工具；實現系統間的數據共享和交互，為數據分析和輔助決策提供支持，實現業務數據化、數據業務化，通過項目業務的數字化開展來獲取大量數據，通過數據的挖掘分析為項目提供價值。

3.5 建設必要性分析

現階段，國家已將信息化建設提升到前所未有的高度，建設部指出建築業信息化是建築業發展戰略的重要組成部分，也是建築業轉變發展方式、提質增效、節能減排的必然要求，對建築業綠色發展、提高人民生活品質具有重要意義。

住建部《2016-2020年建築業信息化發展綱要》提出，“十三五”時期全面提高建築業信息化水平，着力增強BIM、大數據、智能化、移動通訊、雲計算、物聯網等信息技術集成應用能力，建築業數字化、網絡化、智能化取得突破性進展，初步建成一體化行業監管和服務平台，數據資源利用水平和信息服務能力明顯提升，形成一批具有較強信息技術創新能力和信息化應用達到國際先進水平的建築企業及具有關鍵自主知識產權的建築業信息技術企業。

《工程勘察設計行業發展“十三五”規劃》及國家大數據戰略、“互聯網+”行動等相關要求，推動信息化與建築業的深度融合發展，促進BIM、物聯網、雲計算、移動互聯網、大數據、智能化等信息技術的集成應用能力，實現工程建設項目全生命周期數據共享和信息化管理，推動建造方式創新，助力企業轉型升級，促進企業提升核心競爭力，實現業態創新。

作為基礎設施領域的龍頭企業，集團更應積極探索 “互聯網+”協同工作模式，實現全過程信息化，強化企業知識管理，支撐智慧企業建設，以實現跨越式發展。

4. 術語與定義

系統或者平台：如果沒有特別的指出，則本文中述寫的系統或者平台只指XXXXXXX管理平台。
用戶：被授權使用或負責維護應用信息系統的人員。
用戶帳號：在應用信息系統中設置與保存、用於授予用戶合法登陸和使用應用信息系統等權限的用戶信息，包括用戶名、密碼以及用戶真實姓名、單位、聯繫方式等基本信息內容。
權限：允許用戶操作應用信息系統中某功能點或功能點集合的權力範圍。
角色：應用信息系統中用於描述用戶權限特徵的權限類別名稱。

5. 參考資料

《項目可行性建設方案》

《項目開發計劃說明書》

6. 假定和約束

假定：用戶能夠提供系統全面上線的測試環境，以及能夠實地的參與到需求的核准工作中；
約束：本系統的全面上線日期為2019.07.31；

第二章任務描述

1. 目標

本項目將建立“XXXXXXX管理平台”，以項目為基點，通過平台提供覆蓋建設工程的進度、質量、安全、成本、人員、設備、材料等要素的管理工具，項目業務應用數字化後產生大量數據，為集團、子公司、分公司各級的監管提供數據支撐。

同時以分級管理為導向，挖掘分析和可視化展示數據，通過數據應用為業務帶來價值，基於平台實現集團建設工程的管理標準化，業務規範化，監控智能化，數據可視化，經驗智庫化，資源共享化。

2. 主要建設內容

XXXXXXX管理平台的主要建設任務包括以下幾部分：

2.1 前期調研及總體規劃

前期調研和總體規劃階段，將針對集團建設工程監管的實際情況進行深入的調研和需求分析，為項目的方案設計提供必需的基礎資料。

調研目前政府相關主管部門、集團、子公司下發的管理辦法和規定，在平台的設計里體現相應的管控要求和標準，對於目前尚未形成標準的，通過平台能夠建立一套可行的通用管理流程。
對項目經理進行調研，了解目前項目的管理現狀和信息化的需求。各位項目經理共性的需求包括在XX的基礎上深化進度和風險模塊，新增成本管理、知識庫和項目過程資料管理等功能需求，並希望能夠改變XX系統由項目經理進行數據填報的模式，將數據填報模式變為項目管理模式，相應的項目人員都能夠使用系統開展工作，項目經理能夠通過系統來管理項目和相應崗位人員的工作情況。
對集團的業務部門、子公司和分公司分別進行調研，了解他們對於項目的監管需求和數據分析展示需求，進行相應管理端模塊的設計。
對項目上正在使用的系統（如XXXXX項目管理系統、技術管理系統等）、將與本平台進行對接和整合的系統（如XXXX平台、XXXXXX管理系統等）進行專題的深入調研。
根據調研結果，對平台進行頂層架構設計、數據庫總體架構設計、數據信息彙集機制設計和平台主數據標準設計。

2.2 工程項目管控標準體系建設

建立集團建設工程項目的管控標準體系，基於平台實現六個統一：統一的流程管理體系；統一的業務框架體系；統一的項目進度體系；統一的項目評價體系；統一的信息發布與交流體系；統一的知識管理體系。

2.2.1 工程項目管控中心數據庫建設

工程項目管控中心數據庫彙集了相關的各類項目靜態數據、動態業務數據、智能監測數據、環境數據等。

對各類數據的數據源、入庫方式、數據量和數據更新頻率進行分析，制訂合理的數據標準和數據庫結構，實現海量數據存儲和數據預處理，並實現高效的多源異構數據融合、查詢統計、智能分析預警等功能，同時提供標準的API接口，為外部系統的數據接入和共享提供支持。

2.2.2 工程項目智能管控平台開發

平台考慮集團、子公司、分公司和項目的不同需求，功能主要包括：

建設項目智能管控平台（項目端）：項目端平台主要通過對項目現場進度、質量、安全、風險、成本以及“人、機、料、法、環”等具體管理需求對各建設工程全要素進行精細化管理，以及信息的採集、匯聚、分析和應用，業務需求側重於為項目提供全過程的管控功能；
建設項目智能管控平台（管理端）：管理端平台以項目端為基礎，通過統一後台實時接入項目端的各類數據，實現多項目的集中管控、信息分類查詢、統計分析等功能，滿足管理者對各工程項目快速定位、分析預警、審核評價、決策分析等管控功能上的需要。同時管理端平台全面兼容項目端的信息查看功能，有助於各級管理單位及時準確掌握現場信息，更加高效合理的判斷和決策。

2.2.3 工程實施及應用

本項目將深入探索信息化技術對建設工程全方位、全時段、全過程的即時監控管理功能，力爭建立一套簡單、高效、實用的監督管理和項目自檢信息化流程。

為保證平台的穩定性和可靠性，首批擬在各子公司分別選擇1-2個新建項目，對平台的各項功能進行多樣本的充分試用。運行穩定後在集團全面推廣，並將XX系統中的歷史數據全部遷移至本平台，將存量項目逐步遷移至新平台。

3. 建設進度階段

2018.10-2019.04 計劃、需求、設計階段：編撰各項計劃書；主要進行需求的分析和現狀的調研；製作思維導圖；進行平台的總體架構高保真原型（UE、UI）設計；

2019.04-2019.12 研發、測試階段：根據需求分析、原型設計、以及項目開發計劃書，實施相關工作，如下：

04-2019.08
第一階段：XXXXXXX管理平台業務應用模塊的開發和部署；中心數據庫設計和基礎架構的搭建；系統首頁、項目籌劃、進度管理、風險管理、人員管理功能模塊的建設，試點工程實施方案設計，從而實現首批試點工程實施和數據上線為主等。除此之外還包括對已經上線的內容的單元測試和部分集成化測試；
08-2019.10 第二階段：在第一階段的基礎之上，完成安全管理、材料採購、設備管理、供應商管理、視頻監控、動態評價功能模塊的研發，以及對完成的功能模塊進行單元測試和部分集成化測試；
10-2019.12
第三階段：在第一、第二階段的基礎上，完成XXXXXXX管理平台剩餘功能模塊的數據分析和內容開發，包括移動APP的開發，從而實現平台的全面上線；外部系統數據接口開發；原有XX系統歷史數據接入；集團工程項目的全面深化實施應用、日常監管項目數據上線；相關標準規範體系和知識庫建設完成。並生成目標系統，並確認是否達成項目目標。

4. 條件與限制

必須保證程序正常的連接到服務器，並保持網絡的暢通。

第三章功能需求

1. 總體功能架構

平台考慮不同層級的用戶的需求，分為項目端和管理端。

平台一共有17個主要功能模塊，對於項目端，我們提供項目經理工作台，能夠一目了然地在首頁上看到自己項目的總體情況，並為項目經理提供知識庫進行參考。以及為項目提供一個全要素的項目管理工具，包括籌劃、進度、質量、安全、風險、成本、人員、材料、設備、供應商、報表、文檔，項目上不同崗位的管理人員能夠各司其職，項目經理進行總體的把控和管理。

對於分公司和子公司來說，是處於執行管理的角色。平台主要是提供對多個項目的總覽、業務的監督檢查、流程審核、預警管理、報表審閱、績效考核等功能。

集團主要是進行監管，因此提供給集團用戶的功能偏重於數據分析總覽、重大風險預警、管理行為、報表審閱和項目的動態評價。

高層級的用戶可以穿透到項目端，進行詳細的數據的查看。

2. 建設項目智能管控平台

管理端旨在為決策層、管理層提供業務監控和決策支持，平台從業務系統最底層直接獲取數據，以各業態項目管理過程產生的一手數據為基礎，用最直接、最直觀、最及時的方式展示管理關鍵要素信息，並實現各類結構化數據的集中匯總、統計、分析與多維度展示。

管理端平台包括PC版、大屏展示版和移動APP。

3. 功能需求分析

項目端重點在於實現業務的全面管理，為項目經理提供標準化的工具、知識和決策輔助，並提供數字化工地智能監控數據全兼容的支持。

項目端的建立，首先為工程項目管理提供應用服務，同時為平台採集大量的業務數據，自動生成各類報表，為項目監管與決策服務。

3.1 功能模塊結構圖

3.2 模塊劃分

3.2.1 我的工作台

3.2.1.1 模塊描述

平台從各模塊得到的數據在我的工作台會得到更加精鍊的整合，在這裡利用圖、表的方式來展示項目中的重要信息，具有一定的針對性和實時性，其相當於對每一個功能模塊整理出來的信息梗概，並將這些信息進行了統一規劃，形成一個具有一定操作性和層次性的並給用戶以明朗和具有全局觀的數據可視化窗口。

3.2.1.2 需求分析

3.2.1.3 用例矩陣

3.2.1.4 界面描述

第四章數據需求

1. 數據描述

1.1 數據來源及流向示意圖

平台中的數據來源分為內部和外部兩大部分。

1.2 內部數據

內部數據包括項目現場的業務數據、自動化監控數據和項目知識庫。業務數據來源於項目過程管理，包括項目的籌劃信息、進度數據、質量數據、安全數據、施工風險數據、供應商數據等。

自動化監控數據來源於項目智能監控設備，包括設備監控數據、施工監測數據、安全講評台數據、用電監控數據、人員出入及定位數據、環境監測數據、視頻監控數據等。

知識庫初始來源於集團現有經驗和知識的梳理，並在項目過程中不斷補充和完善。

1.3 外部數據

外部數據包括來自既有信息系統（如主數據系統、人力資源系統、陽光採購平台、資金管理系統）的工程基本信息和專題信息，以及通過離線方式導入的地理信息數據及其他數據。

以上數據均在平台數據標準的約束下進入數據中心，通過中心數據庫與應用系統形成數據交換，並在此基礎上開發標準化數據接口，將數據共享給其他需要的外部系統。

2. 邏輯描述

對數據進行邏輯描述時可把數據分為表態數據和動態數據兩種。

進行描述時應把各數據元素邏輯地分成若干組，列如函數、源數據或對於其應用更為恰當的邏輯分組。給出每一數據元的名稱（包括縮寫和代碼）、定義（或物理意義）度量單位、值域、格式和類型等有關信息。

2.1 表態（靜態）數據

表態數據就是所謂的靜態數據，指在運行過程中主要作為參考的數據，它們在很長的一段時間內不會變化，一般不隨運行而改變。

列出所有作為控制或參考用的靜態數據元素如下表所示：

2.2 內部生成數據

列出向用戶或開發單位中的維護調試人員提供的內部生成數據。

2.3 動態數據

所謂動態數據，包括所有在運行中要不斷或者在特定的條件下而發生變化的數據，以及在運行中要輸入、輸出的數據。

2.3.1 輸入數據

2.3.2 輸出數據

3. 數據詞典

對平台中所出現的各個實體的屬性進行整理，使其形成數據詞典，以此可以來作為後繼研發過程中數據結構設計、數據庫設計、數據庫表結構設計的主要參考來源。

並說明對數據要求的制約，逐條列出對進一步擴充或使用方面的考慮而提出的對數據要求的限制（容量、文卷、記錄和數據元的個數的最大值）。

對於在設計和開發中確定是臨界性的限制更要明確指出。

3.1 功能模塊一（案例）

3.1.1 項目表（表名：project）

4. 數據採集

4.1 要求和範圍

按數據元的邏輯分組來說明數據採集的要求和範圍，指明數據的採集方法，說明數據採集工作的承擔者是用戶還是開發者。

具體的內容包括：

輸入數據的來源，例如是單個操作員、數據輸入站，專業的數據輸入公司或它們的一個分組；
數據輸入（指把數據輸入處理系統內部）所用的媒體和硬設備。如果只有指定的輸入點的輸入才是合法的，則必須對此加以說明；
接受者說明輸出數據的接受者；
輸出數據的形式和設備列出輸出數據的形式和硬設備。無論接受者將接收到的數據是打印輸出，還是CRT上的一組字符、一幀圖形，或一聲警鈴，或向開關線圈提供的一個電脈衝，或常用介質如磁盤、磁帶、穿孔卡片等，均應具體說明；
數據值的範圍給出每一個數據元的合法值的範圍；
量綱給出數字的度量單位、增量的步長、零點的定標等。在數據是非數字量的情況下，要給出每一種合法值的形式和含意；

更新和處理的頻度給出預定的對輸入數據的更新和處理的頻度。如果數據的輸入是隨機的，應給出更新處理的頻度的平均值，或變化情況的某種其他度量。

4.2 數據採集對象列表

4.3 輸入的承擔者

4.4 預處理

5. 數據結構與程序的關係

6. 數據庫設計需求

6.1 需求概述

建立完善的數據庫結構管理設備的基本參數、運行狀態和各種工作計劃。

數據庫的框架和結構必須根據設備和運行狀態而設計，方便提供強大的錄入、查詢、統計、分析和報表等各種功能操作，較好的反映平台業務的基本情況和運行狀況，滿足平台的基本要求。

6.2 外部設計需求

6.2.1 標識符和狀態

數據庫表前綴：根據模塊名定義（如用戶模塊：sys_）
用戶名：root
密碼：待定
權限：全部
有效時間：開發階段
說明：系統正式發布後，可能更改數據庫用戶/密碼。

6.2.2 使用它的程序

本系統主要利用java作為後端的應用開發工具，使用MySQL作為後台的數據庫， Linux或Windows均可作為系統平台。

6.2.3 約定

所有命名一定要具有描述性，杜絕一切拼音、或拼音英文混雜的命名方式。
字符集採用 UTF-8，請注意字符的轉換。
所有數據表第一個字段都是系統內部使用主鍵列，自增字段，不可空，名稱為：id，確保不把此字段暴露給最終用戶。
除特別說明外，所有日期格式都採用date格式。
除特別說明外，所有字段默認都設置不充許為空，需要設置默認值。
所有普通縮影的命名都是表名加設置縮影的字段名組合，例如用戶表User中name字段設置普通所以，則縮影名稱命名方式為user_name_index。

6.2.4 專門指導

對本系統的開發者、使用這、測試員和維護人員，提出以下參考意見：

在使用數據庫時，首先要參考上面的約定內容，做好軟件的安裝以及表格的建立。
數據庫的輸入統一採用鍵盤。對於數據庫的使用權限，請參考本系統其他相關文檔。
數據庫的後台管理員沒用等級差異，可根據實際情況添加刪除管理員。

6.2.5 支持軟件

操作系統：Linux / Windows
數據庫系統：MySQL
查詢瀏覽工具：Navicat Premium
命令行工具：mysql
注意：mysql 命令行環境下對中文支持不好，可能無法書寫帶有中文的 SQL 語句。

6.3 結構設計需求

6.3.1 概念結構設計需求

概念數據庫的設計是進行具體數據庫設計的第一步，概念數據庫設計的好壞直接影響到邏輯數據庫的設計，影響到整個數據庫的好壞。

我們已經得到了系統的數據流程圖和數據字典，現在就是要結合數據規範化的理論，用一種模型將用戶的數據要求明確地表示出來。

概念數據庫的設計應該極易於轉換為邏輯數據庫模式，又容易被用戶所理解。概念數據庫設計中最主要的就是採用實體-關係數據模型來確定數據庫的結構。

數據是表達信息的一種重要的量化符號，是信息存在的一種重要形式。數據模型則是數據特徵的一種抽象。它描述的是數據的共性，而不是描述個別的數據。

一般來說，數據模型包含兩方面內容：

數據的靜態特性：主要包括數據的基本結構、數據間的關係和數據之間的相互約束等特性;
數據的動態特性：主要包括對數據進行操作的方法。

在數據庫系統設計中，建立反映客觀信息的數據模型，是設計中最為重要的，也最基本的步驟之一。

數據模型是連接客觀信息世界和數據庫系統數據邏輯組織的橋樑，也是數據庫設計人員與用戶之間進行交流的共同基礎。

概念數據庫中採用的實體-關係模型，與傳統的數據模型有所不同。實體-關係模型是面向現實世界，而不是面向實現方法的，它主要是用使用方便，因而在數據庫系統應用的設計中，得到了廣泛應用。

實體-關係模型可以用來說明數據庫中實體的等級和屬性。以下是實體-關係模型中的重要標識：

在數據庫中存在的實體；
實體的屬性；
實體之間的關係；

6.3.2 邏輯結構設計需求

項目結構實體、實體屬性ER圖如下：

用戶權限實體、實體屬性ER圖如下：

進度計劃權限實體、實體屬性ER圖如下：

6.3.3 物理結構設計需求

（1）定義數據庫、表及字段的命名規範

數據庫、表及字段的命名要遵守可讀性原則；
數據庫、表及字段的命名要遵守表意性原則；
數據庫、表及字段的命名要遵守長名原則；

（2）選擇合適的存儲引擎

（3）為表中的字段選擇合適的數據類型

（4）建立數據庫結構

6.4 運用設計需求

6.4.1 表名的命名規範

表名以英文單詞、單詞縮寫、簡寫、下劃線構成，總長度要求小於30位。

6.4.2 表字段的命名規範

字段名以英文單詞、單詞縮寫、簡寫、下劃線構成，總長度要求不超過30位。

字段名以名詞或名詞短語，字段採用單數形式。若表名由多個單詞組成，則取各個單詞的縮寫組成，單詞縮寫間使用下劃線作為分隔
若某個字段是引用某個表的外鍵，則字段名應盡量與源表的字段名保持一致，一面混淆

6.5 安全保密設計需求

6.5.1 防止用戶直接操作數據庫的方法

通過把關鍵應用服務器和數據庫服務器進行分離，防止用戶對數據庫服務器的直接操作，保證數據庫安全。

6.5.2 應用系統的用戶口令進行加密

在軟件系統中，對於數據的保護、業務操作的許可是通過識別用戶身份和權限來完成的。

用戶口令相比較，相同的話系統將該用戶的操作權限分配給用戶，用戶再根據所分配的權限對系統進行操作。

由以上過程可知，用戶口令在傳輸過程中容易被竊取泄漏，另外如果數據庫被非法進入則其中保存的口令能夠被非法查看。

因此，在傳輸過程中和數據庫中的口令記錄字段不應使用明文傳遞和保存，應該在口令被傳遞前對其明文口令使用有效的主流技術對傳輸數據進行加密部分描述的加密算法進行加密，在加密後傳輸到系統。

系統將用戶提交的經過加密的口令數據保存的加密口令進行比較，相一致則進行後續操作。通過以上措施和過程，證了加密口令即使被竊取仍無法得到原始口令。

6.5.3 對用戶進行權限識別和分級

在集團建設智能管控平台中，不同的業務不同的人員處理，並且對於不同的操作人員其所能夠訪問的數據是不同的。

為了保障各功能模塊的授權使用和數據不被非法訪問，系統劃分了不同的操作權限和數據讀寫等級。系統管理人員可以方便、靈活的將這些權限登記分配給某一個或某一類用戶。

當用戶登陸時，系統在用戶身份驗證通過後取得用戶的權限，根據用戶權限顯示相應的功能菜單。

當用戶對數據進行讀、寫、刪除後瀏覽操作時，系統判斷用戶對該數據的訪問權限確定是否允許該操作的執行。

第五章性能需求

1. 數據性能

平台支持不低於400個在建工地的數據彙集和分析計算，系統應滿足如下技術指標：

1.1 數據類型支持

統除支持一般結構性事務數據外，還需要支持主要二三維地理信息格式（shp、tiff、dem、3ds、max等），支持GPS、GLONASS、北斗等衛星定位數據，主要視頻協議的接入。

1.2 數據量支持

系統對GIS數據的支持能力不小於20TB；對圖片、視頻等非結構化數據的支持能力不小於200TB；對結構化數據的存儲和查詢數據量支持能力不小於500GB。

1.3 數據庫性能要求

根據本系統數據的特點，採用標準MYSQL語句，以便將來的擴展和移植。

系統將採用數據庫建模工具，根據系統功能模塊的設計，構建出整個數據庫。在構建數據庫時，也會定義好數據庫表的約束、關聯以及索引。

針對系統的具體特點和系統要求，我們在進行數據庫方案設計時對數據庫平台提出下列性能方面的要求：

標準化程度高，符合標準ANSI SQL 92語言的規範；
支持對稱處理和多線程技術，支持XML/CORBA，支持數據分區；
可在多種操作系統，HP、IBM等服務器下運行，獨立性強，對系統結構影響比較小；
高級語言、漢化功能先進，易於方便使用，支持漢字，GB18030標準；
支持主流的網絡協議，如TCP/IP、IPX/SPX、NETBIOS、DECNET、SNA等。
能支持同構、異構網絡分布操作，支持鬆散耦合及海量並行處理；
有足夠的並發控制，授權控制和事務處理能力及恢復能力；
與異種數據源有良好的可互操作性；
具有可靠的數據安全保密措施以及故障恢復能力；
具有SMP和MPP功能，具有快速的並發用戶查詢速度，並發控制穩定可靠；
具有很強的容錯能力，錯誤恢復能力，錯誤記錄及預警能力，具備異地容災能力；
允許行級鎖，具有死鎖自動解出功能而無需額外的數據一致性校驗；
具有強大的複製能力，支持主從式、級連式、對等式以及N-向複製，並支持複製日誌技術，具有分布式模式管理能力；
具有完整的安全性（帳號安全，系統級權限，對象安全性，審查等），細粒度化的訪問控制，適合於多層環境的安全模式的能力；
擁有支持MIS的功能強大的開發工具，提供數據倉庫和數據挖掘的工具。

2. 並發性

2.1 數據庫並發

數據庫支持超過500個用戶的並發訪問能力。

2.2 訪問並發

管理端平台具備不少於100個訪問並發的能力。

2.3 傳輸並發

系統業務功能包括附件和圖片的傳輸的時候，需提供穩定快速的傳輸效率，以及支持多附件多圖片並發上傳和下載的能力。

3. 響應特性

3.1 查詢響應

一般數據查詢響應時間<5秒。

3.2 製表速度

一般固定表格製表不超過10秒鐘，複雜統計彙集表格不超過5分鐘。

4. 架構特性

4.1 可靠性

系統需提供7*24的不間斷服務。

4.2 穩定性

系統需合理的利用資源，保證前後台數據操作的效率，以及在數據響應和界面承載方面都要達到不會出現界面混亂、數據報錯、觸發按鈕功能缺失、操作頻繁或者快速容易崩潰的問題。

4.3 兼容性

前端方面具有兼容各大主流瀏覽器的能力。

4.4 靈活性

PC端前端自適應方面具有能夠適配主流筆記本、台式電腦的能力，手機APP能夠適應主流手機屏幕尺寸。

4.5 擴展性

系統應便於新業務或者新功能的生成和實現第三方系統與平台的連接。另外系統提供動態頁面定製組件，能夠有效的幫助運營方生成產品和服務表單，方便管理人員擴充分類目錄等信息，並在權限管理、用戶管理上有高度的靈活性、合理性。

4.6 診斷性

通過詳細信息資料的方式確保用戶身份的可靠性，線上實施管理操作時，需確認用戶的身份。為了防止操作失誤，應該將用戶的操作過程信息以日誌形式保存，以作為失誤診斷的原始依據。

4.7 擴充性

保證已有平台和系統的兼容性及對未來發展的適應性，使系統可在原有的基礎升級改造和更新，並應當充分考慮技術進步因素的影響。

4.8 開放性

平台不是一個封閉的系統，今後必須通過接口和其他平台或系統相連，在平台建設中應充分考慮與外界信息系統交換的需求，保證既能滿足基本功能的需要，有具有與外界系統進行信息交換與處理的能力。

4.9 可伸縮性

要求在不用修改系統架構的情況下，通過增加或增強相應的設備即可實現系統功能的擴展支持，包括垂直擴展和水平擴展。

4.9.1 縱向伸縮

能夠通過增加硬件資源提高目標平均性能和峰值性能（即響應時間、延遲等）及目標平均負荷和峰值負荷（即並發用戶、信息量等）。

4.9.2 橫向伸縮

能夠通過增加應用服務器及實現應用服務器負載均衡、多節點等措施提高目標平均性能和峰值性能（即響應時間、延遲等）及目標平均負荷和峰值負荷（即並發用戶、信息量等）。

4.10 可交換性

系統應符合開放的原則，充分考慮各種業務需求有機結合，建立完善的系統整體構架，可與外部系統進行通訊並可提供標準的接口。既能實現業主業務，還可以完成數據交換、信息共享功能。

4.11 經濟性

系統應具備高性價比，能對系統資源的使用進行優化，在實現系統功能的前提下，盡量節省硬件資源的開銷。

4.12 安全性

主要體現在能夠通過冗餘措施加以保證，具體包括線路冗餘、設備備份措施；
能夠在外網與Internet互連區採用安全可靠的防火牆；
能夠建立完整的網絡防毒機制，以及建立嚴格完善的防毒管理規範；
能夠確保必須的網絡服務的安全和可靠性。如DNS；對其它網絡基本服務，限制使用範圍，建立嚴格的使用管理規定，防止被黑客利用，絕對禁止匿名FTP服務，對需要使用又必須保證安全的場合，要經過身份認證、訪問授權和審計記錄機制的控制；
能夠在Internet互聯區域及與內網互連區域設置防火牆。並採用防黑客攻擊軟件實現安全漏洞的掃描，結合系統管理及時修補安全漏洞；提供網絡實時入侵檢測，在一定程度上實現對內網與外網的入侵阻隔；做好攻擊的跟蹤審計；
能夠防止網站數據被非法篡改，並且在被篡改之後能夠及時的恢復。

4.13 業務驅動性

項目實施以提供業務支持為首要因素。應從業務實際需要出發，選擇重點與關鍵的環節進行信息化管理與控制，在信息化價值和靈活性、管理工作量之間取得良好的平衡，保證在系統實施後能提高工作效率、降低成本。

4.14 集成性

系統具有良好的集成性，對流程審批、數據獲取、信息集成等功能提供標準接口，以實現與其他相關係統的功能和數據集成。

4.15 可層次性

系統可以統一各個層次管理規範，統一數據結構、數據表達方式、數據訪問方式。

4.16 可模塊化性

系統須提供通用的組件支持，能夠減少重複開發工作，保證產品和項目的質量，縮短應用系統的開發周期，有利於系統的擴展。在統一的數據環境下集成化開發各個模塊，模塊的劃分應獨立於當前的組織機構，各個模塊之間的數據交換是結構化的、公用的，從而也是高效的和完整的，最大限度消除冗餘和不一致。

4.17 可維護性

方案和產品的架構須緊密跟蹤國家信息安全、業主標準和國際主流技術標準，開放性好，便於系統的升級維護、以及與各種信息系統進行集成。

4.18 先進實用性

系統規劃和設計理念可對照現有技術先進、成熟的產品，提高用戶體驗，以減少系統開發的周期和成本；功能定位充分考慮平台服務對象的需求。

第六章文檔附錄

1. 運行需求

1.1 用戶界面需求

1.1.1 字體

PingFang SC、Helvetics Neue、Arial、Hiragino Sans GB、Microsoft Yahei、微軟雅黑、STHeiti、華文細黑、sans-serif，正常體/400微粗體，（12至20）px，黑色/白色。

1.1.2 風格

採用全屏網頁設計，扁平化、視差化的化繁為簡的設計思維，讓整個網站的整體性、統一性、靈活性、自適應性、流暢性得到了相對的提高，也使得平台的功能處理和管理能力在這些特點的加持之下得到綜合性的展示。

1.1.3 色值

主題色值：深藍、白、黑；
協調色值：灰、天藍、紅；
文本色值：淺黑、天藍、紅；
按鈕色值：天藍、草綠、灰；
線框色值：天藍、灰。

1.1.4 尺寸

在合理的布局下儘可能多的顯示控件內的內容。

1.1.5 布局

按照操作流程或瀏覽順序自左至右、由上而下的排放各種控件，使界面整體協調、簡潔、美觀大方。

1.1.6 自適應父對象的尺寸改變

控件應具有自適應父對象的尺寸改變的能力，當父對象的尺寸發生變化時，控件應能自動改變自己的尺寸並使界面保持整體協調，盡量減少因父對象的尺寸改變而帶來的操作或瀏覽上的不便。

1.2 內部接口

考慮安全的問題，以供系統內部調用的接口。

1.3 外部接口

1.3.1 硬件接口

硬件接口是軟件所使用硬件設備的基本需求，在這裡平台支持打印功能，應有對接相關打印設備的需求。

1.3.2 軟件接口

平台可以對接其他軟件系統外放的接口，以此來獲得相關功能模塊所需的數據信息，需要對接的軟件系統分別為工程管理（XX）、隱患排查系統、項目跟蹤管理系統（CRM）、視頻監控管理系統等。

1.3.3 用戶接口

有系統系統、有導入導出需求用戶的基本需求。

1.3.4 通訊接口

遵循TCP/IP通信協議接口，要求開發人員使用規定的通訊接口，有協同系統的通訊標準需求，至少能夠支持用手機信息進行互動的通訊方式。

1.4 故障處理

1.4.1 發現問題

需要有完善的監控系統、可以對網絡，服務器CPU、負載、IO、內存、連接數（文件句柄數）以及應用系統性能、異常日誌進行全面訪問。

1.4.2 定位問題

需要有分析問題發生的根源能力，思考是否對網絡、硬件、應用進行升級，或者超過系統的承載量導致問題的發生。

1.4.3 解決問題

需要在故障發生之後有儘快處理問題的效率，不僅能夠恢復系統的正常運行，而且可以降低因系統故障對平台造成的損失。

1.4.4 消除影響

恢復應急過程中可以對系統進行臨時性的改變，用簡單的方式儘快的採取補救的措施，從而降低對用戶的影響。

1.4.5 回顧問題

分析問題的發生原因，該如何解決，怎麼避免問題再次發生，並做好此次故障發生之前的預防錯失。

1.4.6 採取措施

對問題發生的原因，避免方法採取行動、執行相應的措施。

1.5 運行環境

操作系統：
服務器：
瀏覽器：國內主流瀏覽器，比如Google chrome、火狐瀏覽器、360安全/極速瀏覽器、QQ瀏覽器、IE10以上的版本瀏覽器等。

1.6 開發環境

開發系統：
開發環境：
開發語言：
數據庫：

2. 結語

以第一章引言中參考資料所列出的文檔內容為基礎，結合XXXXXXX管理平台高保真原型（UE、UI）設計，根據這篇需求分析文檔記錄的內容為接引，從而來進行研發工作的推進，並以這篇文檔為基礎，通過全面性的論述來理清平台的需求，從而為以後項目的實際實施（研發和測試）提供可靠的依據或者參考。

原創文章，作者：投稿專員，如若轉載，請註明出處：https://www.506064.com/zh-hant/n/315358.html