第3章軟件需求分析基礎(chǔ)-文庫(kù)吧
2025-07-17 15:26 本頁(yè)面
【正文】 器方法似乎是合適的，但是它確實(shí)屬于軟件計(jì)劃的范圍嗎？似乎需要一個(gè)數(shù)據(jù)庫(kù)管理系統(tǒng)，但是，該數(shù)據(jù)庫(kù)系統(tǒng)真的是用戶需要的嗎？繼續(xù)這種評(píng)估和綜合的過(guò)程，直至分析員和客戶均確信針對(duì)后面的開(kāi)發(fā)步驟軟件確實(shí)已被適當(dāng)?shù)乜虅澚恕? ? 在整個(gè)評(píng)估和綜合過(guò)程中，分析員的主要焦點(diǎn)是 “ 做什么 ” ，而不是 “ 怎么做 ” 。 ? 在問(wèn)題評(píng)估和綜合解決方案的活動(dòng)中，系統(tǒng)分析員創(chuàng)建系統(tǒng)模型，以便可以更好地理解數(shù)據(jù)流和控制流、處理功能和操作行為以及信息內(nèi)容。 4. 系統(tǒng)分析員的主要能力 ? 在整個(gè)系統(tǒng)分析活動(dòng)中，系統(tǒng)分析員起著關(guān)鍵的作用，其本人應(yīng)該具備突出的能力，如： ? 能掌握抽象概念，能對(duì)其進(jìn)行分類，能從中綜合出解的能力； ? 能從沖突或者混淆中吸取恰當(dāng)事實(shí)的能力； ? 能弄清用戶環(huán)境的能力； ? 能為用戶系統(tǒng)恰當(dāng)配置軟硬件的能力 ? 能較好地用書面和口頭形式進(jìn)行溝通的能力 ? 有 “ 從樹(shù)木見(jiàn)森林 ” 的能力。 需求獲取 ? 軟件需求分析中需要很好的的相互溝通，溝通總是要在兩方或多方間進(jìn)行。 ? 客戶和系統(tǒng)分析員之間最常用的交流方式，是通過(guò) 預(yù)備會(huì)議 或 訪談 進(jìn)行的。 ? 獲取用戶需求的主要方法是調(diào)查研究。 ? 做好準(zhǔn)備 ? 制定調(diào)研計(jì)劃 ? 準(zhǔn)備調(diào)研資料 ? 訪談?dòng)脩? ? 寫調(diào)研報(bào)告 ? 評(píng)審 ? 系統(tǒng)分析員所問(wèn)的第一組問(wèn)題可以關(guān)注客戶、整體目標(biāo)和收益。 ? 接下來(lái)的下一組問(wèn)題使得系統(tǒng)分析員能夠?qū)?wèn)題做更好的理解，使得客戶能夠表達(dá)其關(guān)于解決方案的感覺(jué)， ? 最后一組問(wèn)題關(guān)注于會(huì)議的效果。 FAST方法 ? 也可以采用一種面向團(tuán)隊(duì)的需求收集方法，該方法被應(yīng)用在分析和規(guī)約的早期階段，被稱為便利的應(yīng)用規(guī)約技術(shù)，即 FAST技術(shù) 。 ? 該方法鼓勵(lì)建立客戶和系統(tǒng)分析員之間的合作，由他們共同工作來(lái)標(biāo)識(shí)問(wèn)題、提出解決方案的要素、商議不同的方法以及刻畫出初步的解決方案需求。 FAST方法的基本原則 ? 在中立的地點(diǎn)舉行會(huì)議，由系統(tǒng)分析員和客戶出席。 ? 建立準(zhǔn)備和參與會(huì)議的規(guī)則。 ? 建議一個(gè)足夠正式的議程，以便可以對(duì)所有重要的、而又是足夠非正式的問(wèn)題進(jìn)行自由交流。 ? 有一個(gè)“協(xié)調(diào)者”控制會(huì)議過(guò)程。 ? 使用一種“定義機(jī)制” 記錄有關(guān)信息。 ? 會(huì)議的目標(biāo)是標(biāo)識(shí)問(wèn)題、提出解決方案的要素、商議不同的方法以及在有利于完成目標(biāo)的氛圍中，刻畫出初步的解決方案需求。 ? 在過(guò)去 20年，研究者已經(jīng)開(kāi)發(fā)出一些實(shí)用分析方法及相應(yīng)的建模符號(hào)，每種分析方法有獨(dú)特的觀點(diǎn)，然而，所有分析方法都遵循以下操作原則： ? 必須表示可理解的問(wèn)題信息域。 ? 必須定義軟件將完成的功能。 ? 必須表示軟件的行為。 ? 必須劃分描述信息、功能和行為的模型，從而能以層次的方式揭示細(xì)節(jié)。 ? 分析過(guò)程應(yīng)該從要素信息移向細(xì)節(jié)實(shí)現(xiàn)。 ? 除了上面提到的操作性分析原則， Davis提出了一組針對(duì)需求工程的指導(dǎo)性原則： ? 在開(kāi)始建立分析模型前，先充分理解問(wèn)題。 ? 開(kāi)發(fā)原型，使得用戶能夠了解如何進(jìn)行人機(jī)交互。 ? 記錄每個(gè)需求的起源及原因。 ? 使用多個(gè)需求視圖。建立數(shù)據(jù)、功能和行為模型，為軟件工程師提供三種不同的視圖。 ? 給需求賦予優(yōu)先級(jí)。 ? 努力刪除歧義性。 ? 所有的應(yīng)用軟件均可稱為 數(shù)據(jù)處理系統(tǒng) 。 ? 信息流 表示了數(shù)據(jù)和控制在系統(tǒng)中流動(dòng)時(shí)的變化方式，輸入對(duì)象被變換為中間信息，這些信息被進(jìn)一步變換為輸出。沿著這個(gè)變換路徑，可能從現(xiàn)存的數(shù)據(jù)存儲(chǔ)中引入附加的信息。 ? 數(shù)據(jù)的變換 是程序必須完成的功能或子功能，在兩個(gè)變換（功能）間流動(dòng)的數(shù)據(jù)和控制定義了每個(gè)功能的接口。 ? 信息結(jié)構(gòu) 表示了各種數(shù)據(jù)和控制項(xiàng)的內(nèi)部組織， ? 我們創(chuàng)建模型，以獲得對(duì)將要建造的實(shí)際實(shí)體有更好的理解。 ? 要對(duì)軟件變換的信息、對(duì)變換發(fā)生的功能（和子功能）、以及對(duì)變換發(fā)生時(shí)的系統(tǒng)行為進(jìn)行建模。 ? 在軟件需求分析階段，我們創(chuàng)建系統(tǒng)模型，這些模型著重于描述系統(tǒng)必須做什么而不是如何去做。 ? 我們常使用圖形符號(hào)創(chuàng)建模型。 ? 功能模型： 記錄軟件的變換信息，為了達(dá)到此目標(biāo)必須至少完成三個(gè)常見(jiàn)功能：輸入、處理和輸出。 ? 行為模型： 一個(gè)計(jì)算機(jī)程序總是存在于某個(gè)狀態(tài)，僅當(dāng)某事件發(fā)生時(shí)才被改變。行為模型創(chuàng)建了軟件狀態(tài)的表示，以及導(dǎo)致軟件狀態(tài)變化的事件表示。 需求分析階段創(chuàng)建模型 的作用 ? 模型幫助分析員理解系統(tǒng)的信息、功能和行為，因此，使得需求分析任務(wù)更容易實(shí)現(xiàn)。 ? 模型變成了復(fù)審的焦點(diǎn)，因此，也成為確定規(guī)約的完整性、一致性和精確性的重要依據(jù)。 ? 模型變成了設(shè)計(jì)的基礎(chǔ)，為設(shè)計(jì)者提供了軟件要素的表示視圖，該表示可被轉(zhuǎn)化到實(shí)現(xiàn)中去。 ? 實(shí)際的問(wèn)題經(jīng)常太大而且復(fù)雜難于進(jìn)行整體理解，我們往往將這樣的問(wèn)題劃分為易于理解的子問(wèn)題，并建立各子問(wèn)題間的接口，以便完成整個(gè)功能。 ? 第四條操作性分析原則 建議劃分軟件的信息、功能和行為域。 需求規(guī)格說(shuō)明 ? 軟件需求規(guī)格說(shuō)明 是分析任務(wù)的 最終產(chǎn)物 ，美國(guó)國(guó)家標(biāo)準(zhǔn)局、 IEEE以及美國(guó)防部門均已提出了軟件需求規(guī)約（以及其他軟件工程文檔）的候選格式。 ? 軟件需求規(guī)格說(shuō)明必須正確地定義所有的軟件需求；
高考資料相關(guān)推薦
鄂ICP備17016276號(hào)-1