需求分析
在具體的研究需求分析之前，我們先了解一下軟體工程這個概念。軟體工程分為三個層次，過程層、方法層、工具層。在最基礎的過程層，最重要的就是一組被稱為關鍵過程區域（kpas）的框架（kpa的概念在討論cmm的書中有詳細的概念說明）。關鍵過程區域構成了軟體專案的管理控制的基礎，並且確立了上下文各區域的關係，其中規定了技術方法的採用、工程產品的，模型、文件、資料、報告、**等，等的產生、里程碑的建立、質量的保證及變化的適當管理。方法層主要是過程在技術上的實現。它解決的問題是如何做。軟體工程方法涵蓋了一系列的任務：需求分析、設計、程式設計、測試、維護。同時他還包括了一組基本原則，控制了每乙個的關鍵過程區域。工具層就很好理解了，他對過程層和方法層提供了自動和半自動的支援。這些輔助工具就稱為case。
可以看到需求分析的位置，但是事實上需求分析是跨越了軟體工程的三個層次的。這一點是和其他的過程是一樣的。當然我們這裡比較重點強調的是在軟體工程的方法層，同時也涉及到一些過程層的思想，至於工具層則不再我們的討論之列，但是會提到一些很適合在需求分析時應用的工具，諸如word、excel、visio等。
方法需求分析都包括了哪些方法呢？這裡列舉出在《需求分析》一書中推薦的一些方法，
1) 繪製系統關聯圖，這種關聯圖是用於定義系統與系統外部實體間的界限和介面的簡單模型。同時它也明確了通過介面的資訊流和物質流。
2) 建立使用者介面原型，當開發人員或使用者不能確定需求時，開發乙個使用者介面原型—乙個可能的區域性實現—這樣使得許多概念和可能發生的事更為直觀明了。使用者通過評價原型將使專案參與者能更好地相互理解所要解決的問題。注意要找出需求文件與原型之間所有的衝突之處。
3) 分析需求可行性，在允許的成本、效能要求下，分析每項需求實施的可行性，明確與每項需求實現相聯絡的風險，包括與其它需求的衝突，對外界因素的依賴和技術障礙。 4) 確定需求的優先級別，應用分析方法來確定使用例項、產品特性或單項需求實現的優先級別。以優先順序為基礎確定產品版本將包括哪些特性或哪類需求。當允許需求變更時，在特定的版本中加入每一項變更，並在那個版本計畫中作出需要的變更。
5) 為需求建立模型，需求的圖形分析模型是軟體需求規格說明極好的補充說明。它們能提供不同的資訊與關係以有助於找到不正確的、不一致的、遺漏的和冗餘的需求。這樣的模型包括資料流圖、實體關係圖、狀態變換圖、對話方塊圖、物件類及互動作用圖。
6) 建立資料字典，資料字典是對系統用到的所有資料項和結構的定義，以確保開發人員使用統一的資料定義。在需求階段，資料字典至少應定義客戶資料項以確保客戶與開發小組是使用一致的定義和術語。分析和設計工具通常包括資料字典元件。
7) 使用質量功能調配，（qfd）是一種高階系統技術，它將產品特性、屬性與對客戶的重要性聯絡起來。該技術提供了一種分析方法以明確那些是客戶最為關注的特性。qfd將需求分為三類：期望需求，即客戶或許並未提及，但如若缺少會讓他們感到不滿意；普通需求；興奮需求，即實現了會給客戶帶去驚喜，但若未實現也不會受到責備（zultner 1993;pardee 1996）。
記住一點，不要試圖在你的專案中把這些方法都用上去，四個現代化並不是一夜就可以實現的。同樣，嘗試著使用你認為對你很有幫助的方法，確實收到效果之後，在考慮繼續學習方法。因為上面提到的都是需求分析的大方法，事實上還有很多很多的方法可以採用，例如，採用srs模板、指明需求的**、為每項需求注上標號、記錄業務規範、建立需求跟蹤能力矩陣、審查需求文件、以需求為依據編寫測試用例、編寫使用者手冊、確定合格的標準。
業務建模
很多人都沒有意識到業務需求階段應該做些什麼事情，實際上業務建模是最重要的一件事情。不要覺得業務建模這個詞很深奧，讓人模不著頭腦。其實所有做過需求分析的人都做過業務建模，比如你了解企業的運作模式就?是一種你腦海中的業務建模。但是大多數人都沒有科學的、系統的、文件化的做過業務建模。
業務建模的目的在於：
了解目標組織（將要在其中部署系統的組織）的結構及機制。
了解目標組織中當前存在的問題並確定改進的可能性。
確保客戶、終端使用者和開發人員就目標組織達成共識。
匯出支援目標組織所需的業務需求。
上面的話是不是很抽象呢，其實沒有什麼複雜的：人和電腦是完全不同的思想（思維方式）。所以，原先適合人的業務流程對於計算機來說可不一定合適的，為了最大限度的利用計算機，必須要了解原先的業務流程並對此加易改造（流程自動化），當然這些動作需要得到使用者的許可。有些人認為說只有erp這種大系統才需要對業務流程進行重組，但是實際上，不論是部門級的mis系統，還是社會級的電子商務系統，都需要對業務流程進行改造，所不同的只是改造的程度。
業務建模很重要的一點是在分析企業流程的同時分析出基礎企業物件（common business object）（這個詞我翻譯的不好，如果大家有更好的翻譯，請告訴我）。任何企業都有最基礎的一些元素，例如銀行的cbo就有帳戶，製造業的cbo就有訂單等。有一次我的乙個在企業應用方面研究多年的朋友告訴我乙個秘訣，他說，企業的cbo無非是4個：客戶、員工、產品和**商（銀行的**商應該稱為同業）。其他的所有cbo都是在這四個cbo的基礎上發展起來的。比如說cbo中客戶和產品是多對多的關係，根據關係資料的理論，任何多對多的關係都可以拆分成多個一對多或一對一的關係。你就可以在這兩個類之間引入訂單類，客戶和訂單之間是一對多，訂單和產品之間又是一對多，這樣乙個多對多的關係就拆分成兩個一對多的關係，而新的訂單類也就順理成章的產生了。在訂單類產生時，你可能還會加入乙個關聯類：業務員類。而業務員類又是從員工類繼承下來的。所以呢，企業的四種cbo通過不同的組合，不同的關係，能夠形成企業運作的許許多多的cbo。
cbo是做業務建模的基礎，在此基礎上，通過評估業務狀態，說明當前業務，確定業務流程，改進業務流程的定義，設計業務流程實現，改進角色和職責，研究流程自動化，開發領域模型等一系列在rup中定義的工作流程實現業務建模的目標。
需求獲取
軟體專案的需求變更管理
一 做好需求工程 需求分析是軟體工程專案最重要 最基礎的起始階段，為後續的規劃設計階段提供參照依據。在軟體研發專案過程中一定要樹立需求工程的意識，將需求視為一項系統工程。為了能夠全面做好需求管理，應根據專案實際情況嚴格劃分專案階段，清晰界定 定義專案階段的基線，在每個專案階段制訂 執行階段性需求管理...
專案的需求分析 管理系統二
一 專案 化學品調查系統 化學品調查專案涉及全國生產使用企業，企業需要每五年提交乙份資料，資訊系統收集資訊並彙 計，生成報表。二 資料 資訊內容包括企業資訊 產品資訊 原料 輔料資訊 特徵汙染物資訊 汙染物排放資訊 碼表。三 報表功能 生成匯 計表包括按地區彙總 按行業彙總 按產品類別彙總 按產品化...
專案的需求分析 管理系統三
一 專案 危險化學品登記管理系統 危險化學品生產使用企業需要定期上報資料資訊，逐級上報，匯 計，產生報表。二 資料 生產使用登記庫 進出口管理登記庫，汙染物排放 轉移資訊 碼表 彙總表 地理資訊表。三 功能 包括資料採集 匯 計 報表列印。與調查系統不同之處在於資料內容不同，分為一般類和重點類危險化...