第一篇：軟件工程實驗心得體會

軟件工程實驗心得體會

軟件工程實驗心得體會一：軟件工程實驗心得體會

經過這學期軟件工程實驗的學習，深深感到用戶需求對軟件的重要性。成功的軟件產品是建立在成功的需求基礎之上的，而高質量的需求來源于用戶與開發人員之間有效的溝通與合作。當用戶有一個問題可以用計算機系統來解決，而開發人員開始幫助用戶解決這個問題，溝通就開始了。

需求獲取可能是最困難、最關鍵、最易出錯及最需要溝通交流的活動。對需求的獲取往往有錯誤的認識：用戶知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求，只要問用戶系統的目標特征，什么是要完成的，什么樣的系統能適合商業需要就可以了，但是實際上需求獲取并不是想象的這樣簡單，這條溝通之路布滿了荊棘。首先需求獲取要定義問題范圍，系統的邊界往往是很難明確的，用戶不了解技術實現的細節，這樣造成了系統目標的混淆。

其次是對問題的理解，用戶對計算機系統的能力和限制缺乏了解，任何一個系統都會有很多的用戶或者不同類型的用戶，每個用戶只知道自己需要的系統，而不知道系統的整體情況，他們不知道系統作為一個整體怎么樣工作效率更好，也不太清楚那些工作可以交給軟件完成，他們不清楚需求是什么，或者說如何以一種精確的方式來描述需求，他們需要開發人員的協助和指導，但是用戶與開發人員之間的交流很容易出現障礙，忽略了那些被認為是'很明顯'的信息。最后是需求的確認，因為需求的不穩定性往往隨著時間的推移產生變動，使之難以確認。為了克服以上的問題，必須有組織的執行需求的獲取活動。

需求獲取活動要完成的任務或者步驟的過程如下：

1、編寫項目視圖和范圍文檔

系統的需求包括四個不同的層次：業務需求、用戶需求和功能需求、非功能性需求。業務需求說明了提供給用戶新系統的最初利益,反映了組織機構或用戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。用戶需求文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。功能需求定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。

非功能性需求是用戶對系統良好運作提出的期望，包括了易用性、反應速度、容錯性、健壯性等等質量屬性。需求獲取就是根據系統業務需求去獲得系統用戶需求，然后通過需求分析得到系統的功能需求和非功能需求。項目視圖和范圍文檔就是從高層次上描述系統的業務需求，應該包括高層的產品業務目標，評估問題解決方案的商業和技術可行性,所有的使用實例和功能需求都必須遵從的標準。而范圍文檔定義了項目產品所包括的所有工作及產生產品所用的過程。項目相關人員對項目的目標和范圍能達成共識,整個項目組都應該把注意力集中在項目目標和范圍上。

2、用戶群分類

系統用戶在很多方面存在著差異，例如：使用系統的頻度和程度、應用領域和計算機系統知識、所使用的系統特性、所進行的業務過程、訪問權限、地理上的布局以及個人的素質和喜好等等。根據這些差異，你可以把這些不同的用戶分成不同的用戶類。與ULM中Usecase的Actor概念一樣，用戶類不一定都指人，也可以包括其他應用系統、接口或者硬件，這樣做使得與系統邊界外的接口也成為系統需求。將用戶群分類并歸納各自特點，并詳細描述出它們的個性特點及任務狀況，將有助于需求的獲取和系統設計。

3、建立核心隊

通常用戶和開發人員不自覺的都有一種'我們和他們'的想法，產生一種對立關系，把彼此放在對立面，每一方都定義自己的'邊界'，只想自己的利益而忽略對方的想法。他們通過文檔、記錄和對話來溝通，而不是作為一個合作的整體去識別和確定需求完成任務。實踐證明這樣的方法是不正確的，不會給雙方帶來一點益處,良好的溝通關系沒有建立導致了誤解和忽略重要的信息。只有當雙方參與者都明白要成功自己需要什么，同時也知道要成功對方需要什么時，才能建立起一種合作關系。

為了建立合作關系通常采取一種組隊的方式來獲取需求，建立一個由用戶代表和開發人員組成的聯合小組作為需求獲取的核心隊伍。聯合小組將負責識別需求、分析解決方案和協商分歧，小組成員可以采用會議、電子郵件、綜合辦公系統等方式進行交流，但交流時應注意以下原則：小組會議應該由中立方來組織和主持，用戶和開發人員都要參加;交流預先要確定準備和參與的規則;議題要明確并覆蓋所有關鍵點，但信息來源應該自由;交流目標要明確，并告知所有的成員。

4、確定使用實例

從用戶代表處收集他們將使用系統完成所需任務的描述，討論用戶與系統間的交互方式和對話要求，這就是使用實例，一個單一的使用實例可能包括完成某項任務的許多邏輯相關任務和交互順序。使用實例方法給需求獲取帶來的好處來自于該方法是用以任務為中心和以用戶為中心的觀點，比起使用以功能為中心和以開發者為中心的方法，使用實例方法可以使用戶更清楚地理解和認識到新系統允許他們做什么和怎么做。描寫使用實例的時候要注意使用簡潔直白的表述，盡量使用主動語態，用'系統'或者'用戶'作為主語，比如'用戶提交用戶密碼，系統驗證用戶密碼是否正確'，還有一點在描述中不要設計界面細節，比如'用戶從下拉框中選擇產品類型'。使用實例為以后寫用例場景描述中的基本路徑和擴展路徑提供了素材。

5、分析用戶工作流程

分析用戶工作流程觀察用戶執行業務任務的過程，通過分析使用實例得到系統的用例圖。編制用例圖文檔將有助于明確系統的使用實例和功能需求，統一建模語言的使用有助于與用戶進一步交流。每個用例的描述應包括：編號,為每個用例分配一個唯一的編號，為需求的追溯提供了方便;參與者，與這個用例交互的 actor;前置條件，開始用例前所必須具備的系統狀態;后置條件，用例完成后系統達到的狀態;基本路徑，用例完成的關鍵路徑，也是用戶期望的路徑;擴展點，基本路徑的分枝，表示意外情況;字段說明，路徑中名稱的進一步分解說明，對以后類屬性的定義和數據庫字段設計起作用;設計約束，實現用例的非功能約束。

6、檢查問題報告

通過檢查當前已經運行系統的問題報告來進一步完善需求客戶的問題報告及補充需求為新系統或新版本提供了大量豐富的改進及增加特性的想法，負責提供用戶支持及幫助的人能為收集需求過程提供極有價值的信息。

7、需求重用

如果客戶要求的功能與已有的系統很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。業務建模和領域建模式需求重用的最好方法，像分析模式和設計模式一樣，需求也有自己的模式。

總結 ：經過一學期的軟工實驗，深刻感到其重要性的同時也學到了不少的東西，將對我在今后的軟件開發過程中起極大的作用

>軟件工程實驗心得體會二：軟件工程實驗心得>>（789字）

早在我選擇民政職業技術學院就讀軟件開發與項目管理這門專業的時候，我一直認為軟件開發無非是努力的敲代碼，從敲代碼的過程中去體會各行代碼的意思和用處，在沒學軟件工程時我一直都是努力的敲代碼去學習軟件開發這門專業。在大一的時候我敲代碼的激情很好，但是到大二的時候就出現問題了，我根本就不喜歡敲代碼了，看見代碼就頭疼。所以感覺厭惡這門專業，對學習也不感興趣了。而且，還有一件更頭疼的事是在寫一個簡單的程序時竟然老是出錯，難一點的，復雜一點的程序竟然無從下手。但是去看程序的參考答案時都看得懂，又感覺很容易。學了軟件工程以后，我就感覺我以前的學習方法是錯誤的。以前我只注重于代碼，而不注重理論知識以及編程的思路，程序的架構。以至于在些程序時沒有寫程序的思路，不能形成程序的架構。只想到看腦袋里是否有與此類似的代碼。越想程序越亂，最后腦袋里一片空白。不知道程序從哪個方面下手了。

軟件工程這門課程是做軟件開發的人必學的課程，通過學這門課程，程序員就會注重軟件開發的理論知識，以及做項目開發的思路。學了這門課程后你寫程序就不會去盲目的去套用代碼，而是理清此程序的架構以及思路。程序該從什么時候開始，什么時候結束。在中間需要添加什么樣的功能，以完善該軟件。其實學軟件工程并不難，而且很容易。軟件工程與日常生活聯系起來的話，就是在一天中你該先做什么，后做什么。理解了先做什么，后做什么了以后寫程序就不是那么難了，再復雜的程序也可以分成幾大塊。你理清程序的思路后就可以一步步的解決其中的難題，最終實現軟件的功能。如果沒學軟件工程不知道理清程序的思路的話，做一個大的項目開發，那么多的代碼，沒有一個很好的結構，最終只會導致程序混亂，錯誤百出，知道代碼再多也會素手無策的。

