【文章內(nèi)容簡(jiǎn)介】 系統(tǒng)需求 功能性需求 非功能性需求 設(shè)計(jì)約束 需求分析 —— 細(xì)化用例 在需求獲取過(guò)程中 ， 我們建立了業(yè)務(wù)模型和系統(tǒng)模型 ， 引入了角色和用例的概念 角色與用例的區(qū)別： ?系統(tǒng)的角色是業(yè)務(wù)之外與業(yè)務(wù)交互的人或事 ?例如： ATM取款機(jī)作為一個(gè)業(yè)務(wù)系統(tǒng) ， 來(lái)取款的客戶(hù)就是一個(gè)角色 ?用例是業(yè)務(wù)模型中 ， 業(yè)務(wù)的活動(dòng) ?在系統(tǒng)模型中 ， 描述了業(yè)務(wù)中系統(tǒng)的工作 （ 內(nèi)部活動(dòng) ） 。 角色是外部 ， 用例是內(nèi)部 。 取款的客戶(hù)是角色 ， 取款是用例 。 用例模型開(kāi)始定義角色之間的關(guān)系 （ 關(guān)聯(lián)關(guān)系：包括關(guān)系 、 擴(kuò)展關(guān)系 、一般化關(guān)系等 ） 。 用例模型描述事件流 ， 包括主事件流 、 其他事件流 、前提條件 、 事后條件等等 。 需求分析 —— 細(xì)化用例 細(xì)化用例的主要步驟： ?審查主角 ?細(xì)化描述 ?定義和細(xì)化事件流程 ?確定前置條件和后置條件 ?確定特殊需求 ?擴(kuò)展用例 需求分析 —— 細(xì)化用例關(guān)系 為需求處理做準(zhǔn)備 ?在定義系統(tǒng)的用例規(guī)約之前，確定一份基本的術(shù)語(yǔ)詞匯表，以統(tǒng)一項(xiàng)目開(kāi)發(fā)中的用詞。 ?確定系統(tǒng)的用例，通常從尋找系統(tǒng)的主角開(kāi)始。如果做了業(yè)務(wù)建模，則可以先從業(yè)務(wù)對(duì)象模型中的業(yè)務(wù)工人（ Business Worker）著手。 ?系統(tǒng)主要的主角確定后，可以根據(jù)為系統(tǒng)主角提供有價(jià)值的結(jié)果（ Result of Value）這一準(zhǔn)則（用例是為主角的活動(dòng)最終提供一個(gè)有價(jià)值的結(jié)果的活動(dòng)過(guò)程）來(lái)確定系統(tǒng)的用例。 ?理清系統(tǒng)用例之間存在的密切關(guān)系，具有的內(nèi)在結(jié)構(gòu)，如泛化關(guān)系、包含關(guān)系、擴(kuò)展關(guān)系等。 ?有二種 Interaction圖 ， 按時(shí)間順序排列的是 Sequence圖 ， 按對(duì)象關(guān)系排列的是 Collaboration圖 。 二種圖從不同的角度 ， 反映了案例中特定情形的流程 。 需求處理階段 需求規(guī)格說(shuō)明書(shū) 項(xiàng)目 《 用戶(hù)需求說(shuō)明書(shū) 》 或 《 前景文件 》 提供了業(yè)務(wù)需求的宏觀描述文檔 ， 使得公司內(nèi)部相關(guān)部門(mén)對(duì)項(xiàng)目 ， 有一個(gè)全局的了解 。 Use Case圖和 Interaction圖為用戶(hù) ， 為項(xiàng)目組提供了需求的詳細(xì)描述 。 為了后續(xù)開(kāi)發(fā)階段 （ 概要設(shè)計(jì)和詳細(xì)設(shè)計(jì) ） 的需要 ， 在傳統(tǒng)模式下， 有了用戶(hù)實(shí)例 ， 還必須編寫(xiě)從用戶(hù)實(shí)例派生出來(lái)的功能需求規(guī)格說(shuō)明書(shū)和非功能需求文檔 。 包括：質(zhì)量檢驗(yàn)標(biāo)準(zhǔn) 、 接口說(shuō)明等 。 這些文件 ， 成為需求分析的成果 。 CMM2也規(guī)定 ， 必須以文檔形式 ， 給出給定需求 。 需求處理 —— 傳統(tǒng)的 《 需求規(guī)格說(shuō)明書(shū) 》 1 2 3 4 5 6 A 引言 目的 文檔約定 預(yù)期的讀者和閱讀建議 產(chǎn)品的范圍 參考文獻(xiàn) B 綜合描述 產(chǎn)品前景 產(chǎn)品的功能 用戶(hù)類(lèi)和特征 運(yùn)行環(huán)境 設(shè)計(jì)和實(shí)現(xiàn)上的限制 假設(shè)和依賴(lài)附錄 C 外部接口需求附錄 用戶(hù)界面附錄 硬件接口 軟件接口 通信接口 D 系統(tǒng)特性 說(shuō)明和優(yōu)先級(jí) 激勵(lì) /響應(yīng)序列 功能需求 E 其他非功能需求 性能需求 完全設(shè)施需求 安全性需求 軟件質(zhì)量屬性 業(yè)務(wù)規(guī)范 用戶(hù)文檔 F 其他需求 G 附件 詞匯表 分析模型 待確定問(wèn)題清單 軟件需求規(guī)格說(shuō)明書(shū)闡述一個(gè)軟件系統(tǒng)必須提供的功能和性能 ， 以及他們必須考慮的限制條件 。這不但是測(cè)試和用戶(hù)使用 、維護(hù)文檔的基礎(chǔ) ， 而且 ， 也是系統(tǒng)的子系統(tǒng)規(guī)劃 、 設(shè)計(jì)和編碼的基礎(chǔ) 。 需求文檔：需求的形式化問(wèn)題 需求文檔化： 需求一旦確定 ， 就需要把它用文檔的形式 ， 固定下來(lái) 。 文檔化的目的： ?首先通過(guò)記錄 （ 紙質(zhì)的文字或數(shù)據(jù)庫(kù)記錄等 ） ， 使需求被記錄下來(lái) 。 任何口頭的傳誤 ， 在文字記錄上 ， 會(huì)被減少 。 ?其次 ， 形式化最主要的追求 ， 是解決完整性和無(wú)歧義性 。 能真正達(dá)到形式化的需求 ， 是需求分解 、 分配 、 追蹤 、 評(píng)估的條件 。 20世紀(jì) 80年代的一項(xiàng)研究表明 ， 20%的錯(cuò)誤是對(duì)需求的錯(cuò)誤解釋造成的。 IBM公司對(duì)需求描述的形式化研究 ， 已經(jīng)提出了一種保證需求文檔更一致的需求描述方法學(xué) ， 使通過(guò)使用這種規(guī)定的方法建立的需求 ， 不同人寫(xiě)的需求之間的差異 ， 已經(jīng)降到最小 。 為了便于需求實(shí)現(xiàn)和變更控制管理 ， 需求形式化在形式上 ， 進(jìn)一步發(fā)展為需求數(shù)據(jù)庫(kù)化 。 需求形式化 ——消除歧義的努力 消除需求描述的歧義性 ， 是軟件工程的 “ 軟肋 ” ， 沒(méi)有什么更好的方法 。 因?yàn)閷?duì)需求的描述和定義 ， 不可能像計(jì)算機(jī)語(yǔ)言的定義那樣 ， 做到無(wú)二義性 。 因?yàn)?， 代價(jià)太高了 。 消除歧義的方法： 原始： 了解和記錄用戶(hù)的最原始需求 ， 不要轉(zhuǎn)述 、 不要用自己的理解代替 。 關(guān)鍵： 對(duì)關(guān)鍵部分 、 關(guān)鍵字 ， 盡量用大家都理解的 、 無(wú)二義的限定詞描述 。 逆向： 對(duì)需求試著用其他的 （ 逆向的 ） 思維和理解方式進(jìn)行解讀 ， 看有什么可能得到不同的解釋 。 分解： 對(duì)需求進(jìn)行分解 ， 在分解過(guò)程中 ， 找到不合理和不符合邏輯的錯(cuò)誤 。 圖形： 用非自然語(yǔ)言的方法 ， 表述需求 ， 減少理解的差異 。 需求的形式化處理 ， 可以幫助你實(shí)現(xiàn)以上目標(biāo) 。 需求形式化的技術(shù)方法： 為了規(guī)范化需求 ， 使以下各階段能夠在可分解 、 可追溯 、 允許增 /刪改的基礎(chǔ)上對(duì)需求進(jìn)行使用和管理 ， 需求形式化的最基本要求 ， 是應(yīng)該把需求按系統(tǒng)體系結(jié)構(gòu)進(jìn)行分解 ， 形成類(lèi)似工作分解的 WBS， 需求被標(biāo)上層號(hào)和序號(hào) 。 需求記錄不僅僅是一篇文字 。 在很多項(xiàng)目組中 ， 需求就是一篇長(zhǎng)文章 ， 有的甚至是事后補(bǔ)寫(xiě)的 ， 更談不上條理化 、 數(shù)據(jù)庫(kù)化 。 在這樣的情況下 ， 需求的分解和實(shí)現(xiàn) ， 充滿(mǎn)了二意性 ， 完全根據(jù)實(shí)現(xiàn)者的理解。 同樣 ， 項(xiàng)目任務(wù)的分解是模糊不清的 ， 需求變更是界線不清的 ， 變更的影響不但無(wú)法評(píng)估 ， 甚至涉及的范圍都無(wú)從知曉 。 在追求需求形式化的道路上 ， 軟件人做了長(zhǎng)期的努力 ， 但結(jié)果并不盡人意 。 可以實(shí)用的方法有： ?偽代碼 ?有限狀態(tài)機(jī) ?決策表和決策樹(shù) ?活動(dòng)圖 （ 流程圖 ） ?實(shí)體聯(lián)系模型 （ ER模型 ） ?不成功的方法：形式語(yǔ)言描述 需求數(shù)據(jù)庫(kù) 在需求數(shù)據(jù)庫(kù)的支持下 ， 需求是細(xì)致的 。 如果把需求的層 、 項(xiàng)看成是一個(gè)搜索網(wǎng)絡(luò)的話 ， 借助這個(gè)網(wǎng)絡(luò) ， 可以全面地捕捉容易疏忽的需求 ， 特別是系統(tǒng)的邊界情況 。 同時(shí)需求數(shù)據(jù)庫(kù)也是可標(biāo)記狀態(tài) 、 記錄活動(dòng)的 。 有支持需求數(shù)據(jù)庫(kù)化處理的工具 ， 如： Rational的RequisitePro或 MS的 VSS， 來(lái)協(xié)助進(jìn)行需求的數(shù)據(jù)庫(kù)管理 。 需求記錄和管理的數(shù)據(jù)庫(kù)化 ， 先是對(duì)需求進(jìn)行分解 ， 然后 ， 是建立需求項(xiàng)的屬性 。 需求形式化的技術(shù)方法： 需求屬性化是需求數(shù)據(jù)庫(kù)化的基礎(chǔ) 需求屬性 含義 說(shuō)明 名稱(chēng) * 需求名稱(chēng) 用最簡(jiǎn)潔的語(yǔ)言表示需求的核心含義 描述與定義 * 對(duì)需求的描述定義 需求的最本質(zhì)內(nèi)容可以用模型 、 圖 、 表表示 編號(hào)層 /序 * 需求的順序號(hào) 可根據(jù)系統(tǒng)結(jié)構(gòu)或任務(wù)的 WBS編排 來(lái)源 * 需求的提出來(lái)源 用戶(hù)需求的更高層依據(jù) 、 來(lái)源 提出 /決策人 需求的提出人 當(dāng)需求變化或受到影響時(shí)能最終決定的人 優(yōu)先級(jí) 需求的優(yōu)先級(jí) 表明高 、 中 、 低 ， 以備取舍或決定響應(yīng)次序 實(shí)體 * 需求實(shí)現(xiàn)的實(shí)體 表明需求與實(shí)現(xiàn)實(shí)體的對(duì)應(yīng)關(guān)系 狀態(tài) * 需求所處的狀態(tài) 包括：提出批準(zhǔn) 、 實(shí)施 、 實(shí)現(xiàn) 、 完成或拒絕 、推遲 、 等待 、 丟棄等 。 穩(wěn)定性 需求的穩(wěn)定性 按穩(wěn)定性定義描述穩(wěn)定性的高 、 中 、 低 驗(yàn)收標(biāo)準(zhǔn) 驗(yàn)收標(biāo)準(zhǔn) 需求實(shí)現(xiàn)的驗(yàn)證方式和標(biāo)準(zhǔn) 負(fù)責(zé)人 需求實(shí)現(xiàn)的負(fù)責(zé)人 備注 對(duì)需求的附加說(shuō)明 作者 需求的提交者 版本號(hào) * 需求的版本號(hào) 變更記錄 * 本版本的變更內(nèi)容 描述本版本的變更原因 、 內(nèi)容 、 影響 更新日期 * 需求的變更日期 需求形式化與需求數(shù)據(jù)庫(kù) ?有了具有信息屬性的需求信息 ， 根據(jù)這些屬性描述 ， 我們可以抽象出需求數(shù)據(jù)字典 ， 這樣 ， 我們就可以建立需求數(shù)據(jù)庫(kù)了 。 ?通過(guò)需求數(shù)據(jù)庫(kù) ， 我們可以方便地對(duì)需求的變化 ， 增加 、修改 、 變化記錄 、 狀態(tài)變化等 ， 做出完善的記錄 。 ?更重要的是 ， 借助需求數(shù)據(jù)庫(kù) ， 我們可以： ?分配資源 ， ?評(píng)估狀態(tài)， ?計(jì)算軟件指標(biāo)， ?管理項(xiàng)目風(fēng)險(xiǎn)， ?估算成本， ?確保用戶(hù)的安全， ?管理項(xiàng)目規(guī)模。 需求形式化與需求分配 在上面的這張表中定義的一個(gè)需求 ， 對(duì)應(yīng)需求數(shù)據(jù)庫(kù)的一個(gè) “ 數(shù)據(jù)項(xiàng) ” ， 我們稱(chēng)之為一個(gè) “ 需求項(xiàng) ” 。 根據(jù)對(duì)整個(gè)系統(tǒng)需求的分解 ， 我們可獲得一棵需求樹(shù)（ WBS樹(shù) ） 。 “ 根 ” 需求項(xiàng) ， 就是對(duì)整個(gè)系統(tǒng)的需求描述 。 需求項(xiàng)在需求 WBS架構(gòu)中 ， 處于節(jié)點(diǎn)的需求 ， 可以分配給一個(gè)部門(mén) 、 小組或個(gè)人 。 他們將根據(jù)人員 、 時(shí)間等 ， 再被分解為更細(xì)的需求項(xiàng) ， 直至不需求再進(jìn)行分解 。 處于 WBS“葉 ” 位置的那些需求項(xiàng) ， 是需求實(shí)現(xiàn)的最低層單位 ， 應(yīng)根據(jù)人員和任務(wù)周期計(jì)劃 ， 進(jìn)行工作分配 。 在項(xiàng)目管理中 ， 有了分層次的需求分解 ， 很快 ， 就可以建立根據(jù) “ 需求項(xiàng) ” 的任務(wù)分解和任務(wù)分配 ， 這就是需求分配 。 需求形式化與需求基線的建立 ?基線 ?在軟件工程環(huán)境中，基線是指在軟件開(kāi)發(fā)過(guò)程中的里程碑，這些里程碑的標(biāo)志是一項(xiàng)或多項(xiàng)經(jīng)過(guò)正式的技術(shù)評(píng)審并一致認(rèn)同的軟件制品的提交 。 ?項(xiàng)目開(kāi)發(fā)過(guò)程的制品經(jīng)過(guò)正式評(píng)審并被相關(guān)人員一致同意，可以作為以后項(xiàng)目開(kāi)發(fā)的基礎(chǔ)。對(duì)已經(jīng)基線化制品的修改必須要通過(guò)正式的變更控制流程。 ?不同的基線 ?A. 功能基線 (Functional Baseline) ?B. 已分配基線 (Allocated Baseline) ?C. 開(kāi)發(fā)基線 (Development Baseline) ?D. 產(chǎn)品基線 (Product Baseline) ?在用戶(hù)和項(xiàng)目組之間達(dá)成共識(shí)、并已經(jīng)按需求屬性建立需求數(shù)據(jù)庫(kù)的需求，是建立需求基線的基本條件。 需求基線的管理 ?配置管理組或委員會(huì) （ CCB） 按照需求基線 ， 對(duì)整個(gè)項(xiàng)目的進(jìn)程 ， 進(jìn)行控制和把握 ， 配置管理員負(fù)責(zé)把符合基線要求完成的構(gòu)件 ， 放進(jìn)配置管理庫(kù)中 。 這樣確保了整個(gè)需求的基線化控制和管理 。 ?需求基線的核心是按基線進(jìn)行控制 。 ?需求基線的條件是需求形式化 。 因?yàn)樾枨蠡€是按需求項(xiàng)進(jìn)行控制的 。 需求項(xiàng)是必須形式化的 。 ?需求的跟