IM聊實現客戶端之間信息交互需求文檔

終於放假啦~以前學習太忙不少知識點都沒有寫博客，可能本身學會了但沒有分享給你們，接下來幾天我可能把一些學過的東西整理成博客發出來供你們相互學習交流。

需求分析說明書

HuaXinIM聊軟件

潘浩

2016/5/6

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1、引言 2

1．編寫目的 2

2．背景 3

3．參考資料 3

2、項目概述 3

1．項目目標 3

2．用戶特色 3

3．設計和實現的約束和限制 3

3．1．開發環境 3

3．2．運行環境 3

3．3．條件和限制 4

4．軟件實現原則 4

3、具體需求 4

1．功能需求 4

2． 具體需求 5

2.1. 登錄註冊 5

2.2. 好友列表 7

2.3. 聊天功能 8

4、其它需求 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、引言

1．編寫目的

HuaXinIM聊軟件是基於TCP/IP協議和XMPP協議實現的一款聊天軟件，主要基於華信內部教學大型通訊項目學習，幫助學生更好的理解Socket編程、設計模式、數據庫編程、和JavaAPI使用。

 

2．背景

隨着互聯網的興起，聊天交流的方式變得多樣化，當今許多企業開發知足本身需求的網絡通信工具，方便部門與部門，員工與員工，員工與領導之間的工做交流，華信科技爲了鞏固學員的知識和技術架構，設計了此軟件，並提供學員小組開發練習。

3．參考資料

2、項目概述

1．項目目標

本項目立足於市場上比價火熱的即時聊天軟件QQ爲原型，設計了一條本身的聊天軟件模式，並提供了很大的發散空間，可讓學員添加更多的個性設計。

2．用戶特色

本項目主要用於內部學習使用。 

3．設計和實現的約束和限制

3．1．開發環境

該系統擬採用C/S結構，前臺採用Java的Swing技術，後臺採用Java的Socket技術和JDBC技術，並結合mysql數據庫作數據存儲。

3．2．運行環境

中文WINXP、WIN7、WIN8，1G以上內存，服務端須要運行mysql數據庫。

3．3．條件和限制

因爲當前項目僅僅只是用於內部學習和討論研究，不涉及任何商業性質，因此開發者只須要嚴格按照項目需求的說明實現便可。

4．軟件實現原則

根據軟件工程規範和當前網站的要求和特色，系統開發得遵循如下原則.

實用性原則：開發的系統必須知足實用性的需求，作到實用方便、輸入數據儘可能小、界面直觀、易學易用，不一樣業務之間界面轉換速度快。

功能完整性原則：所提出的業務可以在計算機平臺上完成，對於同一類型的業務，因爲輸入要求或地址模式等條件的不一樣，將設計不一樣的功能模塊。

高性能原則：系統在性能上作到數據容量小、響應速度快、穩定性高、出錯率低、容錯性能好等優勢。

數據安全性原則：安全性永遠是數據處理的重要課題，必須採起多種措施保證數據庫的安全。

美觀化設計原則：在知足實用性的條件下，界面設計作到美觀大方、大小適中、排列整齊、各類控制鍵的中文名字簡單明瞭、不一樣業務甚至不一樣功能，有不一樣的界面。美觀的界面配色柔和，減輕視覺疲勞，給用戶一個良好的計算機工做環境，並不失政府威嚴。

統一性原則：創建同一合理的數據庫模型，實行統一的文檔編排和管理；實行統一的數據庫關係名、後臺文件名、函數名、變量名等；實行統一的編碼風格。

系統的可擴展性原則：在知足當前開發學習的基礎上，考慮從此係統須要新加功能，爲系統的擴充預留接口。

3、具體需求

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
最後更新者		最後更新日期
主執行者	登錄成功用戶
功能描述	能夠在發送窗口選擇表情，並點擊發送，接收端能夠接收到消息
前置條件	用戶登陸成功後進入的好友界面，並選擇指定好友進入聊天界面
業務規則	圖片正常顯示
其餘需求	界面圖片
流程圖

 

4、其它需求

1．外部接口需求

1．1．用戶界面

對於網站，咱們強調友好的人機交互界面的同時保證平臺的嚴肅性，儘量給用戶提供簡潔的流程操做和完善的功能。

1．2．軟件接口

l Mysql數據庫

l 操做系統：WinXP/Win7/Win8/Win10

2．性能需求

本系統在性能上儘可能作到實時性強、數據容量小、響應速度快、穩定性高、出錯率低、容錯性好等優勢。

2．1．靈活性

2．2．數據管理能力的需求

就目前來看，該軟件數據量相對單一，後臺數據處理相對教簡單。

3．質量要求

3．1．安全性

在本系統的設置中，主要從一下幾個方面考慮系統和數據的安全性：

知足速度要求下的少許原則：餘量指的是邏輯上相同的數據，在不一樣的記錄中重複出現，或在邏輯上能導出存在於數據庫的記錄中。從理論上講，餘量的存在，在數據庫設計的不合理，是破壞數據庫一致性的潛在危險，同時會增長數據空間開銷。可是，在特殊狀況下，爲了知足速度要求，經常設計一些餘量做爲數據庫的記錄。當餘量存在時，數據庫一致性不能靠數據庫管理系統來保證，只能經過開發軟件的計算方法來解決，餘量的存在，大大增長了系統的開發難度，因此餘量是萬不得已才能使用，使用時，在計算方法保證數據的一致性。

3．2．可維護性

3．3．可靠性