【正文】 船工文件 外派 改船員審核 帳戶存款文件 存款清單 查詢 銀行帳 號(hào)查詢 欠帳帳戶余額 銀行代發(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)識(shí)的該工資子系統(tǒng)的需求，也使設(shè)計(jì)人員了解了將來系統(tǒng)可能要設(shè)計(jì)的一些類以及各個(gè)類之間的種種關(guān)系。 船員工資主文件維護(hù) 船員勞資歷史維護(hù) 船員動(dòng)態(tài)歷史維護(hù) 委托項(xiàng)維護(hù)強(qiáng)補(bǔ)強(qiáng)扣信息維護(hù) 建房借款信息維護(hù)房租信息維護(hù)減員處理 ( 工資關(guān)系 )銀行代發(fā)信息維護(hù)　臨時(shí)扣補(bǔ)款項(xiàng)維護(hù)往來賬日常處理生成工資停發(fā)工資人員維護(hù)工資人員 常用用例 圖 編寫需求文檔 需求 文檔所擔(dān)當(dāng)?shù)幕韭氊?zé)就是把有關(guān)問題的 必要信息以及客戶的需求傳達(dá)給設(shè)計(jì)者。 規(guī)格說明任務(wù)定義為：創(chuàng)建并定義解系統(tǒng)的一種行為，使之在問題域中產(chǎn)生所需的效果。 ? 確保把正確信息準(zhǔn)確經(jīng)濟(jì)的傳達(dá)給實(shí)現(xiàn)者，減少交流錯(cuò)誤。 ? 有利于以后的維護(hù)工作。我們的目的在于分析軟件的需求， 通常情況是都用到了 所 介紹的三種方法。 隨著需求的做下去，我們?cè)絹碓角逦恼J(rèn)識(shí)了工資軟件系統(tǒng)的需求。 既要接受新東西，又要回顧所學(xué)過的，我們只有邊學(xué)邊用。 ? 要向每一個(gè)參與需求的人員解釋各種建模技術(shù)和各種圖形代表的意義 ， 當(dāng)然也包括客戶 在內(nèi)。 ? 保持樂觀態(tài)度。 ? 優(yōu)先采用面向問題域的方法分析 。在做需求的過程中，我用過很多工資管理系統(tǒng)，讀了很多使用手冊(cè)。 衷心的謝謝大家，因?yàn)榇蠹遥撐牟拍艿靡皂樌缙谕瓿伞?還要特別感謝指導(dǎo)老師林曉旻講師對(duì)實(shí)習(xí)工作和論文情況的關(guān)懷和指導(dǎo)。這樣做， 就不會(huì)感覺無從下手 ，選擇好切入點(diǎn)。 ? 要得到用戶的認(rèn)可和支持。 ? 了解客戶的語言，使用客戶的語言 。 一些技巧 以下 簡(jiǎn)單 列舉一些技巧能夠幫助需求建模，提高建模的效率： ? 軟件的需求收集和變更貫穿于整個(gè)項(xiàng)目中。 通過幾周的實(shí)習(xí)，發(fā)現(xiàn)要想學(xué)以致用真的很不簡(jiǎn)單 。接下來用面向結(jié)構(gòu)或面向?qū)ο蟮姆椒▽?duì)各個(gè)部分進(jìn)行逐步分析細(xì)化。 ? 可以更準(zhǔn)確估計(jì)后期的開發(fā)。 ? 為生成用戶手冊(cè)提供必要信息。 編寫需求文檔的一些理由： ? 使待求行為完全可見，這樣便于復(fù)審和意見統(tǒng)一， 從而最小化重復(fù)工作。當(dāng)然這并不是我們最終的軟件界面。由于時(shí)間有限，不能參與系統(tǒng)的繼續(xù)開發(fā)階段，迭代就先到此為止。每一張卡片被分為三個(gè)部分，分別是類的名稱，類的職責(zé)，以及該類的合作者。由于數(shù)據(jù)實(shí)體都將是以文件存儲(chǔ)，用文件名代替實(shí)體名更顯通俗易懂。因此， 公司 采用第二種方式進(jìn)行建模。 簡(jiǎn)單地就直接讓各小組進(jìn)入到其所負(fù)責(zé)的部分。 在這個(gè) 需求 迭代過程的開始階段有兩種方式進(jìn)行建模工作 ： 1. 集中所有 小組所得 需求在一起進(jìn)行建模。 工資業(yè)務(wù)領(lǐng)域要涉及的信息有幾大部分：船員基本信息，公司工資標(biāo)準(zhǔn)，往來帳處理，工資計(jì)算生成，月度處理，歷史核算統(tǒng)計(jì)。 當(dāng)然還會(huì)有其他實(shí)體，就目前來講，不是很重要 ，可以先不予考慮。 ? 報(bào)銷處理：對(duì)各種報(bào)銷的紀(jì)錄 存盤、查詢和統(tǒng)計(jì)、預(yù)算等 。 ? 工資主文件維護(hù)：必要時(shí)能夠更正文件數(shù)據(jù)。很顯然 的 這是一個(gè)信息系統(tǒng)， 使用面向問題域 分析 的方法， 可以畫出簡(jiǎn)單的問題框架，如圖所示 ，其中的工資子系統(tǒng)即為解系統(tǒng)。 很慶幸的是該軟件系統(tǒng)是為自家公司設(shè)計(jì)的，項(xiàng)目組和用戶只 在同一個(gè)地點(diǎn)，能就該系統(tǒng)應(yīng)該做什么達(dá)成比較一致的意見，這個(gè)階段只需要 一天的時(shí)間 ；否則的話，有可 能會(huì)延長(zhǎng)至幾天或數(shù)周 。 而工資本身又分為 在岸 工資、 在船工資、 職務(wù)工資、級(jí)別工資、工齡工資、 英語 津貼 、補(bǔ)扣、醫(yī)療保險(xiǎn)、加班費(fèi)、建房貸款、業(yè)績(jī)工資 等 。 6. 新增一些功能，業(yè)績(jī)工資、工資封存、報(bào)銷系統(tǒng)等。 2. 工資數(shù)據(jù)的 excel 表 希望 能 改為 由財(cái)務(wù)人員直接導(dǎo)入導(dǎo)出。 由于是老系統(tǒng)的升級(jí)，得到的更多的是“抱怨”。 考慮到合作公司的業(yè)務(wù)代表的計(jì)算機(jī)的水平較高，需求調(diào)查和需求說明書采需求分析實(shí)踐 16 用以業(yè)務(wù)代表為主， IT 人員協(xié)助的方式。為了方便清晰地進(jìn)行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。我所在的小組是工資（包含報(bào)銷）。 建模技術(shù) 14 表 常見應(yīng)用領(lǐng)域表 上下文圖 問題框架 一次性原型 功能分解 用例 任務(wù)動(dòng)作法 F S M D F D 結(jié)構(gòu)圖 E R D E L H 面向?qū)ο? D D (B N F) 需求獲取 √ √ 問題域（ PD）概述 √ √ 問題域結(jié)構(gòu) √ √ √ PD 數(shù)據(jù)模型 √ √ √ I/O 問題數(shù)據(jù) √ √ 子域行為 √ 子域狀態(tài) √ √ 功能需求 √ 性能需求 √ 約束 SS 外觀 √ I/O 解數(shù)據(jù) √ SS 行為（ ER 動(dòng)作） √ √ √ √ √ SS 狀態(tài) √ √ 定時(shí) √ √ 需求分析實(shí)踐 15 第四章 需求分析實(shí)踐 項(xiàng)目介紹 在現(xiàn)有《中遠(yuǎn)船員綜合管理信息系統(tǒng)》操作平臺(tái)的基礎(chǔ)上， 用不到一年的時(shí)間，設(shè)計(jì)開發(fā)中遠(yuǎn)通用、技術(shù)先進(jìn)、功能全面、人性化與智能化突出的“中遠(yuǎn)船員信息系統(tǒng)”（以下簡(jiǎn)稱 CSIS），同時(shí)建立起以集團(tuán)為核心的，聯(lián)結(jié)各家系統(tǒng)的中遠(yuǎn)船員信息管理網(wǎng)絡(luò)，在中遠(yuǎn)系統(tǒng)內(nèi)實(shí)現(xiàn)船員信息的高度共享。一個(gè)對(duì)象是存儲(chǔ)數(shù)據(jù)和對(duì)其數(shù)據(jù)上的操作進(jìn)行抽象。 主要的兩種模型是實(shí)體生命歷史（ ELH） 和面向?qū)ο蠼！ＷR(shí)別有意義實(shí)體的好方法是問問：“哪些相關(guān)信息與這個(gè)實(shí)體相聯(lián)系？”。 對(duì)通信順序處理建模的常用表示法有樹狀圖或結(jié)構(gòu)圖，另一種主要方法是偽碼。好的 DFD 后面的解釋是較為直觀的，因而可理解性是比較良好的。 1. 面向處理技術(shù) 抽象的把所考慮的系統(tǒng)建模成一組通信子系統(tǒng)，重點(diǎn)放在它們實(shí)施的處理上。 ? 同一個(gè)觸發(fā)器可能對(duì)多個(gè)狀態(tài)有效。 4. 有限狀態(tài)機(jī) 有限狀態(tài)機(jī)（ Finite State Machines， FSM）通過輸入與輸出之間的因果關(guān)系對(duì)系統(tǒng)的行為進(jìn)行建模。事實(shí)上，情形可能是客戶和潛在用戶確實(shí)發(fā)現(xiàn)用例易于理解，因此，用例就有助于客戶 /用戶與開發(fā)建模技術(shù) 12 者之間的交流。任務(wù)是獲得這些目標(biāo)的高級(jí)機(jī)制 ，操作是實(shí)現(xiàn)任務(wù)的交互?；舅枷胂喈?dāng)簡(jiǎn)單，通常系統(tǒng)功能性的詳細(xì)定義是按層次結(jié)構(gòu)來實(shí)現(xiàn)的，即通過把功能分解為若干低層的、更為詳細(xì)的功能集。 行為（功能）建模 行為模型只是系統(tǒng)行為的抽象。如在需求獲取中：初始原型將向用戶演示，獲得的反饋將用于細(xì)化原型，在實(shí)踐中這種迭代會(huì)出現(xiàn)好幾次。 建模技術(shù) 11 結(jié)構(gòu)原型 —— 用于評(píng)價(jià)可能的內(nèi)部設(shè)計(jì)方案，例如檢查性能。合算的開發(fā)原型需要相對(duì)強(qiáng)有力的開發(fā)平臺(tái)，好在現(xiàn)在已 經(jīng)沒有了技術(shù)障礙，原型開發(fā)得到了快速的采用。 表示建模 表示模型是對(duì)系統(tǒng)外觀進(jìn)行的模仿，相當(dāng)于描述可見的輸出，最有效的表示法通常是畫圖。 因地制宜的應(yīng)用三種方法，不僅能夠如實(shí)的認(rèn)識(shí)問題域，創(chuàng)建出健全的解系統(tǒng)，還能夠向用戶和設(shè)計(jì)人員都提供滿意的需求文檔。 面向問題域分析被認(rèn)為是一種較為理想的方法。 SA 和 OOA 還是有幾點(diǎn)相同特性的： ? 主要模型是結(jié)構(gòu)模型（關(guān)于模型，在下章有詳細(xì)介紹）。 OOA 要求所有的系統(tǒng)均可以按照對(duì)象的特點(diǎn)來建模。它最初的版本主要是圍繞對(duì)數(shù)據(jù)流以及問題域的數(shù)據(jù)結(jié)構(gòu)進(jìn)行建模，而現(xiàn)代的 SA 則直接將重點(diǎn)放在開發(fā)解系統(tǒng)的模型。