軟件項目需求確認書[共14頁]

《軟件項目需求確認書[共14頁]》由會員分享，可在線閱讀，更多相關《軟件項目需求確認書[共14頁]（14頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 上海正善信息科技有限公司 需求確認書 項目編號：HDLH0001 項目名稱： 合達聯(lián)行“樂盒”項目 密 級：公開 版本信息： V1.0 創(chuàng) 建 人： 創(chuàng)建日期：2014年9月10日 審 核 者： 批 準 人： 批準日期： 編輯軟件：Microsoft Word 2007/2010中文版 文件狀態(tài)： √草稿 「」正式發(fā)布 「」正在修改

2、 上海正善信息科技有限公司 <版權所有> 文檔修訂記錄 版本編號或者更改記錄編號 *變化 狀態(tài) 簡要說明（變更內容和變更范圍） 日期 變更人 批準日期 批準人 *變化狀態(tài)：A——增加，M——修改，D——刪除 文檔審批信息 序號 審批人 角色 審批日期 簽字 備注

3、 主要內容 1 引言 4 1.1 編寫目的 4 1.2 背景范圍 4 1.3 術語定義 4 1.4 參考資料 4 1.5 讀者范圍 4 2 調研情況介紹 4 3 需求范圍 4 4 總體需求 4 4.1 系統(tǒng)組成 4 4.2 系統(tǒng)的邏輯崗位及職責 5 4.3 系統(tǒng)業(yè)務流程 5 5 功能需求 5 5.1 功能清單 5 5.2 功能規(guī)范 5 5.2.1 功能綜合說明 5 5.2.2 功能詳細定義 5 6 系統(tǒng)接口描述 6 6.1 用戶界面 6 6.2 硬件接口 6 6.3 軟件接口 6 6

4、.4 通信接口 6 7 非功能需求 6 7.1 性能需求 6 7.2 安全性要求 7 7.3 對軟硬件環(huán)境的要求 7 7.4 其它需求 7 8 附錄1 7 8.1 原型 7 8.2 采用建模工具所形成的模型文件 7 8.3 調研相關資料和文件 7 8.4 同類產品簡介 7 8.5 需求分析過程中制定的相關規(guī)范或模板 7 9 附錄2：需求確認表 8 1 引言 1.1 編寫目的 說明：編寫這份需求規(guī)格說明書的目的。 1.2 背景范圍 說明： 軟件名稱:樂盒手機APP a. 待開發(fā)的軟件系統(tǒng)的名稱； 任務提出者:成都合達聯(lián)行物業(yè)服務有限責任公司 開

5、發(fā)者:上海正善信息科技有限責任公司 b. 本項目的任務提出者、開發(fā)者、用戶及實現(xiàn)該軟件的計算中心或計算機網(wǎng)絡； c. 該軟件系統(tǒng)同其他系統(tǒng)或其他機構的基本的相互來往關系。 1.3 術語定義 列出本文件中用到的專門術語的定義和外文的首字母組詞的原詞組。 1.4 參考資料 列出用得著的參考資料，如： 本項目的經核準的計劃任務書和合同、上級機關的批文； 屬于本項目的其他已發(fā)表的文件； 本文件中各處引用的文件、資料，包括所要用到的軟件開發(fā)標準。列出這些文件資料的標題、文件編號、發(fā)表日期和出版單位，說明能夠得到這些文件資料的來源。 1.5 讀者范圍 指出預期讀者。 2 調研情

6、況介紹 可采用表格形式簡明地描述調研過程，如下表： 序號 調研對象 調研時間 調研內容 調研人 調研方式 調研輸出結果 其中的調研輸出結果可能包括兩類文檔資料：一是用戶的原始資料，如報表樣張或者用戶的內部資料等；二是經過分析和整理的文件，如調研報告或者會議記錄等。一般把這些資料作為需求規(guī)格說明書的附件處理。 3 需求范圍 說明本需求規(guī)格說明書是否包含了立項階段所涉及的所有功能。 如果是合同項目是否包括合同所有需求，及合同以外擴展的需求。 4 總體需求 4.1 系統(tǒng)組成 說明整個系統(tǒng)的組成和系統(tǒng)運行機理；概述每個子系統(tǒng)的功能，并說明子系

