需求分析基礎PPT課件.ppt

需求分析基礎 3 第三章 軟件需求作為軟件生命周期的第一個階段 其重要性越來越突出 到20世紀80年代中期 逐步形成了軟件工程的子領域 需求工程 90年代后 需求工程成為軟件界研究的重點之一 從1993年起 每兩年舉辦一次需求工程國際研討會 ISRE 1994年起 每兩年舉辦一次需求工程國際會議 ICRE 一些關于需求工程的工作小組相繼成立 使需求工程的研究得到了迅速進展 3 1軟件需求工程的基本概念 對系統(tǒng)應該提供的服務和所受到的約束進行理解 分析 建立文檔 檢驗的過程 需求工程 1 什么是軟件需求工程 2 軟件需求工程的任務是什么 3 需求工程過程4 軟件需求分析方法 軟件需求的重要性 軟件需求無疑是當前軟件工程中的關鍵問題 沒有需求就沒有軟件 美國于1995年開始對全國范圍內(nèi)的8000個軟件項目進行跟蹤調(diào)查 分析失敗的原因發(fā)現(xiàn) 與需求過程相關的原因占了45 而其中缺乏最終用戶的參與以及不完整的需求又是兩大首要原因 各占13 和12 未完成 完成未實施 完成 軟件需求的困難 軟件需求是軟件工程中最復雜的過程之一 應用領域的廣泛性 它的實施無疑與各個應用行業(yè)的特征密切相關 非功能性需求建模技術的缺乏 及其與功能性需求有著錯綜復雜的聯(lián)系 大大增加了需求工程的復雜性 溝通上的困難 由于系統(tǒng)分析員 需求分析員等各方面人員有不同的著眼點和不同的知識背景 給需求工程的實施增加了人為的難度 軟件需求 軟件需求的內(nèi)容 一 軟件需求內(nèi)容 功能需求它是對系統(tǒng)應該提供的服務 功能以及系統(tǒng)在特定條件下的行為的描述 它與軟件系統(tǒng)的類型 使用系統(tǒng)的用戶等相關 有時需要詳細描述系統(tǒng)的功能 輸入 輸出 異常等 有時還需要申明系統(tǒng)不應該做什么 領域需求是由軟件系統(tǒng)的應用領域所決定的特有的功能需求 或是對功能的約束 傳統(tǒng)需求分析 在傳統(tǒng)軟件工程生命周期中 涉及需求的階段稱作需求分析 一般來說 需求分析的作用是 定義軟件的范圍及必須滿足的約束 確定軟件的功能和性能及與其他系統(tǒng)成分的接口 建立數(shù)據(jù)模型 功能模型和行為模型 最終提供需求規(guī)格說明 并用于作為評估軟件質(zhì)量的依據(jù) 二 需求工程的活動 需求工程是系統(tǒng)工程和軟件工程的一個交叉分支 涉及到軟件系統(tǒng)的目標 軟件系統(tǒng)提供的服務 軟件系統(tǒng)的約束和軟件系統(tǒng)運行的環(huán)境 它還涉及這些因素和系統(tǒng)的精確規(guī)格說明以及系統(tǒng)進化之間的關系 它也提供現(xiàn)實需求和軟件能力之間的橋梁 需求工程 需求工程的基本活動包括 獲取需求 深入實際 在充分理解用戶需求的基礎上 獲取系統(tǒng)需求 需求分析與建模 進行需求建模 對模型或原型進行分析 確認需求 確保需求說明準確 完整地表達系統(tǒng)的主要特性 進化需求 客戶的需要總是不斷 連續(xù) 增長的 進化需求是必要的 一 需求獲取 requirementelicitation 是需求工程的主體 缺乏領域知識 應用領域的問題常常是模糊的 不精確的 存在默認的知識 如難以描述的常識問題 存在多個知識源 且多知識源之間可能有沖突 客戶可能的偏見 如不能提供或不想告知你所需要了解的事情 非常困難 主要原因有 需求獲取技術 需求抽取的方法一般有 1 面談法重要而直接 簡單的需求獲取技術 2 問卷調(diào)查法是對面談法的補充 3 需求專題討論會最有力的需求獲取技術 有利于培養(yǎng)高效團隊 4 觀察用戶的工作流程適用于用戶無法準確表達需求的情況 5 原型化方法6 基于用例的方法 還有知識工程方法等如 場記分析法 卡片分類法 分類表格技術和基于模型的知識獲取等 面談的對象主要有用戶和領域?qū)＜?1 面談前的準備要充分 2 面談后注意認真分析總結 3 注意掌握面談的人際交流技能 需求獲取技術 需求抽取的方法一般有 1 面談法重要而直接 簡單的需求獲取技術 2 問卷法調(diào)查法是對面談法的補充 3 需求專題討論會最有力的需求獲取技術 有利于培養(yǎng)高效團隊 4 觀察用戶的工作流程適用于用戶無法準確表達需求的情況 5 原型化方法6 基于用例的方法 是從多個用戶中收集需求信息的有效方式 一般問卷設計形式 1 多項選擇問題 2 評分問題 3 排序問題 需求獲取技術 需求抽取的方法一般有 1 面談法重要而直接 簡單的需求獲取技術 2 問卷法調(diào)查法是對面談法的補充 3 需求專題討論會最有力的需求獲取技術 有利于培養(yǎng)高效團隊 4 觀察用戶的工作流程適用于用戶無法準確表達需求的情況 5 原型化方法6 基于用例的方法 由開發(fā)方和用戶方共同召開 操作步驟 開發(fā)方根據(jù)雙方制定的 需求調(diào)研計劃 召開相關需求主題溝通會 會后開發(fā)方整理出 需求調(diào)研記錄 提交給用戶方確認 如果此主題還有未明確的問題則再次溝通 否則開始下一主題 所有需求都溝通清楚后 開發(fā)方根據(jù)歷次 需求調(diào)研記錄 整理出 用戶需求說明書 提交給用戶方確認簽字 因此系統(tǒng)應該具備以下功能 基本數(shù)據(jù)維護功能 基本業(yè)務功能 數(shù)據(jù)庫管理功能 信息查詢功能 例1 有一個大學圖書管理系統(tǒng) 該系統(tǒng)除了一般的圖書管理功能外 還能夠為學生和教工從其他圖書館借閱圖書和文獻資料提供服務 1 功能需求 基本數(shù)據(jù)維護功能 提供使用者錄入 修改并進行維護基本數(shù)據(jù)的途徑 基本數(shù)據(jù)包括讀者的信息 圖書資料的相關信息 可以對這些信息進行修改 更新 基本業(yè)務功能 讀者借 還書籍的登記管理功能 隨時根據(jù)讀者借 還書籍的情況更新數(shù)據(jù)庫系統(tǒng) 如果書籍已經(jīng)借出 可以進行預留操作 書籍的編目 入庫 更新等操作 數(shù)據(jù)庫管理功能 對所有圖書信息及讀者信息進行統(tǒng)一管理維護的功能 對書籍的借還也要進行詳細的登記 以便協(xié)調(diào)整個圖書館的運作 信息查詢功能 提供對各類信息的查詢功能 如對本圖書館的用戶借書信息 還書的信息 書籍源信息 預留信息等進行查詢 對其他圖書館的書籍 資料源信息的查詢功能 2 非功能需求 系統(tǒng)安全性需求 為保證系統(tǒng)安全性 對本圖書館的各項功能進行分級 分權限操作 對各類用戶進行確認 對其它圖書館借閱圖書和文獻資料服務控制訪問范圍 如限IP 限用戶等 對系統(tǒng)可用性的需求 為了方便使用者 要求對所有交互操作提供在線幫助功能 對系統(tǒng)查詢速度的需求 要求系統(tǒng)在20S之內(nèi)響應查詢服務請求 對系統(tǒng)可靠性的需求 要求系統(tǒng)失敗發(fā)生率小于1 3 領域需求例如 對 大學圖書管理系統(tǒng) 提出一些與圖書管理的業(yè)務相關的需求 圖書編目要求按照 中國圖書館分類法 進行 由于版權限制 某些文獻資料只能在圖書館規(guī)定的閱覽室閱讀 并限制復制和打印 第一條需求是對遵循我國圖書管理的規(guī)定 執(zhí)行對圖書的分類管理的標準 而第二條需求則是版權法對圖書館文獻資料的保護的需要 描述了對一類文獻資料有限制的使用和服務 二 需求分析與建模 需求分析和建模又包含三個層次的工作 1 需求分析2 需求建模 分為企業(yè)建模 功能需求建模和非功能需求建模等 3 需求規(guī)格說明 不同的描述方式 主要對收集到的需求進行提煉 分析和認真審查 確保所有參加人員取得一致共識 找出錯誤 遺漏和不足 建立完整的分析模型 需求分析常用技術 為了降低軟件的復雜度 便于對問題的分析和理解 常采用以下技術 1 分解將大問題分解為小問題 通常是自頂而下 不斷細化的過程 2 抽象抓住問題的本質(zhì)特性 從不同抽象層次進行分析 提出解決問題的方案 3 多視點注意從各類開發(fā)人員和不同用戶的角度考慮問題 才能獲得對系統(tǒng)的全面完整的需求 三 需求的有效性驗證 一 需求驗證的重要性 由于需求是軟件開發(fā)的第一階段 直接影響后面各階段的開發(fā) 需求的可變性必須進行驗證 做什么 怎么做 三 需求的有效性驗證 二 需求驗證的內(nèi)容1 有效性檢查 指功能需求是否符合用戶所提出的需求 2 一致性檢查 系統(tǒng)功能描述及約束是否一致 3 完備性檢查 是否包含所有系統(tǒng)用戶的需求和約束 4 可檢驗性檢查 是否能設計出一組驗證方法 確定了檢驗的標準 四 需求管理 需求管理貫穿需求分析全過程 包括 四 需求管理 需求管理的所有活動中 最重要的是 需求變更管理 包括 問題分析和變更描述 變更分析和成本計算 變更實現(xiàn) 需求管理過程需要CASE ComputerAidedSoftwareEngineering 工具支持 1 傳統(tǒng)的變化管理基本內(nèi)容包括軟件配置 軟件基線和變化審查 2 新的管理方法 軟件家族法 即軟件產(chǎn)品線方法 該方法是源于工業(yè)界產(chǎn)品線的概念 關注于一個軟件企業(yè)如何組織一組具有共性特征的 相似產(chǎn)品的生產(chǎn) 并應用軟件復用的相關原理與技術 多視點方法 它可以用于管理不一致性并進行關于變化的推理 是從多個視點出發(fā)在軟件工具的協(xié)助下對需求描述 進行自動需求建模 從而提高需求模型的完整性 需求變更管理方法 需求工程過程 3 2需求分析方法 功能分解方法將系統(tǒng)看作若干功能模塊的集合 每個功能又可以分解為子功能 子功能還可繼續(xù)分解 分解的結果即是系統(tǒng)的雛形 存在問題1 需要人工完成2 無法對描述的準確度進行驗證 3 難以適應需求的變化 1 客房預定系統(tǒng)2 前臺接待系統(tǒng)3 前臺收銀系統(tǒng)4 帳務系統(tǒng)5 管家系統(tǒng)6 電話系統(tǒng)7 客歷系統(tǒng)8 合約系統(tǒng)9 經(jīng)理系統(tǒng)10 總經(jīng)理系統(tǒng)11 密碼管理系統(tǒng)12 報表系統(tǒng)13 帳務報表 酒店管理系統(tǒng) 例 按照功能分解為以下子系統(tǒng) 例 盤存 銷售系統(tǒng) 用戶提出系統(tǒng)應有以下功能 計算買主訂單 準備銷售報表 建立買主文件和應收帳發(fā)票 運行更新的盤存文件 產(chǎn)生托運單和包裝單 保證庫存及時訂貨 計算銷售記錄1 1 1 產(chǎn)生銷售報表1 1 2 核對買主貸方金額1 1 3 3 2需求分析方法 結構化分析方法是一種以數(shù)據(jù) 數(shù)據(jù)的封閉性為基礎 從問題空間到某種表示的映射方法 由數(shù)據(jù)流圖 DFD圖 表示 3 2需求分析方法 面向?qū)ο蟮姆治龇椒嫦驅(qū)ο蠓治龇椒?OOA 的關鍵是識別問題域內(nèi)的對象 分析它們之間的關系 并建立起三類模型 信息建模法是從數(shù)據(jù)的角度對現(xiàn)實世界建立系統(tǒng)的信息模型 基本工具是ER圖 是由實體 屬性和關系組成的網(wǎng)絡圖 E 實體 是一個或一組對象 R 關系 實體之間聯(lián)系或交互作用 注意 信息建模與面向?qū)ο蠓治龅膮^(qū)別 3 2 1結構化分析方法 分解 對于一個復雜的系統(tǒng) 為了將復雜性降低到可以掌握的程度 可以把大問題分解成若干小問題 然后分別解決 如右圖 一 SA法的基本思想 分解 和 抽象 抽象 分解可以分層進行 即先考慮問題最本質(zhì)的屬性 暫把細節(jié)略去 以后再逐層添加細節(jié) 直至涉及到最詳細的內(nèi)容 這種用最本質(zhì)的屬性表示一個系統(tǒng)的方法就是 抽象 基本思想與步驟 三 SA法的描述方法1 分層的數(shù)據(jù)流圖 DFD圖 2 數(shù)據(jù)詞典3 描述加工邏輯的結構化語言 判定表及判定樹 二 SA法的步驟 深入調(diào)查研究 分析用戶需求 用DFD圖描述 分析系統(tǒng)需求 用DFD圖描述 修改完善DFD圖 增添功能 顧客 出版社 驗證訂單 匯總訂單 訂單 出版社訂單 圖書目錄文件 正確訂單 一批訂單 出版社檔案文件 畫圖步驟 1 確定外部實體及輸入 輸出數(shù)據(jù)流 2 確定分解頂層的加工 3 確定使用的文件 4 用數(shù)據(jù)流將各部分連接起來 形成數(shù)據(jù)封閉 注意 標注各加工框及數(shù)據(jù)流名稱 例一圖書預定系統(tǒng) 頂層DFD圖 2020 1 9 37 三 數(shù)據(jù)流圖 數(shù)據(jù)流圖 DataFlowDiagram DFD 是描述系統(tǒng)中數(shù)據(jù)流程的圖形工具 它描述了將系統(tǒng)的邏輯輸入轉(zhuǎn)換為邏輯輸出所需的加工處理過程 還有一些輔助的圖例 一 數(shù)據(jù)流圖的圖符基本圖形符號 頂層 中間層 底層 先全局后局部 先整體后細節(jié) 先抽象后具體 0圖 1圖 2圖 1 1圖 2 1圖 2 2圖 分層DFD圖 需求案例分析 案例一醫(yī)院病房監(jiān)護系統(tǒng) 采用結構化分析方法 案例二網(wǎng)上競拍系統(tǒng) 采用基于用例的方法 一 問題的描述在醫(yī)院ICU病房里 將病癥監(jiān)視器安置在每個病床 對病人進行監(jiān)護 監(jiān)視器將病人的組合病癥信號實時地傳送到中央監(jiān)護系統(tǒng)進行分析處理 在中心值班室里 值班護士使用中央監(jiān)護系統(tǒng)對病員的情況進行監(jiān)控 監(jiān)護系統(tǒng)實時地將病人的病癥信號與標準的病診信號進行比較分析 當病癥出現(xiàn)異常時 系統(tǒng)會立即自動報警 并打印病情報告和更新病歷 根據(jù)醫(yī)生的要求隨時打印病人的病情報告 系統(tǒng)還定期自動更新病歷 案例一醫(yī)院病房監(jiān)護系統(tǒng) 經(jīng)過初步的需求分析 得到系統(tǒng)功能要求 1 監(jiān)視病員的病癥 血壓 體溫 脈搏等 2 定時更新病歷 3 病情出現(xiàn)異常情況時報警 4 隨機地產(chǎn)生某一病員的病情報告 例2 醫(yī)院病房監(jiān)護系統(tǒng) 監(jiān)視病情 更新病歷 2 2 3實例 醫(yī)院病房監(jiān)護系統(tǒng) 請分析軟件系統(tǒng)需求 1 監(jiān)視病員的病癥 采集病癥信號 血壓 體溫 脈搏等 組合病癥信號 將模擬病癥信號轉(zhuǎn)換為數(shù)字信號 A D轉(zhuǎn)換 2 定時更新病歷 將病癥信號進行格式化并加入更新日期 時間 更新病歷庫中病人的信息 可人工設定更新病歷的時間間隔 3 病情出現(xiàn)異常情況時報警 根據(jù)標準病癥信號庫中的值 判斷是否報警 將報警信號轉(zhuǎn)換為各種模擬信號 D A轉(zhuǎn)換 實時打印病情報告 立即更新病歷 4 隨機地產(chǎn)生某一病員的病情報告 二 系統(tǒng)功能需求 局部監(jiān)視 更新日志 產(chǎn)生病情報告 非功能需求 1 監(jiān)視器與網(wǎng)絡的可靠性要求 涉及人的生命安全 2 效率需求中對時間 空間的需求 所采集的病癥信號數(shù)據(jù)量大 3 互操作需求 如要求監(jiān)視器采樣頻率可人工調(diào)整等 4 對病人病歷的隱私的要求 頂層DFD圖 醫(yī)院病房監(jiān)護系統(tǒng)分層DFD圖 頂層確定了系統(tǒng)的范圍 其外部實體為病員和護士 護士 病員 護士 第一層 醫(yī)院病房監(jiān)護系統(tǒng)頂層DFD圖 第二層 加工 中央監(jiān)視 分解 醫(yī)院病房監(jiān)護系統(tǒng)二層DFD圖 醫(yī)院病房監(jiān)護系統(tǒng)分層DFD圖 緊急報告 加工分解的原則自然性 概念上合理 清晰 均勻性 理想的分解是將一個問題分解成大小均勻的幾個部分 分解度 一般每一個加工每次分解最多不要超過 個子加工 分解應分解到基本加工為止 四 畫分層DFD圖的基本原則 數(shù)據(jù)守恒與數(shù)據(jù)封閉原則數(shù)據(jù)守恒是指加工的輸入 出數(shù)據(jù)流是否匹配 即每一個加工既有輸入數(shù)據(jù)流又有輸出數(shù)據(jù)流 數(shù)據(jù)封閉是對整個系統(tǒng)而言 合理使用文件當文件作為某些加工之間的交界面時 文件必須畫出來 一旦文件作為數(shù)據(jù)流圖中的一個獨立成份畫出來了 那么他同其他成份之間的聯(lián)系也應同時表達出來 注意 DFD圖不是流程圖 不表示軟件的控制流程 四 畫分層DFD圖的基本原則 子圖與父圖的 平衡 父圖中某個加工的輸入輸出數(shù)據(jù)流應該同相應的子圖的輸入輸出相同 相對應 分層數(shù)據(jù)流圖的這種特點稱為子圖與父圖 平衡 五 分層DFD圖的改進 DFD圖須經(jīng)過反復修改 才能獲得最終的目標系統(tǒng)的DFD圖 從以下方面改進DFD圖 1 檢查數(shù)據(jù)流的正確性 數(shù)據(jù)守恒 子圖 父圖的平衡 文件使用是否合理 特別注意輸入 出文件的數(shù)據(jù)流 2 改進DFD圖的易理解性 簡化加工之間的聯(lián)系 聯(lián)系越少 獨立性越強 易理解性越好 改進分解的均勻性 適當命名 各成分名稱無二義性 準確 具體 分層數(shù)據(jù)流圖只是表達了系統(tǒng)的 分解 為了完整地描述這個系統(tǒng) 還需借助 數(shù)據(jù)詞典 和 小說明 對圖中的每個數(shù)據(jù)和加工給出解釋 對數(shù)據(jù)流圖中包含的所有元素的定義的集合構成了數(shù)據(jù)詞典 詞典中可有以下四種類型的條目 六 數(shù)據(jù)詞典 DD 數(shù)據(jù)流文件數(shù)據(jù)項加工 A 數(shù)據(jù)流條目給出某個數(shù)據(jù)流的定義 通常是列出該數(shù)據(jù)流的各組成數(shù)據(jù)項 例如 報名單 姓名 單位名 年齡 性別 課程名常用符號 C 數(shù)據(jù)項條目數(shù)據(jù)項條目給出某個數(shù)據(jù)單項的定義 通常是數(shù)據(jù)項的值類型 允許的取值范圍 B 文件條目給出某個文件的定義 文件的定義通常是列出文件記錄的組成數(shù)據(jù)流 例如 訂單文件 訂單編號 顧客名稱 產(chǎn)品名稱 訂貨數(shù)量 交貨日期 D 加工條目加工類條目就是 加工小說明 一般應該單獨列出 七 加工說明 結構化語言判定表判定樹 對DFD圖中每一個基本加工都必須有一個小說明給出該加工的精確描述 小說明中應精確地描述加工的激發(fā)條件 加工邏輯 優(yōu)先級 執(zhí)行頻率和出錯處理等 加工邏輯是其中最基本的部分 指用戶對這個加工的邏輯要求 對基本加工說明有三種描述方式 結構化語言是介于自然語言和形式語言之間的一種半形式語言 是自然語言的一個受限制的子集 一般分為兩層結構 外層語法較具體 為控制結構 順序 選擇 循環(huán) 內(nèi)層較靈活 表達 做什么 一 結構化語言 例如 外層可為以下結構 1 順序結構2 選擇結構IF THEN ELSE CASE OF ENDCASE 3 循環(huán)結構WHILE DO REPEAT UNTIL 判定表是一種二維的表格 常用于較復雜的組合條件 與結構化語言比較 二 判定表 特點 可處理較復雜的組合條件 但不易理解 不易輸入計算機 通常由四部分組成 條件框 條件定義 操作框 操作的定義 條件條目 各條件的取值及組合 操作條目 在各條件取值組合下所執(zhí)行的操作 例如 對商店每天的營業(yè)額所收稅率 例 一圖書銷售系統(tǒng) 其中一加工為 優(yōu)惠處理 條件是 顧客的營業(yè)額大于1000元 同時必須信譽好 或者雖然信譽不好 但是20年以上的老主顧 判定表應用舉例 特點 描述一般組合條件較清晰 易理解 不易輸入計算機 如上例 三 判定樹 1992年由Jacobson提出了Usecase的概念及可視化的表示方法 Usecase圖 并加入由他提出的面向?qū)ο蟮能浖こ?OOSE Usecase的概念受到了IT界的歡迎 被廣泛應用到了面向?qū)ο蟮南到y(tǒng)分析中 基于用例的需求方法 已成為面向?qū)ο蟮姆治龇椒ǖ闹髁?用例模型被推薦為獲取和識別需求的首選工具 基于用例的方法 3 2 2面向?qū)ο蟮姆治龇椒?OOA Usecase圖 采用 基于用例的方法 來識別和獲取需求 是從外部的角度來看系統(tǒng)功能 建立系統(tǒng)的Usecase模型 描述外部執(zhí)行者 Actor 所理解的系統(tǒng)功能 即待開發(fā)系統(tǒng)的功能需求 用例 表示一個子系統(tǒng) 或者系統(tǒng)一個獨立的功能 角色 表示外部的 執(zhí)行者 ATM機驗證儲戶身份的Usecase圖 創(chuàng)建用例模型的工作包括 定義系統(tǒng) 確定執(zhí)行者和用例 描述用例 定義用例間的關系 確認模型 3 2 2面向?qū)ο蟮姆治龇椒?OOA 案例3網(wǎng)上拍賣系統(tǒng)隨著Internet技術的發(fā)展和互聯(lián)網(wǎng)的日益普及 互聯(lián)網(wǎng)用戶中約1 4的用戶使用Internet進行互聯(lián)網(wǎng)通信或經(jīng)貿(mào)活動 電子商務總額每年可達到6萬億美元 網(wǎng)上拍賣系統(tǒng)就是一個在互聯(lián)網(wǎng)上模擬拍賣環(huán)境的典型的范例 可實現(xiàn)從展示產(chǎn)品 相互競價到最后產(chǎn)品成交等一系列功能 用戶可以輕松實現(xiàn)在線商品的拍賣和競標 建立系統(tǒng)的USECASE模型 一 競拍平臺1 競拍者資格審查2 競拍規(guī)則設定3 競拍過程控制 二 拍賣商品信息發(fā)布確定發(fā)布的商品信息對商品信息操作 三 拍賣步驟及在線幫助四 網(wǎng)上支付系統(tǒng)五 用戶管理 用戶需求 系統(tǒng)需求 1 執(zhí)行者 用戶系統(tǒng)是通過網(wǎng)絡提供給商品的銷售者和購買者一個交易平臺 因此所有上網(wǎng)用戶都是本系統(tǒng)的用戶 具體又分為商品購買者和商品銷售者 系統(tǒng)管理員 考慮到一般用戶既可能是商品購買者也可能是商品銷售者 所以將用戶分為 非會員用戶和會員用戶 非會員 未注冊的用戶 只能在網(wǎng)站上瀏覽商品 不能參與競標 也不能提供物品出售 會員 已注冊的用戶 可以直接參與拍賣或競標 系統(tǒng)需求 2 用例 分析系統(tǒng)功能 提供高效的內(nèi)容豐富的Web拍賣商業(yè)服務 展示產(chǎn)品 相互競價 產(chǎn)品成交 實現(xiàn)拍賣商品種類的更新和消息的發(fā)布 實現(xiàn)個人物品流通和網(wǎng)上信息發(fā)布 留言 初步確定以下功能 1 會員注冊2 會員天地3 商品分類瀏覽4 查找商品5 拍賣商品6 購買商品7 網(wǎng)上支付 系統(tǒng)需求 進一步確定以下功能 1 會員注冊 填寫用戶帳號 用戶名 密碼 Email等 2 會員天地 查看并修改個人信息 交易記錄 收