總而言之，作為一個程序員學習軟件工程這門課程是至關必要的，如果沒學習軟件工程，你就不會做項目開發，也不可能開發出一個完善的軟件出來。

>軟件工程實驗心得體會三：軟件工程實驗心得>>（1261字）

曾經看過一本書叫《道法自然》，內容略記得一二，但我最欣賞的是它的書名。軟件設計沒什么太神秘有東西，只要用心體會，其實一切都很自然。軟件的設計之“道”，也不在于設計有多么的華麗、精巧，而在于其樸實、自然，最終達到“以無招勝有招”，進入一個全新的境界。

一、軟件設計理論的層次

以我的拙見，軟件設計領域中的各種概念，可以分為以下幾個層次來進行理解：

1、軟件設計的目的：重用性、擴展性。

這是最高的層次，是應對軟件危機的需要。

2、設計原則：低耦合、高聚合。

各種軟件設計的原則，如依賴倒置原則、單一職則原則、面向接口等，以及各種設計模式，其根本的目的其實只是為了降低耦合這么簡單。因為只有低耦合才能更好的適應變化，更好的重用和擴展。

3、實現方法：運用設計模式封裝變化、降低耦合。

設計模式只是用來“封裝變化、降低耦合”的工具而已。它是面向對象設計時代的產物，其本質就是充分運用面向對象的三個特性，即：封裝、繼承和多態，進行靈活的組合運用。

二、關于耦合1、耦合的粒度

耦合無論如何也是不可避免的。當我們實現接口、繼承父類的時候，就會不可避免的產生耦合。耦合是有不同粒度的，我們解耦到什么粒度為止，我認為應以模塊的重用粒度為準。盡量解除重用模塊或對象之間的耦合。而重用模塊之內的耦合，應屬于聚合的范疇，所以不要盲目的去解耦，否則就陷入了誤區。

2、解耦的原理

怎樣才能解耦呢，或者說為什么各種設計模式能達到解耦的目的呢?我覺得有以下幾個思路：

(1)將具體的東西抽象處理

(2)將分散的東西集中處理

而面向對象中的接口、繼承正為我們提供了這樣的一種機制。通過訪問接口或基類或抽象類，而不是具體的實現類，從而與具體的實現類達到了解耦的目的。我們還可以設計一些控制類，像潤滑劑一樣，協調各實現類之間的訪問，也可以達到耦的目的。

事實上，各種設計模式的基本思想也就是這樣。創建型模式是為了解除創建對象時產生的耦合，實際上是解除對類稱名的依賴，而結構型和行為型是為了解除對象屬性或方法的直接調用。不管什么設計模式，都是將對具體實現類的訪問提升為對接口、基類或用于協調的控制類的訪問。

三、關于接口

這一節更具體，談一談接口，因為使用接口是軟件設計的重要手段，但已經不屬于“道”了~

1、接口與繼承

接口描述的是對象某一個方面行為特征。使用接口與使用繼承關系各有優缺點，使用子類繼承可以繼承父類的功能，體現了重用的精神。而接品更加靈活，因為它解除了子類與父類之間的高度耦合，它體現在靈活擴展的精神。

2、接口與純虛類

理論上接口可以由純虛基類實現類似的功能，那為什么還我們不去掉接口的概念，而直接使用虛類呢?

接口存在的理由就是它更加靈活，關系簡單，易于理解。比如一個類可以實現十幾個甚至幾十個接口，但一般開發工具只支持單繼承(由于多繼承太容易導致混亂和沖突)，如果要繼承十幾層，系統結構想必會無法理解了，我以為這是接口存在的最重要的原因。

如果接口和虛類繼承結合使用，可以產生強大的威力，這也是許多設計模式的“殺手锏”。

以上算是總結一下自己的心得。肯定有不少片面之處，請各位指教。

第二篇：軟件工程實驗的心得體會

軟件工程實驗的心得體會

----獲取用戶需求的溝通技巧

經過這學期軟件工程實驗的學習，深深感到用戶需求對軟件的重要性。成功的軟件產品是建立在成功的需求基礎之上的，而高質量的需求來源于用戶與開發人員之間有效的溝通與合作。當用戶有一個問題可以用計算機系統來解決，而開發人員開始幫助用戶解決這個問題，溝通就開始了。

需求獲取可能是最困難、最關鍵、最易出錯及最需要溝通交流的活動。對需求的獲取往往有錯誤的認識：用戶知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求，只要問用戶系統的目標特征，什么是要完成的，什么樣的系統能適合商業需要就可以了，但是實際上需求獲取并不是想象的這樣簡單，這條溝通之路布滿了荊棘。首先需求獲取要定義問題范圍，系統的邊界往往是很難明確的，用戶不了解技術實現的細節，這樣造成了系統目標的混淆。

其次是對問題的理解，用戶對計算機系統的能力和限制缺乏了解，任何一個系統都會有很多的用戶或者不同類型的用戶，每個用戶只知道自己需要的系統，而不知道系統的整體情況，他們不知道系統作為一個整體怎么樣工作效率更好，也不太清楚那些工作可以交給軟件完成，他們不清楚需求是什么，或者說如何以一種精確的方式來描述需求，他們需要開發人員的協助和指導，但是用戶與開發人員之間的交流很容易出現障礙，忽略了那些被認為是“很明顯”的信息。最后是需求的確認，因為需求的不穩定性往往隨著時間的推移產生變動，使之難以確認。為了克服以上的問題，必須有組織的執行需求的獲取活動。

需求獲取活動要完成的任務或者步驟的過程如下：

1、編寫項目視圖和范圍文檔

系統的需求包括四個不同的層次：業務需求、用戶需求和功能需求、非功能性需求。業務需求說明了提供給用戶新系統的最初利益,反映了組織機構或用戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。用戶需求文檔描述了用戶使用產品必須要完成的任務，這在使用實例文檔或方案腳本說明中予以說明。功能需求定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。

非功能性需求是用戶對系統良好運作提出的期望，包括了易用性、反應速度、容錯性、健壯性等等質量屬性。需求獲取就是根據系統業務需求去獲得系統用戶需求，然后通過需求分析得到系統的功能需求和非功能需求。項目視圖和范圍文檔就是從高層次上描述系統的業務需求，應該包括高層的產品業務目標，評估問題解決方案的商業和技術可行性,所有的使用實例和功能需求都必須遵從的標準。而范圍文檔定義了項目產品所包括的所有工作及產生產品所用的過程。項目相關人員對項目的目標和范圍能達成共識,整個項目組都應該把注意力集中在項目目標和范圍上。

2、用戶群分類

系統用戶在很多方面存在著差異，例如：使用系統的頻度和程度、應用領域和計算機系統知識、所使用的系統特性、所進行的業務過程、訪問權限、地理上的布局以及個人的素質和喜好等等。根據這些差異，你可以把這些不同的用戶分成不同的用戶類。與ULM中Usecase的Actor概念一樣，用戶類不一定都指人，也可以包括其他應用系統、接口或者硬件，這樣做使得與系統邊界外的接口也成為系統需求。將用戶群分類并歸納各自特點，并詳細描述出它們的個性特點及任務狀況，將有助于需求的獲取和系統設計。

3、建立核心隊

通常用戶和開發人員不自覺的都有一種“我們和他們”的想法，產生一種對立關系，把彼此放在對立面，每一方都定義自己的“邊界”，只想自己的利益而忽略對方的想法。他們通過文檔、記錄和對話來溝通，而不是作為一個合作的整體去識別和確定需求完成任務。實踐證明這樣的方法是不正確的，不會給雙方帶來一點益處,良好的溝通關系沒有建立導致了誤解和忽略重要的信息。只有當雙方參與者都明白要成功自己需要什么，同時也知道要成功對方需要什么時，才能建立起一種合作關系。

為了建立合作關系通常采取一種組隊的方式來獲取需求，建立一個由用戶代表和開發人員組成的聯合小組作為需求獲取的核心隊伍。聯合小組將負責識別需求、分析解決方案和協商分歧，小組成員可以采用會議、電子郵件、綜合辦公系統等方式進行交流，但交流時應注意以下原則：小組會議應該由中立方來組

