終于放假啦~之前學習太忙很多知識點都沒有寫部落格,可能自己學會了但沒有分享給大家,接下來幾天我可能把一些學過的東西整理成部落格發出來供大家互相學習交流。
需求分析說明書 |
HuaXinIM聊軟體 |
潘浩 |
2016/5/6 |
一、引言
2
1.編寫目的
2
2.背景
3
3.參考資料
3
二、項目概述
3
1.項目目标
3
2.使用者特點
3
3.設計和實作的限制和限制
3
3.1.開發環境
3
3.2.運作環境
3
3.3.條件和限制
4
4.軟體實作原則
4
三、具體需求
4
1.功能需求
4
2.
具體需求
5
2.1.
登陸注冊
5
2.2.
好友清單
7
2.3.
聊天功能
8
四、其它需求
14
1.外部接口需求
14
1.1.使用者界面
14
1.2.軟體接口
14
2.性能需求
14
2.1.靈活性
14
2.2.資料管理能力的需求
14
3.品質要求
14
3.1.安全性
14
3.2.可維護性
15
3.3.可靠性
15
一、引言
1.編寫目的
HuaXinIM聊軟體是基于TCP/IP協定和XMPP協定實作的一款聊天軟體,主要基于華信内部教學大型通信項目學習,幫助學生更好的了解Socket程式設計、設計模式、資料庫程式設計、和JavaAPI使用。
2.背景
随着網際網路的興起,聊天交流的方式變得多樣化,當今許多企業開發滿足自己需求的網絡通訊工具,友善部門與部門,員工與員工,員工與上司之間的工作交流,華信科技為了鞏固學員的知識和技術架構,設計了此軟體,并提供學員小組開發練習。
3.參考資料
二、項目概述
1.項目目标
本項目立足于市場上比價火熱的即時聊天軟體QQ為原型,設計了一條自己的聊天軟體模式,并提供了很大的發散空間,可以讓學員添加更多的個性設計。
2.使用者特點
本項目主要用于内部學習使用。
3.設計和實作的限制和限制
3.1.開發環境
該系統拟采用C/S結構,前台采用Java的Swing技術,背景采用Java的Socket技術和JDBC技術,并結合mysql資料庫做資料存儲。
3.2.運作環境
中文WINXP、WIN7、WIN8,1G以上記憶體,服務端需要運作mysql資料庫。
3.3.條件和限制
由于目前項目僅僅隻是用于内部學習和讨論研究,不涉及任何商業性質,是以開發者隻需要嚴格按照項目需求的說明實作即可。
4.軟體實作原則
根據軟體工程規範和目前網站的要求和特點,系統開發得遵循以下原則.
實用性原則:開發的系統必須滿足實用性的需求,做到實用友善、輸入資料盡量小、界面直覺、易學易用,不同業務之間界面轉換速度快。
功能完整性原則:所提出的業務能夠在計算機平台上完成,對于同一類型的業務,由于輸入要求或位址模式等條件的不同,将設計不同的功能子產品。
高性能原則:系統在性能上做到資料容量小、響應速度快、穩定性高、出錯率低、容錯性能好等優點。
資料安全性原則:安全性永遠是資料處理的重要課題,必須采取多種措施保證資料庫的安全。
美觀化設計原則:在滿足實用性的條件下,界面設計做到美觀大方、大小适中、排列整齊、各種控制鍵的中文名字簡單明了、不同業務甚至不同功能,有不同的界面。美觀的界面配色柔和,減輕視覺疲勞,給使用者一個良好的計算機工作環境,并不失***威嚴。
統一性原則:建立同一合理的資料庫模型,實行統一的文檔編排和管理;實行統一的資料庫關系名、背景檔案名、函數名、變量名等;實行統一的編碼風格。
系統的可擴充性原則:在滿足目前開發學習的基礎上,考慮今後系統需要新加功能,為系統的擴充預留接口。
三、具體需求
1.功能需求
系統功能分為:登陸注冊、線上使用者清單、聊天功能、表情發送、曆史消息、檔案發送、遠端協助等功能。
結構圖如下:
2.具體需求
2.1.
登陸注冊
處理登陸流程
用例ID | 1 | 用例名稱 | 使用者登陸 |
建立者 | 小張 | 建立日期 | 2016-5-5 |
最後更新者 | 最後更新日期 | ||
主執行者 | 所有已經存在賬戶的客戶 | ||
功能描述 | 軟體登陸 | ||
前置條件 | 存在新增賬號 | ||
業務規則 | 1.使用者名必須正确 2.密碼必須正确 3.可以用手機号、賬号、郵箱登陸 4.提供IP和端口号的修改 | ||
其他需求 | 界面圖檔 | ||
流程圖 |
處理注冊流程
用例ID | 2 | 用例名稱 | 使用者注冊 |
建立者 | 小張 | 建立日期 | 2016-5-5 |
最後更新者 | 最後更新日期 | ||
主執行者 | 所有需要執行注冊的角色 | ||
功能描述 | 提供賬号注冊,為後續登陸提供前提 | ||
前置條件 | 無 | ||
業務規則 | 1.使用者名2-10位的數字或者字元 2.使用者名、密碼、手機号、郵箱、性别不能為空 3.手機号碼必須為11位的純數字 4.郵箱格式***@***.com | ||
其他需求 | 界面圖檔 | ||
流程圖 |
2.2.
好友清單
用例ID | 3 | 用例名稱 | 好友清單 |
建立者 | 小張 | 建立日期 | 2016-5-5 |
最後更新者 | 最後更新日期 | ||
主執行者 | 登陸成功使用者 | ||
功能描述 | 1.展示目前所有線上的使用者 2.上線下線消息提示 | ||
前置條件 | 使用者登入成功後進入的界面 | ||
業務規則 | 展示所有線上的使用者,不線上的使用者直接不展示 展示個人資訊:使用者名 好友資訊:好友姓名、好友性别 | ||
其他需求 | 界面圖檔 | ||
流程圖 |
2.3.
聊天功能
用例ID | 4 | 用例名稱 | 聊天功能 |
建立者 | 小張 | 建立日期 | 2016-5-5 |
最後更新者 | 最後更新日期 | ||
主執行者 | 登陸成功使用者 | ||
功能描述 | 1.聊天界面 2.發送消息、檔案、表情、遠端協助、曆史消息 | ||
前置條件 | 使用者登入成功後進入的好友界面,并選擇指定好友 | ||
業務規則 | 選擇界面指定功能,執行相應操作 | ||
其他需求 | 界面圖檔 | ||
流程圖 |
2.3.1
聊天消息
用例ID | 5 | 用例名稱 | 發送聊天消息 |
建立者 | 小張 | 建立日期 | 2016-5-5 |
最後更新者 | 最後更新日期 | ||
主執行者 | 登陸成功使用者 | ||
功能描述 | 1.在輸入框輸入聊天内容,并點選發送,會發送消息出去 2.接收消息框,顯示接收到的消息内容(包括好友的和自己的消息) | ||
前置條件 | 使用者登入成功後進入的好友界面,并選擇指定好友進入聊天界面 | ||
業務規則 | 接收消息顯示框必須顯示内容:使用者名、接收日期、接收時間 | ||
其他需求 | 界面圖檔 | ||
流程圖 |
2.3.2.
表情發送
用例ID | 6 | 用例名稱 | 發送聊天消息 |
建立者 | 小張 | 建立日期 | 2016-5-5 |
最後更新者 | 最後更新日期 | ||
主執行者 | 登陸成功使用者 | ||
功能描述 | 可以在發送視窗選擇表情,并點選發送,接收端可以接收到消息 | ||
前置條件 | 使用者登入成功後進入的好友界面,并選擇指定好友進入聊天界面 | ||
業務規則 | 圖檔正常顯示 | ||
其他需求 | 界面圖檔 | ||
流程圖 |
2.3.3.
檔案發送
用例ID | 7 | 用例名稱 | 發送聊天消息 |
建立者 | 小張 | 建立日期 | 2016-5-5 |
最後更新者 | 最後更新日期 | ||
主執行者 | 登陸成功使用者 | ||
功能描述 | 可以在發送視窗選擇表情,并點選發送,接收端可以接收到消息 | ||
前置條件 | 使用者登入成功後進入的好友界面,并選擇指定好友進入聊天界面 | ||
業務規則 | 發送圖檔,對方會收到是否接收檔案的請求,如果确認接收,則開始傳輸檔案,否則,取消發送 | ||
其他需求 | 界面圖檔 | ||
流程圖 |
2.3.4.
遠端協助
用例ID | 8 | 用例名稱 | 發送聊天消息 |
建立者 | 小張 | 建立日期 | 2016-5-5 |
最後更新者 | 最後更新日期 | ||
主執行者 | 登陸成功使用者 | ||
功能描述 | 可以在發送視窗選擇表情,并點選發送,接收端可以接收到消息 | ||
前置條件 | 使用者登入成功後進入的好友界面,并選擇指定好友進入聊天界面 | ||
業務規則 | 圖檔正常顯示 | ||
其他需求 | 界面圖檔 | ||
流程圖 |
2.3.5
曆史消息
用例ID | 9 | 用例名稱 | 發送聊天消息 |
建立者 | 小張 | 建立日期 | 2016-5-5 |
最後更新者 | 最後更新日期 | ||
主執行者 | 登陸成功使用者 | ||
功能描述 | 可以在發送視窗選擇表情,并點選發送,接收端可以接收到消息 | ||
前置條件 | 使用者登入成功後進入的好友界面,并選擇指定好友進入聊天界面 | ||
業務規則 | 圖檔正常顯示 | ||
其他需求 | 界面圖檔 | ||
流程圖 |
四、其它需求
1.外部接口需求
1.1.使用者界面
對于網站,我們強調友好的人機互動界面的同時保證平台的嚴肅性,盡可能給使用者提供簡潔的流程操作和完善的功能。
1.2.軟體接口
l Mysql資料庫
l 作業系統:WinXP/Win7/Win8/Win10
2.性能需求
本系統在性能上盡量做到實時性強、資料容量小、響應速度快、穩定性高、出錯率低、容錯性好等優點。
2.1.靈活性
2.2.資料管理能力的需求
就目前來看,該軟體資料量相對單一,背景資料處理相對教簡單。
3.品質要求
3.1.安全性
在本系統的設定中,主要從一下幾個方面考慮系統和資料的安全性:
滿足速度要求下的少量原則:餘量指的是邏輯上相同的資料,在不同的記錄中重複出現,或在邏輯上能導出存在于資料庫的記錄中。從理論上講,餘量的存在,在資料庫設計的不合理,是破壞資料庫一緻性的潛在危險,同時會增加資料空間開銷。但是,在特殊情況下,為了滿足速度要求,常常設計一些餘量作為資料庫的記錄。當餘量存在時,資料庫一緻性不能靠資料庫管理系統來保證,隻能通過開發軟體的計算方法來解決,餘量的存在,大大增加了系統的開發難度,是以餘量是萬不得已才能使用,使用時,在計算方法保證資料的一緻性。