7、統(tǒng)之間的關系。 /**添加**/ 系統(tǒng)由java后臺，android手機APP，ios手機APP組成。 Java后臺為手機app提供數(shù)據(jù)交互接口，為用戶添加數(shù)據(jù)提供界面。 Android手機app為android手機用戶提供數(shù)據(jù)瀏覽，數(shù)據(jù)交互界面。 Ios手機app為ios手機用戶提供數(shù)據(jù)瀏覽，數(shù)據(jù)交互界面。 4.2 系統(tǒng)的邏輯崗位及職責 不同的單位實際的崗位名稱和職責可能不相同，在做需求分析的時候需要加以抽象形成邏輯工作崗位并對每個崗位的職責加以描述。 /**修改**/ 系統(tǒng)管理員:對后臺數(shù)據(jù)進行添加修改操作，對一般用戶進行刪除操作，對一般的管理員進行添加修改操作。 一般

8、管理員：對后臺數(shù)據(jù)進行添加修改，刪除。 一般用戶：通過手機app，可以瀏覽數(shù)據(jù)，與后臺進行數(shù)據(jù)交互。 4.3 系統(tǒng)業(yè)務流程 在邏輯工作崗位及職責確定之后，需要進一步歸納用戶的業(yè)務情況。每一項業(yè)務都由一個或者多個崗位的人按照一定順序來完成，可以采用業(yè)務流程圖來描述每一項業(yè)務。 /**修改**/ 后臺流程圖: app流程圖: 5 功能需求 5.1 需求清單 采用列表形式列舉產品的所有需求，每個需求均需標識，并需要確定每個功能的優(yōu)先級，如可能還應估計每個功能項所需開發(fā)時間（包括設計和編碼時間）。 標識號采用層次化命名。需求優(yōu)先級建議分為1、2、3級，其中1級為最高級，表示

9、必須實現(xiàn)的功能。 功能清單可以采用下面的表格表示： 后臺管理: 標識號 需求名稱 需求說明 優(yōu)先級別 備注 1 訂單管理 1.訂單的處理，訂單的刪除，記錄訂單處理人，查看訂單詳情。 2 2 去哪兒玩 1.添加攻略的名稱，時間，詳情。包括上傳攻略的圖片。 1 3 吃什么 同去哪兒玩 4 商家管理 1.商家的添加，刪除，查看詳情，修改。 1 包括玻璃房子，玫瑰園，宜必思。 5 人員管理 1.添加管理員，刪除管理員，修改管理員。 2.刪除注冊用戶。 1 6 活動管理 1.添加，刪除，查看，修改活動信息。包括上傳活

10、動圖。 1 7 操作管理 1.操作的查詢和查看 2 8 推薦管理 1.推薦的查看與刪除 1 9 App升級管理 1.版本的添加和apk的上傳。 1 10 特推商家管理 1.添加，修改，刪除后臺特推商家。 1 11 商品管理 1.商品的添加，修改，刪除 1 App前端: 標識號 需求名稱 需求說明 優(yōu)先級別 備注 1 首頁 1.讀取推薦信息并在滑動欄展示。 2.讀取后臺特推商家并展示 1 參考原型設計main_page 2 推薦點擊 1.進入到各自的詳情界面。2.推薦內容包括果蔬，活動，去哪兒

11、玩，吃什么。 1 3 點擊去哪兒玩 1.進入去哪兒玩列表界面，按時間先后順序排列。 2.根據(jù)長假，短假，周末和好評圖，發(fā)布時間進行過濾排序。 3.列表顯示第一張圖片，標題，評分，假期類型。 4.點擊搜索，搜索去哪兒玩的標題，模糊搜索。 1 參考原型設計activity_news_page 4 點擊去哪兒玩列表 1.進入去哪兒玩詳情界面。 2.點擊右上角分享，分享到微信。 3.內容下方的評分，不用登錄，可以直接評分。同一個用戶可以多次評分。 1 參考原型設計activity_news_details_page 5 點擊吃什么 1.進入到吃什么列表。 1