織和主持，用戶和開發人員都要參加；交流預先要確定準備和參與的規則；議題要明確并覆蓋所有關鍵點，但信息來源應該自由；交流目標要明確，并告知所有的成員。

4、確定使用實例

從用戶代表處收集他們將使用系統完成所需任務的描述，討論用戶與系統間的交互方式和對話要求，這就是使用實例，一個單一的使用實例可能包括完成某項任務的許多邏輯相關任務和交互順序。使用實例方法給需求獲取帶來的好處來自于該方法是用以任務為中心和以用戶為中心的觀點，比起使用以功能為中心和以開發者為中心的方法，使用實例方法可以使用戶更清楚地理解和認識到新系統允許他們做什么和怎么做。描寫使用實例的時候要注意使用簡潔直白的表述，盡量使用主動語態，用“系統”或者“用戶”作為主語，比如“用戶提交用戶密碼，系統驗證用戶密碼是否正確”，還有一點在描述中不要設計界面細節，比如“用戶從下拉框中選擇產品類型”。使用實例為以后寫用例場景描述中的基本路徑和擴展路徑提供了素材。

7、分析用戶工作流程

分析用戶工作流程觀察用戶執行業務任務的過程，通過分析使用實例得到系統的用例圖。編制用例圖文檔將有助于明確系統的使用實例和功能需求，統一建模語言的使用有助于與用戶進一步交流。每個用例的描述應包括：編號,為每個用例分配一個唯一的編號，為需求的追溯提供了方便；參與者，與這個用例交互的actor；前置條件，開始用例前所必須具備的系統狀態；后置條件，用例完成后系統達到的狀態；基本路徑，用例完成的關鍵路徑，也是用戶期望的路徑；擴展點，基本路徑的分枝，表示意外情況；字段說明，路徑中名稱的進一步分解說明，對以后類屬性的定義和數據庫字段設計起作用；設計約束，實現用例的非功能約束。

5、檢查問題報告

通過檢查當前已經運行系統的問題報告來進一步完善需求客戶的問題報告及補充需求為新系統或新版本提供了大量豐富的改進及增加特性的想法，負責提供用戶支持及幫助的人能為收集需求過程提供極有價值的信息。

6、需求重用

如果客戶要求的功能與已有的系統很相似，則可查看需求是否有足夠的靈活性以允許重用一些已有的軟件組件。業務建模和領域建模式需求重用的最好方法，像分析模式和設計模式一樣，需求也有自己的模式。

小結 ：經過一學期的軟工實驗，深刻感到其重要性的同時也學到了不少的東西，將對我在今后的軟件開發過程中起極大的作用。

第三篇：軟件工程實驗

作業一

1.請畫出由下列文字描述的系統流程圖，請用Microsoft Visio 或Word軟件畫圖

設某城市招干考試成績統計系統。

考生分三個專業，不同專業考試科目不同：

法律專業---考政治、語文、法律

行政專業---考政治、語文、行政

財經專業---考政治、語文、財經學

每個考生在報名時登記姓名、地址、年齡和報考專業。報名后招干辦公室根據專業考生專業及地址在市區或郊區來編排準考證號碼和考場。考生參加考試后，輸入每個考生的各門課程的成績，并統計出每個考生三門課程的總成績。按準考證號的順序打印出考生考試成績單，分發給每個考生。各專業分別將考生按成績總分從高到低的次序排序，以便決定錄取名單。

作業二

畫考務處理系統的數據流圖。

考務處理系統功能如下：

(1)對考生送來的報名單進行檢查;(2)對合格的報名單編好準考證號后將準考證送給考生，并將匯總后的考生名單送給閱卷站;?3)對閱卷站送來的成績單進行檢查，并根據考試中心制定的合格標準審定合格者;(4)制作考生通知單(含成績及合格/不合格標志)送給考生;(5)按地區進行成績分類統計和試題難度分析，產生統計分析表。

作業三

1、請為某倉庫的管理設計一個ER模型。該倉庫主要管理零件（包括零件編號、名稱、顏色、重量）的定購和供應等事項。倉庫向工程項目（包括項目編號、項目名稱、開工日期）供應零件，并且根據需要向供應商（包括供應商編號、名稱、地址）定購零件。

2、畫復印機的狀態轉換圖 復印機的工作過程大致如下： 未接到復印命令時處于閑置狀態，一旦接到復印命令則進入復印狀態，完成一個復印命令規定的工作后又回到閑置狀態，等待下一個復印命令；

如果執行復印命令時發現沒紙，則進入缺紙狀態，發出警告，等待裝紙，裝滿紙后進入閑置狀態，準備接收復印命令；

如果復印時發生卡紙故障，則進入卡紙狀態，發出警告等待維修人員來排除故障，故障排除后回到閑置狀態。

作業四

請將上列給出的具有變換型的DFD圖導出它的軟件結構SC圖

作業五

某程序流程圖如下圖所示，請分別用N-S圖和PAD圖表示。

作業六

練習題：用判定表和判定樹表示“檢查訂貨單”偽碼 IF 客戶訂貨金額超過5000元 THEN IF 客戶拖延未還賒欠錢款超過60天 THEN 在償還欠款前不予批準

ELSE(拖延未還賒欠錢款不超過60天)發批準書，發貨單 ENDIF ELSE(客戶訂貨金額未超過5000元)IF 客戶拖延未還賒欠錢款超過60天 THEN 發批準書，發貨單，并發催款通知書 ELSE(拖延未還賒欠錢款不超過60天)發批準書，發貨單 ENDIF ENDIF

作業七

設計下列偽碼程序的語句覆蓋和路徑覆蓋測試用例： START

INPUT(A,B,C)IF A>5 THEN X=10 ELSE X=1 END IF IF B>10 THEN Y=20 ELSE Y=2 END IF IF C>15 THEN Z=30 ELSE Z=3 END IF PRINT(X,Y,Z)STOP

實習

請參考機票預訂系統實例 飛機票預訂系統.zip

一、課程實踐任務

學生自行分組選擇一個項目，完成一個實際軟件項目的分析、設計、開發、測試全過程，領會軟件工程的基本思想，明晰各個階段的主要任務，使用 MicroSoft Visio、Project、Rose、VSS、Power Designer 等計算機輔助軟件工具，采用規范化的軟件工程方法進行軟件項目的研發。

二、課程實踐的要求

第四篇：軟件工程實驗二

實驗二：需求分析報告

實驗學時：2

課后2學時

實驗類型：技能性

一、目的與任務

目的：明確需求分析任務的重要性，掌握需求分析的主要具的使用方法和步驟，寫出需求規格說明書。

二、實驗安排

1、裝有Offic軟件，Visio 2010的微機系統.2、實驗安排方式：本實驗為開放實驗，各組可同時進行實驗，每組8-10人。

三、實驗內容及步驟

1、選擇一個管理系統（人事管理系統、工資管理系統、學生檔案管理系統等）。

2、軟件工程的原理對該系統的問題進行分析；

3、分析系統的數據需求獲得當前系統的物理模型，然后抽象出當前系統的邏輯模型，再建立目標系統的邏輯模型；理出系統的數據流程圖；

4、用Visio 2010畫出該系統的數據流圖，用結構化分析方法對整個系統進行分析細化，用數據流圖描繪系統的邏輯模型，描繪信息在系統中流動和處理的情況；數據流圖是分析和設計的工具，它主要描述系統完成的功能而不是系統的物理實現。

5、在Microsoft Word文檔下寫出該系統的數據字典，用數據字典對人們不了解的條目進行解釋，對所有被加工引用的數據流和數據存儲進行解釋；

6、用小說明來描述最底層的基本加工邏輯，小說明并不描述具體的加工過程，而只是這個加工的輸入數據和輸出數據的邏輯關系。

7、用Visio 2007畫出該系統的IPO圖，它的基本形式是左邊框中列出有關的輸入數據，在中間的框中列出主要的處理，在右邊的框中列出產生的輸出數據；

8、用層次方框圖或Warnier圖對系統進行說明；層次方框圖是由樹型結構的一系列多層次的矩形框描繪數據的層次結構數型結構的頂層是一個單獨的矩形框，它代表完整的數據結構，下面的各層矩形框代表這個數據的子集，最底層的各個框代表組成這個數據的實際數據元素。

