今天讀了關於如何做需求分析的博文，學習了軟體需求與分析需要掌握的一些內容，下面就做一些總結。
首先要認識到深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。第乙個舉出來東軟的例子，東軟在做這個專案的時候，整個過程經歷了10多次結構性的大變更，區域性性的調整更是不計其數。百處程式進行修改。最後這個專案導致的結果是，整個這個專案組的所有成員都離開了東軟，常常會聽到抱怨客戶總是對需求改來改去，那是因為我們對客戶的需求沒有真正理解清楚時，我們做出來的東西客戶必然不滿意。不知道怎麼才能讓客戶滿意，於是就在一點兒一點兒試，於是這種反覆變更就這樣發生了。我們要從業務角度深入的去分析，他為什麼提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。當我們提出更加合理的方案時，客戶是樂於接受的，變更也變得可控了。
第二個舉例自己一次失敗的例子告訴了我們不能客戶怎麼說軟體就怎麼做。客戶提出的原始需求往往是不考慮技術實現，基於非計算機管理的操作模式提出來的。他們提出的很多需求常常比較理想而不切實際，畢竟人家是非技術的。但我們作為技術人員，需求分析必須實事求是的、基於技術可以實現的角度去考慮。那種「有條件要上，沒有條件創造條件也要上」的魯莽行事，結果必然是悲慘的。我們做需求就應當首先理解現有的管理模式，然後站在資訊化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操作與管理。
在本學期我們應該學會學會需求調研，需求調研是需求分析最重要的一環，它既要求我們具有一種理解能力、設計能力，更要求我們具有一種與人交往、溝通的能力。我們對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。感覺你非常專業，你在客戶心目中的形象也會無形中提高，使你有更多的機會提出有利於開發的可行方案，降低開發的風險。
需求研討首先跟客戶**的不是軟體功能，而是客戶現有的業務知識，需求分析不是一種簡單的你說我記的收集活動，而是在大量業務分析與技術可行性分析基礎上的分析活動。只有建立在這種分析基礎上的軟體研發，才能保證需求的正確與變更的可控。
對乙個系統進行功能和角色方面的梳理和分析，可以採用的比較主流的方法之一就是繪製用例圖。在乙個用例圖中通常有三種元素：參與者（actor）、用例（use case）與系統邊界（boundary）。用例描述的是系統為使用者提供的功能，也就是系統能為使用者做什麼。
進行業務流程分析時，我們是繪製行**、狀態圖，以及編寫用例說明來完成這部分工作。編寫用例說明應當是最主要的工作，用例標識，用例名稱，用例型別，用例描述，參與者，觸發事件，前置條件，事件流。用例分析實質是需求人員的乙份設計。用例說明中對流程的描述都是用枯燥無味的文本來表述的，缺乏生動形象的圖形表示。針對這些不足，uml的另外兩種檢視，可以有效地彌補用例圖的缺陷。它們就是行**與狀態圖。
業務領域分析，就是通過與使用者進行交流，掌握領域知識，然後繪製成業務領域模型，去指導我們軟體開發的過程。我們去設計開發系統時，應當設計哪些類，類中都應當有什麼屬性和行為，以及怎樣去設計資料庫，都是以這個領域模型為基礎的。
軟體需求分析 閱讀筆記
筆記要求 發表一篇閱讀筆記，說明本學期 軟體需求分析 需要掌握哪些必要的內容？針對每個內容點說出自己的理解，並繪圖標意相互之間的關聯關係。讀 需求工程 軟體建模與分析 有感 今天大致的看了一下這本書，對軟體需求分析有了初步的了解，我認為學習軟體需求分析需要掌握的內容主要包括五個方面 需求基礎與過程 ...
《軟體需求分析》閱讀筆記
很多需求分析的工作都是從需求調研開始，需求調研是需求分析最重要的一環，決定之後的工作能否順利地展開，與客戶的交流決定了能否明確的交換雙方的想法，讓客戶與我們都可以達到滿意。面對客戶群體的不同層次決定了如何交流，不同的群體對程式設計的了解是不同的，對不同的人要有不同的交流方法，而需求調研不是一朝一夕所...
軟體需求分析 閱讀筆記6
在需求開發活動之後，需求基線應該成為後序軟體系統開發的工作基礎和粘合劑。需求管理在需求開發之後的產品生命週期中保證需求作用的有效發揮。作為需求開發的結果，最終的需求應該被明確和固定，需求基線就是被明確和固定的需求集合，是專案團隊需要在，某一特定產品版本中實現的特徵和需求集合。需求基線是需求開發過程中...