最近的課程中老師一直在強調需求分析這個部分，最近讀書也讀到了這個部分，現在簡談各個階段的常用方法，方便自己以後查閱。
軟體工程團隊接活兒的時候需要明確使用者需要什麼，專業一點的說法就是需求確定。雖然這個部分從技術角度上來講在整個需求處理過程中最低，但一旦沒有完成好帶來的後果是最糟的。為了完成業務需求，需要克服業務過程設計和過程實現之間的困難，前者是由業務人員完成，而後者則是it專家的活兒了，兩個不同領域的互動溝通是必要的，因此專家們提出了很多方便溝通的語言和表示法。主要應用的是業務過程建模表示法（bpmn）。bpmn是專門用於對由活動定義的業務過程建模，而形式上它不支援過程的結構建模。bpmn提供了4種基本的型別的建模元素：流物件；連線物件；泳池（泳道）；人工製品。其中流物件是bpmn的核心元素。這些是bpmn的基礎構造和概要。
第二階段是需求引導，業務分析員通過諮詢發現系統需求，該諮詢過程涉及客戶和問題領域的專家。在一些情況下，業務分析員擁有足夠的領域經驗，領域專家可能不需要。這時書中引出了需求引導的理念。需求可以分成兩類：系統需求和非功能性需求，前者為組織定義了策略方向，而後者本質上不是行為的，是系統開發和實現過程中的約束。需求引導的傳統方法有：面談，調查表，觀察和研究業務文件。這些方法符合成本效益，但取得的效果與專案的風險程度是成反比的，因此在使用的時候需要斟酌情況。因此，需求引導又出現了一些現代方法：原型法，頭腦風暴，聯合應用開發和快速應用開發。原型法是構建乙個軟體模型給使用者進行演示，獲取反饋；頭腦風暴則是打破思維邊界，無視規則拓展自己的想法，這種方法一般用於產生新思想或者可能的解決方案，但不負責之後的分析和決定；聯合應用開發類似頭腦風暴，它將所有利益相關者聚在一起進行討論；快速應用開發就像它的名字一樣，主要目的是快速交付系統解決方案。
第三階段是需求協商與確認。由於來自客戶的需求也許是重疊或者矛盾的，有些需求也可能是模稜兩可或者不現實的。因此在形成需求文件之前需要對需求進行協商與確認。這個過程需要與需求引導同步進行。該過程不能從書寫需求文件的過程中脫離出來，它通常以文件的草稿為基礎的。該過程分三個模組：超出範圍的需求，需求依賴矩陣，需求風險和優先順序。每乙個階段都是為了校正需求的方向。
第四階段是需求管理。該部分涉及三個主要問題：標識，分類，組織需求，並為需求建立文件；需求變更；需求跟蹤。需求標識與分類以自然語言進行描述，再按某種標識方案對需求進行編號，這個方案可能包括將需求劃分為更多的可能管理組的需求分類。談到這裡我們很容易就能想到資料庫。需求層次則是按父子關係建立層次化結構，父級需求由子級需求組成；變更管理則是考慮到各種需求的變更要求，對此進行一定的管理策略，防止出現混亂。
第五階段是需求業務模型。這個階段書中做了幾點摘要：系統範圍模型，界定系統的範圍；業務用例模型，用來標識高層業務程序；業務詞彙表，解釋明確業務和系統術語以避免出現溝通問題；
業務類模型，uml類模型，標識系統中業務物件的主要型別。
最後乙個階段是需求文件。它是需求確定階段的乙個實實在在的結果。需求文件的主體由需求陳述組成，它還要解決專案問題，該部分在文件的開頭以及文件的結尾都要討論。文件模板：可以從教科書，標準化組織，諮詢公司的web頁面，軟體工程工具的**商等處獲得，文件模板定義了文件結構，並給出了文件每一節需要書寫的內容的詳細指南。專案準備：文件的專案準備部分主要針對管理者和決策制定者，這些人不可能仔細研究整個文件。專案的目的和範圍需要在文件一開始就解釋清楚，緊跟著就是業務環境。系統服務：需求文件的主要部分是定義系統服務，這部分很可能佔到整個文件的一半以上，這也是文件中包含解決方案的高層模型僅有的部分。系統約束：設立系統約束是由於以下幾個需求：介面需求，效能需求，安全性需求，操作性需求，政策和法律需求。這些都需要在文件中體現。專案的其他問題：需求文件最後的主要部分是解決專案的其他問題。這部分的乙個重要內容是開放問題。附錄：附錄是文件的最後部分，附錄包含理解需求的其他有用的資訊，主要包括乙個業務詞彙表。參考文獻部分則提供需求文件中引用的文件，或者攢需求文件的準備過程中使用的文件。
以上是對需求分析部分的簡述。
《需求分析與系統設計》閱讀筆記二
為了完整地說明乙個系統，有必要採用多種模型。需求規格說明以敘述性的使用者需求作為輸入，構造出規格說明模型作為輸出。需求規格說明涉及對需求確定期間定義的客戶需求進行嚴格的建模，重點放在那些系統將要提供的所期望的服務 功能性需求 上。軟體體系結構定義了系統中相互作用的軟體構件及子系統的結構和組織形式。模...
《需求分析與系統設計》閱讀筆記四
資訊系統從定義上就是多使用者系統。多個使用者和應用程式可以通過資料庫管理系統併發訪問同乙個資料庫。應用程式依賴與資料庫的不僅僅是資料，還有資料庫提供的解決併發衝突 保證資料的安全訪問 保證資料一致性 事務錯誤恢復等功能。類模型和 子系統中只包含應用類，而不包含資料庫結構的儲存。實體類表示應用程式中持...
《需求分析與系統設計》閱讀筆記（五）
本學期的人機互動，net，軟體開發案例分析三門課程中，都考察過介面設計，在大作業要求中介面設計佔了相當的比重。在軟體開發過程中，需求分析有著明確的準則，模型，那麼介面設計有沒有呢，答案顯然是肯定的。使用者介面開發開始於需求分析階段中早期的gui窗體草圖。gui窗體在學習過程中我已經接觸過了，但要說對...