《軟件技術(shù)基礎(chǔ)第3章.ppt》由會(huì)員分享，可在線閱讀，更多相關(guān)《軟件技術(shù)基礎(chǔ)第3章.ppt（36頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

3 1問題定義和可行性研究3 2需求分析3 3結(jié)構(gòu)化分析 SA方法 概述3 4數(shù)據(jù)流圖3 5數(shù)據(jù)詞典3 6需求分析階段的其他工作 第3章需求分析 返回主目錄 第3章需求分析 3 1問題定義和可行性研究軟件開發(fā)一般涉及用戶和開發(fā)人員 即先由用戶提出問題 然后由軟件開發(fā)人員給出問題的解答 但用戶和開發(fā)人員往往缺乏共同的語言 用戶熟悉本身的業(yè)務(wù) 如飛機(jī)訂票 但不熟悉計(jì)算機(jī)技術(shù) 軟件開發(fā)人員熟悉計(jì)算機(jī)技術(shù)但不了解用戶的業(yè)務(wù) 軟件開發(fā)人員習(xí)慣用數(shù)據(jù)結(jié)構(gòu) 程序結(jié)構(gòu) 編程語言等方式來討論問題 而用戶不能確切地理解這些概念 所以雙方交流時(shí)存在著隔閡 更有甚者 用戶本身也不知道他究竟要計(jì)算機(jī)做些什么 如果開發(fā)人員急于求成 在未明確軟件系統(tǒng)應(yīng)該 做什么 的情況下就開始進(jìn)行設(shè)計(jì) 編程 直至系統(tǒng)完成交付給用戶之后 才發(fā)現(xiàn)它不符合要求 但這時(shí)已太遲了 由此人們認(rèn)識(shí)到 為了開發(fā)出滿意的軟件系統(tǒng) 開發(fā)過程應(yīng)該分為兩大階段進(jìn)行 第一階段是正確地確定問題 即明確地確定用戶所要解決的問題是什么 并形成關(guān)于目標(biāo)系統(tǒng)的規(guī)模和報(bào)告 第二階段才是為問題尋找合適的解答 作為軟件開發(fā)組織 其開發(fā)軟件的目的是為了利益 因此 必須對(duì)該軟件項(xiàng)目進(jìn)行可行性研究 可行性研究主要從兩方面進(jìn)行 從技術(shù)角度對(duì)目標(biāo)系統(tǒng)進(jìn)行可行性分析 以確定目標(biāo)系統(tǒng)是否有可行的解 另一方面 從成本 效益角度對(duì)目標(biāo)系統(tǒng)進(jìn)行可行性分析 以確定目標(biāo)系統(tǒng)是否值得去解 并形成有關(guān)目標(biāo)系統(tǒng)的高層邏輯模型的報(bào)告 該模型是用某種描述方法 對(duì)問題進(jìn)行邏輯上的描述 抽象出問題的實(shí)際模型 并對(duì)項(xiàng)目的可行性給出明確說明 3 2需求分析 在可行性研究的基礎(chǔ)上 就必須明確軟件系統(tǒng)必須 做什么 并形成有關(guān)目標(biāo)系統(tǒng)的需求說明書 這就是需求分析RequirementAnalysis 又稱需求分析階段 其目的是澄清用戶的需求 這個(gè)階段的基本任務(wù)是 用戶和軟件人員雙方一起來充分地理解用戶的要求 并把雙方共同的理解明確地表達(dá)成一份書面文檔 需求說明書 RequirementSpecification 所以分析階段的兩大任務(wù)就是 理解 和 表達(dá) 分析 就是理解問題 規(guī)格說明 就是按某種標(biāo)準(zhǔn)的方式把問題表達(dá)出來 在軟件生命期的各個(gè)階段中 分析階段是面向 問題 的 它主要是對(duì)用戶的業(yè)務(wù)活動(dòng) 如飛機(jī)訂票 進(jìn)行分析 明確在用戶的業(yè)務(wù)環(huán)境中 軟件系統(tǒng)應(yīng)該 做什么 后面的設(shè)計(jì) 編程階段則是面向 解答 的 這時(shí)考慮的是如何構(gòu)造一個(gè)滿足用戶要求的系統(tǒng) 所以 在分析階段 我們應(yīng)集中考慮軟件系統(tǒng) 做什么 而盡可能少考慮系統(tǒng)將怎樣具體實(shí)現(xiàn)的問題 實(shí)現(xiàn)問題應(yīng)盡量推遲到以后的階段去解決 那么什么是 用戶要求 Requirements 呢 在軟件工程中 所謂 用戶要求 或稱 需求 是指軟件系統(tǒng)必須滿足的所有性質(zhì)和限制 用戶要求通常包括功能要求 性能要求 可靠性要求 安全保密要求 開發(fā)費(fèi)用 開發(fā)周期以及可使用的資源等方面的限制 其中功能要求是最基本的 它又包括數(shù)據(jù)要求和加工要求兩方面 用戶和軟件人員充分地理解了用戶的要求之后 要將共同的理解明確地寫成一份文檔 需求說明書 所以需求說明書就是 用戶要求 的明確表達(dá) 需求說明書主要有以下三個(gè)作用 1 作為用戶和軟件人員之間的合同 為雙方相互了解提供基礎(chǔ) 2 反映出問題的結(jié)構(gòu) 可以作為軟件人員進(jìn)行設(shè)計(jì)和編程的基礎(chǔ) 3 作為驗(yàn)收的依據(jù) 即作為選取測(cè)試用例 如進(jìn)行形式驗(yàn)證 的依據(jù) 這三種作用對(duì)需求說明書提出了不同的 有些矛盾的要求 作為設(shè)計(jì)的基礎(chǔ)和驗(yàn)收的依據(jù) 需求說明書應(yīng)該是精確而無二義的 這樣才不致被人誤解 需求說明書越精確 以后出現(xiàn)錯(cuò)誤 混淆 反復(fù)的可能性就越少 例如 本系統(tǒng)應(yīng)能令人滿意地處理所有的輸入信息 是一種含糊不清的描述 驗(yàn)收時(shí)無法檢查這一要求是否滿足 又如 響應(yīng)時(shí)間足夠快 也是不明確的 而 響應(yīng)時(shí)間小于3秒 則是精確的描述 在測(cè)試時(shí)可以檢查系統(tǒng) 滿足 還是 不滿足 這個(gè)要求 用戶能看懂需求說明書 并能發(fā)現(xiàn)和指出其中的錯(cuò)誤是保證軟件系統(tǒng)質(zhì)量的關(guān)鍵 所以需求說明書必須簡明易懂 盡量不包含計(jì)算機(jī)技術(shù)中的概念和術(shù)語 使用戶和軟件人員雙方都能接受它 由于用戶往往不是一個(gè)人 而是企業(yè)組織中各個(gè)部門的好幾個(gè)工作人員 他們可能提出相互沖突的要求 分析階段必須協(xié)調(diào)和解決這些沖突 最后在需求說明書中表達(dá)的應(yīng)該是一致的 無矛盾的用戶要求 由于用戶的要求時(shí)時(shí)會(huì)發(fā)生變化 需求說明書也就需作相應(yīng)的修改 所以需求說明書的表達(dá)方式又必須是易于修改和維護(hù)的 總之 需求說明書應(yīng)該既完整 一致 精確 無二義 又要簡明易懂并易于修改和維護(hù) 顯然 要達(dá)到這樣的目標(biāo)并不容易 分析階段是保證軟件質(zhì)量的第一步 如何分析用戶要求 需求說明書用什么形式表示等都需要有一定的技術(shù)來指導(dǎo) 由于分析階段是同用戶進(jìn)行討論 因此這個(gè)階段的方法 模型 語言和工具都必須考慮到用戶的特點(diǎn) 20世紀(jì)70年代以來 逐步出現(xiàn)了多種適用于分析階段的技術(shù) 但是至今還沒有出現(xiàn)既能完整精確地描述大型系統(tǒng)的用戶要求 又能簡單易懂地被廣大用戶接受的形式語言 目前大多數(shù)軟件系統(tǒng)的需求說明書還是用非形式化的方式 例如用圖形或自然語言等 表示的 3 3結(jié)構(gòu)化分析 SA方法 概述 3 3 1由頂向下逐層分解軟件工程技術(shù)中 控制復(fù)雜性的兩個(gè)基本手段是 分解 和 抽象 對(duì)于一個(gè)復(fù)雜的問題 由于人的理解力 記憶力均有限 所以不可能觸及到問題的所有方面以及全部的細(xì)節(jié) 為了將復(fù)雜性降低到人可以掌握的程度 可以把大問題分割成若干個(gè)小問題 然后分別解決 這就是 分解 分解也可以分層進(jìn)行 即先考慮問題最本質(zhì)的屬性 暫把細(xì)節(jié)略去 以后再逐層添加細(xì)節(jié) 直至涉及到最詳細(xì)的內(nèi)容 這就是 抽象 SA方法也是采用了這兩個(gè)基本手段 對(duì)于一個(gè)復(fù)雜的系統(tǒng) 例如銀行管理系統(tǒng) 如何理解和表達(dá)它的功能呢 SA方法使用了 由頂向下逐層分解 的方式 圖3 1中系統(tǒng)S很復(fù)雜 為了理解它 可以將它分解成S1和S2兩個(gè)子系統(tǒng) 如果子系統(tǒng)S1仍然很復(fù)雜 可以將它們?cè)俜纸獬蒘1 1和S1 2等子系統(tǒng) 如此繼續(xù)下去 直到子系統(tǒng)足夠簡單 能夠清楚地被理解和表達(dá)為止 對(duì)系統(tǒng)作了合理的逐層分解后 我們就可分別理解系統(tǒng)的每一個(gè)細(xì)節(jié) 圖3 1中的S1 1 S1 2 S2 1 S2 2等 并為每個(gè)細(xì)節(jié)寫下說明 稱為 小說明 再將所有這些 小說明 組織起來 就獲得了整個(gè)系統(tǒng)S的系統(tǒng)說明書 逐層分解 體現(xiàn)了分解和抽象的原則 它使人們不至于一下子陷入細(xì)節(jié) 而是有控制地逐步了解更多的細(xì)節(jié) 這是有助于理解問題的 圖3 1由頂向下逐層分解示例 圖3 1的頂層抽象地描述了整個(gè)系統(tǒng) 底層具體地畫出了系統(tǒng)的每一個(gè)細(xì)節(jié) 而中間層則是從抽象到具體的逐步過渡 按照這樣的方式 無論系統(tǒng)多么復(fù)雜 分析工作都可以有計(jì)劃 有步驟并有條不紊地進(jìn)行 系統(tǒng)規(guī)模再大 分析工作的復(fù)雜程度也不會(huì)隨之增大 只是多分解幾層而已 所以SA方法有效地控制了復(fù)雜性 3 3 2描述方式由于目前還沒有出現(xiàn)既能精確地描述大型系統(tǒng)的用戶要求 又簡明易懂的形式語言 因此SA方法采用了介于形式語言和自然語言之間的描述方式 它雖然不如形式語言精確 但是簡明易懂 所表達(dá)的意義也比較明確 用SA方法獲得的需求說明書由以下幾部分組成 1 一套分層的數(shù)據(jù)流圖 2 一本數(shù)據(jù)詞典 3 一組小說明 4 補(bǔ)充材料 這套文檔中 數(shù)據(jù)流圖 描述系統(tǒng)的分解 即描述系統(tǒng)由哪些部分組成 各部分之間有什么聯(lián)系等 數(shù)據(jù)詞典 描述系統(tǒng)中的每一個(gè)數(shù)據(jù) 小說明 則詳細(xì)描述系統(tǒng)中的每一個(gè)加工所完成的操作 上述資料再加上視系統(tǒng)而定的各種補(bǔ)充材料就可明確而完整地描述一個(gè)系統(tǒng)的功能 SA方法在描述方式上的特點(diǎn)是盡量采用圖形表示 因?yàn)閳D形比較形象 直觀 易于理解 一張圖的表達(dá)效果可能比幾千字的敘述還要好 3 4數(shù)據(jù)流圖 數(shù)據(jù)流圖主要用來描述目標(biāo)系統(tǒng)的邏輯模型 下面分析數(shù)據(jù)流圖的基本成分 SA方法采用 分解 的方式來理解一個(gè)復(fù)雜的系統(tǒng) 分解 需要有描述的手段 數(shù)據(jù)流圖 DataFlowDiagram 就是作為描述 分解 的手段而引進(jìn)的 對(duì)大多數(shù)數(shù)據(jù)處理系統(tǒng)來說 從數(shù)據(jù)流的角度來描述一個(gè)企事業(yè)組織的業(yè)務(wù)活動(dòng)是比較合適的 數(shù)據(jù)流圖描述了一個(gè)組織有哪幾個(gè)組成部分 也描述了來往于各部分之間的數(shù)據(jù)流 下面先看一個(gè)例子 假定要為某培訓(xùn)中心研制一個(gè)計(jì)算機(jī)管理系統(tǒng) 我們首先需分析這個(gè)系統(tǒng)應(yīng)該做些什么 為此必須分析培訓(xùn)中心的業(yè)務(wù)活動(dòng) 培訓(xùn)中心是一個(gè)功能很復(fù)雜的系統(tǒng) 它為在職人員開設(shè)許多門課程 有興趣的人可以來電或來函報(bào)名選修某門課程 培訓(xùn)中心要收取一定的費(fèi)用 學(xué)員通過支票付款 也可以來電或來函查詢課程計(jì)劃等有關(guān)事宜 培訓(xùn)中心的日常業(yè)務(wù)是 將學(xué)員發(fā)來的電報(bào) 信件 電話收集分類后 按幾種不同情況處理 如果是報(bào)名的 則將報(bào)名數(shù)據(jù)送給負(fù)責(zé)報(bào)名事務(wù)的職員 他們要查閱課程文件 檢查某課程是否額滿 然后在學(xué)生文件 課程文件上登記 并開出報(bào)名單交財(cái)務(wù)部門 財(cái)務(wù)人員再開出發(fā)票經(jīng)復(fù)審后通知學(xué)員 如果是付款的 則由財(cái)務(wù)人員在帳目文件上登記 再經(jīng)復(fù)審后發(fā)給學(xué)員一張通知單 如果是查詢的 則交查詢部門查閱課程文件后給出答復(fù) 如果是想注銷原來已選修的課程 則由注銷人員在課程 學(xué)生 帳目文件上作相應(yīng)修改 經(jīng)復(fù)審后通知學(xué)員 對(duì)一些要求不合理的函電 培訓(xùn)中心將拒絕處理 我們可以用圖3 2的數(shù)據(jù)流圖描述這個(gè)系統(tǒng)的 分解 這張圖告訴我們 系統(tǒng)分解成 收集 分類 報(bào)名 等八個(gè)部分 這些部分之間通過圖中所示的數(shù)據(jù)流進(jìn)行聯(lián)系 要理解整個(gè)系統(tǒng)只需分別理解這八個(gè)部分就可以了 由于每個(gè)部分比整個(gè)系統(tǒng)小多了 所以分析工作就可以簡化 從圖3 2看出 數(shù)據(jù)流圖有四種基本成分 1 數(shù)據(jù)流 用箭頭表示 2 加工 用圓表示 3 文件 用直線段表示 4 數(shù)據(jù)流的源點(diǎn)或終點(diǎn) 用方框表示 數(shù)據(jù)流圖中的每個(gè)成分都有一個(gè)互不相同的名字來加以區(qū)分 下面分別討論各種成分 1 數(shù)據(jù)流數(shù)據(jù)流由一組固定成分的數(shù)據(jù)組成 在圖3 2中 數(shù)據(jù)流 報(bào)名請(qǐng)求 由 姓名 年齡 性別 單位名 課程名 等成分組成 數(shù)據(jù)流 發(fā)票 由 姓名 單位名 金額 組成 它們的組成成分都是確定的 圖3 2數(shù)據(jù)流圖 數(shù)據(jù)流可以從加工流向加工 也可以從加工流向文件或從文件流向加工 也可以從源點(diǎn)流向加工或從加工流向終點(diǎn) 一般來說 除了流向文件或從文件流出的數(shù)據(jù)流不必命名之外 在這種情況下 有文件名已足夠了 每個(gè)數(shù)據(jù)流都必須有一個(gè)合適的名字 名字一方面是為了區(qū)別 同時(shí)也是給人一個(gè)直觀的印象 使人容易理解這個(gè)數(shù)據(jù)流的含義 應(yīng)該注意的是 數(shù)據(jù)流圖中描述的是數(shù)據(jù)流而不是控制流 圖3 3中 取下一張卡片 是一個(gè)控制流而不是數(shù)據(jù)流 因?yàn)椴]有任何數(shù)據(jù)沿著這個(gè)箭頭流動(dòng) 所以這個(gè)箭頭應(yīng)該從圖中刪去 習(xí)慣使用框圖 程序流程圖 的軟件人員特別應(yīng)該注意不要犯這種錯(cuò)誤 圖3 3數(shù)據(jù)流和控制流 2 加工加工是對(duì)數(shù)據(jù)進(jìn)行的操作 在圖3 2中 報(bào)名 產(chǎn)生發(fā)票 查詢 等都是加工 加工的名字也應(yīng)適當(dāng)?shù)胤从尺@個(gè)加工的含義 使之容易理解 3 文件文件是暫時(shí)存儲(chǔ)的數(shù)據(jù) 圖3 2中有 學(xué)生 課程 帳目 等文件 文件的名字也應(yīng)適當(dāng)?shù)剡x擇 以便理解 我們還應(yīng)注意加工與文件之間數(shù)據(jù)流的方向 如果加工要讀文件 則數(shù)據(jù)流是從文件流出的 如果加工要寫文件或修改文件 雖然修改文件一般先要讀文件 但其本質(zhì)是寫 則數(shù)據(jù)流是流向文件的 如果加工既要讀文件 除了修改文件之外 又要寫文件 則數(shù)據(jù)流是雙向的 在圖3 4中 加工 檢查拼寫的正確性 對(duì)輸入的詞進(jìn)行檢查 圖3 4源點(diǎn)和終點(diǎn) 4 源點(diǎn)和終點(diǎn)一個(gè)數(shù)據(jù)處理系統(tǒng)的內(nèi)部用數(shù)據(jù)流 文件和加工三種成分表示一般已足夠了 然而為了便于理解 有時(shí)還可以畫出數(shù)據(jù)流的源點(diǎn)和終點(diǎn)來說明它的來龍去脈 源點(diǎn)和終點(diǎn)通常是存在于系統(tǒng)之外的人員或組織 如圖3 2中 學(xué)員 是數(shù)據(jù)流 函電 的源點(diǎn) 也是數(shù)據(jù)流 通知單 的終點(diǎn) 畫出源點(diǎn)和終點(diǎn)只是起到注釋作用和幫助理解而已 由于它們是系統(tǒng)之外的事物 我們對(duì)此是不大關(guān)心的 所以源點(diǎn)和終點(diǎn)的表達(dá)不必很嚴(yán)格 總之 數(shù)據(jù)流圖從 數(shù)據(jù) 和 數(shù)據(jù)的加工 這兩個(gè)相互補(bǔ)充的方面來表達(dá)一個(gè)數(shù)據(jù)處理系統(tǒng) 它從數(shù)據(jù)的角度描述它們作為輸入進(jìn)入系統(tǒng) 經(jīng)過某個(gè)加工 再經(jīng)過某個(gè)加工 或者合并 或者分解 或者存儲(chǔ) 最后成為輸出離開系統(tǒng) 經(jīng)驗(yàn)證明 對(duì)數(shù)據(jù)處理系統(tǒng)來說 從數(shù)據(jù)角度觀察問題一般能夠較好地抓住問題的本質(zhì) 并描述出系統(tǒng)的概貌 但是 數(shù)據(jù)流圖只描述了系統(tǒng)的 分解 它并沒有表達(dá)出每個(gè)數(shù)據(jù)和加工的具體含義 這些信息需在 數(shù)據(jù)詞典 和 小說明 中表達(dá)出來 數(shù)據(jù)流圖的優(yōu)點(diǎn)是直觀 容易理解 容易被一組人同時(shí)進(jìn)行審查 如果圖中有錯(cuò)誤 一般也比較顯眼 容易被人們發(fā)現(xiàn) 實(shí)踐證明 從事數(shù)據(jù)處理工作的人 包括用戶和軟件開發(fā)人員 都很容易接受這個(gè)描述方式 3 5數(shù)據(jù)詞典 3 5 1數(shù)據(jù)詞典與數(shù)據(jù)流圖的聯(lián)系數(shù)據(jù)流圖描述了系統(tǒng)的 分解 即描述了系統(tǒng)由哪幾部分組成 各部分之間有什么聯(lián)系等 但是并沒有說明系統(tǒng)中各個(gè)成分是什么含義 因此僅僅一套數(shù)據(jù)流圖并不能構(gòu)成系統(tǒng)的需求說明書 只有為圖中出現(xiàn)的每一個(gè)成分都給出明確定義之后 才較完整地描述了一個(gè)系統(tǒng) 數(shù)據(jù)流圖中所有名字的定義就構(gòu)成了一本詞典 同日常使用的詞典一樣 SA方法所用的詞典也是這樣一個(gè)工具 當(dāng)我們不知道某個(gè)名字的含義時(shí) 借助于它就可查出這個(gè)名字的含義 詞典中所有條目應(yīng)該按一定次序排列起來 這樣才能供人們方便地查閱 數(shù)據(jù)流圖與詞典是密切聯(lián)系的 兩者結(jié)合在一起才構(gòu)成了 需求說明書 單獨(dú)一套數(shù)據(jù)流圖或單獨(dú)一本詞典都是沒有任何意義的 數(shù)據(jù)流圖中出現(xiàn)的每一個(gè)數(shù)據(jù)流名 每一個(gè)文件名和每一個(gè)加工名在詞典中都應(yīng)有一個(gè)條目給出這個(gè)名字的定義 此外 在定義數(shù)據(jù)流 文件和加工時(shí) 又要引用到它們的組成部分 所以每一個(gè)組成部分在詞典中也應(yīng)有一個(gè)條目給出其定義 3 5 2數(shù)據(jù)詞典條目的各種類型詞典中包含以下四種類型的條目 1 數(shù)據(jù)流 2 文件 3 數(shù)據(jù)項(xiàng) 指不能再分解的數(shù)據(jù)單位 4 加工 數(shù)據(jù)流 文件和數(shù)據(jù)項(xiàng)等數(shù)據(jù)型條目構(gòu)成了數(shù)據(jù)詞典 DataDictionary 1 數(shù)據(jù)流條目數(shù)據(jù)流條目給出某個(gè)數(shù)據(jù)流的定義 它通常是列出該數(shù)據(jù)流的各組成數(shù)據(jù)項(xiàng) 如圖3 2中的數(shù)據(jù)流 報(bào)名單 由 姓名 單位名 年齡 性別 和 課程名 等數(shù)據(jù)項(xiàng)組成 詞典中 報(bào)名單 這個(gè)條目就可寫成報(bào)名單 姓名 單位名 年齡 性別 課程名有些數(shù)據(jù)流的組成很復(fù)雜 一下子列出它所有的數(shù)據(jù)項(xiàng)可能不易使人理解 此時(shí)同樣可采用 由頂向下逐步分解 的方式來說明 例如某學(xué)校管理系統(tǒng)中 有個(gè)名為 課程 的數(shù)據(jù)流 它由 課程名 教員 教材 和 課程表 組成 而 課程表 又由 星期幾 第幾節(jié) 和 教室 組成 則詞典中可以建立 課程 及 課程表 兩個(gè)條目 它們分別是課程 課程名 教員 教材 課程表課程表 星期幾 第幾節(jié) 教室 這樣 只要依次查閱這兩個(gè)條目 就可確切地理解 課程 這個(gè)名字的含義 給出數(shù)據(jù)流的定義時(shí) 需要使用一些簡單的符號(hào) 如 表示 與 表示 或 即選擇括號(hào)中的某一項(xiàng) 表示 重復(fù) 即括號(hào)中的項(xiàng)要重復(fù)若干次 重復(fù)次數(shù)的上 下限也可在括號(hào)邊上標(biāo)出 表示 可選 即括號(hào)中的項(xiàng)可能沒有 分析員可根據(jù)自己的習(xí)慣 選擇使用類似的符號(hào) 其中自定義的符號(hào)應(yīng)說明其功能 下面再給出一個(gè)數(shù)據(jù)流條目的例子 數(shù)據(jù)流 發(fā)票 由1 5個(gè) 發(fā)票行 組成 而每個(gè) 發(fā)票行 又由 貨名 數(shù)量 單位 和 總價(jià) 組成 則詞典中的 發(fā)票 條目是發(fā)票 貨名 數(shù)量 單價(jià) 總價(jià) 也可分別建立 發(fā)票 和 發(fā)票行 兩個(gè)條目 它們是發(fā)票 發(fā)票行 發(fā)票行 貨名 數(shù)量 單價(jià) 總價(jià)2 文件條目文件條目給出某個(gè)文件的定義 同數(shù)據(jù)流一樣 文件的定義通常是列出其記錄的組成數(shù)據(jù)項(xiàng) 此外 文件條目還可指出文件的組織方式 如 按帳號(hào)遞增次序排列 等 是一個(gè)例子 帳目 帳號(hào) 戶名 地址 款額 日期組織 按帳號(hào)遞增次序排列 3 數(shù)據(jù)項(xiàng)條目數(shù)據(jù)項(xiàng)條目給出某個(gè)數(shù)據(jù)項(xiàng)的定義 這通常是該數(shù)據(jù)項(xiàng)的值類型 允許值等 例如 帳號(hào) 這個(gè)數(shù)據(jù)項(xiàng)的值可以是00000 99999之間的任意整數(shù) 則詞典條目 帳號(hào) 可寫成 帳號(hào) 00000 99999又如 數(shù)據(jù)項(xiàng) 日期 可取1997 1 12 1 31等值 則詞典條目 日期 可寫成 日期 1997 1 12 1 31 有了這樣的詞典 我們只要依次查閱 帳目 帳號(hào) 日期 等條目 就可了解文件 帳目 的精確含義了 有些數(shù)據(jù)項(xiàng)本身名字已足以說明其含義 如詞典條目 學(xué)生 中 學(xué)生 姓名 年齡 性別 班級(jí)這里 姓名 年齡 性別 等數(shù)據(jù)項(xiàng)的含義是不言而喻的 所以就不必再解釋了 這些名字稱為是 自定義 的 自定義的詞在詞典中就不必再給出條目了 詞典條目的具體格式往往因系統(tǒng)而異 它也同用戶習(xí)慣使用的表達(dá)方式有關(guān) 3 6需求分析階段的其他工作 除了前面討論的工作之外 需求分析階段還應(yīng)完成下列工作 1 確定設(shè)計(jì)限制軟件的設(shè)計(jì)要受到系統(tǒng)以外許多因素的影響 如成本 進(jìn)度 可用的軟硬件資源等 因此分析還必須確定設(shè)計(jì)的限制 并試圖說明每種限制都是合理的 2 確定驗(yàn)收準(zhǔn)則在同用戶討論時(shí) 分析員應(yīng)該提出這樣的問題 如果明天就將系統(tǒng)交給你 你憑什么認(rèn)為這個(gè)系統(tǒng)是成功的 這個(gè)問題和相應(yīng)的回答便構(gòu)成了一組驗(yàn)收準(zhǔn)則 驗(yàn)收準(zhǔn)則應(yīng)該盡可能具體 用于確認(rèn)每個(gè)主要功能的測(cè)試方法也應(yīng)同時(shí)確定下來 用戶往往會(huì)很一般地回答上述問題 而分析員必須尋求精確的答復(fù) 他應(yīng)該認(rèn)識(shí)到 如果不能精確地規(guī)定這些準(zhǔn)則 則說明用戶需求還是模糊的 驗(yàn)收準(zhǔn)則是測(cè)試計(jì)劃的基礎(chǔ) 如果被忽視了 就是開發(fā)人員的失職 3 編寫 初步用戶手冊(cè) 初步用戶手冊(cè) 為系統(tǒng)的操作員描繪了軟件系統(tǒng)的外貌 并能說明需求分析工作是否已確定了軟件系統(tǒng)的所有主要輸入和輸出 該手冊(cè)還可用來評(píng)價(jià)系統(tǒng)的人機(jī)界面 用戶在審查 初步用戶手冊(cè) 時(shí)經(jīng)常會(huì)這樣說 我想這不是我們啟動(dòng)這個(gè)功能的方式 這不行 因?yàn)?這些評(píng)論最好在分析階段就做出 到系統(tǒng)驗(yàn)收時(shí)才說就太遲了 需求說明書寫成之后 用戶和分析員應(yīng)該對(duì)它進(jìn)行復(fù)查 爭取系統(tǒng)還只在紙上時(shí)就發(fā)現(xiàn)其中的錯(cuò)誤并及時(shí)糾正 開發(fā)人員應(yīng)該檢查是否正確地理解了問題的整個(gè)含義 仔細(xì)評(píng)價(jià)全部文檔的完整性 一致性 正確性和清晰性 復(fù)查的結(jié)果幾乎總是修改并重新定義某些需求 需求分析中的這些反復(fù)正是所期望的 甚至是值得提倡的 最后 一份能被用戶和開發(fā)人員雙方共同接受的需求說明書終于產(chǎn)生 需求說明書的篇幅可能較長 我們可將各種圖形和文字材料適當(dāng)裝訂起來 分成章節(jié) 再加上前言 目錄等 編成一本易于閱讀的手冊(cè) 需求說明書將為軟件系統(tǒng)的設(shè)計(jì) 實(shí)現(xiàn)和驗(yàn)收奠定良好的基礎(chǔ) 獲得用戶和開發(fā)人員共同確認(rèn)的需求說明書 就是分析階段勝利完成的里程碑