云大軟件工程實驗二 軟件需求

實驗報告課程：軟件工程實驗任課教師：指導(dǎo)教師：序號：專業(yè)：學(xué)號：姓名：成績：實驗二軟件需求找出對于計算機系統(tǒng)來說四種可能要定義的需求，并簡要描述之答:可能要定義的需求如下：功能需求:對系統(tǒng)應(yīng)該提供的服務(wù)和功能、如何對輸入做出反應(yīng)以及在特定條件下的行為的描述。在某些情況下，功能需求可能還要明確聲明系統(tǒng)不應(yīng)該做什么。非功能需求：指不直接與系統(tǒng)具體功能相關(guān)的一類需求。換言之，它們定義了對系統(tǒng)提供的服務(wù)或功能的約束。包括可靠性、存儲空間、時間約束、開發(fā)過程的約束、標(biāo)準(zhǔn)等。用戶需求：從用戶的角度來描述系統(tǒng)功能和非功能需求，以便讓不具備專業(yè)技術(shù)方面知識的用戶看懂。它是用自然語言、圖表和直觀的圖形來敘述關(guān)于系統(tǒng)需要提供那些服務(wù)以及系統(tǒng)操作受到那些約束。系統(tǒng)需求：比用戶需求更詳細(xì)的需求描述，是系統(tǒng)實現(xiàn)的基本依據(jù)。詳細(xì)地給出系統(tǒng)將要提供的服務(wù)以及系統(tǒng)所受到的約束，系統(tǒng)需求應(yīng)該陳述系統(tǒng)應(yīng)該做什么而不包括系統(tǒng)應(yīng)該如何實現(xiàn)。討論用自然語言定義用戶需求和系統(tǒng)需求存在的問題。使用一個小例子說明格式化的自然語言能否幫助避免一些表述困難答：(1)用自然語言定義用戶需求和系統(tǒng)需求存在的問題：自然語言的解釋依賴于讀者和作者對于同一個詞語有一致的解釋，因為自然語言存在二義性，因此會造成語義理解的偏差；一個自然語言的需求描述隨意性很大，能以完全不同的方式來描述相同的事物，用戶很難判斷什么時候需求是一樣的，什么時候需求是不一樣的；不存在一個簡單的方法，使自然語言書寫的需求模塊化，這種形式描述的需求極難發(fā)現(xiàn)相關(guān)性；用自然語言書寫的需求描述容易引起誤會，而這些誤會可能在軟件過程的后期才發(fā)現(xiàn)，這時再去解決問題費用將會相當(dāng)高。例子說明：例如，“Shoesmustbeworn”有兩種解釋：“鞋子必須被穿”，“一個人必須要穿鞋”，這樣就存在了二義性。如果使用格式化的自然語言，我們可以說“Onepeoplewearpairofshoes”，這樣就可以避免二義性。使用格式化的自然語言描述除去了描述中的一些問題，這是在描述中減少了可變性和需求被有效劃分的結(jié)果。但在描述中還是會存在一些二義性。開發(fā)一個軟件系統(tǒng)管理進(jìn)入診所治療的病人的記錄。記錄內(nèi)容包含所有一般性的病人監(jiān)控記錄（溫度，血壓等）、所進(jìn)行的處置、病人的反映等。處置完畢，如果病人需要住院觀察，將這些記錄傳給負(fù)責(zé)的住院大夫。由他/她來維護(hù)病人的完整記錄。請找出主要的視點，用視點層次圖組織這些視點。答：（1）主要的視點有：病人、記錄、住院大夫、管理員（2）視點層次圖：分別對上下文模型、行為模型、數(shù)據(jù)模型、對象模型、結(jié)構(gòu)化方法進(jìn)行分析說明其優(yōu)劣。答：（1）上下文模型：優(yōu)點:在需求導(dǎo)出和分析過程的早期階段，應(yīng)該界定系統(tǒng)的邊界,定義系統(tǒng)的上下文是有意義的，由于系統(tǒng)使用的社會性和組織性，系統(tǒng)邊界的確定充滿了非技術(shù)性因素。比如，可能需要一種劃分，使得分析過程可以完全在一個地點完成;或者需要一種劃分使得成本增長、部門必須擴張才能完成系統(tǒng)的設(shè)計和實現(xiàn)。缺點:體系結(jié)構(gòu)模型描述系統(tǒng)的環(huán)境，不描述其他子系統(tǒng)之間的關(guān)聯(lián)關(guān)系，也不描述要分析的系統(tǒng)本身。外部系統(tǒng)可能產(chǎn)生數(shù)據(jù)供該系統(tǒng)使用，同時也使用該系統(tǒng)生成的數(shù)據(jù)。這些周邊子系統(tǒng)可能與該系統(tǒng)共享數(shù)據(jù)，可能與系統(tǒng)直接相連，或通過網(wǎng)絡(luò)相連，或者根本就不連在一起。在空間上，這些子系統(tǒng)可能與該系統(tǒng)同在一處，也可能分處在不同的建筑物中，所有的這些因素都將影響系統(tǒng)的需求，必須加以考慮。行為模型：優(yōu)點:行為模型用來描述系統(tǒng)的所有行為。主要有兩類，一類是數(shù)據(jù)流模型，用來描述系統(tǒng)中的數(shù)據(jù)處理過程，另一類是狀態(tài)機模型，用以描述系統(tǒng)如何對事件做出響應(yīng)。數(shù)據(jù)流模型的價值主要體現(xiàn)在它對系統(tǒng)中的數(shù)據(jù)和數(shù)據(jù)在特定的過程中的流動的跟蹤和記錄，有助于系統(tǒng)分析人員理解系統(tǒng)中到底發(fā)生了什么。狀態(tài)機模型尤其適合用來描述實時系統(tǒng)。缺點:數(shù)據(jù)流模型在分析模型中，對程序功能模塊的加工只能由手工處理或借助計算機來處理。狀態(tài)機模型的主要問題在于可能的狀態(tài)數(shù)會劇增。數(shù)據(jù)模型：優(yōu)點:最廣泛采用的數(shù)據(jù)建模技術(shù)是實體-關(guān)系-屬性建模(即ERA建模)，它描述數(shù)據(jù)實體、關(guān)聯(lián)屬性以及實體間的關(guān)系。數(shù)據(jù)模型常常和數(shù)據(jù)流模型一起用來描述系統(tǒng)的信息結(jié)構(gòu)。缺點:UML沒有為數(shù)據(jù)模型引進(jìn)專門的描述符號，只可以用UML類模型以及在類之間建立名字關(guān)聯(lián)的方法表示出數(shù)據(jù)模型。ERA模型缺乏對細(xì)節(jié)的描述，還需要對實體、關(guān)系、屬性做更詳細(xì)的描述。對象模型：優(yōu)點:在需求分析階段開發(fā)的對象模型既可以用來表達(dá)系統(tǒng)數(shù)據(jù)也可以用來表達(dá)對數(shù)據(jù)的處理，在這一方面，對象模型可以看成是數(shù)據(jù)流和語義數(shù)據(jù)模型的結(jié)合，同時，對象模型在說明系統(tǒng)實體是如何分類和復(fù)用的時候也非常有用。對于某些系統(tǒng)而言，對象模型是一種映射真實世界中實體及對其操作的自然方式。缺點:某些抽象的高層實體(如圖書館、醫(yī)療記錄系統(tǒng)或字處理器)就很難使用對象模型，它們沒有必要擁有一個簡單的界面以包容獨立的屬性和操作。結(jié)構(gòu)化方法：優(yōu)點:結(jié)構(gòu)化的方法，如結(jié)構(gòu)化系統(tǒng)分析和面向?qū)ο蠓治龅龋峁┝艘粋€詳細(xì)的系統(tǒng)建?？蚣埽鳛樾枨髮?dǎo)出和分析的一部分。絕大部分結(jié)構(gòu)化方法有自己常用的系統(tǒng)模型集，這些方法通常是先定義一個用來導(dǎo)出模型的過程和作用于模型的一組規(guī)則和指南，然后再建立系統(tǒng)的標(biāo)準(zhǔn)化文檔。缺點:不提供對非功能性系統(tǒng)需求的有效理解和建模；不提供對用戶選擇的合適方法指導(dǎo)，也沒有對方法適用的特殊環(huán)境的忠告；往往產(chǎn)生大量文檔，系統(tǒng)需求的要素被隱藏在一大堆具體細(xì)節(jié)的描述中；產(chǎn)生的模型太注重細(xì)節(jié)以致用戶覺得難以理解，因而很難去驗證這些模型的真實性。對電子郵件系統(tǒng)中的數(shù)據(jù)處理進(jìn)行建模，并分別為郵件發(fā)送和郵件接收建立處理模型。答:可以使用數(shù)據(jù)流模型來進(jìn)行建模，它是描述系統(tǒng)數(shù)據(jù)處理的很直觀的方式，模型中的符號分別表示功能模塊處理、數(shù)據(jù)的存儲和數(shù)據(jù)在功能模塊之間的流動。(1)電子郵件系統(tǒng)數(shù)據(jù)處理模型：(2)郵件發(fā)送處理模型:新建郵件(3)郵件接收處理模型:新建郵件簡要說明Z方法在軟件工程中的應(yīng)用。答：軟件工程中的形式化方法是一種基于數(shù)學(xué)的軟件開發(fā)方法，它可應(yīng)用于軟件工程的各個階段。Z本身是一個書寫規(guī)格說明的語言，或者說是一種表示法，它是目前人們非常感興趣的一種規(guī)格說明方法。Z是一種形式化語言，在需要時開發(fā)者可以嚴(yán)格地驗證規(guī)格說明的正確性，Z語言的模式是基本結(jié)構(gòu)，用于描述系統(tǒng)的狀態(tài)和操作。使用Z語言可以降低軟件開發(fā)費用，雖然用Z寫規(guī)格說明所需用的時間比使用非形式化技術(shù)要多，但開發(fā)過程所需要的總時間卻減少了。雖然用戶無法