【正文】 這樣能 在開始時勾勒出 工資子 系統(tǒng)的輪廓，了解系統(tǒng)的面貌，然后再集中在 各個小的部分 。 雖然應用方法和建模技術使我們能夠清楚地去了解軟件需求，但是，大部分的需求文檔和規(guī)格說明書都是以文本的形式記錄的，因此，如何去表達我們所了解的需求也是很值得注意的。 規(guī)格說明的特點：完整性，一致性，可修改性，可跟蹤性。 為了達到更細致的查詢 ，我們增加了數(shù)據(jù)實體以方便查詢，增加查詢速度。 工資子系統(tǒng)還需實現(xiàn)一些功能： ? 讀取勞資標準：勞資是對工資基準和算法的設定； ? 讀取調(diào)配情況： 船員的工資地點和狀況是很不固定的，隨時都可能變更； ? 更改船員信息：只進行小方面的 更改； 需求分析實踐 19 ? 讀取證培情況： 有用的證件當然能夠提高工資了； ? 讀取基本信息：船員遷移，辭職，晉升等等； 讀取勞資標準讀取船員基本信息 讀取培訓情況更改船員基本信息工資子系統(tǒng)讀取調(diào)配情況 圖 系統(tǒng)用例 操作人員對工資系統(tǒng)的操作都會得到的回應，可能的結(jié)果 （非全部） 有 ： ? 操作失誤 ? 信息有誤 ? 工資主文件被更 改 ? 查詢結(jié)果 ? 統(tǒng)計預算 ? 生成的 excel 文件或打印的圖表 ? 工資派送 ? 收到工資確認 ? 報銷確定 經(jīng)過以上的逐步分析， 對工資系統(tǒng)的問題域 信息框架 ，我們有了比較清楚的了解 。子系統(tǒng)主要 用于船員工資的查詢 更改 、計算聲稱、 發(fā)放 轉(zhuǎn)賬 、 報銷、 打印 以及公司 對船員工資 的設置、管理 、歷史查詢與統(tǒng)計。 下面就用戶抱怨作個簡單總結(jié)： 1. 外派和內(nèi)派 船員的 工資不容易分清，希望能分開計算。 需求調(diào)查階段分四個小組： 調(diào)配、工資、勞資、證培。 面向?qū)ο蠼０阉紤]的系統(tǒng)建模為一組相互通信的對象。DFD 的開發(fā)需要大量的專門知識，以消除建模中可能導致的二義性和錯誤。對新系統(tǒng)將投入使用的環(huán)境進行分析相當于研究該系統(tǒng)所必須滿足的要求。 需求工程主要關注的是前兩種原型，原型開發(fā) 隱含著迭代。 PDOA 豐富和完善了現(xiàn)今的“分析”方法，然而人們對它的了解和掌握還差一大段距離。 方法的對比 結(jié)構(gòu)化 分析及其相應的派生方法，曾一度風行了許多年頭。 OOA 的大致方法是 ? 標識出問題域中的對象類； ? 定義這些類的屬性和方法； ? 定義這些類的行為； ? 對這些類間的關系建模。在構(gòu)建一個新 軟件 系統(tǒng)之前，最好先決定它應當 能夠 做些什么 又不要做些什么 ；從問題域的研究入手，獲得問題的描述，以及新的解系統(tǒng)在其中將產(chǎn)生效果的陳述（即需求）；確定新系統(tǒng)所需的行為，以便讓它在問題域內(nèi)產(chǎn)生 所需要的效果。 。 4．需求有效性驗證 這 個活動檢查需求實現(xiàn)、一致和完備。對服務和約束的發(fā)現(xiàn)、分析、建立文檔 、驗證 活動現(xiàn)在常稱為需求工程。越來越多的產(chǎn)品把計算機和控制軟件以一定的方式結(jié)合起來。結(jié)果就是要得出結(jié)論，該系統(tǒng)是否值得進行更細致的分析。一致性意味著需求描述不能前后矛盾。在這個問題域內(nèi) ，問題可以確定為“讓電梯在建筑物中更有效使用的控制系 統(tǒng)”。 結(jié)構(gòu)化分 析所用的原型 ， 無論是對開發(fā)者還是客戶都顯得直觀易懂，若將初始重點放在對原有系統(tǒng)的建模是對實現(xiàn)理解問題域這一基本的分析目標的有力支持?；诓煌瑔栴}子域的本質(zhì)及存在于問題子域間的關系，可以把問題框架分類： ? 工件系統(tǒng) —— 系統(tǒng)必須完成針對只存在于系統(tǒng)中的這些對象的直接操作。 SA 和 OOA 還是有幾點相同特性的： ? 主要模型是結(jié)構(gòu)模型（關于模型，在下章有詳細介紹）。合算的開發(fā)原型需要相對強有力的開發(fā)平臺，好在現(xiàn)在已 經(jīng)沒有了技術障礙，原型開發(fā)得到了快速的采用?；舅枷胂喈敽唵?，通常系統(tǒng)功能性的詳細定義是按層次結(jié)構(gòu)來實現(xiàn)的，即通過把功能分解為若干低層的、更為詳細的功能集。 ? 同一個觸發(fā)器可能對多個狀態(tài)有效。識別有意義實體的好方法是問問：“哪些相關信息與這個實體相聯(lián)系？”。 考慮到合作公司的業(yè)務代表的計算機的水平較高，需求調(diào)查和需求說明書采需求分析實踐 16 用以業(yè)務代表為主， IT 人員協(xié)助的方式。 而工資本身又分為 在岸 工資、 在船工資、 職務工資、級別工資、工齡工資、 英語 津貼 、補扣、醫(yī)療保險、加班費、建房貸款、業(yè)績工資 等 。 ? 報銷處理：對各種報銷的紀錄 存盤、查詢和統(tǒng)計、預算等 。 簡單地就直接讓各小組進入到其所負責的部分。由于時間有限，不能參與系統(tǒng)的繼續(xù)開發(fā)階段，迭代就先到此為止。 ? 可以更準確估計后期的開發(fā)。 ? 了解客戶的語言，使用客戶的語言 。 衷心的謝謝大家，因為大家，論文才能得以順利如期完成。 ? 要向每一個參與需求的人員解釋各種建模技術和各種圖形代表的意義 ， 當然也包括客戶 在內(nèi)。 ? 有利于以后的維護工作。 圖 CRC 模型 需求分析實踐 24 勞 資歷史文件 工資主文件 主文件查詢 主文件更改 業(yè)績工資查詢 外派暫扣查詢 委托項查詢 加班費查詢 部門工資匯總 停發(fā)工資名單 業(yè)績工資發(fā)放 外派船工文件 委托文件 加班文件 工資發(fā)放方式 勞資歷史查詢 勞資歷史更改 動態(tài)歷史文件 動態(tài)歷史查詢 動態(tài)歷史更改 工資往來文件 個人往來帳查詢 往來帳存取 往來帳處理 憑證號更改 憑證號匯總 工資主文件 外派船工文件 外派 改船員審核 帳戶存款文件 存款清單 查詢 銀行帳 號查詢 欠帳帳戶余額 銀行代發(fā)編輯 工資主文件 工資主文件 強補強扣文件 強補強扣查詢 綜合補扣查詢 外語津貼查詢 動態(tài)補扣查詢 強補強扣更改 原因編輯 工資主文件 工資主文件 動態(tài)歷史文件 年度休假文件 休假查詢 動態(tài)歷史事假 動態(tài)歷史文件 勞資接口文件 工資標準查詢 接口文件查詢 接口文件修改 工資主文件 動態(tài)接口文件 接口文件查詢 接口數(shù)據(jù)更改 待派工資文件 待派工資查詢 工資往來文件 建房存款文件 建房借款查詢 建房借款 更改 房租更改 工資主文件 減員歷史文件 減員處理 減員錯誤修正 工資主文件 工資發(fā)放方式文件 方式代碼輸入 工資生成文件 勞資數(shù)據(jù)寫入 動態(tài)數(shù)據(jù)寫入 強補強扣生成 主工資生成 休假生成 寫入往來帳 工資匯總 數(shù)據(jù)傳送 勞資接口文件 動態(tài)接口文件 強補強扣文件 主工資文件 年休假文件 工資往來文件 發(fā)放方式文件 需求分析實踐 25 以上的 CRC 圖 是一種比較有效的分析方法，不僅能夠讓客戶更好的理解分析人員所認識的該工資子系統(tǒng)的需求，也使設計人員了解了將來系統(tǒng)可能要設計的一些類以及各個類之間的種種關系。注意一旦完成了 這個初期階段的工作，每個 需求小組仍然需要對它們所負責的部分進行詳細的建模。 功能需求 數(shù)據(jù)模型 功 能的請求 得到結(jié)果 工資子系統(tǒng) 需求分析實踐 18 ? 月度處理：統(tǒng)計某幾月或日的工資或船員情況。 船員 工資 業(yè)務目前主要存在如下特點： ? 政策復雜，在工作中容易出現(xiàn)對政策把握不準的情況，在執(zhí)行政策尺度方面不能完全規(guī)范統(tǒng)一； ? 船員數(shù)量多， 工作量大，因此漏報、錯報的情況時有發(fā)生； ? 情況復雜，工資的晉升原因、變動種類比較多，而且 各家公司 的政策也 不 盡相同 。 需要 用戶 去了解一點： 對于某些功能的討論并不意味著即將在 軟件 中實現(xiàn) 它。 （由于在做需求過程種，發(fā)現(xiàn)報銷與工資有很多相近之處，因此已經(jīng)合二為一） 進度 20xx 年 4 月 – 6 月，完成系統(tǒng)需求調(diào)查； 20xx 年 7 – 8 月中旬，在前期需求調(diào)查基礎上，拿出系統(tǒng)設計初步方案； 20xx 年 8 月中旬 – 8 月底，征求各家單位對初步方案的意見，修訂方案； 20xx 年 912 月，進入系統(tǒng)實質(zhì)開發(fā)階段，在此期間 還需反復征求各家單位意見。 實體屬性關系建模 ，則是數(shù)據(jù)庫應用系統(tǒng)的通用方法。 ? 一個轉(zhuǎn)移總是有一個相關的觸發(fā)器。聲明使用文本方式，描述輸入和輸出之間的因果關系。對軟件系統(tǒng)定義而言，它并不是全部的內(nèi)容，只是一個從中起著有效作用的基本元素。 OOA 不能對問題域有 個清楚的了解，因而它的起點若是有一份原需求文檔，便可大大簡化問題域的分析。一個子域可以是那些可方法論 8 能算是精選出來的問題域的任一部分。 如同結(jié)構(gòu)化編程一樣， 它致力于系統(tǒng)范圍內(nèi)的 事物 處理，數(shù)據(jù)流以及存儲數(shù)據(jù)結(jié)構(gòu)的建模。 問題域是需求分析員所要研究的首要對象。 理論上，系統(tǒng)的 功能需求描述應該既全面又具有一致性。從業(yè)務角度來決定系統(tǒng)開發(fā)是否劃算以及 在預算范圍內(nèi) 能否開發(fā)出來。 借助這次中遠船 員 信息管理