需求分析的方法
需求分析各個方法論的派別均有不同的作法，以下簡述RUP（Rational Unified Process）、XP（eXtreme Programming）、MSF（Microsoft Solutions Framework）及鼎新研發的MDM（Model Driven Methodology）開發方法論需求分析的方法：
RUP：使用案例（Use Case）－在需求分析階段繪製使用案例圖（Use Case Diagram），描述操作者（Actor）的行為模式。
一個使用案例就是一個系統功能，不過，使用案例沒有描述使用者介面，是在User Interface Analysis中建立User Experience Model作為使用介面製作的依據。
XP：客戶駐點及User Story－XP並沒有需求分析的過程，每個人都身兼分析師、設計師與開發者的角色，而且開發者與使用者均是專案團隊的成員。藉由客戶駐點使用者提供第一手的需求描述，開發者根據使用者的描述，或Story Card的內容，產出可執行的版本，交給使用者確認，再根據使用者的回饋，持續修正或增加新的功能，經由一次次反覆的互動與調適，最後實作出最貼近需求的產品。
MSF：案例（Scenario）－案例與RUP的使用案例（Use Case）的精神類似，利用案例反映不同角色的使用者的需求。「Persona」就代表不同角色的使用者，類似RUP Use Case中的Actor（操作員），其用意類似劇本中的演員，呈現了使用者的角色、行為、背景與動機等，例如惡意使用者的操作行為與一般使用者的行為模式便有很大的不同。以區分角色與行為模式的方式，更貼近真實的系統需求。
鼎新MDM：模型驅動－軟體需求的表達太過抽象，可能使用者描述不清；也可能開發者理解有誤；更多的例子是使用者看到實際的成品後，才知道怎麼做是符合需求的。
鼎新希望在需求分析階段徹底解決可能的誤差，以模型導向的方式，改變生產流程，並創造了塑模師的角色，提前呈現系統的面貌，讓使用者在需求定義階段，就確認系統是不是他們要的樣子。
流程改善5步驟－沒有偉大的流程，只有適合的流程
專家觀點
鄭炳強
●國立中山大學資管系教授
●臺灣軟體工程學會理事
●高雄醫學大學資訊處顧問
“在選擇開發的方法與工具之前，一定要先了解它的缺點與限制。”
周忠信
●東海大學資訊工程系教授
●臺灣軟體工程學會理事
●鼎新電腦技術總顧問
“簡單就是美。簡單才能輕易融入成為公司的文化。如果需要重新學習很多的知識、面臨大範圍的習慣改變，可能引發很大的痛苦與反彈。”
胡佑長
●美國SEI授權臺灣首位CMMI主任評鑑員
●寶發科技總經理
“不要迷信最佳實務。流程改善應該考量企業的規模、文化、專案的性質、人員素質、開發方式及開發團隊的成熟度等，尤其開發團隊的成熟度最為關鍵。”
David Anderson
●微軟總部參與MSF設計的Visual Enterprise Studio部門流程架構師
“流程應該像汽車的引擎，發動之後就自動運行。”
軟體開發流程的學派林立，從輕量級的如XP、SCRUM、FDD到重量級的RUP有多種選擇。不過，所有知名的理論，都找得到成功案例與和失敗教材，企業應考量自身的規模、文化、人員素質、開發方式及開發團隊的成熟度，選擇適合的流程，並允許保留調適的空間，硬套死板的理論或僵硬的工具，其實無法複製他人成功的經驗。
標準化是為了強化控管
軟體專案不能沒有管理，而管理必須透過計畫與流程落實。專案初期制訂的計畫都很理想，但是經過長時間的演變，實際情況往往與計畫脫勾。
制訂標準化的流程，開發階段的所有活動，便可區分為「進行中」、「完成」、「停滯」或「延遲」等各種狀態，其實與Workflow的概念類似，透明化的資訊，幫助管理者掌握實際的進展，便可有效地追蹤與管理分析、設計、開發、測試等各項活動執行的情況。
「制度」會帶來相對的「限制」，不過，寶發科技總經理胡佑長：「企業越希望靈活，就越需要制訂流程。」流程與靈活並不衝突，如果流程無法因應改變，表示流程過於死板而需要改善。
選擇方法論前，先了解缺點與限制
軟體開發的方法論很多，每一種都有令人嚮往的好處。不過，中山大學資訊管理系教授鄭炳強認為：「在選擇方法與工具之前，一定要先了解它的缺點與限制。」例如採用XP的前提，是擁有實力堅強的開發團隊；RUP不適合無法以使用案例（Use Case）描述需求的專案。若選擇了錯誤的方法，會為專案帶來無窮的困擾。
任何方法論找得到失敗的案例，微軟總部Visual Enterprise Studio部門流程架構師David Anderson分享在過去參與新加坡銀行開發信用貸款系統的經驗，在David加入前，原先採用RUP方法論，耗時3年產生3,500頁的文件，客戶最常說的一句話是：「Show me Something to eat!」除了成堆文件之外，客戶希望看到實際的東西，最終專案宣告失敗。David接手後，丟掉數以噸計的文件，採用敏捷的FDD（Feature Driven Development，特性驅動開發）方法論，結果出奇成功地在期限與預算內結案。
這表示敏捷的流程比較好嗎？在微軟舉辦的企業軟體工程高峰會中，便有使用者詢問，他們採用XP方法論，初期很順利，但開發到一定規模之後，逐漸面臨重構的困難，導致進度持續延宕。
再看看目前臺灣軟體界興起的CMMI全民運動，似乎為臺灣軟體開發流程品質找到了改善的契機，但若軟體廠商以通過「評鑑」為目標，實際開發專案仍以老方法做事情，大家也可以共同檢視品質改善的成果。
步驟１：考量自身的特質
成功的案例值得參考，失敗的教材不代表理論本身有問題，而是應該依據專案性質的不同，調整或混合應用成為真正適合的開發流程，並允許團隊在執行過程中，做必要的彈性修改。胡佑長認為：「流程改善應該考量企業的規模、文化、專案的性質、人員素質、開發方式及開發團隊的成熟度等，尤其開發團隊的成熟度最為關鍵。」
此外，胡佑長強調：「不要迷信最佳實務。」流程改善工程，大家都希望尋求參考的「範本」，然而並沒有「一體適用」或所謂的「最佳實務」存在，流程是需要量身訂作的。
凌群電腦研發二處經理鄧大宇，以3次參與導入CMMI的經驗分析：「即使同一集團的不同企業體，流程也有很大的差異。」凌安電腦是凌群電腦集團於大陸投資的子公司，鄧大宇協助凌安電腦導入CMMI Level 3時，曾以凌群電腦的流程提供參考，最終卻修改了60%以上的內容。
步驟2：尋找改善的目標
與其硬套別人的學說或理論，不如基於既有習慣的開發流程，調適成為標準化的步驟，再參考其他方法論的作法，補強自身脆弱的環節，就可以形成一個量身訂作的最佳流程。
至於什麼是脆弱的環節，鄭炳強認為：「如果某些問題一再發生，就需特別針對重複出現的問題，設計因應的流程。」軟體開發最常發生的問題，是層出不窮、無法預期的臭蟲（Bug），凌群電腦長達10年的品質改善工程，便是起因於臭蟲，進而開始學習測試的方法，建立專責的測試單位與測試流程，由測試又引發一連串對品質各環節的重視。
周忠信認為：「管理者可以從想『看』什麼，作為思考流程的出發點。」敏捷的流程，注重溝通與互動，文件與控管相對較少；如果希望掌握工作的細節，流程的設計必定複雜，那麼RUP或許是不錯的選擇。
此外，專案與產品導向的軟體，開發的流程是不同的。資訊單位面對主管今天提出需求，明天就希望看到成果的要求，從「服務」的角度思考，流程的設計與產品導向的流程絕對是不同的。
步驟3：從簡單開始
從資策會工程研究所的案例分析，導入RUP需要對架構與概念有一定程度的了解，因為專案負責人李至霓對RUP與Java均有相當程度的了解，再加上團隊成員人數少且實力平均，所以李至霓在每個階段，都親自示範一個功能的實作，工程師就可以跟著依樣畫葫蘆產出其他功能的實作。
但是對於剛開始改善流程的企業，周忠信建議：「簡單就是美。」簡單才能輕易融入成為公司的文化。如果需要重新學習很多的知識、面臨大範圍的習慣改變，可能引發很大的痛苦與反彈。
David Anderson表示：「流程應該像汽車的引擎，發動之後就自動運行。」好的流程是無感的，觸發以後便自然推動每個環節的進行。
步驟4：先訂流程，再選工具
鄭炳強建議：「從簡單流程的開始，初期甚至不需要電腦工具。」利用人工化的流程，觀察初期的使用情況，並做必要的調整，待專案團隊達成共識，流程發揮效益後，再考慮自動化，提升工作的效率。
根據景華科技顧問協助軟體公司導入CMMI的經驗，第一階段設計流程、表單與控管機制，經過不斷地討論、試行與調整，找出最適合也最有效益的流程。在流程逐漸固定，也看出改善的效益後，才會選擇工具來搭配流程，享受自動化的好處。
屈就工具制訂流程是本末倒置的作法，一開始就自動化，套用僵硬的流程，只會造成困擾。企業應該先定義流程，然後選擇適合的工具，讓工具配合流程的需求，才不會限制了流程的可能性。
步驟5：持續改善
改善是持續的過程，企業發現新的問題時，再針對問題改善流程，才能強化應變的能力。所以流程絕非不是一陳不變，就像CMMI不是通過評鑑就結束。
凌群電腦在CMMI評鑑的前兩天，仍然在修改流程，評鑑過後又立即擬定了新的改善計畫。當你對企業軟體開發流程的強弱環節瞭若指掌時，可以變化的花樣就多了。
XP訴求以最佳智慧做出客戶最想要的東西
敏捷軟體開發聯盟宣言
● 個人及互動勝於流程和工具
● 可用的軟體勝於詳盡的文件
● 與客戶合作勝於合約談判
● 回應變更勝於墨守計畫
導入XP（eXtreme Programming，極限製程）的第一步就是拿起扳手與螺絲起子，動手拆隔板，因為XP強調的溝通、簡單、回饋與決心這4個價值觀，以及12項實務，主要精神說穿了就是貫徹「溝通」兩字。
XP是以少數人力在短時間開發系統的方式，適合2～12人的開發團隊，特別適合應用在需求經常改變的領域，因為需求的不確定性，所以相當重視客戶在開發過程所扮演的角色。管理者、客戶及開發人員對XP而言，都是專案的成員，必須透過充分的溝通與回饋，讓每個成員了解目前的版本能否滿足需求。
12項實務貫穿XP的核心精神－溝通
仔細研究XP，會發現以下12項實務多數只是為了達到充分溝通的手段：
1. 客戶駐廠：為方便隨時隨地的溝通，因此客戶必須駐廠，即時地回饋意見，並確認目前的版本能否符合需求。
2. 系統隱喻：XP並沒有系統分析師（SA）、系統設計師（SD）與程式開發人員等區別，每個人都扮演SA、SD和程式開發者的角色，直接跳過需求分析的階段，藉由客戶駐點面對面溝通的方式，取得第一手的需求，並直接做給客戶看，目的是為了做出符合客戶真正想要的東西。
而隱喻是為了讓客戶與開發者以共通的語言，確保彼此的溝通沒有誤解。以實際的比喻或故事，取代冗長而難以理解的文件，比喻可以與IT無關。例如說明授權機制可以舉實際生活的例子說明：一棟房子有很多層樓，每一層又很多房間，而某人的鑰匙只能開啟9樓A室的房間。總之盡量以易於了解的方式，表達需要的功能。
3. 通盤規畫：透過使用案例（User Story）發掘與評估需求，並在卡片（Story Card）寫上對需求的描述，讓開發者得以根據客戶的描述切割工作量，並確保在穩定的周期內，發布新的版本。
4. 小階段發行：依據Story Card切割工作，分階段發行新版本，而且必須是可執行的版本。
5. 簡單設計：今天的需求可能明天就改變，預留彈性反而是包袱，而且環境與技術都會改變，因此不去預想未來可能的功能，盡可能保持符合需求的最簡單版本。
6. 測試先行：XP的創始者Kent Beck提出的測試哲學，包括單元測試與整合測試。單元測試由開發者在撰寫系統程式前先寫測試程式，所以專案應有25~50%的時間是開發測試程式；而整合測試才是由測試人員負責。
7. 編程標準化：包括命名原則、編碼風格、函數、類別設計、繼承、運算符號等，設定一致的表現方式，提高程式的可讀性，將有助於改善軟體品質、提高開發效率並簡化維護工作。
8. 重構：在每個小階段發行、每個往覆式（Iteration）的周期後，甚至是每天下班前都可以執行一次重構，以保持程式碼的乾淨、簡單且具表達性。
9. 搭檔編程：兩個人共同開發一隻程式，一個人寫程式，另一個人看程式，檢視是否有錯誤或可改進的地方。兩人經常互換角色，這麼做的目的，是藉由充分的溝通與交流提升團隊整體的能力。
10. 共同維護：搭檔編程的搭檔關係，也需要經常替換（Switch Pair），讓每個人都可以維護系統的每個部分。
11. 持續整合：在開發期間，每一組搭檔可以隨時在測試過後，將程式簽入整合至系統，並諮詢其他搭檔執行所有測試，所以XP一天可能建構系統好幾次。
12. 每周40工時：為避免精疲力盡，XP希望以持久穩定的步調，維持高品質的工作效率，不借用明天的精力，強求在今天多完成一些工作，因此XP不允許團隊超時工作。唯一可以超時工作的例外，是發行前的最後一周，做最後的衝刺。
測試驅動的開發流程
XP之類的敏捷開發方法論，其輕巧特質，頗受開發者認同，然而大家著眼於其簡單設計與靈活因應需求改變的主張，卻往往忽略XP是測試驅動（Test Driven）的開發方法論，「測試」是必要的條件，若未撰寫測試程式，便不算是XP。
需求恆變是許多專案團隊抱怨的問題，然而XP的建議是擁抱改變，測試案例的目的，就是為了因應改變。以XP的經驗來看，透過錄製使用者介面的操作劇情，所執行的測試太過脆弱，系統底層很多功能與使用者介面無關，可能導致測試的漏洞，而建置健全的測試案例將使專案無懼改變。
未著手寫程式前，如何寫測試「程式」的程式？事實上，寫測試程式本身就是在進行系統的細部設計，寫測試程式前，必須決定Class（類別）的命名、參數為何、功能為何等。從測試的角度分析，叫用者（Caller）的觀點將多於開發者觀點，有助於設計更彈性、易用及簡潔的系統。
而先寫程式再寫測試的問題，在於開發完成後，團隊往往會缺乏動力，而且可能因為遺漏，使得有些程式沒有測試到，或者也可能將測試寫得太複雜。
強調不拘型式的文件
XP的「文件無用論」廣受IT界爭議：一個沒有文件的專案，後續的維護性令人質疑。其實XP有文件，而且是不拘型式的文件，以「Story Card」說故事打比方、畫UML圖、拍下白板上畫好架構的圖，甚至手繪的各種圖或文，都可以是文件的一種。
更重要的是，軟體會變，文件會過時，所以最好的文件是程式碼。為了讓程式擁有像文件一樣的可讀性，所以必須落實編程標準化，以同樣的風格撰寫程式，才能降低對文件的依賴性。