四、思考題

1、軟件需求分析在整個軟件生存周期中的地位？

2、在軟件需求分析中要完成哪些任務，所完成的資料在以后的工作中起什么作用？

3、做需求分析的過程中有沒有做社會調研？

附錄一：

實驗要求

軟件工程實驗要求學生采用“項目小組”的形式，結合具體的開發項目進行設計。具體要求如下：

1．班級按項目小組進行分組，每組不得超過10人 2．每個項目小組選出項目負責人或項目經理，由項目經理召集項目組成員討論、選定開發項目

3．項目中的每項任務要落實到人且規定該任務的起止日期和時間

4．每個項目小組必須按照《軟件工程實驗指導書》附錄中給定的文檔規范標準提供項目文檔

5．題目自定或采用附錄二中的題目

6．軟件開發的方法自定（結構化或面向對象的方法學）

附錄二：

實驗題目

題目一：“教務管理系統之子系統——學院課程安排” 1．系統簡介

每個學期的期中，學校教務處向各個學院發出下各學期的教學計劃，包括課程名稱、課程代碼、課時、班級類別（本科、專科、成人教育、研究生）、班號等；學院教學主管人員根據教學任務和要求給出各個課程的相關限制（如：任課教師的職稱、上課的班數、最高和最低周學時數等）；任課教師自報本人授課計劃，經所在教研室協調任可，將教學計劃上交學院主管教學計劃的人員，批準后上報學校教務處，最終由教務處給出下個學期全學院教師的教學任務書。

假設上述排課過程全部由人工操作，現要求為上述過程實現計算機自動處理過程。2．限定條件

（1）每位教師的主講課程門數不超過2門/學期：講師以下職稱的教師不能承擔學院定主課的主講任務。（2）學院中層干部的主講課時不能超過4學時/周。

（3本學期出現嚴重教學事故的教師不能承擔下各學期的主講任務。

（4）本系統的輸入項至少包括：教務處布置的教學計劃，學院教師自報的授課計劃和學院定的有關授課限制條件。（5）本系統的輸出項至少包括：教務處最終下達全院教師的教學任務書和學院各個班級下各學期的課程表（可以不含上課地點）。

題目二：“學校教材定購系統” 1．系統簡介

本系統可以細化為兩個子系統：銷售系統和采購系統 銷售系統的主要工作過程為：首先由教師或學生提交購書單，經教材發行人員審核是有效購書單后，開發票、登記并返給教師或學生領書單，教師或學生可以到書庫領書。

采購系統的主要工作過程為：若是教材脫銷，則登記缺書，發缺書單給書庫采購人員；一旦新書入庫后，即發進書通知給教材發行人員。

以上功能要求在計算機上實現。2．技術要求和限制條件

（1）當書庫中的各種書籍數量發生變化（包括進書和出書）時，都應修改相關的書庫記錄，如庫存表或進/出庫表。（2）在實現上述銷售和采購的工作過程時，需考慮有關的合法性驗證。

（3）系統的外部項至少包括：教師、學生和教材工作人員。（4）系統的相關數據存儲至少包括：購書表、庫存表、缺書登記表、待購教材表、進庫表和出庫表。

題目三：“機票預定系統” 1．系統簡介

航空公司為給旅客乘機提供方便，需要開發一個機票預定系統。各個旅行社把預定機票的旅客信息（姓名、性別、工作單位、身份證號碼（護照號碼）、旅行時間、旅行始發地和目的地，航班艙位要求等）輸入到系統中，系統為旅客安排航班。當旅客交付了預訂金后，系統打印出取票通知和帳單給旅客，旅客在飛機起飛前一天憑取票通知和帳單交款取票，系統核對無誤即打印出機票給旅客。此外航空公司為隨時掌握各個航班飛機的乘載情況，需要定期進行查詢統計，以便適當調整。

2．技術要求和限制條件（1）在分析系統功能時要考慮有關證件的合法性驗證（如身份證、取票通知和交款發票）等。（2）對于本系統還應補充一下功能： 1．旅客延誤了取票時間的處理 2．航班取消后的處理

3．旅客臨時更改航班的處理（3）系統的外部輸入項至少包括：旅客、旅行社和航空公司。

題目四：“學校內部工資管理系統” 1．系統簡介

假設學校共有教職工約1000人，10個行政部門和8個系。每個月20日前各個部門（包括系和部門）要將出勤情況上報人事處，23日前人事處將出勤工資、獎金及扣款清單送到財務處。財務處于每個月月底將教職工的工資表做好并將數據送銀行。每個月3日將工資條發給每個單位。若由員工調入或調出、校內調動、離退休變化，則由人事處通知相關部門和財務處。

2．技術要求和限制條件

（1）本系統的數據存儲至少包括：工資表、部門匯總表、扣稅款表、銀行發放表等。

（2）除人事處、財務處外，其他職能部門和系名稱可以簡化表示。

（3）工資、獎金、扣款細節由學生自定義。

題目五：“實驗室設備管理系統” 1．系統簡介

每學年要對實驗室設備使用情況進行統計、更新。其中：（1）對于已徹底損壞的做報廢處理，同時詳細記錄有關信息。（2）對于由嚴重問題（故障）的要及時修理，并記錄修理日期、設備名、編號、修理廠家、修理費用、責任人等。（3）對于急需修改但又缺少的設備，需以“申請表”的形式送交上級領導請求批準購買。新設備購入后要立即進行設備登記（包括類別、設備名、編號、型號、規格、單價、數量、購置日期、生產廠家、保質期和經辦人等信息），同時更新申請表的內容。

（4）隨時對現有設備及其修理、報廢情況進行統計、查詢，要求能夠按類別和時間段等查詢。

2．技術要求及限制條件

（1）所有工作由專門人員負責完成，其他人不得任意使用。（2）每件設備在做入庫登記時均由系統按類別加自動順序號編號，形成設備號；設備報廢時要及時修改相應的設備記錄，且有領導認可。

（3）本系統的數據存儲至少包括：設備記錄、修理記錄、報廢記錄、申請購買記錄。

（4）本系統的輸入項至少包括：新設備信息、修理信息、申請購買信息、具體查詢統計要求。本系統的輸出項至少包括：設備購買申請表、修理/報廢設備資

金統計表

題目六：“校園代金卡系統” 1．系統簡介

校園代金卡系統配套符合金融標準的金融設備——自助繳費機（帶圈存功能），以銀行卡為輔助，從真正意義上實現全方位的現代化校園管理，實現校園貨幣電子化。它以非接觸式IC卡又稱射頻卡為操作手段，配合校園計算機網絡，實現整個學校的全方位智能卡網絡化管理，將先進的IC卡技術服務用于學校的教學、科研、管理和生活等方面。用IC卡取代借書證、餐票、計算機房的上機卡、通道出入證件等；并作為校園信息查詢卡，使教師和學生可以輕松查詢教學設備、教室情況、圖書音像資料、校園活動等各類信息。整個系統的建成，為學校從各項日常管理事務到各種長期數據處理提供科學的解決方案，以節約學校的人力物力，在提高學校管理能力的基礎上，亦能為學校帶來一定的經濟效益。師生手持一張智能卡就可以實現學校全部事務，實現學校的各種消費的無紙幣流通。

2．校園代金卡系統功能要求 在代金卡系統的功能要求中，首先應該劃分出系統必須完成的所有功能。

校園代金卡系統能夠運用于解決學生和教職工的消費既管理問題，包括購物消費、購飯消費、遲到、早退學生登記、圖書借閱、機房上機、學生成績查詢、校園綜合信息查詢、學生身份驗證等。其中校園代金卡系統又分為一卡通中心平臺、銀行接口子系統、圖書管理系統、消費管理系統、學生學籍管理系統、身份驗證識別系統、門禁考勤系統等子系統，各個系統所實現功能也不相同，主要分為： 一卡通中心平臺

校園代金卡的一卡通中心平臺實現了對校園卡的發放、掛失、取消等管理，能夠傳輸和處理數據系統，交易數據，結算清算各種費用，在沒有工作人員參與的情況下自己也能進行一系列的工作，節省時間和人力。

銀行接口子系統

校園代金卡的銀行接口子系統能實現銀行卡和學生校園卡帳號對應，兩卡分離，學生家長持銀行卡，學生持校園代金卡。家長使用銀行系統的全國異地通存通兌業務，給學生銀行卡中匯款。通過設在校園內的圈存機，可以實現銀行卡到校園卡的電子錢包圈存并可自助查詢銀行帳戶余額。這樣學生不必從銀行取出現金然后再對校園卡進行充值，節約了人力，方便了學生充值校園代金卡。

