【正文】 在面向?qū)ο箢I(lǐng)域主要作為一種分析和規(guī)格說(shuō)明的技術(shù)。 ? 一個(gè)轉(zhuǎn)移總是有一個(gè)相關(guān)的觸發(fā)器。最常采用的方法是“數(shù)據(jù)流圖”，即 DFD。 實(shí)體屬性關(guān)系建模 ，則是數(shù)據(jù)庫(kù)應(yīng)用系統(tǒng)的通用方法。 ELH 的作用是在其他模型 之間充當(dāng)一個(gè)交叉的檢查和一種集成。 （由于在做需求過(guò)程種，發(fā)現(xiàn)報(bào)銷(xiā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 月底，征求各家單位對(duì)初步方案的意見(jiàn)，修訂方案； 20xx 年 912 月，進(jìn)入系統(tǒng)實(shí)質(zhì)開(kāi)發(fā)階段，在此期間 還需反復(fù)征求各家單位意見(jiàn)。 需要 用戶 去了解一點(diǎn)： 對(duì)于某些功能的討論并不意味著即將在 軟件 中實(shí)現(xiàn) 它。 幾天的會(huì)議、老文檔的閱讀、相似系統(tǒng)的試用，也還是瞞有收獲的。 船員 工資 業(yè)務(wù)目前主要存在如下特點(diǎn)： ? 政策復(fù)雜，在工作中容易出現(xiàn)對(duì)政策把握不準(zhǔn)的情況，在執(zhí)行政策尺度方面不能完全規(guī)范統(tǒng)一； ? 船員數(shù)量多， 工作量大，因此漏報(bào)、錯(cuò)報(bào)的情況時(shí)有發(fā)生； ? 情況復(fù)雜，工資的晉升原因、變動(dòng)種類(lèi)比較多，而且 各家公司 的政策也 不 盡相同 。它不僅只是工資，還包括津貼，加班費(fèi)，建房貸款，醫(yī)療保險(xiǎn)，等等。 功能需求 數(shù)據(jù)模型 功 能的請(qǐng)求 得到結(jié)果 工資子系統(tǒng) 需求分析實(shí)踐 18 ? 月度處理：統(tǒng)計(jì)某幾月或日的工資或船員情況。盡管這方面比較隱蔽，還是要粗略羅列一下。注意一旦完成了 這個(gè)初期階段的工作，每個(gè) 需求小組仍然需要對(duì)它們所負(fù)責(zé)的部分進(jìn)行詳細(xì)的建模。 除了工資明細(xì)表、匯總表以外，系統(tǒng)還提供變動(dòng)分析表、所得稅表等十多種統(tǒng)計(jì)報(bào)表，且報(bào)表的查詢可動(dòng)態(tài)調(diào)整語(yǔ)種、 幣種和顯示順序。 圖 CRC 模型 需求分析實(shí)踐 24 勞 資歷史文件 工資主文件 主文件查詢 主文件更改 業(yè)績(jī)工資查詢 外派暫扣查詢 委托項(xiàng)查詢 加班費(fèi)查詢 部門(mén)工資匯總 停發(fā)工資名單 業(yè)績(jī)工資發(fā)放 外派船工文件 委托文件 加班文件 工資發(fā)放方式 勞資歷史查詢 勞資歷史更改 動(dòng)態(tài)歷史文件 動(dòng)態(tài)歷史查詢 動(dòng)態(tài)歷史更改 工資往來(lái)文件 個(gè)人往來(lái)帳查詢 往來(lái)帳存取 往來(lái)帳處理 憑證號(hào)更改 憑證號(hào)匯總 工資主文件 外派船工文件 外派 改船員審核 帳戶存款文件 存款清單 查詢 銀行帳 號(hào)查詢 欠帳帳戶余額 銀行代發(fā)編輯 工資主文件 工資主文件 強(qiáng)補(bǔ)強(qiáng)扣文件 強(qiáng)補(bǔ)強(qiáng)扣查詢 綜合補(bǔ)扣查詢 外語(yǔ)津貼查詢 動(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ù)更改 待派工資文件 待派工資查詢 工資往來(lái)文件 建房存款文件 建房借款查詢 建房借款 更改 房租更改 工資主文件 減員歷史文件 減員處理 減員錯(cuò)誤修正 工資主文件 工資發(fā)放方式文件 方式代碼輸入 工資生成文件 勞資數(shù)據(jù)寫(xiě)入 動(dòng)態(tài)數(shù)據(jù)寫(xiě)入 強(qiáng)補(bǔ)強(qiáng)扣生成 主工資生成 休假生成 寫(xiě)入往來(lái)帳 工資匯總 數(shù)據(jù)傳送 勞資接口文件 動(dòng)態(tài)接口文件 強(qiáng)補(bǔ)強(qiáng)扣文件 主工資文件 年休假文件 工資往來(lái)文件 發(fā)放方式文件 需求分析實(shí)踐 25 以上的 CRC 圖 是一種比較有效的分析方法，不僅能夠讓客戶更好的理解分析人員所認(rèn)識(shí)的該工資子系統(tǒng)的需求，也使設(shè)計(jì)人員了解了將來(lái)系統(tǒng)可能要設(shè)計(jì)的一些類(lèi)以及各個(gè)類(lèi)之間的種種關(guān)系。 規(guī)格說(shuō)明任務(wù)定義為：創(chuàng)建并定義解系統(tǒng)的一種行為，使之在問(wèn)題域中產(chǎn)生所需的效果。 ? 有利于以后的維護(hù)工作。 隨著需求的做下去，我們?cè)絹?lái)越清晰的認(rèn)識(shí)了工資軟件系統(tǒng)的需求。 ? 要向每一個(gè)參與需求的人員解釋各種建模技術(shù)和各種圖形代表的意義 ， 當(dāng)然也包括客戶 在內(nèi)。 ? 優(yōu)先采用面向問(wèn)題域的方法分析 。 衷心的謝謝大家，因?yàn)榇蠹?，論文才能得以順利如期完成。這樣做， 就不會(huì)感覺(jué)無(wú)從下手 ，選擇好切入點(diǎn)。 ? 了解客戶的語(yǔ)言，使用客戶的語(yǔ)言 。 通過(guò)幾周的實(shí)習(xí)，發(fā)現(xiàn)要想學(xué)以致用真的很不簡(jiǎn)單 。 ? 可以更準(zhǔn)確估計(jì)后期的開(kāi)發(fā)。 編寫(xiě)需求文檔的一些理由： ? 使待求行為完全可見(jiàn)，這樣便于復(fù)審和意見(jiàn)統(tǒng)一， 從而最小化重復(fù)工作。由于時(shí)間有限，不能參與系統(tǒng)的繼續(xù)開(kāi)發(fā)階段，迭代就先到此為止。由于數(shù)據(jù)實(shí)體都將是以文件存儲(chǔ)，用文件名代替實(shí)體名更顯通俗易懂。 簡(jiǎn)單地就直接讓各小組進(jìn)入到其所負(fù)責(zé)的部分。 工資業(yè)務(wù)領(lǐng)域要涉及的信息有幾大部分：船員基本信息，公司工資標(biāo)準(zhǔn)，往來(lái)帳處理，工資計(jì)算生成，月度處理，歷史核算統(tǒng)計(jì)。 ? 報(bào)銷(xiāo)處理：對(duì)各種報(bào)銷(xiāo)的紀(jì)錄 存盤(pán)、查詢和統(tǒng)計(jì)、預(yù)算等 。很顯然 的 這是一個(gè)信息系統(tǒng)， 使用面向問(wèn)題域 分析 的方法， 可以畫(huà)出簡(jiǎn)單的問(wèn)題框架，如圖所示 ，其中的工資子系統(tǒng)即為解系統(tǒng)。 而工資本身又分為 在岸 工資、 在船工資、 職務(wù)工資、級(jí)別工資、工齡工資、 英語(yǔ) 津貼 、補(bǔ)扣、醫(yī)療保險(xiǎn)、加班費(fèi)、建房貸款、業(yè)績(jī)工資 等 。 2. 工資數(shù)據(jù)的 excel 表 希望 能 改為 由財(cái)務(wù)人員直接導(dǎo)入導(dǎo)出。 考慮到合作公司的業(yè)務(wù)代表的計(jì)算機(jī)的水平較高，需求調(diào)查和需求說(shuō)明書(shū)采需求分析實(shí)踐 16 用以業(yè)務(wù)代表為主， IT 人員協(xié)助的方式。我所在的小組是工資（包含報(bào)銷(xiāo)）。一個(gè)對(duì)象是存儲(chǔ)數(shù)據(jù)和對(duì)其數(shù)據(jù)上的操作進(jìn)行抽象。識(shí)別有意義實(shí)體的好方法是問(wèn)問(wèn)：“哪些相關(guān)信息與這個(gè)實(shí)體相聯(lián)系？”。好的 DFD 后面的解釋是較為直觀的，因而可理解性是比較良好的。 ? 同一個(gè)觸發(fā)器可能對(duì)多個(gè)狀態(tài)有效。事實(shí)上，情形可能是客戶和潛在用戶確實(shí)發(fā)現(xiàn)用例易于理解，因此，用例就有助于客戶 /用戶與開(kāi)發(fā)建模技術(shù) 12 者之間的交流?；舅枷胂喈?dāng)簡(jiǎn)單，通常系統(tǒng)功能性的詳細(xì)定義是按層次結(jié)構(gòu)來(lái)實(shí)現(xiàn)的，即通過(guò)把功能分解為若干低層的、更為詳細(xì)的功能集。如在需求獲取中：初始原型將向用戶演示，獲得的反饋將用于細(xì)化原型，在實(shí)踐中這種迭代會(huì)出現(xiàn)好幾次。合算的開(kāi)發(fā)原型需要相對(duì)強(qiáng)有力的開(kāi)發(fā)平臺(tái)，好在現(xiàn)在已 經(jīng)沒(méi)有了技術(shù)障礙，原型開(kāi)發(fā)得到了快速的采用。 因地制宜的應(yīng)用三種方法，不僅能夠如實(shí)的認(rèn)識(shí)問(wèn)題域，創(chuàng)建出健全的解系統(tǒng)，還能夠向用戶和設(shè)計(jì)人員都提供滿意的需求文檔。 SA 和 OOA 還是有幾點(diǎn)相同特性的： ? 主要模型是結(jié)構(gòu)模型（關(guān)于模型，在下章有詳細(xì)介紹）。它最初的版本主要是圍繞對(duì)數(shù)據(jù)流以及問(wèn)題域的數(shù)據(jù)結(jié)構(gòu)進(jìn)行建模，而現(xiàn)代的 SA 則直接將重點(diǎn)放在開(kāi)發(fā)解系統(tǒng)的模型?；诓煌瑔?wèn)題子域的本質(zhì)及存在于問(wèn)題子域間的關(guān)系，可以把問(wèn)題框架分類(lèi)： ? 工件系統(tǒng) —— 系統(tǒng)必須完成針對(duì)只存在于系統(tǒng)中的這些對(duì)象的直接操作。 面向問(wèn)題域分析 （ PDOA） 面向問(wèn)題域分析 面向問(wèn)題域的分析 （ PDOA） 是一種新技術(shù) 。 結(jié)構(gòu)化分 析所用的原型 ， 無(wú)論是對(duì)開(kāi)發(fā)者還是客戶都顯得直觀易懂，若將初始重點(diǎn)放在對(duì)原有系統(tǒng)的建模是對(duì)實(shí)現(xiàn)理解問(wèn)題域這一基本的分析目標(biāo)的有力支持。 需求分析 通過(guò)對(duì)問(wèn)題 域 的研究，獲得對(duì)該領(lǐng)域特性及存在于其中（需要解決）的問(wèn)題特性的透徹理解并用文檔說(shuō)明。在這個(gè)問(wèn)題域內(nèi) ，問(wèn)題可以確定為“讓電梯在建筑物中更有效使用的控制系 統(tǒng)”。 。一致性意味著需求描述不能前后矛盾。在這個(gè)過(guò)程中，不分析問(wèn)題 定義系統(tǒng) 理解涉眾需求 改進(jìn)系統(tǒng)定義 管理需求變更 管理系統(tǒng)規(guī)模 新的輸入 新系統(tǒng) 現(xiàn)有系統(tǒng) 錯(cuò)誤問(wèn)題 正確問(wèn)題 無(wú)法完成 范圍之內(nèi) 更多迭代 完成需求 緒論 3 難發(fā)現(xiàn)需求文檔中的錯(cuò)誤，然后必須加以改正。結(jié)果就是要得出結(jié)論，該系統(tǒng)是否值得進(jìn)行更細(xì)致的分析。 需求工程對(duì)于軟件過(guò)程是一個(gè)特別關(guān)鍵的階段，這個(gè)階段的錯(cuò)誤將不可避免地帶到后續(xù)的系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)階段中。越來(lái)越多的產(chǎn)品把計(jì)算機(jī)和控制軟件以一定的方式結(jié)合起來(lái)。 關(guān)鍵字： 分析，領(lǐng)域， 方法學(xué)， 建模技術(shù)， 需求 ABSTRACT Abstract The requirement analysis took the software engineering the start, has the suitable difficulty to grasp it. In order to understanding software requirement better, people have developed many methods and the