要求：
《軟體需求與分析
》需要掌握內容？針對每個內容說出理解
繪圖標意之間的相關關係
原文先從三個案例指出需求的重要性及專案失敗原因，東歐->業務分析角度分析 為什麼提出變更，提出變更合不合理，有沒有更合理方案滿足需求。自己做專案->基於技術實現去引導客戶的需求.做需求就應當首先理解現有的管理模式，然後站在資訊化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操作與管理。
從參加集團資訊化建設的專案中，客戶是乙個龐大的群體的看，
需求分析必須遵從的是一定的科學方法，而不是盲目的大上快上。
最後乙個故事指明
需求分析階段不可能解決所有的需求問題，因此在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時獲得反饋。只有這樣才能及時糾正需求理解的偏差，保證專案的成功。
需求調研方式：
初始：我們對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。如果能夠這樣，客戶不僅能夠欣然接收你提出的方案，而且會感覺你非常專業，你在客戶心目中的形象也會無形中提高，使你有更多的機會提出有利於開發的可行方案，降低開發的風險
。不同的部門，由於業務的不同，對軟體的需求自然是不同的，因此我們在進行需求調研的時候，什麼部門的需求就應當跟什麼部門談。同時，縱向又可以劃分為多個層次，如高層領導
（巨集觀目標
）、中層領導
（具體效益
）與基層人員
（每一項業務流程的操作者
）1）樹立良好的職業威信；2）進行詳細角色分析，將與會各方代表對號入座；3）從巨集觀上制訂目標與方案。隨後的工作，就是與各方**建立聯絡，逐一拜訪他們，將需求調研工作一步一步進行下去。
在需求調研過程中，與客戶建立感情，
經過一番交往，我們將逐漸在客戶中結識一批可以幫助我們的人。今後一段日子裡，我們將依靠他們去學習和認識業務知識，收集業務需求，為日後的軟體研發提供素材。
研討會：
有效抑制個性化差異、分模組組織專項研討會。
需求研討：
大量業務分析與技術可行性分析基礎上的分析活動。只有建立在這種分析基礎上的軟體研發，才能保證需求的正確與變更的可控。
需求捕獲，就是我們與客戶在一起開研討會，討論需求的活動。客戶可能會描述他們的業務流程，這時我們在紙上繪製簡單的流程草圖，及時地記錄下來；客戶在描述業務的同時，可能會反覆提到一些業務名詞，詳細詢問這些名詞的含義，以及它們與其它名詞的關係，用類圖或者物件圖繪製簡單的草圖；客戶在描述業務的同時，還會提出今後的軟體希望實現的功能，如能夠展示某個報表、能夠匯出檔案，以需求列表的形式記錄下來。需求列表是客戶提出的最最原始的需求
。需求整理：
首先，需求分析人員應當通過用例模型，劃分整個系統的功能模組，以及各個模組的業務流程。用例模型分析是乙個由粗到細的過程，這樣乙個過程也是符合人類認識世界的思維習慣的乙個過程。最先，我們應當對整個系統繪製用例圖，設計用例場景，並依次對這些用例進行用例描述、流程分析、角色分析等分析過程。當然，在整體用例分析的同時，我們還應當進行乙個整體的角色分析，繪製乙個角色分析圖，進行乙個流程分析，繪製乙個流程分析圖（可以是傳統的流程圖、uml中的行**，甚至乙個簡單的示意圖，等等）。
細化需求：業務流程分析與業務領域分析對流程改進的分析：清除低效環節、簡化業務瓶頸、整合可用資源，以及將繁瑣任務自動化。
（繪製行**、狀態圖，以及編寫用例說明來完成這部分工作。
）需求分析：功能角色分析與用例圖
。需求分析階段--需求捕獲->需求整理->需求驗證->再需求捕獲
軟體需求與分析 閱讀筆記
1.需要掌握的必要的內容 1 需求調研 需求調研是需求分析最重要的一環，也最集中地體現了需求分析的特點 既是乙份體力活兒，更是乙份技術活兒。它既要求我們具有一種理解能力 設計能力，更要求我們具有一種與人交往 溝通的能力。我們對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加...
軟體需求分析 閱讀筆記
筆記要求 發表一篇閱讀筆記，說明本學期 軟體需求分析 需要掌握哪些必要的內容？針對每個內容點說出自己的理解，並繪圖標意相互之間的關聯關係。讀 需求工程 軟體建模與分析 有感 今天大致的看了一下這本書，對軟體需求分析有了初步的了解，我認為學習軟體需求分析需要掌握的內容主要包括五個方面 需求基礎與過程 ...
軟體需求分析閱讀筆記
今天讀了關於如何做需求分析的博文，學習了軟體需求與分析需要掌握的一些內容，下面就做一些總結。首先要認識到深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。第乙個舉出來東軟的例子，東軟在做這個專案的時候，整個過程經歷了10多次結構性的大變更，區域性性的調整更是不計其數...