附錄三：

軟件開發文檔指南 可行性研究報告

可行性研究報告的編寫目的是：說明該軟件開發項目的實現在技術、經濟和社會條件方面的可行性；評述為了合理地達到開發目標而可能先擇的各種方案；說明論證所選定的方案。可行性研究報告的編寫內容要求如下：

1.1 引言

1.1.1 編寫目的 1.1.2 背景 1.1.3 定義

1.1.4 參考資料

1.2 可行性研究的前提

1.2.1 要求 1.2.2 目標

1.2.3 條件、假定和限制 1.2.4 進行可行性研究的方法 1.2.5 評價尺度

1.3 對現有系統的分析 1.3.1 數據流程和處理流程 1.3.2 工作負荷 1.3.3 費用開支 1.3.4 人員 1.3.5 設備 1.3.6 局限性

1.4 所建議的系統

1.4.1 對所建議系統的說明 1.4.2 數據流程各處理流程 1.4.3 改進之處 1.4.4 影響

1.4.4.1 對象設備的影響 1.4.4.2 對軟件的影響

1.4.4.3 對用戶單位機構的影響 1.4.4.4 對系統動行的影響 1.4.4.5 對開發的影響

1.4.4.6 對地點和設施的影響 1.4.4.7 對經費開支的影響 1.4.5 局限性

1.4.6 技術條件方面的可行性 1.5 可選擇其他系統方案 1.5.1 可選擇的系統方案1 1.5.2 可選擇的系統方案2 ……

1.6 投資及收益分析 1.6.1 支出

1.6.1.1 基本建設投資 1.6.1.2 其他一次性支出 1.6.1.3 非一次性支出 1.6.2 收益

1.6.2.1 一次性收益 1.6.2.2 非一次性收益 1.6.2.3 不可定量的收益 1.6.3 收益/投資比 1.6.4 投資回收周期 1.6.5 敏感性分析

1.7 社會條件方面的可行性 1.7.1 法律方面的可行性 1.7.2 使用方面的可行性 1.8 結論 項目開發計劃

編制項目開發計劃的目的是用文件的形式，把對于在開發過程中各項工作的負責人員、開發進度所需經費預算、所需軟、硬件條件等問題作出安排記載下來，以便根據本計劃開展和檢查本項目的開發工作。編制內容要求如下：

2.1 引言

2.1.1 編寫目的 2.1.2 背景 2.1.3 定義

2.1.4 參考資料 2.2 項目概述 2.2.1 工作內容 2.2.2 主要參加人員 2.2.3 產品及成果 2.2.3.1 程序 2.2.3.2 文件 2.2.3.3 服務

2.2.3.4 非移交產品 2.2.4 驗收標準

2.2.5 完成項目的最遲期限 2.2.6 本計劃的審查者與批準者 2.3 實施總計劃

2.3.1 工作任務的分解 2.3.2 接口人員 2.3.3 進度 2.3.4 預算

2.3.5 關鍵問題 2.4 支持條件

2.4.1 計算機系統支持 2.4.2 需要用戶承擔的工作 2.4.3 需由外單位提供的條件 2.5 專題計劃要點 3 軟件需求說明書

軟件需求說明書的編制是為了使用戶的軟件開發者雙方對該軟件的起初規定有一個共同的理解，使之成為整個開發工作的基礎。編制軟件需求說明書的內容要求如下：

3.1 引言

3.1.1 編寫的目的 3.1.2 背景 3.1.3 定義

3.1.1 參考資料 3.2 任務概述 3.2.1 目標

3.2.2 用戶的點 3.2.3 假定與約束 3.3 需求規定

3.3.1 對功能的規定 3.3.2 對性能的規定 3.3.2.1 精度

3.3.2.2 時間特性要求 3.3.2.3 靈活性

3.3.3 輸入輸出要求

3.3.4 數據管理能力的要求 3.3.5 故障處理要求 3.3.6 其它的專門的要求 3.4 運行環境規定 3.4.1 設備

3.4.2 支持軟件 3.4.3 接口 3.4.4 控制 數據需求說明書

數據要求說明書的編制目的是為了向整個開發時期提供關于處理數據的描述和數據采集要求的技術信息。編制數據要求說明書的內容要求如下： 引言

編寫目的 背景 定義

參考資料

數據的邏輯描述 靜態數據 動態輸入數據 動態輸出數據 內部生成數據 數據約定 數據的采集 要求和范圍 輸入的承擔者 處理 影響 概要設計說明書

概要設計說明書可稱作系統設計說明書，這里說的系統是指程序系統，編制的目的是說明對程序的系統的設計考慮，包括程序系統的基本處理流程、程序系統的組織結構、模塊劃分、功能分配、接口設計、運行設計、數據結構設計和出錯處理設計等，為程序的詳細設計提供基礎。編制概要設計說明書的內容要求如下：

5.1 引言

5.1.1 編寫目的 5.1.2 背景 5.1.3 定義

5.1.4 參考資料 5.2 總體設計 5.2.1 需求規定 5.2.2 運行環境

5.2.3 基本設計概念和處理流程 5.2.4 結構

5.2.5 功能需求與程序的關系 5.2.6 人工處理過程 5.2.7 尚未解決的問題 5.3 接口設計 5.3.1 用戶接口 5.3.2 內部接口 5.3.3 外部接口 5.4 運行設計

5.4.1 運行模塊組合 5.4.2 運行控制 5.4.3 運行時間

5.5 系統數據結構設計 5.5.1 邏輯結構設計要點 5.5.2 物理結構設計要點 5.5.3 數據結構與程序的關系 5.6 系統出錯處理設計 5.6.1 出錯信息 5.6.2 補救措施 5.6.3 系統維護設計 6 詳細設計說明書

詳細說明書可稱作程序設計說明書。編制目的是說明一個軟件系統各個層次中的每一個程序（每個模塊或子程序）的設計考慮，如果一個軟件系統比較簡單，層次很少，本文件可以不單獨編寫，有關內容合并概要設計說明書。對詳細設計說明書的內容要不得要求如下：

6.1 引言

6.1.1 編寫目的 6.1.2 背景 6.1.3 定義 6.1.4 參考資料

6.2 程序系統的組織結構

6.3 程序1（標識符）設計說明 6.3.1 程序描述 6.3.2 功能 6.3.3 性能 6.3.4 輸入項 6.3.5 輸出項 6.3.6 算法 6.3.7 流程邏輯 6.3.8 接口 6.3.9 存儲分配 6.3.10 注釋設計 6.3.11 限制條件 6.3.12 測試計劃

6.3.13 尚未解決的問題

6.4 程序2（標識符）設計說明 …… 數據庫設計說明書

數據庫設計說明書的編制目的是對于設計中的數據庫所有標識、邏輯結構和理結構作出具體的設計規定。其內容要求如下：

7.1 引言

7.1.1 編寫目的 7.1.2 背景 7.1.3 定義

7.1.4 參考資料 7.2 外部設計

7.2.1 標識符和狀態 7.2.2 使用它的程序 7.2.3 約定

7.2.4 專門指導 7.2.5 支持軟件 7.3 結構設計

7.3.1 概念結構設計 7.3.2 邏輯結構設計 7.3.3 理結構設計 7.4 運用設計

7.4.1 數據字典設計 7.4.2 安全保密設計 8 用戶手冊

用戶手冊的編制是要使用非專門術語的語言，充分地描述該軟件系統工程所具有的功能及基本的使用方法。使用戶（或潛在用戶）通過本手冊能夠了解該軟件的用途，并且能夠確定在什么情況下，如何使用它。具體的內容要求如下：

8.1 引言

8.1.1 編寫目的 8.1.2 背景 8.1.3 定義

8.1.4 參考資料 8.2 用途 8.2.1 功能 8.2.2 性能 8.2.2.1 精度 8.2.2.2 時間特性 8.2.2.3 靈活性 8.2.3 安全保密 8.3 運行環境 8.3.1 硬設備 8.3.2 支持軟件 8.3.3 數據結構 8.4 使用過程

8.4.1 安裝與初始化 8.4.2 輸入

8.4.2.1 輸入數據的現實背景 8.4.2.2 輸入格式 8.4.2.3 輸入舉例 8.4.3 輸出

