【正文】 聯(lián)的子域。 問(wèn)題框架法在應(yīng)用時(shí)，建議采用直截了當(dāng)?shù)牟呗裕? ? 抽象問(wèn)題域： 1. 標(biāo)識(shí)子域 2. 標(biāo)識(shí)子域間的交互 3. 刻畫每個(gè)子域的特征 4. 生成一個(gè)上下文圖 ? 識(shí)別出相關(guān)的標(biāo)準(zhǔn)框架 ? 調(diào)整框架，盡可能使之適用 于問(wèn)題 ? 使用關(guān)于相關(guān)框架的內(nèi)容技術(shù)表來(lái)指導(dǎo)進(jìn)一步的分析與文檔編制任務(wù)。它也繼承了很多結(jié)構(gòu)化分析的思想體系。 PDOA 特點(diǎn)是重新將重點(diǎn)定位在問(wèn)題域及需求上，通過(guò)對(duì)問(wèn)題域的分類，向分析人員提供具體問(wèn)題的相關(guān)指南。這種技術(shù)特有的優(yōu)點(diǎn)是易于獲得工具支持、模糊性低、不易出錯(cuò)和可理解性高。雖然是用于設(shè)計(jì)階段，但也用于需求階段可行性的檢查。 行為建模有很多種，我們就較一般的可能用到的簡(jiǎn)單介紹幾 個(gè) ： 1. 功能聲明與分解 功能聲明也許是最簡(jiǎn)單、常用的行為定義技術(shù)。 3. 用例與腳本 用例（ usecase）描述所設(shè)計(jì)的解系統(tǒng)與一個(gè)或多個(gè)端子之間的某種特定的交互。 (1) 系統(tǒng)可看作有若干個(gè)相互區(qū)別的穩(wěn)定狀態(tài)； (2) 當(dāng)條件改變時(shí)，系統(tǒng)從一個(gè)狀態(tài)改變到另一個(gè)狀態(tài)； FSM 的設(shè)計(jì)規(guī)則 ? 轉(zhuǎn)移總是起始于一個(gè)狀態(tài)并終止于一個(gè)狀態(tài)。 (1) 通信并發(fā)處理 這個(gè)模型把子系統(tǒng)看成是并行運(yùn)行的，現(xiàn)實(shí)世界中的各種事物也是通常是如此的，因此 它 具有相當(dāng)?shù)闹庇^性。 2. 面向數(shù)據(jù)結(jié)構(gòu)的技術(shù) 數(shù)據(jù)結(jié)構(gòu)建模是 所有 信息系統(tǒng)最重要的 技術(shù) ， 也 常稱為數(shù)據(jù)分析，關(guān)注的是靜態(tài)數(shù)據(jù)的結(jié)構(gòu)。 實(shí)體生命歷史建模起的是輔助性的作用，它從數(shù)據(jù)分析和數(shù)據(jù)流建模繼續(xù)而來(lái)，實(shí)體來(lái)自于 ERD，實(shí)體處理來(lái)自 DFD，然后為每個(gè)實(shí)體的有關(guān)處理順序進(jìn)行建模。 按照系統(tǒng)功能劃 分，工作小組下設(shè) 7 個(gè)業(yè)務(wù)組，分別為調(diào)配管理組、證件培訓(xùn)組、勞動(dòng)工資組、工資核算組、費(fèi)用報(bào)銷組、集團(tuán)平臺(tái)組、船員平臺(tái)組。對(duì)需求問(wèn)題的全面考察需要一種技術(shù)，利用這種技術(shù)不但考慮了問(wèn)題的功能需求方面，還可討論項(xiàng)目的非功能需求。 盡管如此還是 要盡可能的去了解工資的業(yè)務(wù)領(lǐng)域，因?yàn)樵诖沃皩?duì)這東西真的一無(wú)所知。 7. 完善查詢種類和方式。 工資子系統(tǒng) 是遠(yuǎn)洋公司財(cái)務(wù)科的應(yīng)用辦公系統(tǒng)。 ? 往來(lái)帳處理：查詢或設(shè)置工資發(fā)放的情況或方式。 從總體架構(gòu)來(lái)看，工資系統(tǒng)還 涉及 到與其他子系統(tǒng)的關(guān)聯(lián) 。 采用這種方法，整個(gè)項(xiàng)目組以及 參與的客戶 會(huì)在一起探討詳細(xì)的需求，分析這些需求，對(duì)已有的系統(tǒng)設(shè)計(jì)提出修改建議以支持這些需求。 這樣也有利于充分利用資源，免得出現(xiàn)人手富余的情 況。類是一類相似對(duì)象的抽象，職責(zé)是該類所知道的或要去做的，合作者是另外一個(gè)與該類有交互的類。 用戶界面合影 規(guī)格說(shuō)明可認(rèn)為是把需求轉(zhuǎn)換成行為。 ? 消除軟件產(chǎn)品交付后的爭(zhēng)論。 在逐步分析過(guò)程運(yùn)用各種建模技術(shù)對(duì)問(wèn)題各部分建立合適的模型來(lái)細(xì)化需求。 雖然工資子系統(tǒng)的需求是在我們實(shí)習(xí)的階段已經(jīng)完成了，然而在將來(lái)系統(tǒng)的設(shè)計(jì)和測(cè)試過(guò)程中，相信還是會(huì)有更改的。雖然是同為中散公司的員工，但我們也是在為他人作軟件的，有任何新的想法或更改一定要和客戶溝通，特別是取得客戶高級(jí)管理人員的支持。還有一起上班的同學(xué)們給予的支持和鼓勵(lì)，本部實(shí)習(xí)的舍友給我無(wú)數(shù)個(gè)寧?kù)o的夜晚讓我安心的學(xué)習(xí)和寫作。 ? 盡可能的收集需求的來(lái)源。如，在船，外派，基地，農(nóng)合工，年功工資等等。 之前對(duì)于工資的認(rèn)識(shí)只有是：一個(gè)發(fā)一個(gè)領(lǐng)，完全不懂。 技巧與心得 28 第五章 技巧與心得 總結(jié)與 展望 在做軟件需求的時(shí)候，我們完全沒(méi)必要去限定要用或?qū)⒁褂煤畏N方法或建模技術(shù)。 ? 提供待求行為的安全記錄，可以防止重要人員的流失。 以下 畫出比較完整的用戶用例圖，這些是操作人員經(jīng)常要使用到的功能，應(yīng)具有較高的優(yōu)先級(jí)。主要文件有： 船員工資主文件 勞資接口文件 勞資歷史文件 動(dòng)態(tài)接口文件 動(dòng)態(tài)歷史文件 待派工資文件 工資往來(lái)文件 建房存款文件 業(yè)績(jī)工資發(fā)放文件 減員歷史文件 外派工資文件 工資發(fā)放方式文件 帳戶存款文件 獎(jiǎng)金文件 委托文件 郵寄文件 強(qiáng)補(bǔ)強(qiáng) 扣文件 工資生成文件 年度休假文件 船舶文件 加班文件 需求分析實(shí)踐 22 經(jīng)過(guò)對(duì)各個(gè)主要功能的逐步調(diào)查分析，我們發(fā)現(xiàn)了愈來(lái)愈多的子功能，下面就各個(gè)子功能建模以進(jìn)行描述和記錄。這種方式的成功需要有這樣的前提：需求間沒(méi)有聯(lián)系，或至少聯(lián)系不是太多；開(kāi)發(fā)人員遵循 集體所有制 這個(gè)做法；基于共有的代碼之上。整體的流程可能會(huì)有些復(fù)雜， 綜合在一起只會(huì)減低理解性和需求的質(zhì)量， 可以分成幾個(gè)子流程來(lái)研究。 ? 報(bào)表核算： 這個(gè)信息希望能支持會(huì)計(jì)核算的一些要求，如按部室、船型、單船等核算工資及各種保 險(xiǎn)和補(bǔ)貼，按職務(wù)或動(dòng)態(tài)查詢平均工資及保險(xiǎn)。 圖 工資子系統(tǒng)的問(wèn)題框架類型－信息系統(tǒng) 雖然是 僅僅這樣一個(gè) 框架 圖， 但我們已經(jīng)可以 大 體上的了解問(wèn)題域。 ? 審批工作比較困難，工資的審批不僅要基于當(dāng)前的工資狀況，還要審核歷次的工資情況，這就給工資的審批帶來(lái)一定的困難 。 3. 程序界面需更加友好，設(shè)置默認(rèn)值，并能自動(dòng)記憶以前的輸入 。首先，將業(yè)務(wù)代表集中起來(lái)，說(shuō)明需求調(diào)查采用的方法和需求說(shuō)明書的規(guī)范。 獲取需求 需求獲取可能是軟件開(kāi)發(fā)中最困難、最關(guān)鍵、最易出錯(cuò)及最需要交流的方面。 識(shí)別和定義對(duì)象只是一部分工作。 與實(shí)體相關(guān)聯(lián)的信息即為實(shí)體的屬性。 以下規(guī)則可以用來(lái)檢查 DFD 的有效性： ? 數(shù)據(jù)不能直接在數(shù)據(jù)存儲(chǔ)之 間流動(dòng)； ? 數(shù)據(jù)在端子之間的流動(dòng)不顯示； 建模技術(shù) 13 ? 處理和數(shù)據(jù)存儲(chǔ)通常至少有一個(gè)輸入和一個(gè)輸出。 內(nèi)部模型 內(nèi)部模型是對(duì)系統(tǒng)內(nèi)部的構(gòu)造或體系結(jié)構(gòu)的建模技術(shù) 。大多數(shù)用例都有“執(zhí)行者”，可以是人，也可能是系統(tǒng)的軟硬件設(shè)施。該技術(shù)也稱為功能求精或功能組合。迭代中可能會(huì)增加新內(nèi)容，也可能減少內(nèi)容。原型可以為各種目的而購(gòu)造，與需求工程相關(guān)的是那些試圖繪制所需系統(tǒng)的外觀和一些可能的行為的原型。 建模技術(shù) 10 第三章 建模技術(shù) 系統(tǒng)建?？偟膩?lái)說(shuō)是軟件開(kāi)發(fā)過(guò)程中、尤其是需求工程中的一個(gè)極其重要的部分。 ? 通常焦點(diǎn)集中在對(duì)解系統(tǒng)的建模上。描述問(wèn)題域的 SA 可以算是想當(dāng)不錯(cuò)的，所產(chǎn)生的功效可見(jiàn)一斑。 ? 控制系統(tǒng) —— 系統(tǒng)控制部分問(wèn)題域的行為，包括待求行為框架和受控行為框架。 PDOA 更 多的強(qiáng)調(diào)描述，而較少的強(qiáng)調(diào)建模。 結(jié)構(gòu)化分析方法和人們的思維方式和相似，注重的是事物的過(guò)程和方面。 需求分析旨在揭示一個(gè)現(xiàn)有的系統(tǒng)（問(wèn)題域）的方法論 6 結(jié)構(gòu)，而內(nèi)部設(shè)計(jì)則是要?jiǎng)?chuàng)建出一個(gè)尚未存在的 軟件 系統(tǒng)（解系統(tǒng)）的結(jié)構(gòu)。為了解決問(wèn)題，‘解系統(tǒng)’顯然有必要在問(wèn)題域內(nèi)產(chǎn)生某些效果， 構(gòu)成軟件需求的正是這些想要獲得的效果 ，也就是 為何 做軟件需求 的原因和目的 。 產(chǎn)品需求 外部需求 非功能需求 緒論 4 領(lǐng)域需求 這是來(lái)自系統(tǒng)的應(yīng)用程序領(lǐng)域的需求，反映了該領(lǐng)域的特點(diǎn)。在實(shí)際過(guò)程中，對(duì)大型而又復(fù)雜的系統(tǒng)而言，要做到需求描述既全面又一致幾乎是不可能的。 當(dāng)然，需求過(guò)程中的各項(xiàng)活動(dòng)并不是嚴(yán)格按順序進(jìn)行的。 2．需求的導(dǎo)出和分析 這是一個(gè)通過(guò)對(duì)現(xiàn)有系統(tǒng)分析、與潛在用戶和購(gòu)買者討論、進(jìn)行任務(wù)分析等導(dǎo)出系統(tǒng)需求的過(guò)程。 需求工程階段的獨(dú)特之處在于很少有現(xiàn)成模式或特制的文檔可供參考。軟件工程作為一門工程學(xué)科，其目標(biāo)在于使軟件系統(tǒng)向高性價(jià)比發(fā)展。 借助這次中遠(yuǎn)船 員 信息管理系統(tǒng)需求分析實(shí)踐機(jī)會(huì)，盡量的在作分析的過(guò)程中運(yùn)用了解的方法、掌握的建模技術(shù)，不僅能夠 有效 的分析軟件需求，還能加深知識(shí)。 其中，軟件描述，目標(biāo)是確定 軟件 系統(tǒng)需要哪些服務(wù)以及開(kāi)發(fā)和運(yùn)行期間受到哪些約束。從業(yè)務(wù)角度來(lái)決定系統(tǒng)開(kāi)發(fā)是否劃算以及 在預(yù)算范圍內(nèi) 能否開(kāi)發(fā)出來(lái)。用戶需求是從客戶和最終用戶對(duì)系統(tǒng)需求的抽象描述；系統(tǒng)需求是對(duì)系統(tǒng)要提供的功能的詳盡描述。 理論上，系統(tǒng)的 功能需求描述應(yīng)該既全面又具有一致性。主要有的類型如 圖 非功能需求的類型 . 機(jī)構(gòu)需求 可用性 效率 可靠性 移植性 交付 實(shí)現(xiàn) 標(biāo)準(zhǔn) 互操作 道德 法律 。 問(wèn)題域是需求分析員所要研究的首要對(duì)象。 到現(xiàn)在為止，我們得到初步論點(diǎn)。 如同結(jié)構(gòu)化編程一樣， 它致力于系統(tǒng)范圍內(nèi)的 事物 處理，數(shù)據(jù)流以及存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)的建模。 OOA 的真正本質(zhì)意義是作為解系統(tǒng)的高層體系結(jié)構(gòu)的設(shè)計(jì)，并且有利于系統(tǒng)的下一步開(kāi)發(fā)設(shè)計(jì) （如果是 OOD 開(kāi)發(fā)的話） 。一個(gè)子域可以是那些可方法論 8 能算是精選出來(lái)的問(wèn)題域的任一部分。 問(wèn)題域的描述與必須滿足的需求二者之間有著明顯的區(qū)別，對(duì)新的解 系統(tǒng)的行為創(chuàng)建與定義應(yīng)單獨(dú)處理并且推遲到下一步的規(guī)格說(shuō)明階段。 OOA 不能對(duì)問(wèn)題域有 個(gè)清楚的了解，因而它的起點(diǎn)若是有一份原需求文檔，便可大大簡(jiǎn)化問(wèn)題域的分析。 并且它將規(guī)格說(shuō)明 作為另行的任務(wù)處理，它的成果只是一份問(wèn)題域的全面描述和一份需求列表而已。對(duì)軟件系統(tǒng)定義而言，它并不是全部的內(nèi)容，只是一個(gè)從中起著有效作用的基本元素。 演化原型 —— 通過(guò)逐步求精過(guò)程，原型最終成為了產(chǎn)品。聲明使用文本方式，描述輸入和輸出之間的因果關(guān)系。 用例