需求規格說明書

1.引言

---

1.1目的

    本文檔首先給出項目的總體結構和功能結構的概貌，試圖從整體架構上給出整個系統的輪廓。同時對功能需求、性能需求進行詳細的描述，以便於用戶、開發人員進行理解和交流，反映出用戶問題的結構，能夠做爲軟件工做開發的基礎依據以及確認測試和驗收的依據。

    本文檔面向的讀者:

• 項目經理:項目經理根據該文檔瞭解預期產品的功能，並據此進行系統設計
• 設計員:對需求進行分析，並設計出系統，包括數據庫的設計
• 程序員:瞭解系統功能，開發編碼
• 測試員:根據本文檔對軟件產品進行功能性測試和非功能性測試

• 用戶:瞭解預期產品的功能和性能，並與分析人員一塊兒對整個需求進行討論和協商

  1.2背景

• 軟件名稱:鹹魚
• 項目任務:軟件工程課程實踐

• 項目開發者:至誠學院2016級軟件工程實踐《善學如泉》小組

  1.3參考文獻

      《GB9385-2008 計算機軟件需求規格說明規範》

  ---

  2.項目概述

  項目loge

  用例圖

  
  

  ---

  2.1產品背景

      現現在網絡上的二手交易平臺有不少，例如轉轉、閒魚等APP，用戶能夠在這些APP上出手本身閒置或者想要轉讓的物品，這些APP給用戶帶來方便的同時也有許多隱患。例如二手交易的安全性、不可預知性。因爲這些APP的具備跨地域交易性，所以不少二手交易的結果不盡人意。所以，咱們但願可以作出一個只服務於校內學生的二手交易平臺，在提升交易便捷性的同時提升交易的安全性。

  2.2產品描述

      咱們的《跳蚤》（如下簡稱爲本產品），是一個可以整合二手交易信息的平臺。在這個平臺上，咱們的用戶能夠收集到大量的二手交易信息，並在本產品上進行二手交易，能爲不知道如何出手閒置物品的學生提供可靠信息並進行二手交易。

  2.3產品功能

      本產品的功能主要有兩個,分別是購買和拍賣。同時還兼具商品評價和用戶信用評級等功能。

  2.4將來市場

      高校內的新生和老生每每分別具備購買和拍賣物品的需求。新生因爲剛到校園，每每須要購置一些大學生平常生活必需品，而這些必需品內每每有一些須要高價才能購買到，例如按摩椅、電腦、相機等。這些物品並非一次性的，不少都是能夠重複使用的，所以以原價購入並不划算。並且大學生的平常生活習慣具備高度的重合性，所以向高年級的學長學姐收購他們再也不須要的物品就是一個很好的折中方案。因而可知新生與老生之間存在需求互補的現象。所以作一個服務於校內學生的二手交易平臺具備必定的市場。

  2.5用戶場景

  用戶	使用場景
  用戶A	A是一名剛入學的計算機大一新生，在宿舍的前一個月，坐着宿舍內的座椅敲代碼的時候以爲腰痠背痛，考慮到將來的很長一段時間都須要在電腦面前度過。所以他決定購買一張按摩椅來緩解長期坐在電腦前的痛苦。他去某寶上查看了按摩椅的價格，一看好一點的都要大幾百甚至上千，所以他決定買入一張二手的按摩椅。他使用了本產品，很快找到了一張心儀的按摩椅---這是一位快要離校的學長在大二的時候買入的，如今還很新，最後A買入了這把椅子，以很低的成本解決了本身的需求。
  B	B在大二上學期選修了學校的網球課，體育老師要求你們須要自帶網球拍，因爲網球課只上一學期，並且B對於網球運動並非很感興趣，所以買一個全新的球拍並不合算，所以他到咱們的APP上發佈收購二手網球拍的消息，用較低的成本成功的買入一個二手的網球拍。在課程結束後，他又將網球拍進行拍賣,用較低的成本解決了本身的需求。
  C	C在大三的時候萌生了考研的想法，可是苦於沒有經驗，不知道從何開始。他就想能不能嚮往年的學長買一些考研筆記，讓本身更有方向。所以他在咱們的APP上發佈了這類消息，很快他同專業的一個剛剛考研完的學長找到了他，達成了交易的意向。經過學長的筆記他很快就找到了考研複習方向的確立，爲本身的考研之路制定了明確的目標。

  2.6假設與約束

  2.6.1假設