8.4.3.1 輸出數據的現實背景 8.4.3.2 輸出格式 8.4.3.3 輸出舉例 8.4.4 文卷查詢

8.4.5 出錯處理與恢復 8.4.6 終端操作 9 操作手冊

操作手冊的編制是為了向操作人中提供該軟件每一個運行的具體過程和有關知識，包括操作方法的細節。具體的內容要求如下：

9.1 引言

9.1.1 編寫目的 9.1.2 背景 9.1.3 定義 9.1.2 參考資料 9.2 軟件概述 9.2.1 軟件的結構 9.2.2 程序表 9.2.3 文卷表

9.3 安裝與初始化 9.4 運行說明 9.4.1 運行表 9.4.2 運行步驟

9.4.3 運行1（標識符）說明 9.4.3.1 運行控制 9.4.3.2 操作信息

9.4.3.3 輸入-輸出文卷 9.4.3.4 輸出文段

9.4.3.5 輸出文段的復制 9.4.3.6 啟動恢復過程

9.4.4 運行2（標識符）說明 9.5 非常規過程 9.6 遠程操作 10 模塊開發卷宗

模塊開發卷宗是在模塊開發過程中逐步編寫出來的，每完成一個模塊或一級密切相關的模塊的復審時編寫一份，應該把所有的模塊開發卷宗匯集在一起。編寫的目的是記錄和匯總低層次開發的進度和結果，以便于對整個模塊開發工作的管理和復審，并為將來的維護提供非常有用的技術信息。具體的內容要求如下：

10.1 標題

10.2 模塊開發情況表 10.3 功能說明 10.4 設計說明 10.5 源代碼清單 10.6 測試說明 10.7 復審的結論 11 測試計劃 11.1 引言

11.1.1 編寫目的 11.1.2 背景 11.1.3 定義

11.1.4 參考資料 11.2 計劃

11.2.1 軟件說明 11.2.2 測試內容

11.2.3 測試1（標識符）11.2.3.1 進度安排 11.2.3.2 條件 11.2.3.3 測試資料 11.2.3.4 測試培訓

11.2.4 測試2（標識符）……

11.3 測試設計說明

11.3.1 測試1（標識符）11.3.1.1 控制 11.3.1.2 輸入 11.3.1.3 輸出 11.3.1.4 過程

11.3.2 測試2（標識符）……

11.4 評價準則 11.4.1 范圍

11.4.2 數據整理 11.4.3 尺度 測試分析報告

測試分析報告的編寫是為了把組裝測試和確認測試的結果、發現及分析寫成文件加發記載，具體的編寫內容要求如下：

12.1 引言

12.1.1 編寫目的 12.1.2 背景 12.1.3 定義 12.1.4 參考資料 12.2 測度概要

12.3 測試結果及發現 12.3.1 測試1（標識符）12.3.2 測試2（標識符）……

12.4 對軟件功能的結論 12.4.1 功能1（標識符）12.4.1.1 能力 12.4.1.2 限制

12.4.2 功能2（標識符）……

12.5 分析摘要 12.5.1 能力

12.5.2 缺陷和限制 12.5.3 建議 12.5.4 評價

12.6 測試資源消耗 13 開發進度月報

開發進度月報的編制目的是及時向有關管理部門匯報項目開發的進展和情況，以便函及時發現或處理開發過程中出現的問題。一般地，開發進度月報是以項目組為單位每月編寫的。如果被開發的軟件系統規模比較大，整個工程項目被劃分給若干個分項目組承擔，開發進度月報將以項目組為單位按月編寫。具體的內容要求如下：

13.1 標題

13.2 工程進度與狀態 13.2.1 進度 13.2.2 狀態

13.3 資源耗用與狀態 13.3.1 資源耗用 13.3.1.1 工時 13.3.1.2 機時 13.3.2 狀態

13.4 經費支出與狀態 13.4.1 經費支出 13.4.1.1 支持性費用 13.4.1.2 設備購置費 13.4.2 狀態

13.5 下個月的工作計劃 13.6 建議 項目開發總結報告

項目開發總結報告的編制是為了總結本項目開發工作的經驗，說明實際取得的開發結果以及對整個開發工作的各個方面的評價。具體的內容要求如下：

14.1 引言

14.1.1 編寫目的 14.1.2 背景 14.1.3 定義 14.1.4 參考資料 14.2 實際開發結果 14.2.1 產品

14.2.2 主要功能和性能 14.2.3 基本流程 14.2.4 進度 14.2.5 費用

14.3 開發工作評價

14.3.1 對生產效率的評價 14.3.2 對產品質量的評價 14.3.3 對技術方法的評價 14.3.4 出錯原因的分析

第五篇：軟件工程實驗文檔

《軟件工程課程設計》

一、提交實驗報告文擋及要求

序報告名目 的 要 求

號 稱

以全面、系統的分析為主要方法，經濟效益為核心，圍繞影響項目的可行性各種因素，運用大量的數據資料論證擬建項目是否可行，給出項目可1

分析

行性分析報告。2 3 項目需根據給定的的題目或自選題目進行需求分析工作；進行功能需求、非求分析 功能需求分析得出需求規格說明書。

項目概建立初始結構圖，對初始結構構圖進行改進、優化得出概要設計說明要設計 書。

項目詳進行詳細設計工作，得出詳細設計說明書。

細設計

項目編本次實習不需編碼

碼 5

進行黑盒、白盒測試試用例設計形成測試用例表；

項目測進行黑盒測試，得出測試記錄； 6

試 進行白盒測試，得出測試記錄；

形成測試報告。7 項目管利用Project進行項目計劃、進度、協調等管理材料。

理

二、課程實踐選題（課程設計題目）

題目一：電子商務網站建設

是一個集客戶購物、下訂單、訂單處理、銷售統計等功能于一體的系統。通過瀏覽器，讓客戶可以查詢貨物，把貨物放入購物車，創建賬戶/登陸賬戶，創建訂單，通過信用卡支付等。系統劃分成了多個模塊，松耦合的設計架構，允許可以和多個數據源，EIS（企業信息系統）進行交互。功能如下： 1．用戶

注冊/登陸/忘記密碼/管理個人信息

查詢貨物

購物車管理

提交訂單

信用卡支付

查詢歷史購物記錄 2．貨物商店

接受/處理訂單消息

手工接受/拒絕訂單

用E-mail來通知客戶

發訂單給供應商 銷售統計 3．供應商

接受訂單

派送貨物給用戶

提供一個基于web的庫存管理

維護庫存數據庫

題目二：外文圖書采購系統 1.問題概述

某圖書館外文采購有兩個組--征訂組和驗收登記組。分別承擔書籍訂購和進書驗收任務。為了減輕勞動強度和提高工作效率，打算采用計算機進行管理。為此，系統分析員在進行了調查研究，描述出外文采購室現行系流程。

1）訂書組從供書單價收到訂書目錄，根據各單位的需要選擇出要訂購的書目。2）為了避免浪費，對于已進入過或已訂過的圖書和訂單留底。3）打印的訂單，要送給訂書單位和驗收登記組，并留底。4）對所登記的書進行統計表。

5）驗收登記組從供書單位收到圖書和發票，根據訂單留底進行驗收。6）發票交給財務科進行報賬。

7）為了避免浪費，對于已進圖書再做查重，如果重了，轉讓出去或作別處理。如果不重，則登賬和打印查重卡。8）查重卡要交給訂書組用于查重。

9）已登記的書籍要送給編目室進行編目。

10）已進的書要記入圖書總賬并進行進書統計和打印進行統計表。11）訂書統計表和進書統計表交館領導。

這里沒有考慮出錯和例外情況的處理。這些驗收不合格怎么辦？查重的書號或書名輸入錯誤怎么辦？等等。在實際運行中，這些問題都必須考慮到。

2．這個問題比較適合用面向數據流的方法來求解。

求解這類問題應理解和當前系統（可能是人工系統可能是計算機系統）的業務流程，首先獲得當前系統的物理模型。接著從當前系統的物理模型抽象出當前系統的的“怎么做到當前系統的”做什么“的現象到本質的抽象過程。然后通過分析目標系統與當前系統在邏輯上的差異，導出目標系統的邏輯型。最后通過對目標系統的邏輯模型，才能得到最終所要求的目標系統。

題目三：畢業設計指導網站

畢業設計指導網站的目的是使學生和教師能夠通過網絡進行畢業設計輔導，這樣能夠得到最新的畢業設計信息，更好的輔導效果。內容如下： 1．學生

