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