• 可操做性：假設使用本產品的用戶在通過一段時間的熟悉後，能夠靈活地操做本產品
• 用戶支持：假設本產品開發的各個環節中獲得用戶的有效支持和積極配合
• 技術支持：假設開發初期，項目架構設計合理，小組成員充分認識本產品的需求，認真學習相關知識。開發過程當中遇到的技術問題能夠及時獲得老師的指導與幫助。開發後期，團隊熟練掌握適用於該項目的技術，充分優化系統性能
• 人員配合：假設團隊成員的積極合做配合，爲了項目的開發和實施，可以合理規劃我的時間，而且在必要時，能爲團隊作出合理犧牲，配合隊友完成任務。若小組成員變更，新舊成員可以出色地交接和快速瞭解項目、投入開發；若小組成員無變更，則假設項目開發過程當中不會有突發狀況致使項目成員沒法正常參與開發工做
• 時間限定：假設項目截止日期不會提早

• 需求限定：假設項目需求肯定後不會有太大改動

  2.6.2約束

• 人員約束：團隊成員皆爲大三學生，共 7人
• 管理約束: 本次開發實行以一人擔任組長，分工合做的模式進行。力求每一個人的分工涉及開發過程當中的全部流程，並按照進度表進行，開發過程遇到的問題經過小組會議獲得一致解決。小組成員首次合做，須要一個磨合的過程，須要明確自身責任，分清各自任務，互相配合，遇到問題組長必須能進行有效的協調，才能快速、較好地完成開發過程
• 技術約束：小組成員在相關技術水平方面存在必定的欠缺，缺少相關的項目經驗，須要在開發中併發學習多種技術和能力；在文檔編寫能力方面也有待提高
• 時間約束：本項目開發週期短，時間相對緊張，兩個月的開發時間須要開發者合理規劃時間，作到多項任務併發

• 其餘約束：開發期間，小組成員還有其餘科目的學習任務，將對項目進度形成必定影響
  

  ---

  3.具體需求

  3.1外部接口需求

  3.1.1用戶接口

      無特殊要求;

  3.1.2硬件接口

      無特殊要求;

  3.1.3軟件接口

      IE8.0及以上；

  3.1.4通訊接口

      無特殊要求;

  3.2功能需求

  3.2.1界面原型

• 首頁：商品類型總覽及熱門商品推薦
  
• 註冊登陸：新用戶註冊、已有用戶登陸界面
  
  
• 商品詳情:查看商品詳情
  
• 商品發佈:發佈商品信息，進行拍賣
  

• 我的信息:查看、修改我的信息
  

  3.3產品屬性

  3.3.1可用性

• 界面簡潔大方，操做簡便，易於用戶使用
• 可以支持多人同時在線使用

• 能穩定運行，出現突發情況時能保證用戶資料完整、正常退出程序

  3.3.2安全性

• 能對用戶身份進行識別，避免非用戶本人對用戶帳號進行操做

• 在多用戶併發運行時能保證用戶數據完整性、獨立性

  3.3.3可維護性

• 系統能按期更新迭代、修復bug

• 對系統進行更新迭代、修復的時候能保證用戶數據的完整性、獨立性
  

  ---

  4.驗證驗收標準

  4.1文檔驗收標準

• 組員的文檔格式統一

• 文檔編寫符合國際文檔編寫規範

  4.2軟件驗收標準

• 客戶端:用戶能進行正常的檢索、拍賣、收購等功能

• 服務器端：管理員能正常的對用戶、數據庫進行管理

  4.3界面驗收標準

• 界面簡潔大方，操做簡便，易於用戶使用

  4.4功能驗收標準

• 購買：用戶能正常購買商品
• 拍賣：用戶能正常拍賣商品
• 評價：用戶能正常評價商品、商家
• 舉報：用戶可以舉報已購買過商品的商家，進行舉報
• 學號註冊：用戶可以使用學院學號註冊帳號
• 檢索商品：用戶能正常檢索商品

• 註冊、登陸：用戶能正常註冊、登陸網站

  4.5初期版本最核心完成內容

• 完成總體界面UI的設計及展現
• 實現用戶正常的登陸、註冊
• 實現商品展現
• 實現購買、拍賣兩大核心內容

• 實現多人併發操做