注冊/登陸/忘記密碼/管理個人信息

上傳文件和下載文件

向指導教師提問

查詢問題 2．教師

登陸/忘記密碼

管理所輔導學生的賬戶 上傳文件和下載文件

回答問題

群發消息 3．管理員

管理教師和學生信息

查詢統計數據（日問題量，答疑率）

提醒教師答疑

發布公告

群發消息

要求： 1.加入評價機制（學生評價教師；系統根據網絡利用效率評價教師對學生的指導質量等）

2.擴展文檔管理功能（根據畢業設計的特點，催交/管理/評價學生在不同階段上交的畢業設計文檔）

3.考慮適應所有學院/大學的畢業設計指導網站

題目四：教務處課程管理網站

教務處課程管理網站的目的是使教務處方便地管理學生的選課情況、學習成績等信息，并通過該系統向學校的其他管理部門提供或獲取數據。內容如下： 1．學生

登陸/忘記密碼

查詢成績

上傳平時作業 選課 2．教師

登陸/忘記密碼 查詢學生花名冊 布置作業 批改學生作業 提交學生成績

上傳課程資料（教學大綱、教學日歷和課件等）3．教務處

管理學生的賬戶 管理教師帳戶 發布公告

啟動/關閉課程注冊功能 查詢成績 統計成績數據

提供查詢學生成績服務的接口 4．學生處

提供學生信息導入的接口

要求：1.通過Web Service提供服務或使用服務（如查詢成績服務和學生處學生信息獲取服務）

2.考慮通用的教務處課程網站 題目五：病員監護系統

本例為醫院特級護理病房的病員監視系統。1）在每一病床旁有一個監護器。

2）在病員身上附著各種傳感嘆器，監測各種生理參數，諸如血壓，呼吸，體溫。信號被被送到監護器。

3）監護器帶有輸入鍵盤，用以輸入病員的病號的病歷號，各種監測的生理因素的安全范圍值（上下限值），以及監測頻率定期（監測周期）等。

4）各監測部件與中心計算機相連，后者按指定的監測頻率定期地對監視器進行檢查。

5）檢查所得到的數據記錄在每個病員的記錄文件上。

6）如果發現病員的生理因數超出在安全范圍時，在護理室有各病員的各種報警信號（燈光）出現。

7）每個監視器有一開關，用來控制監測工作。

8）本例中假設監視255個病員，每人設定4個因素。監視周期可從1秒到小時變化，對每一病員監視1秒時間。

9）安全范圍為十進數值，內部表示為浮點數。病歷號為9整數。

題目六：簡易辦公系統

很多辦公室的計算機完成了大量的文字處理功能，并沒有行使管理功能，現對其改進如下：

（1）收發文管理：

對收到的公文進行登記，分類編號，（學校主要發文部門分為：教務處、財務處、學生處、人事處、保衛處、工會以及其他），并形成文件主要內容關鍵字，使收文能夠按照關鍵字、時間和部門查詢；對發文進行登記，并形成文件主要內容關鍵字，使發文能夠按照關鍵字、時間和部門查詢。（2）會議管理：

對所管理的2個會議室進行自動化管理，即由申請部門提交申請，然后統一安排會議室以及各種會議資源（如投影儀、計算機、桌子、凳子等），能形成會議資源使用通知單送達申請部門，主管領導隨時查詢會議室使用情況（管理者直接負責管理）。能夠按照申請者的要求自動生成會議通知單，由辦公室負責通知發放。能夠形成會議紀要，存檔并送到需要的部門（由申請者提供的信息決定）

題目七：低值易耗品管理系統

為了加強對學校實驗室低值易耗品的管理和監督，將指定專門的部門對其進行管理，為了方便管理，減少工作量，擬定開發一個低值易耗品管理系統，描述如下：（1）學校每個院系及工程訓練中心均有一個實驗室，每個實驗室每學期均有低值易耗品。

（2）基本管理流程：

每學期期末由各實驗室上報下學期的低值易耗品清單，由材料管理科負責分類匯總，并報送審計處、財務處和校長，由實驗主管部門負責對所有清單進行審核，將清單中所有物品分為未批、待批、統購和自購四大部分。并將審批后的清單返還給實驗室。其中統購和自購物品作為實驗室計劃內消耗，并根據參考價格計算出各個實驗室下學期的計劃消耗金額。并形成計劃匯總表，報送上級部門。統購物品由材料管理科統一購買，應能自動生成全校統購物品清單，清單上的物品能夠按院系和按物品類別分類匯總。物品購買后，入庫。各個實驗室按照指定計劃到庫房領用，其對應消耗進入實驗室計劃消耗內。

自購物品由實驗室自行購買，購買后將清單送到材料管理科審核，備案后，方可報帳。自購物品也進入本實驗室計劃消耗內。

材料管理科應能隨時查詢當前還未購買的物品、以及當前各個實驗室計劃內物品的領和消耗情況。

對未在計劃內的物品消耗，采取由實驗室填報申請表（在表中，必須說明申報原因），送上級領導審核后，執行所需費用仍然進入相應院系的消耗。

學期末，應產生學校各類物品消耗匯總表，各個院系實際消耗匯總表，所有物品計劃消耗與實際消耗對比分析表，各個院系計劃消耗與實際消耗對比分析表。

題目八：軟件工程課程自主學習課件建設

本課程主要在于采取一種全新的學習模式，采取網上自主教學的新模式，以自主教學，強調教學順序，提出課件資源組件化、組件庫的思想，其主要描述如下： 選定軟件工程教材并對軟件工程進行教學單元的劃分，形成教學內容的劃分，并形成教學資源勘查點，并形成不同的教學模式。

完成組件設計。并形成組件的建設和組件庫管理的基本框架。完成服務器架構以及客戶端界面的設計

題目九：超市管理系統一個面向小型超市的管理系統，可完成以下工作： 1.實現客戶購物收銀管理； 2.向超市倉庫中添加商品，記錄商品的損耗（如過期、變質等非購買方式的損耗）； 3.查詢某商品的庫存情況；

4.當各種商品庫存量少于某規定值時，系統給予提示； 5.實現月度、商品銷售情況統計（如銷售量最大的商品，銷售額最多的商品，各商品的銷售量、銷售額匯總等）

題目十：學生管理系統

1.學生檔案信息維護，包括注冊、注銷、更新等； 2.學生選課管理，從可選的課程中選擇若干課程； 3.學生成績管理，實現學生成績的登記；

4.學生信息、選課情況、成績的查詢和報表輸出； 滿足以下限制：

每個學生選擇的課程數在15～18之間；

學生信息注銷后，便不允許對與之相關的信息作任何修改，但可查閱； 成績的登記是按照課程來登記的；

學生只能實現2、4功能，且只涉及與自身相關的內容；

題目十一：企業單位物資管理系統

1.實現物資的購入、登記、報廢等管理；

2.可將各類物資分配到企業各個科室以便使用； 3.可按照物資類別，名稱，價格、科室等查詢、統計； 4.可生成相應的統計報表； 其他說明、限制：

所管理的物資分兩大類：固定資產（如家具、電器）、耗材（文具等）； 每一件固定資產有唯一的資產編號；

物資管理員可以完成以上1、2、3、4功能，而普通員工只可查詢本人、本科室相關的情況；

題目十二：高等數學學習和測試系統

系統緊扣高等數學教學大綱，根據教學大綱的要求，將高等數學的全部教學內容分為課程學習、隨堂練習、綜合測試三大部分。系統制作應遵循的幾個原則

1.教學性原則； 2.可操作性原則； 3.科學性原則； 4.簡約性原則； 5.藝術性原則； 6.適度信息量原則

題目十三：高等學校畢業生就業服務信息系統 不僅僅提供基礎的信息服務，而且要充分利用豐富的網絡資源，將現代化的管理手段與先進網絡技術的有機結合，對畢業生順利就業將起到重大的促進和保障作用。（最好要具有就業論壇的信息過濾功能）.題目十四：學校教材訂購系統 本系統可細化為兩個子系統：銷售系統和采購系統銷售系統的工作過程為：首先由教師或學生提交購書單，經教材發行人員審核是有效購書單后，開發票、登記并返給教師或學生領書單，教師或學生即可去書庫領書。

采購系統的主要工作過程為：若是脫銷教材，則登記缺書，發缺書單給書庫采購人員；一旦新書入庫后，即發進書通知給教材發行人員。以上的功能要求在計算機上實現。技術要求和限制條件：

