【正文】 過程中運用了解的方法、掌握的建模技術(shù)，不僅能夠 有效 的分析軟件需求，還能加深知識。 所有的軟件 工 程都具有以下基本活動： 1．軟件描述 軟件的功能以及軟件操作上的約束必須定義。 其中，軟件描述，目標(biāo)是確定 軟件 系統(tǒng)需要哪些服務(wù)以及開發(fā)和運行期間受到哪些約束。后續(xù)階段可以建立在前期所做工作基礎(chǔ)上（各種相關(guān)模型至少在一定程度上可 以衍生導(dǎo)出），而需求工程階段的成果卻是靠創(chuàng)建而來的 ——— 幾乎就是從無到有。從業(yè)務(wù)角度來決定系統(tǒng)開發(fā)是否劃算以及 在預(yù)算范圍內(nèi) 能否開發(fā)出來。也可能需要開發(fā)一個或多個不同的系統(tǒng)模型和原型。用戶需求是從客戶和最終用戶對系統(tǒng)需求的抽象描述；系統(tǒng)需求是對系統(tǒng)要提供的功能的詳盡描述。在定義和描述期間，需求分析繼續(xù)進(jìn)行，這樣在整個需求工程過程中不斷有新的需求出現(xiàn)。 理論上，系統(tǒng)的 功能需求描述應(yīng)該既全面又具有一致性。一方面是因為系統(tǒng)固有的復(fù)雜性，另一方面是因為觀點不同，需求也會發(fā)生矛盾。主要有的類型如 圖 非功能需求的類型 . 機構(gòu)需求 可用性 效率 可靠性 移植性 交付 實現(xiàn) 標(biāo)準(zhǔn) 互操作 道德 法律 。他們也可能是功能需求或非功能需求。 問題域是需求分析員所要研究的首要對象。 圖 問題域與 解系統(tǒng)的相互關(guān)系 上圖中也定義了三個主要 軟件 開發(fā)活動的 階段 任務(wù)。 到現(xiàn)在為止，我們得到初步論點。 對于這一重要任務(wù)其特性如下： 分析關(guān)注問題域及 對 其建 立的模型， 而不是解系統(tǒng)； 主要目標(biāo)是要獲得對問題域及存在于其中的問題本質(zhì)的理解； 分析在本質(zhì)上先于解系統(tǒng)行為的規(guī)格說明（盡管有重疊和反復(fù)的過程）。 如同結(jié)構(gòu)化編程一樣， 它致力于系統(tǒng)范圍內(nèi)的 事物 處理，數(shù)據(jù)流以及存儲數(shù)據(jù)結(jié)構(gòu)的建模。利用結(jié)構(gòu)化分析很容易去理解一個剛剛接觸的問題域，適合對比較生疏領(lǐng)域做軟件需求。 OOA 的真正本質(zhì)意義是作為解系統(tǒng)的高層體系結(jié)構(gòu)的設(shè)計，并且有利于系統(tǒng)的下一步開發(fā)設(shè)計 （如果是 OOD 開發(fā)的話） 。描述大致劃分為兩個部分：一部分關(guān)注于問題域，而另一部分關(guān)注于解系統(tǒng)的待求行為。一個子域可以是那些可方法論 8 能算是精選出來的問題域的任一部分。 ? 信息系統(tǒng) —— 系統(tǒng)將提供有關(guān)的問題域的信 息，包括，信息是自動提供的，和，信息只在響應(yīng)具體的請求時提供。 問題域的描述與必須滿足的需求二者之間有著明顯的區(qū)別，對新的解 系統(tǒng)的行為創(chuàng)建與定義應(yīng)單獨處理并且推遲到下一步的規(guī)格說明階段。然而，它對其他方面的支持卻不夠完善，在處理一些其他類型問題時顯得有些笨拙。 OOA 不能對問題域有 個清楚的了解，因而它的起點若是有一份原需求文檔，便可大大簡化問題域的分析。 ? 兩中方法都較少地應(yīng)用于需求獲取領(lǐng)域。 并且它將規(guī)格說明 作為另行的任務(wù)處理，它的成果只是一份問題域的全面描述和一份需求列表而已。相關(guān)建模技術(shù)之間的最重要區(qū)別在于他們是構(gòu)成系統(tǒng)的外部模型還是構(gòu)成系統(tǒng)的內(nèi)部模型。對軟件系統(tǒng)定義而言，它并不是全部的內(nèi)容，只是一個從中起著有效作用的基本元素。 對原型一個普遍認(rèn)同的分類： 探索性原型 —— 幫助需求獲取或細(xì)化需求，也稱為一次性原型，一旦需求工程完成后，它便沒有用處。 演化原型 —— 通過逐步求精過程，原型最終成為了產(chǎn)品。 原型在需求工程中主要作用是對用戶接口進(jìn)行建模，尤其是當(dāng)這些接口相當(dāng)復(fù)雜、關(guān)鍵、新鮮時。聲明使用文本方式，描述輸入和輸出之間的因果關(guān)系。 2. 任務(wù)分析 任務(wù)分析，涉及的是人的任務(wù)性能的分析或外部設(shè)計，特別用于人機接口（ HMI）。 用例在面向?qū)ο箢I(lǐng)域主要作為一種分析和規(guī)格說明的技術(shù)。用例文檔可以用文本或 UML 圖來描述。 ? 一個轉(zhuǎn)移總是有一個相關(guān)的觸發(fā)器。可以很簡單的 把 解 系統(tǒng)的內(nèi)部分成兩方面：數(shù)據(jù)和操作。最常采用的方法是“數(shù)據(jù)流圖”，即 DFD。 (2) 通信順序處理 雖然真實事物一般都是 一個 并行的系統(tǒng)， 就 如 同 一個人可 以同時做很多事情一樣。 實體屬性關(guān)系建模 ，則是數(shù)據(jù)庫應(yīng)用系統(tǒng)的通用方法。實體間的關(guān)系有三種：一對一，一對多，多對多。 ELH 的作用是在其他模型 之間充當(dāng)一個交叉的檢查和一種集成。還必須探討對象間的關(guān)系。 （由于在做需求過程種，發(fā)現(xiàn)報銷與工資有很多相近之處，因此已經(jīng)合二為一） 進(jìn)度 20xx 年 4 月 – 6 月，完成系統(tǒng)需求調(diào)查； 20xx 年 7 – 8 月中旬，在前期需求調(diào)查基礎(chǔ)上，拿出系統(tǒng)設(shè)計初步方案； 20xx 年 8 月中旬 – 8 月底，征求各家單位對初步方案的意見，修訂方案； 20xx 年 912 月，進(jìn)入系統(tǒng)實質(zhì)開發(fā)階段，在此期間 還需反復(fù)征求各家單位意見。需求獲取只有通過有效的客戶 —— 開發(fā)者的合作才能成 功。 需要 用戶 去了解一點： 對于某些功能的討論并不意味著即將在 軟件 中實現(xiàn) 它。然后，業(yè)務(wù)代表梳理本業(yè)務(wù)領(lǐng)域的業(yè)務(wù)需求，先粗后細(xì)寫出需求說明書，交由 IT 人員整理，雙方多次溝通反復(fù)，形成需求說明書初稿，交項目工作小組評審。 幾天的會議、老文檔的閱讀、相似系統(tǒng)的試用，也還是瞞有收獲的。 4. 更正一些不合時宜的設(shè)定，如船員憑證號改為 6 位、銀行帳號 19 位。 船員 工資 業(yè)務(wù)目前主要存在如下特點： ? 政策復(fù)雜，在工作中容易出現(xiàn)對政策把握不準(zhǔn)的情況，在執(zhí)行政策尺度方面不能完全規(guī)范統(tǒng)一； ? 船員數(shù)量多， 工作量大，因此漏報、錯報的情況時有發(fā)生； ? 情況復(fù)雜，工資的晉升原因、變動種類比較多，而且 各家公司 的政策也 不 盡相同 。 ? 船員分布廣泛，工資發(fā)放難免有不及時或不到位的地方。它不僅只是工資，還包括津貼，加班費，建房貸款，醫(yī)療保險，等等。為了更進(jìn)一步的深入 ，我們需要多種模型 對各個模塊 進(jìn)行補充。 功能需求 數(shù)據(jù)模型 功 能的請求 得到結(jié)果 工資子系統(tǒng) 需求分析實踐 18 ? 月度處理：統(tǒng)計某幾月或日的工資或船員情況。 圖 操作人員 usecase 往來帳處理月度處理工資生成報表核算報銷處理工資文件查詢財務(wù)人員工資文件維護(hù) 要開發(fā)的是一個數(shù)據(jù)庫 應(yīng)用 系統(tǒng)， 數(shù)據(jù)模型 以實體屬性模型來表示最為合適的里。盡管這方面比較隱蔽，還是要粗略羅列一下。 1． 對單個船員的操作 （ 狀態(tài) 活動 圖 ） 圖 業(yè)務(wù)流程圖一 需求分析實踐 20 輸入工號或姓名錯誤或不存在查詢各種信息更改信息打印結(jié)果繼續(xù)？等待狀態(tài) 2． 對所有船員的操作 （有限狀態(tài)圖） 圖 業(yè)務(wù)流程圖二 費用 報銷 待機 狀態(tài) 打印 報表 工資 生成 分類統(tǒng) 計查詢 外部數(shù) 據(jù)寫入 更新工 資標(biāo)準(zhǔn) 確定 操作 返回報銷信息 發(fā)放 方式 轉(zhuǎn)入 銀 行帳戶 郵寄 工資 到公司 領(lǐng)取 需求分析實踐 21 詳細(xì)需求建模階段 現(xiàn)在工資子 系統(tǒng)的范圍和高層需求得到 客戶 認(rèn)同，基于前一階段的成果， 可以開始為開發(fā)工作制定進(jìn)度，將這些需求帶進(jìn)一個迭代過程。注意一旦完成了 這個初期階段的工作，每個 需求小組仍然需要對它們所負(fù)責(zé)的部分進(jìn)行詳細(xì)的建模。它的優(yōu)點就是能夠使得項目組在迭代過程開始的第一天就進(jìn)入詳細(xì)分析建模。 除了工資明細(xì)表、匯總表以外，系統(tǒng)還提供變動分析表、所得稅表等十多種統(tǒng)計報表，且報表的查詢可動態(tài)調(diào)整語種、 幣種和顯示順序。 查詢功能： 查詢主文件往來帳戶統(tǒng)計補扣個人勞資動態(tài)歷史接口歷史接口標(biāo)準(zhǔn)建房余額帳號 代發(fā)津貼加班業(yè)績 綜合 工資生成： 工資生成備份 恢復(fù)勞資補扣 動態(tài)補扣津貼強補強扣加班費獎金業(yè)績工資計算 往來處理 需求分析實踐 23 往來帳處理： 往來帳處理往來帳存取款憑證號修改日報打印月報打印按憑證號匯總 往來處理類圖 工資維護(hù)： 維護(hù) 主文件委托項個人勞資動態(tài)歷史歷史建房房租借款還清補扣強補強扣臨時減員停發(fā)代發(fā)獎金 工資維護(hù)類圖 CRC + Use case 的 OOA 模型。 圖 CRC 模型 需求分析實踐 24 勞 資歷史文件 工資主文件 主文件查詢 主文件更改 業(yè)績工資查詢 外派暫扣查詢 委托項查詢 加班費查詢 部門工資匯總 停發(fā)工資名單 業(yè)績工資發(fā)放 外派船工文件 委托文件 加班文件 工資發(fā)放方式 勞資歷史查詢 勞資歷史更改 動態(tài)歷史文件 動態(tài)歷史查詢 動態(tài)歷史更改 工資往來文件 個人往來帳查詢 往來帳存取 往來帳處理 憑證號更改 憑證號匯總 工資主文件 外派