12、 同去哪兒玩列表 6 點擊吃什么列表 1.進入到吃什么詳情 1 同吃什么詳情。 7 點擊購物信息 1. 進入到購物信息列表 2.點擊搜索，根據(jù)的標題模糊搜索。 3.列表顯示第一張圖片，開始時間，結束時間，名稱以及店名。 1 參考原型設計community_news_activity 8 點擊購物信息列表 1.進入到購物信息詳情 2.詳情界面顯示名稱，開始時間結束時間，商家名稱，活動的列表。 3.活動的列表顯示圖片，商家名稱，商家的描述，活動的內容。 1 參考原型設計news_details_page 9 點擊果蔬 1.進入到果蔬的列表 2.列表顯

13、示第一張圖片，商品名稱，商品描述，剩余時間，市場價，當前價。 1 參考原型設計 tuangou_page 10 點擊果蔬列表 1.進入到果蔬詳情 2.上面滑動欄，顯示商品的圖片。 3.點擊立即搶購，添加商品搶購界面，（2.0版本不作要求） 4.點擊咨詢，撥打咨詢電話。 5．購買人數(shù)可以修改。 1 參考原型設計tuangou_details_page 11 點擊品味生活 1.進入到品味生活列表 2.列表分為預告和報道兩個類別。預告指將要發(fā)生的活動，活動完成之后由管理員刪除預告活動，并寫報道。報道是指已經完成的活動。 3.品味生活放十個類別， 4.列表內容顯示圖片

14、，名稱，描述，時間，類別。 1 參考原型設計 pingweishenghuo_list_page 12 點擊品味生活列表 1.點擊列表，進入到品味生活詳情 2.界面最上面的title顯示分類的名稱， 3.顯示贊的個數(shù)，并可以多次點擊贊。點選贊不用登錄。 4.分享到微信。 5.先顯示圖片，再顯示文字。 1 參考原型設計 pwsh_details_page 13 點擊房產經紀 1.點擊房產經紀進入到房產經紀列表。 2.房產列表過濾條件包括地點和房產類型。 3.輸入搜索條件，模糊搜索房產信息。 4.列表顯示房產照片，房子名稱，房子地理位置，面積，房子屬性。 1

15、 參考原型設計house_list_page 14 點擊房產經紀列表 1.點擊房產經紀列表，進入到房產經紀詳情。 2.顯示房子的詳細信息。 3.點擊撥打電話，直接撥打房產經紀電話。 4.分享到微信 5.房產信息全部都能夠修改。 1 參考原型設計house_details_page 15 特推商家 1.點擊特推商家，進入到特推商家詳情。 2.商家詳情顯示商家名稱，商家圖片，地理位置，聯(lián)系方式。 3.分享到微信。 4.點擊產品列表，顯示產品列表信息。 1 參考原型設計shoppoing_details_page 16 玻璃房子 1.點擊玻璃房子，進入到玻璃

16、房子詳情。 2.玻璃房子 17 錦瑞坊 參考玻璃房子 18 玫瑰園 參考玻璃房子 19 錦瑞坊 參考玻璃房子 20 宜必思 參考玻璃房子 21 運動中心 參考玻璃房子 5.2 需求規(guī)格 編寫需求規(guī)范之前應該先制定與當前開發(fā)的項目/產品相適用的模板，然后根據(jù)這個模板來對需求清單中的所有功能進行描述?？梢园铝袃热荩? 5.2.1 需求綜合說明 包含下列內容： （1） 使用者的邏輯崗位。 （2） 業(yè)務背景。即使用者在什么情況下使用該功能。 （3） 業(yè)務規(guī)則。比如算法 （4） 后續(xù)描述中用到的術語解釋

