從概念到產(chǎn)品-需求分析過程-免費閱讀
【正文】 – 產(chǎn)品定義 ? 本節(jié)必須給出易發(fā)生混淆的術語的定義 ? 把詞匯表都放這里 84 一份需求規(guī)格說明書的內(nèi)容 5/6 ? 概述 1。 78 幾個不好的需求 ? “產(chǎn)品應在 不少于每 60秒（？） 的 正常周期（？） 內(nèi)提供 狀態(tài)信息 ” ? “產(chǎn)品應 瞬間 在顯示和隱藏 不可打印字符間切換” ? “ HTML分析器可以產(chǎn)生 HTML標記 錯誤報告 ，幫助 HTML入門者 快速 解決錯誤”。 – 需求中的不一致必須在開發(fā)開始前得到解決。 73 高質(zhì)量需求說明書的特征 ? 完整 ? 一致性 ? 可修改性 ? 可追蹤 74 高質(zhì)量需求說明書的特征 1/4 ? 完整： – 不應該遺漏要求和必需的信息。 – 自然語言極易導致含糊。 69 高質(zhì)量需求敘述的特性 3/6 ? 必要性： – 每個需求應載明什么是客戶確實需要的，什么要順應于外部的需求，接口或標準。 ) g)當郵件用戶要求退出管理新來郵件信息時，功能夾終止。 [用戶必須能夠區(qū)分新的、已讀過的、未讀過的消息。 57 Use Case 闡述的逐步細化 － 3 補充值域 a)當郵件用戶要求管理郵件信息時功能夾啟動，系統(tǒng)顯示信息。 – 不包含 Omni PCX交換機的外線撥號前綴。最常用 (80%以上 )為女性 (2140)。 [用戶必須能夠區(qū)分新的、已讀過的、未讀過的消息。 } e)把郵件信息保存為文件； f)把郵件信息的附件保存為文件； [用戶必須能夠看見附件的文件類型 ] {這種情況下， 95%的郵件都少于 2個附件。 } e)把郵件信息保存為文件； (在這種情況下，少于 5%做了此項操作。 68 高質(zhì)量需求敘述的特性 2/6 ? 可行性： – 在已知的能力、有限的系統(tǒng)及其環(huán)境中每個需求必須是可實現(xiàn)的。 ? 如果所有的需求都被視為同等重要，那么由于在開發(fā)中，預算削減，計劃超時或組員的離開導致新的需求時， 項目經(jīng)理將不能起到作用。 – 如果需求是不可驗證的，決定需求是不是正確的實現(xiàn)就成了判斷的事。 ? 能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。 – 通過良好的組織可以使需求易于修改，如： ? 將相關的需求分組，建立目錄表，索引，以及前后參考 ? Feature 是很好的工具 77 高質(zhì)量需求說明書的特征 4/4 ? 可追蹤： – 應能將一個軟件與其原始材料相對應 ? 如高級系統(tǒng)需求，用例，用戶的提議等。 ? 參考資料清單： – 請在表格中羅列本文檔所引用的有關參考文獻名稱 、 作者 、 標題 、 編號 、 發(fā)布日期和出版單位等基本信息 。 開發(fā)環(huán)境 一般整個系統(tǒng)作一份，所有需求文檔都 Copy 4。文檔的多份文本要在同一時間內(nèi)全部更新，避免不一致性。 76 高質(zhì)量需求說明書的特征 3/4 ? 可修改性： – 當每個需求的要求修改了或維護其歷史更改時，你必須能夠?qū)彾?SRS。 ? 在 SRS中將需求以分層目錄方式組織，將幫助評審人員理解功能性描述的結構，使他們很容易指出遺失的東西。 – 檢查需求模糊的有效方式包括需求說明書的正規(guī)檢查，根據(jù)需求寫測試，建立用戶的假想來說明產(chǎn)品某個特定部分預期的特性。 70 高質(zhì)量需求敘述的特性 4/6 ? 優(yōu)先權： – 為了表明在一個詳細的產(chǎn)品版本中應包含哪些要點，需要為每個需求，特征，或用例分配實現(xiàn)的優(yōu)先權。 – 只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時，要包括他們或他們的代理的關鍵所在。 } b)郵件用戶可以按照以下的一個或多個步驟執(zhí)行： c)按照發(fā)送這或主題整理郵件信息； (在這種情況下，有超過 60%做了此項操作。 ] {平均每 100個同時顯示的未讀郵件消息中，其中 90%的消息主題行少于 40個字符。 b)郵件用戶可以按照以下的一個或多個步驟執(zhí)行： c)按照發(fā)送這或主題整理郵件信息； d)閱讀郵件信息的內(nèi)容； e)把郵件信息保存為文件； f)把郵件信息的附件保存為文件； g)當郵件用戶要求退出管理新來郵件信息時，功能夾終止。從概念到產(chǎn)品－需求分析過程 Something about grammar amp。 － 《 RTX Omni PCX插件軟件需求規(guī)格說明書 .doc》 49 Use Case的 Pattern ? 大部分互聯(lián)網(wǎng)服務本質(zhì)上是 DB： – 增刪改查 – 導入導出 – 批量操作 ? 計算機應用的基礎支撐功能： – 安裝卸載 – 啟動停止重啟動 – OAM（運營、管理、監(jiān)視） 50 自定義頭像的 Use Case 用戶 Server組管理員 PMM 第三方頭像 CP 設置自定義頭像 從本機設置 從網(wǎng)絡硬盤設置 從第三方系統(tǒng)設置 第三方 頭像系統(tǒng) 網(wǎng)絡硬盤 系統(tǒng) 《 extend》 《 extend》 《 extend》 添加第三方 CP 查看頭像運營數(shù)據(jù) 51 Use Case闡述 52 Use Case：開始走向需求規(guī)格說明書 ? Use Case圖并不是需求文檔的必備部分 ? Use Case分析是過程，不是結果 ? Use Case闡述，等于： 53 Use Case闡述的基本四要素 ? 進入條件 – 描述 Use Case在何種情況下進入 – 如用戶必須具備什么條件？之前發(fā)生了什么？ ? 基本流程 – 不考慮任何異常例外，沒有 if then else – 從用戶角度闡述 Use Case如何運作 ? 結束條件 – Use Case成功結束后，發(fā)生了什么變化 – 用戶發(fā)生什么變化？系統(tǒng)發(fā)生什么變化？ ? 例外流程 – 逐個闡述在基本流程中某個環(huán)節(jié)出現(xiàn)異常時的處理 54 Use Case闡述的幾個禁止 ? 禁止假設系統(tǒng)由哪些技術實現(xiàn)模塊組成 – “系統(tǒng)從 服務器基礎 DB中刪除好友關系” ? 禁止假設用戶可以使用哪些 UI界面 – “系統(tǒng)彈出 錯誤提示窗口 ” ? 禁止使用沒有主謂賓的語句 – “給出提示” ? 禁止使用沒
環(huán)評公示相關推薦
鄂ICP備17016276號-1