一個軟件的開發是一個極其復雜的過程,其中設計分析,設計、編碼、測試、維護等,而系統分析卻往往是一個軟件成敗的關鍵。
如何進行系統分析,以及如何傳遞分析的的結果文檔等,又是系統分析師的首要任務。系統分析對于任何人來說都不是容易 ,它沒有規則的限定,它需要系統分析師的應變,雖然有相應的指導,但指導往往是教課書般,沒有一個項目一塵不變地去原用教課書上的東西,更多的是經驗。
系統分析的成品即軟件需求分析說明書,此書到底需要包括什么內容,到底是什么。這個問題很難回答,也許有很多人不加思索地可以答出,但我認為這個問題很難。這個由不同公司不同項目的具體情況決定的。從我的角度來看我覺得這個文檔中的內容要走夠設計師們看懂并可以作出設計。既然是為設計作打算,那么設計需要什么內容呢,這又涉及到設計方面的東西。
需求來源于用戶的一些“需要”,這些“需要”被分析,確認后形成完整的文檔,該文檔詳細地說明了產品必須或應當做什么。如果只有一些零碎的對話、資料或郵件,就認為掌握了需求,那就是自欺欺人。需求是一個產品的源頭,它的好壞對產品的影響最大,就像一條河流,如果源頭被污染了,那么整條河流就被污染了。“用戶”是一種泛稱,可分為“客戶”,最終用戶或間接用戶。需求分為兩類,一類屬于需求開發,另一類屬于需求管理。需求開發分為需求調查、需求分析和需求定義。需求管理分為需求確認、需求跟蹤和需求變更控制。需求開發的目的是通過調查與分析,獲取用戶需求并定義產品需求。需求調查的目的是通過各種途徑獲取用戶的需求信息,產生《用戶需求說明書》。需求分析的目的是對各種需求信息進行分析,消除錯誤,刻畫細節等,常見的需求分析方法有“問答分析法”和“建模分析法”等。需求定義的目的是根據需求調查和需求分析的結果進一步定義準確無誤的產品需求,產生《產品需求規格說明書》,系統設計人員依據《產品需求規格說明書》開展系統設計工作。需求管理的目的是在客戶與開發方之間建立對需求的共同理解,維護需求與其它工作成果的一致性,并控制需求的變更。需求確認是指在開發方和客戶共同對需求文檔進行評審,雙方對需求達成共識后作出書面承諾,使需求文檔具有商業合同效果。需求跟蹤是指通過比較需求文檔和后續工作之間的對應關系,建立與維護“需求跟蹤矩陣”,確保產品依據需求文檔進行開發。需求變更控制是指依據“變更申請—審批—更改—重新確認”的流程處理需求的變更,防止需求變更失去控制而導致項目發生混亂。
如何進行需求分析是需求調研中最重要的一步。需求分析是指在需求開發過程中,對所獲取的需求信息進行分析,及時排除錯誤和彌補不足,確保需求文檔正確的反映用戶的真實意圖。分析方法大體有兩類:“問答分析法”和“建模分析法”。問答分析法:刨根究底地問,如果問題都被解答了,那么需求也就分析清楚了。建模分析法是指用圖形符號來表示、刻畫需求。
在系統分析中,用例的重要性不用多說。真正理解了用例,懂得利用用例來驅動項目的開發,才能真正把握住需求的精髓。每個用例是一組場景的集合,而每個場景又是一個步驟序列。用例圖通常是供客戶和開發組參考的設計文檔的一部分。用例之間可以以兩種方式相互關聯,一種方式是包含,即在一個用例中重用另一個用例中的步驟。另一種方式叫擴展,允許通過對已有用例增加步驟創建一個新的用例。用例之間的另外兩種關系是泛化和分組。泛化是指一個用例繼承了另一個用例。分組是一組用例的簡單組織方式。
用例可以解釋為某個參與者要做的一件事。也可以解釋為一系列完成一個特定目標的“功能”的組合。這一件事可以解釋為:1.這件事是相對獨立的。它不需要與其他用例交互而獨自完成參與者的目的。2.這件事的執行結果對于參與者來說是可觀測的和有意義的。3.這件事必須由一個參與者發起,不存在沒有參與者的用例。4這件事是以短賓短語出現。即這件事必須有一個動作和動作的受體。用例的背后是一種需求方法論。用例的核心是以參與者為核心,從參與者的角度描述他的日常工作,并分析這些日常工作是如何交互的。用例的首要目的不是要弄清楚某項業務是如何一步步完成的,而是要弄清楚有多少參與者?每個參與者都做什么?
需求分析需要經過業務建模、用例分析和系統建模三部分組成。1.業務建模的目標是通過用例模型的建立來描述用戶需求,需求規格說明書通常在這個階段產生。2.用例分析是分析員用OO的方法來分析業務用例的過程,這個階段稱為概念模型階段,這個階段通常使用無類型的用例。3.系統建模是將用戶的業務需求轉化為計算機實現的過程,這個階段通常使用無類型的用例和用例實現兩種類型。系統范圍、項目計劃和系統架構通常在這個階段形成雛形。業務用例(business usecase),是用來描述用戶原始需求的,它的含義是站在用戶的角度,使用用戶的業務術語來描述用戶在其領域所做的事。業務用例命名,描述都必須采用純業務語言,不能出現計算機術語。業務模型是系統分析員和用戶討論需求,達到一致理解的基礎。只有完成下面的工作,才能算是業務模型已經建立完成。1.發現和定義
如何進行系統分析,以及如何傳遞分析的的結果文檔等,又是系統分析師的首要任務。系統分析對于任何人來說都不是容易 ,它沒有規則的限定,它需要系統分析師的應變,雖然有相應的指導,但指導往往是教課書般,沒有一個項目一塵不變地去原用教課書上的東西,更多的是經驗。
系統分析的成品即軟件需求分析說明書,此書到底需要包括什么內容,到底是什么。這個問題很難回答,也許有很多人不加思索地可以答出,但我認為這個問題很難。這個由不同公司不同項目的具體情況決定的。從我的角度來看我覺得這個文檔中的內容要走夠設計師們看懂并可以作出設計。既然是為設計作打算,那么設計需要什么內容呢,這又涉及到設計方面的東西。
需求來源于用戶的一些“需要”,這些“需要”被分析,確認后形成完整的文檔,該文檔詳細地說明了產品必須或應當做什么。如果只有一些零碎的對話、資料或郵件,就認為掌握了需求,那就是自欺欺人。需求是一個產品的源頭,它的好壞對產品的影響最大,就像一條河流,如果源頭被污染了,那么整條河流就被污染了。“用戶”是一種泛稱,可分為“客戶”,最終用戶或間接用戶。需求分為兩類,一類屬于需求開發,另一類屬于需求管理。需求開發分為需求調查、需求分析和需求定義。需求管理分為需求確認、需求跟蹤和需求變更控制。需求開發的目的是通過調查與分析,獲取用戶需求并定義產品需求。需求調查的目的是通過各種途徑獲取用戶的需求信息,產生《用戶需求說明書》。需求分析的目的是對各種需求信息進行分析,消除錯誤,刻畫細節等,常見的需求分析方法有“問答分析法”和“建模分析法”等。需求定義的目的是根據需求調查和需求分析的結果進一步定義準確無誤的產品需求,產生《產品需求規格說明書》,系統設計人員依據《產品需求規格說明書》開展系統設計工作。需求管理的目的是在客戶與開發方之間建立對需求的共同理解,維護需求與其它工作成果的一致性,并控制需求的變更。需求確認是指在開發方和客戶共同對需求文檔進行評審,雙方對需求達成共識后作出書面承諾,使需求文檔具有商業合同效果。需求跟蹤是指通過比較需求文檔和后續工作之間的對應關系,建立與維護“需求跟蹤矩陣”,確保產品依據需求文檔進行開發。需求變更控制是指依據“變更申請—審批—更改—重新確認”的流程處理需求的變更,防止需求變更失去控制而導致項目發生混亂。
如何進行需求分析是需求調研中最重要的一步。需求分析是指在需求開發過程中,對所獲取的需求信息進行分析,及時排除錯誤和彌補不足,確保需求文檔正確的反映用戶的真實意圖。分析方法大體有兩類:“問答分析法”和“建模分析法”。問答分析法:刨根究底地問,如果問題都被解答了,那么需求也就分析清楚了。建模分析法是指用圖形符號來表示、刻畫需求。
在系統分析中,用例的重要性不用多說。真正理解了用例,懂得利用用例來驅動項目的開發,才能真正把握住需求的精髓。每個用例是一組場景的集合,而每個場景又是一個步驟序列。用例圖通常是供客戶和開發組參考的設計文檔的一部分。用例之間可以以兩種方式相互關聯,一種方式是包含,即在一個用例中重用另一個用例中的步驟。另一種方式叫擴展,允許通過對已有用例增加步驟創建一個新的用例。用例之間的另外兩種關系是泛化和分組。泛化是指一個用例繼承了另一個用例。分組是一組用例的簡單組織方式。
用例可以解釋為某個參與者要做的一件事。也可以解釋為一系列完成一個特定目標的“功能”的組合。這一件事可以解釋為:1.這件事是相對獨立的。它不需要與其他用例交互而獨自完成參與者的目的。2.這件事的執行結果對于參與者來說是可觀測的和有意義的。3.這件事必須由一個參與者發起,不存在沒有參與者的用例。4這件事是以短賓短語出現。即這件事必須有一個動作和動作的受體。用例的背后是一種需求方法論。用例的核心是以參與者為核心,從參與者的角度描述他的日常工作,并分析這些日常工作是如何交互的。用例的首要目的不是要弄清楚某項業務是如何一步步完成的,而是要弄清楚有多少參與者?每個參與者都做什么?
需求分析需要經過業務建模、用例分析和系統建模三部分組成。1.業務建模的目標是通過用例模型的建立來描述用戶需求,需求規格說明書通常在這個階段產生。2.用例分析是分析員用OO的方法來分析業務用例的過程,這個階段稱為概念模型階段,這個階段通常使用無類型的用例。3.系統建模是將用戶的業務需求轉化為計算機實現的過程,這個階段通常使用無類型的用例和用例實現兩種類型。系統范圍、項目計劃和系統架構通常在這個階段形成雛形。業務用例(business usecase),是用來描述用戶原始需求的,它的含義是站在用戶的角度,使用用戶的業務術語來描述用戶在其領域所做的事。業務用例命名,描述都必須采用純業務語言,不能出現計算機術語。業務模型是系統分析員和用戶討論需求,達到一致理解的基礎。只有完成下面的工作,才能算是業務模型已經建立完成。1.發現和定義