2015軟件工程實驗心得體會範文

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

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

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

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

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

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

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

2、用戶羣分類

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

3、建立核心隊

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

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

4、確定使用實例

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

5、分析用戶工作流程

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

6、檢查問題報告

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

7、需求重用

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

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