第11章 分析概念和原則
對軟件需求的完全理解對軟件開發(fā)工作的成功是至關重要的，不論我們設計得如何好、編碼得如何好，未很好地分析和編寫的程序將只會給用戶帶來失望，并給開發(fā)者帶來煩惱。
需求分析任務是發(fā)現(xiàn)、求精、建模和規(guī)約的過程。包括詳細地精化初始由系統(tǒng)工程師建立并在軟件項目計劃中精化的軟件范圍，創(chuàng)建所需數(shù)據(jù)、信息和控制流以及操作行為的模型，此外還有分析可選擇的解決方案，并將它們分配到各軟件元素中去。
在需求分析和規(guī)約中，軟件開發(fā)者和客戶均扮演了積極的角色?？蛻舯仨毐M力將有時有些模糊的軟件功能和性能概念重新具體詳細地描述出來，而開發(fā)者則是軟件功能的詢問者、咨詢顧問和問題解決者。
需求分析和規(guī)約看起來可能是相當簡單的任務，但其實并不是這樣。用戶與開發(fā)者之間需要通信的內(nèi)容非常大，其中可能會存在錯誤解釋或誤傳的可能性，或含糊性。軟件工程師可能要面臨的進退兩難的局面可通過重復某客戶的陳述而得到的理解：“我知道你認為你已經(jīng)理解了我所說的內(nèi)容，但是我并不能肯定你已認識到你所聽到的并不是我所想要的?！?BR> 11.1 需求分析
需求分析是一種軟件工程活動，它在系統(tǒng)級軟件分配和軟件設計間起到橋梁的作用(如圖11－1所示)。需求分析使得系統(tǒng)工程師能夠刻劃出軟件的功能和性能、指明軟件和其他系統(tǒng)元素的接口、并建立軟件必須滿足的約束。需求分析允許軟件工程師(在這種角色中經(jīng)常稱為分析員)精化軟件分解模塊，并建造將被軟件處理的數(shù)據(jù)、功能、和行為模型。需求分析為軟件設計者提供了可被翻譯成數(shù)據(jù)、體系結構、界面和過程設計的模型，最后，需求規(guī)約為開發(fā)者和客戶提供了軟件建造完后質(zhì)量評估的依據(jù)。
軟件需求分析可被劃分成5個工作階段：(1)問題分析，(2)問題評估和方案綜合，(3)建模，(4)規(guī)約，和(5)復審。
初始時，分析員研究系統(tǒng)規(guī)約(如果存在的話)和軟件項目計劃，并在系統(tǒng)語境內(nèi)理解軟件和復審，從而生成計劃軟件范圍的估算。接著，必須建立針對分析的相互通信方式，以使得問題分析得到保證。分析員的目標是對用戶/客戶認識到的基本問題要素進行識別。
問題評估和方案綜合是分析工作的下一個主要關注點，分析員必須定義所有外部可觀察到的數(shù)據(jù)對象，評估信息流和內(nèi)容；定義并詳細闡述所有軟件功能；在影響系統(tǒng)的事件的語境內(nèi)理解軟件行為；建立系統(tǒng)界面特征；以及揭示其他設計約束。這些任務中的每一個旨在描述問題，以便可以綜合出全面的方法或解決方案。
例如，汽車零件的主要供應商需要一個庫存控制系統(tǒng)，分析員發(fā)現(xiàn)與當前的手工系統(tǒng)相關的問題包括：(1)不能快速地獲得部件的狀況；(2)更新卡片文件需要2或3天的工作量；(3)由于沒有辦法查找相關廠商的部件信息而使得對同一廠商同一貨品多次再訂貨，等等。一旦問題被標識出來，分析員將確定新系統(tǒng)該產(chǎn)生什么信息，以及將提供什么信息給系統(tǒng)①，例如，客戶希望得到指明什么零件被從庫存中取出以及還剩余多少相似零件的日報表?？蛻糁该饕坏┊斣摿慵x開倉庫時庫存管理員就該記載每個零件的標號。
通過對當前問題和希望的信息(輸入和輸出)進行的評估，分析員開始綜合一個或多個解決方案。為了便于開始，必須詳細地定義系統(tǒng)的數(shù)據(jù)、處理功能和行為。一旦已經(jīng)建立這些信息，就該考慮針對實現(xiàn)的基本體系結構?？蛻?服務器方法似乎是合適的，但是，它確實屬于在軟件計劃中概括的范圍嗎？似乎需要一個數(shù)據(jù)庫管理系統(tǒng)，但是，該數(shù)據(jù)庫系統(tǒng)真的是用戶/客戶需要的嗎？繼續(xù)評估和綜合的過程，直至分析員和客戶均確信針對后面的開發(fā)步驟軟件確實已被適當?shù)乜虅澚恕?BR> 貫穿整個評估和綜合過程，分析員的主要焦點是“什么(what)”，而不是“怎么做(how)”，系統(tǒng)會產(chǎn)生和使用什么數(shù)據(jù)？系統(tǒng)必須完成什么功能？將定義什么界面？會應用什么約束？等。②
在問題評估和綜合解決方案的活動中，分析員創(chuàng)建系統(tǒng)模型，以便可以更好地理解數(shù)據(jù)和控制流、處理功能和操作行為、以及信息內(nèi)容。模型是軟件設計的基礎，也是創(chuàng)建軟件規(guī)約的基礎。
重要的是要注意，在本階段要得到詳細的規(guī)約是不可能的。客戶可能并不能精確地肯定需要什么，開發(fā)者可能不能肯定可用什么特定的方法來適當?shù)赝瓿晒δ芎托阅?。由于這些以及許多其他理由，可以采用一種可選擇的需求分析方法——原型法，(第2章)，本章后面我們將討論原型法。
11.2通信技術
軟件需求分析中的相互通信總是要在兩方或多方間進行?？蛻粲心硞€問題需要基于計算機的解決方案，開發(fā)者要要針對客戶的請求提供幫助，這時便產(chǎn)生了通信需求。但是，正如我們已經(jīng)提到，從相關通信、交流到理解的道路經(jīng)常是充滿坎坷的。
11.2.1 過程的啟動
客戶和開發(fā)者之間最常用的交流方式以及開始相互通信過程的技術是進行預備會議或訪談。在軟件工程師(分析員)和客戶間的第一次會議可與兩個青年間的第一次約會的笨拙程度相比較，沒有人知道該說什么或問什么；雙方均擔心他們所說的會被誤解；雙方均在考慮最終談話將導向何處(雙方在這里可能有完全不同的期望)；雙方均希望能控制事情的進程；而同時，雙方均希望能夠獲得成功。
對軟件需求的完全理解對軟件開發(fā)工作的成功是至關重要的，不論我們設計得如何好、編碼得如何好，未很好地分析和編寫的程序將只會給用戶帶來失望，并給開發(fā)者帶來煩惱。
需求分析任務是發(fā)現(xiàn)、求精、建模和規(guī)約的過程。包括詳細地精化初始由系統(tǒng)工程師建立并在軟件項目計劃中精化的軟件范圍，創(chuàng)建所需數(shù)據(jù)、信息和控制流以及操作行為的模型，此外還有分析可選擇的解決方案，并將它們分配到各軟件元素中去。
在需求分析和規(guī)約中，軟件開發(fā)者和客戶均扮演了積極的角色?？蛻舯仨毐M力將有時有些模糊的軟件功能和性能概念重新具體詳細地描述出來，而開發(fā)者則是軟件功能的詢問者、咨詢顧問和問題解決者。
需求分析和規(guī)約看起來可能是相當簡單的任務，但其實并不是這樣。用戶與開發(fā)者之間需要通信的內(nèi)容非常大，其中可能會存在錯誤解釋或誤傳的可能性，或含糊性。軟件工程師可能要面臨的進退兩難的局面可通過重復某客戶的陳述而得到的理解：“我知道你認為你已經(jīng)理解了我所說的內(nèi)容，但是我并不能肯定你已認識到你所聽到的并不是我所想要的?！?BR> 11.1 需求分析
需求分析是一種軟件工程活動，它在系統(tǒng)級軟件分配和軟件設計間起到橋梁的作用(如圖11－1所示)。需求分析使得系統(tǒng)工程師能夠刻劃出軟件的功能和性能、指明軟件和其他系統(tǒng)元素的接口、并建立軟件必須滿足的約束。需求分析允許軟件工程師(在這種角色中經(jīng)常稱為分析員)精化軟件分解模塊，并建造將被軟件處理的數(shù)據(jù)、功能、和行為模型。需求分析為軟件設計者提供了可被翻譯成數(shù)據(jù)、體系結構、界面和過程設計的模型，最后，需求規(guī)約為開發(fā)者和客戶提供了軟件建造完后質(zhì)量評估的依據(jù)。
軟件需求分析可被劃分成5個工作階段：(1)問題分析，(2)問題評估和方案綜合，(3)建模，(4)規(guī)約，和(5)復審。
初始時，分析員研究系統(tǒng)規(guī)約(如果存在的話)和軟件項目計劃，并在系統(tǒng)語境內(nèi)理解軟件和復審，從而生成計劃軟件范圍的估算。接著，必須建立針對分析的相互通信方式，以使得問題分析得到保證。分析員的目標是對用戶/客戶認識到的基本問題要素進行識別。
問題評估和方案綜合是分析工作的下一個主要關注點，分析員必須定義所有外部可觀察到的數(shù)據(jù)對象，評估信息流和內(nèi)容；定義并詳細闡述所有軟件功能；在影響系統(tǒng)的事件的語境內(nèi)理解軟件行為；建立系統(tǒng)界面特征；以及揭示其他設計約束。這些任務中的每一個旨在描述問題，以便可以綜合出全面的方法或解決方案。
例如，汽車零件的主要供應商需要一個庫存控制系統(tǒng)，分析員發(fā)現(xiàn)與當前的手工系統(tǒng)相關的問題包括：(1)不能快速地獲得部件的狀況；(2)更新卡片文件需要2或3天的工作量；(3)由于沒有辦法查找相關廠商的部件信息而使得對同一廠商同一貨品多次再訂貨，等等。一旦問題被標識出來，分析員將確定新系統(tǒng)該產(chǎn)生什么信息，以及將提供什么信息給系統(tǒng)①，例如，客戶希望得到指明什么零件被從庫存中取出以及還剩余多少相似零件的日報表?？蛻糁该饕坏┊斣摿慵x開倉庫時庫存管理員就該記載每個零件的標號。
通過對當前問題和希望的信息(輸入和輸出)進行的評估，分析員開始綜合一個或多個解決方案。為了便于開始，必須詳細地定義系統(tǒng)的數(shù)據(jù)、處理功能和行為。一旦已經(jīng)建立這些信息，就該考慮針對實現(xiàn)的基本體系結構?？蛻?服務器方法似乎是合適的，但是，它確實屬于在軟件計劃中概括的范圍嗎？似乎需要一個數(shù)據(jù)庫管理系統(tǒng)，但是，該數(shù)據(jù)庫系統(tǒng)真的是用戶/客戶需要的嗎？繼續(xù)評估和綜合的過程，直至分析員和客戶均確信針對后面的開發(fā)步驟軟件確實已被適當?shù)乜虅澚恕?BR> 貫穿整個評估和綜合過程，分析員的主要焦點是“什么(what)”，而不是“怎么做(how)”，系統(tǒng)會產(chǎn)生和使用什么數(shù)據(jù)？系統(tǒng)必須完成什么功能？將定義什么界面？會應用什么約束？等。②
在問題評估和綜合解決方案的活動中，分析員創(chuàng)建系統(tǒng)模型，以便可以更好地理解數(shù)據(jù)和控制流、處理功能和操作行為、以及信息內(nèi)容。模型是軟件設計的基礎，也是創(chuàng)建軟件規(guī)約的基礎。
重要的是要注意，在本階段要得到詳細的規(guī)約是不可能的。客戶可能并不能精確地肯定需要什么，開發(fā)者可能不能肯定可用什么特定的方法來適當?shù)赝瓿晒δ芎托阅?。由于這些以及許多其他理由，可以采用一種可選擇的需求分析方法——原型法，(第2章)，本章后面我們將討論原型法。
11.2通信技術
軟件需求分析中的相互通信總是要在兩方或多方間進行?？蛻粲心硞€問題需要基于計算機的解決方案，開發(fā)者要要針對客戶的請求提供幫助，這時便產(chǎn)生了通信需求。但是，正如我們已經(jīng)提到，從相關通信、交流到理解的道路經(jīng)常是充滿坎坷的。
11.2.1 過程的啟動
客戶和開發(fā)者之間最常用的交流方式以及開始相互通信過程的技術是進行預備會議或訪談。在軟件工程師(分析員)和客戶間的第一次會議可與兩個青年間的第一次約會的笨拙程度相比較，沒有人知道該說什么或問什么；雙方均擔心他們所說的會被誤解；雙方均在考慮最終談話將導向何處(雙方在這里可能有完全不同的期望)；雙方均希望能控制事情的進程；而同時，雙方均希望能夠獲得成功。