當書庫中的各種書籍數量發生變化（包括領書和進書時），都應修改相關的書庫記錄，如庫存表或進/出庫表。

在實現上述銷售和采購的工作過程時，需考慮有關單據的合法性驗證。系統的外部項至少包含三個：教師、學生和教材工作人員。系統的相關數據存儲至少包含6個：購書表、庫存表、缺書登記表、待購教材表、進/出庫表。

題目十五：機票預訂系統

航空公司為給旅客乘機提供方便，需開發一機票預定系統。各旅行社把預定機票的旅客信息（姓名、性別、工作單位、身份證號碼、旅行時間、旅行目的地等）輸入到該系統，系統為旅客安排航班。當旅客交付了預定金后，系統印出取票通知和帳單給旅客，旅客在飛機起飛的前一天憑取票通知和帳單交款取票，系統核對無誤即印出機票給旅客。此外航空公司為隨時掌握各航向飛機的乘載情況，需定期進行查詢統計，以便適當調整。技術要求及限定條件：

（1）在分析系統功能時要考慮有關證件的合法性驗證（如身份證、取票通知、交款發票等）。（2）對于本系統還應補充以下功能： 1）旅客延誤了取票時間的處理 2）班機取消后的處理

3）旅客臨時更改機票班次的處理

系統的外部項至少包含三個：旅客、旅行社和航空公司。

題目十六：實驗室設備管理系統

每學年要對實驗室設備使用情況進行統計、更新，其中：

（1）對于已徹底損壞的作報廢處理，同時詳細記錄有關信息。

（2）對于有嚴重問題（故障）的要即使修理，并記錄修理日期、設備名、修理廠家、修理費、責任人等。（3）對于急需但又缺少的設備需以“申請表”的形式送交上級領導請求批準購買。新設備購入后要立即進行設備登記（包括類別、設備名、型號、規格、單價、數量、購置日期、生產廠家、購買人等），同時更新申請表的內容。

（4）隨時對現有設備及其修理、報廢情況進行統計、查詢，要求能夠按類別和時間段（某日期之前）查詢。技術要求及限定條件

（1）所有工作由專門人員負責完成，其他人不得任意使用。

（2）每件設備在作入庫登記時均由系統按類別自動順序編號，形成設備號；設備報廢時要及時修改相應的設備記錄，且有領導認可。

（3）本系統數據存儲至少應包含：設備記錄、修理記錄、報廢記錄、購買申請。（4）本系統的輸入項至少包含：新設備信息、修理信息、申請購買信息、報廢信息、具體查詢統計要求。

（5）本系統輸出項至少包含設備購買申請表、修理/報廢注銷/設備資金統計表。

題目十七：通用試題庫組卷系統的設計與實現

考試是進行教學目標評價的主要手段 ,試卷是測量學生學習質量的一把”尺子"。而命題的水平則是檢驗教學質量的關鍵。傳統的試卷命題一般是用手工的方式實現的 ,不但工作量大、容易出錯 ,而且不能把教師從繁重的出卷勞動中解放出來。在現行的教育中 ,雖然有些高等院校也有一些專門的課程的試題庫管理系統 ,但是通用性的效果不佳。隨著 Internet 的出現和廣泛使用 ,WEB 使得實現廣泛的網絡共享、集中的安全控制和友好的使用界面達到了完美的結合。開發基于 Web 的在線組卷系統就具有很重要的意義。

開發網上的通用試題庫組卷系統 ,不僅可以很好的實現教考分離 ,可以提高教學質量 ,而且可以使高校的教學管理質量更上一層樓。它是將系統架設在一個 WEB站 點上運行 ,通過瀏覽器訪問 ,它提供了傳統題庫系統所不能完成的某些功能。充分利用網絡資源 ,教師、專家可以在終端進行試題庫的編輯、更新等操作 ,學生則可以通過動態的選擇不同的類型、數量的試題來進行在線學習和考試 ,來檢測自己的學習效果。

功能模塊：

錄入模塊：在教學大綱和考試大綱的指導下 ,可以向組卷庫里添加符合要求的試題和試卷。

查詢模塊：系統中的所有用戶可以查詢試卷、試題、用戶等信息。組卷模塊：是通用試題庫組卷系統的一個核心模塊 ,這部分的設計的優劣能夠反映其試卷質量的高低。就目前而言 ,為了滿足不同人的需求 ,組卷的形式大概可以分為以下兩種。手工組卷是指系統根據一些條件后調出一定范圍的試題,然后出題人員在這個范圍的試題內逐個地通過復選來形成試卷的方法。出題者可以利用現有的試題庫 ,按照條件查詢 ,可以在查詢結果中對每一試題進行率選, 順序也可以進行調整 ,出題人員不斷重復這個步驟 ,并可以依據每題的難易程度來控制整份試卷的難易。自動組卷是指出題人員向系統只提供一些很簡潔的計劃,完全由系統自動按照一定的算法和規則在試題庫里自動 ,系統根據一些參數的設定 ,比如: 試題的考試時間 ,按題型比例出卷,隨機抽取試題并試題不重復等等, 靈活地抽取各類型的試題組成試卷 ,那么就會導致試卷的內容隨著庫中的試題的變化而變化。

考試模塊：本系統的另一個核心模塊。其主要功能是為學生提供一個考試平臺 ,根據對出題方式的設定 ,輸入試卷編號,如果試卷確實存在 ,那就可以調出試卷進行在線測試 ,考生在頁面上進行答題, 最后將答案提交給服務器 ,為了規范考試紀律,該系統采用了自愿交卷和自動交卷。

刪除模塊：只有管理員才具有權限去刪除，可以選擇刪除試題、科目等信息。

題目十八：操作系統精品課程網站設計與實現 《操作系統》是軟件學院軟件工程專業的主干必修課，為嵌入式系統及其應用提供課程支持，它在計算機知識結構中有著極其重要的地位和作用，可為學生較全面的建立起關于計算機系統的概念。《操作系統》課程又是考研課程和軟考重要必考課程之一，定位于計算機各相關專業的本科生，因此在授課內容上強調知識的完備性、實際系統的關聯性、基本理論的應用性及新技術的引入。該課程要求學生能夠很好地掌握計算機操作系統的基本概念、各種資源管理的思想和算法，能夠較好的理解操作系統原理，而且能夠拓展原理的應用，也為學生的底層程序開發及后續發展奠定基礎。因此，開發一個操作系統精品課程網站顯得尤其重要。

功能模塊：

課程介紹：主要包括軟件工程的課程簡介、教學大綱、選用教材、參考文獻等。師資隊伍：主要是介紹軟件工程的主講教師、教學專家、教師風采（主要采用視頻播放教師現場授課）、教學成果（包括教改課題、教改論文）教學資源：主要向學生提供豐富的課內和課外知識，使學生可在課外時間預習和復習課程知識，并能根據自己的興趣了解相關的課外知識。這些模塊還提供各類資源的下載功能，如電子課件、閱讀資料、例題習題、課程設計等。

在線考試：管理員或教師維護題庫、根據試題的題庫設置考試的試卷規則、錄入允許參加考試的考生名單、考生隨機抽取題庫試題進行考試、教師批卷或計算機自動判卷、統計考試成績、查詢考試結果。在線考試還具備學生的自測功能，即學生可任意選擇自測章節、知識點和難度系數進行組題，以確定測試范圍，系統將根據學生的選項，自動隨機調出相應范圍內的題目。學生答題結束后，系統記錄學生的答題情況，以供學生日后參考復習。系統還會在答題結束后自動給出參考答案，供學生參考。對于客觀性題目, 系統還會自動打出分數。

輔導答疑：是實現“網上答疑”，在網上學生提出問題，教師進行解答，這些提問和解答都被系統記錄，以便其他用戶查看和學習，達到信息的共享目的。用戶管理：主要用于對用戶分角色進行有效的授權管理，系統主要包含三類用戶：學生、教師和系統管理員，每類用戶對本系統有各自不同的使用權限。學生的權限最低，只有一般的使用權。教師和系統管理員具有較高的權限，如教師可以進行作業管理，題庫模塊的維護及答疑等；系統管理員則負責公告，教學資源，試題庫，角色等各種功能的管理。

作業管理：該模塊主要是學生在這里提交作業，教師可以在線批改作業，給出成績，學生可以在查看作業批改情況。