17、/**修改**/ 后臺分為管理員和普通管理員角色。 App端是普通的注冊用戶。 App用戶查看社區(qū)的活動，打折信息，參加線下活動報名，購買果蔬。 5.2.2 需求詳細定義 本部分的描述步驟如下： （1） 分析當前需求需要的用戶界面。一些功能可能需要多個用戶界面；還有一些需求雖然都在一個用戶界面中，但界面過于復雜，象這種情況需要拆分為幾部分，每部分單獨描述。建議給每個界面（或者界面的一部分）按照一定規(guī)則編號。 （2） 針對每個用戶界面需要說明下列內容： a) 界面完成功能簡介 b) 界面數(shù)據(jù)描述。對界面中的所有數(shù)據(jù)項詳細定義，一般需要包含下列內容：數(shù)據(jù)項　名稱、數(shù)據(jù)項說明、數(shù)據(jù)

18、類型及限制規(guī)則、數(shù)據(jù)來源、缺省值等。 c) 界面操作描述。對界面中所有可能的用戶操作詳細定義，一般需要包含下列內容：操作項名稱、操作過程描述、操作過程中隱含的系統(tǒng)處理、操作的限制條件（即什么情況下該操作失效）等。 此部分分為兩部分描述:后臺管理和app端呈現(xiàn)。 6 系統(tǒng)接口描述 6.1 用戶界面 描述需要的用戶界面的邏輯特征。 后臺界面:1.簡潔，以后臺的信息操作管理為主。顏色以深藍為主。 2.左邊顯示操作欄，右邊顯示操作內容。 3.操作為標準的操作鏈接，按鈕為標準矩形按鈕，有確定和取消。 4.錯誤信息顯示以彈出對話框的形式。 6.2 硬

19、件接口 6.3 軟件接口 軟件接口名稱 外部組件名稱 版本號 接口描述 推薦接口 用于首頁推薦系統(tǒng) 特推商家 6.4 通信接口 通信接口名稱 協(xié)議或方式 安全要求 傳輸速率要求 同步通信描述 Web瀏覽器 HTTP/1.0 1M 7 非功能需求 7.1 性能需求 需要對軟件靜態(tài)和動態(tài)兩個方面的性能作出定量規(guī)定。 可能包含如下內容： l 所支持的并發(fā)用戶數(shù)。 l 容錯要求, 如異常操作后應如何處理，如編制預算過程中突然中斷時應能自動恢復或保護上一次編制狀態(tài)。 l 數(shù)據(jù)的處理能力要求，如可處理的文件和記

20、錄數(shù),表及文件的大小規(guī)模, 數(shù)據(jù)增長情況。 l 對數(shù)據(jù)存儲的空間的要求。 l 正?；驑O端情況下，對用戶操作響應速度的要求。 7.2 安全性要求 7.3 對軟硬件環(huán)境的要求 硬件環(huán)境 CPU 內存 硬盤 網(wǎng)絡 …… 軟件環(huán)境 操作系統(tǒng) 數(shù)據(jù)庫 相關軟件 …… 7.4 其它需求 　　　如：美化界面等； 8 附錄1 8.1 原型 8.2 采用建模工具所形成的模型文件 在需求分析階段經常用到一些模型來輔助說明，如果采用結構化分析技術，通常使用數(shù)據(jù)流程圖、實體聯(lián)系圖；而采用面向對象的分析技術，通常使用實例圖、順序圖、協(xié)作圖

21、和狀態(tài)圖。 8.3 調研相關資料和文件 如調研報告、會議記錄以及調研過程中獲取的用戶原始資料等。 8.4 需求分析過程中制定的相關規(guī)范或模板 如原型風格說明、功能規(guī)范模板、用戶調研規(guī)范等。 9 附錄2：需求確認表 本需求文檔建立在雙方對需求的共同理解基礎之上，是后續(xù)的開發(fā)的依據(jù)，是用戶驗收的依據(jù)。經甲乙雙方確認簽字后，最終確定。如果需求發(fā)生變化，請?zhí)岢稣綍嬉?，并且雙方協(xié)商成本、資源和進度等。 需求確認 客戶代表簽字 　　　　　　　　　　　　　　　簽字：　　　　　　日期： 項目經理簽字 　　　　　　　　　　　　　　　簽字：　　　　　　日期： 機密文件 14 / 14