【正文】 致謝 30 致 謝 這次論文是在 COSCO 天津中散公司塘沽分 部完成的，首先要感謝的是中散公司給予的上班環(huán)境和機(jī)房機(jī)器，以及南開大學(xué)和軟件學(xué)院安排的畢業(yè)工作實(shí)習(xí)機(jī)會(huì)。很多時(shí)候我不知道客戶在講 些什么，或者他們說的根本不是技巧與心得 29 我們想要聽的，但還是得 認(rèn)真地去記錄。 如今 再回頭看書上的內(nèi)容，感覺還真是不一樣 。首先我們用面向問題域的方法把問題分成幾個(gè) 部分。 ? 為功能性測試提供基準(zhǔn)。 一般需求文檔必須具備以下特性： ? 較低的二義性 ? 良好的組織 ? 完整性 ? 一致性 需求分析實(shí)踐 26 ? 可驗(yàn)證的 ? 可修改的 下面給出用戶所需要的用戶界面，為了節(jié)省空間，我們一起列出了重要的下拉菜單，用戶可以方便的核查。 CRC 模型是一組標(biāo)準(zhǔn)的索引卡片。 基于各組對各自的需求把握得比較透徹，也沒有足夠的時(shí)間去完全了解其他各組的需求。該計(jì)劃隨著對需求的理解的不斷發(fā)展而演化，由此 就開始了真正的開發(fā)。可能 實(shí)體 ： 船員： 工號 ，姓名，職務(wù)，地址，工資，津貼， ?? .. 航船： 船舶代碼 ，名稱，功率，速度，噸位，船籍港， ?? . 公司： 公司標(biāo)識 ，名稱，地址，電話，船員數(shù)，船舶數(shù)， ?? . 由于船員的工資標(biāo)準(zhǔn)跟船員是否在船（ 出海）、是否外派（這公司的船員到另一公司工作）有緊密關(guān)系，所以我們確定 至少 要 有 以上 三個(gè)實(shí)體。 功能需求 方面 ， 根據(jù)我們所取得的資料， 可以初步定位這幾個(gè) 行為 ： ? 工資主文件查詢：一些基本的工資方面的信息查詢。 需求分析實(shí)踐 17 需求初始化階段 這個(gè)階段 有三個(gè)主要的目的：第一，至少從高層次上確定 工資 系統(tǒng)的范圍，以明確 所要做的工作 范圍；第二，定義 工資 系統(tǒng)的高層需求；第三，對于需求的含義，在 用戶 和開發(fā)項(xiàng)目組間取得一致。 5. 財(cái)務(wù)員不再設(shè)置工資標(biāo)準(zhǔn)等 ，而由勞資方面設(shè)定 。 馬上開始第一次的訪談，對方是財(cái)務(wù)人員，目標(biāo)描 得 很準(zhǔn) 的 。分析者必須建立一個(gè)對問題進(jìn)行徹底探討的環(huán)境，而這些問題與 軟件 有關(guān)。 選擇技術(shù) 可以從兩個(gè)方面來選擇技術(shù)： 1. 特定的目的需要什么技術(shù) 2. 特定的技術(shù)適合什么目的 特定的目的或許更多的需要我們?nèi)ネ诰颉⑺伎?，而熟悉各種技術(shù)的常見應(yīng)用領(lǐng)域?qū)?huì)有很大幫助。 3. 處理 /數(shù) 據(jù)相結(jié)合 該技術(shù)集中在對發(fā)生的處理和處理的數(shù)據(jù)的建模上，采用了一種完整的觀點(diǎn)，卻抽象更加復(fù)雜。但是，大部分計(jì)算機(jī)以順序的方式處理，特別的 在 軟件 設(shè)計(jì)的時(shí)候（即使是面向?qū)ο笤O(shè)計(jì)）。 根據(jù)建模所側(cè)重的方面，可以劃分為三種內(nèi)部建模技術(shù)。用例的應(yīng)用和構(gòu)造具有相當(dāng)大的靈活性，人們可能認(rèn)為它不夠嚴(yán)格，但 是 應(yīng)用 指定的 合適的指導(dǎo)原則可以解決這個(gè)問題。任務(wù)分析從人們所希望獲得的目標(biāo)開始。原型開發(fā)的一個(gè)潛在好處是：可以促進(jìn)潛在用戶的參與和客戶的承諾，但有個(gè)副作用：真實(shí)原型的早期外觀會(huì)誤導(dǎo)人們認(rèn)為該項(xiàng)目比實(shí)際情形先進(jìn)得多，隨著最終產(chǎn)品的出現(xiàn)就會(huì)感到失望。 定義原型 —— 形成部分所需行為的定義，即部分規(guī)格說明。 表 建模技術(shù)對比 外部建模 內(nèi)部建模 功能的 結(jié)構(gòu)的 黑盒 白盒 行為的 非行為的 外部模型 外部模型可進(jìn)一步劃分為建模系統(tǒng)外觀的模型和建模系統(tǒng)行為的抽象模型。 ? 分析與內(nèi)部設(shè)計(jì)之間沒有明顯差異。 方法論 9 面向?qū)ο蠓治鍪钱?dāng)今主流的方法。 ? 轉(zhuǎn)換系統(tǒng) —— 系統(tǒng)必須將某種特定格式的輸入數(shù)據(jù)轉(zhuǎn)換成相應(yīng)的、另一種特定格式的輸出。 一般 建議同時(shí)有兩個(gè)單獨(dú)文檔：第一文檔含有對問題域相關(guān)部分的描述以及一個(gè)需求在該域中求解的問題列表（即需求）；第二文檔（規(guī)格說明書）包含的是對解系統(tǒng)的待求行為的描述以解決需求。 面向?qū)ο蠓治?（ OOA） 面向?qū)ο蠓椒ㄗ畛踔皇且环N系統(tǒng)的結(jié)構(gòu)進(jìn)行建模的方式，后來擴(kuò)展到了內(nèi)部方法論 7 設(shè)計(jì)，如今也已經(jīng)開始廣泛應(yīng)用于分析階段。 方法論 方法不只是一種技術(shù)，它是解決任務(wù)的一種途徑，并且通常由一組技術(shù)組成。分析，關(guān)注問題 域 和存在于其中的問題 ，目的在于真實(shí)的了解問題域 。 軟件需求文檔 有時(shí)叫做軟件需求描述（ SRS）是對系統(tǒng)開發(fā)者要求的正式陳述 。 非功能需求 對系統(tǒng)提供的服務(wù)或功能給出的約束。因此，分析、定義和描述是交替進(jìn)行的。這些都會(huì)幫助分析員了解所要描述的系統(tǒng)。 需求 的 過程 需求工程本身就是一個(gè)過程，這個(gè)過程產(chǎn)生用以描述系統(tǒng)的需求文檔。 2．軟件設(shè)計(jì)和實(shí)現(xiàn) 軟件一定要按照 描述來生產(chǎn)。 南 開 大 學(xué) 本 科 生 畢 業(yè) 論 文（設(shè) 計(jì)） 題 目： ____需求分析的方法與建模 __ 學(xué) 號： ____0010127____________ 姓 名： ____方 春 強(qiáng) ___________ 年 級： ____20xx 級 ___________ 學(xué) 院： ____軟件學(xué)院 ___________ 系 別： ____軟件工程 ___________ 專 業(yè)： ____軟件工程 ___________ 完成日期： ____20xx524__________ 指導(dǎo)教師： ____林 曉 旻 ___________ 摘要 需求分析的方法與建模 軟件學(xué)院軟件工程系 軟件工程專業(yè) 方春強(qiáng) 學(xué)號： 0010127 指導(dǎo)教師： 林曉旻 講師 摘要 : 需求分析作為軟件工程的開始，具有相當(dāng)?shù)碾y度去把握它。 3．軟件有效性驗(yàn)證 軟件要被確定是有效的，能做客戶想要的事情。通常需求在這個(gè)文檔中被分成兩個(gè)層次描述：最終用戶和客戶需要高層次的需求描述；而系統(tǒng)開發(fā)人員需要比較詳細(xì)的系統(tǒng)描述。 3．需求描述 需求描述就是把在分析活動(dòng)中收集的信息以文檔的形式確定下來。 軟件系統(tǒng)需求 常常分為功能需求、非功能需求和領(lǐng)域需求： 功能需求 包括對系統(tǒng)應(yīng)該提供的服務(wù)、如何對輸入做出反應(yīng)以及系統(tǒng)在特定條件下的行為的描述。包括時(shí)間約束、開發(fā)過程約束、標(biāo)準(zhǔn)等。 IEEE 標(biāo)準(zhǔn)為需求文檔提出了以下結(jié)構(gòu)：引言（目的、范圍、縮略詞等），一般描述（產(chǎn)品透視、功能、用戶特征、約束等），專門需求（功能、非功能、接口），附錄，索引。 規(guī)格說明，關(guān)注問題域與解系統(tǒng)之間的相互關(guān)系 ，定義了系統(tǒng)預(yù)期的目標(biāo) 。任何分 析方法， 要使它得到很好的利用 ，都應(yīng)當(dāng)要求并且 做到 便于描述以下幾個(gè)方面： 1. 問題域的結(jié)構(gòu)，根據(jù)其子域及其相互間的關(guān)系； 2. 問題域數(shù)據(jù)，語法和語義方面 3. 問題子域的內(nèi)在屬性和行為； 4. 問題域中的重要事件及現(xiàn)象； 5. 需求，解系統(tǒng)在問題域中應(yīng)產(chǎn)生的效果。面向?qū)ο蠓治龌舅枷胧牵喝绻褜ο箢惖慕Ｏ薅ㄔ谛枨髥栴}域，那么面向?qū)ο蟮幕驹怼⒛Ｐ鸵约氨硎?法均可以用于分析。其中第一文檔才是通過 做 分析產(chǎn)生的；第二文檔推遲到后續(xù)的規(guī)格說明任務(wù)中。 ? 連接系統(tǒng) —— 系統(tǒng)必須維持那些相互沒有直接連接的子域間的通信。 OOA 要求所有的系統(tǒng)均可以按照對象的特點(diǎn)來建模。 面向問題域分析被認(rèn)為是一種較為理想的方法。 表示建模 表示模型是對系統(tǒng)外觀進(jìn)行的模仿，相當(dāng)于描述可見的輸出，最有效的表示法通常是畫圖。 建模技術(shù) 11 結(jié)構(gòu)原型 —— 用于評價(jià)可能的內(nèi)部設(shè)計(jì)方案，例如檢查性能。 行為（功能）建模 行為模型只是系統(tǒng)行為的抽象。任務(wù)是獲得這些目標(biāo)的高級機(jī)制 ，操作是實(shí)現(xiàn)任務(wù)的交互。 4. 有限狀態(tài)機(jī) 有限狀態(tài)機(jī)（ Finite State Machines， FSM）通過輸入與輸出之間的因果關(guān)系對系統(tǒng)的行為進(jìn)行建模。 1. 面向處理技術(shù) 抽象的把所考慮的系統(tǒng)建模成一組通信子系統(tǒng)，重點(diǎn)放在它們實(shí)施的處理上。 對通信順序處理建模的常用表示法有樹狀圖或結(jié)構(gòu)圖，另一種主要方法是偽碼。 主要的兩種模型是實(shí)體生命歷史（ ELH） 和面向?qū)ο蠼！? 建模技術(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 解