1.需求獲取
在進入正式開發之前，必須先從用戶處獲取準確的需求。在這上面花費相當時間是很必要的。
軟件項目可以大致分為專用軟件和通用軟件兩大類。
對于專用軟件，例如給某單位開發一套該單位專用的系統，一般用戶對于軟件
但是，開發合同上規定的只是一個大概的框架，在進入開發之前必須與用戶進行比較具體的交流和討論，了解清楚用戶心目中的產品究竟是什么樣子。這個步驟如果沒有好好做，往往到了開發工作的后期才發現開發人員的理解和用戶的要求有一些誤解，那么必然造成時間上的浪費。
對于通用軟件，在開發之前應該做一定的市場調查工作，一方面是從經濟效益考慮，調查產品的潛在市場有多大，另一方面是從技術的角度，必須了解清楚潛在用戶對軟件的各種技術上的要求，例如，用戶現有硬件配置如何，軟件配置如何，使用什么網絡，使用 什么數據庫等等，根據調查的統計結果決定即將開發的軟件的一些技術指標。
為了比較好地與用戶進行交流，使用一些工具是很有好處的。
為了討論用戶界面，可以用VB, delphi等做一個原型，根據原型有針對性地與用戶討論需求。(原型開發不僅僅可以用于準確獲取用戶的需求，開發出來的原型本身可以作為下一步開發的基礎，增量式地完成開發)
為了討論軟件運行的流程，可以采用UML的Use Case圖。
2.需求分析
在了解用戶的需求之后，將需求用一種模型來表示，就是需求分析，目前比較流行的 分析方法是面向對象的方法，通過分析用戶需求，用類、類之間的各種關系來表示整個系統。
這部分涉及到具體的方法，在此不詳細討論，但是原則上是提取類->類之間關系,可能需要不斷修改而形成一份分析文檔。
我想強調幾個問題。
一是要分清問題域與系統責任。系統責任是指所要開發的軟件應該完成的功能，而問題域是包含所有相關的部分。例如你要開發一個程控機計費程序，程控機已經是現成，輸出的數據格式也已經是固定的，你的程序僅僅需要從程控機中讀取相應的信息，那么，程控機在你的系統里只是一個外部的東西，把它作為一個類也許就是不必要的，僅僅需要一個類來完成讀數據的操作。又如，你需要在一個已經存在的數據庫上開發一些應用，數據庫的格式已經固定，并且已經有一個后臺程序在運行，你需要開發一個新的前臺程序，這時，服務器程序對你來說就是一個外部的東西。但是，象這種外部的內容必須在分析文檔中有一些說明，作為系統的外在約束。
二是需求獲取與需求分析的關系。
用什么方法來完成需求的獲取，在很大程度上影響了需求分析的做法。
例如當初采用Use Case來表示用戶需求，那么從各種序列圖中選出相互交互的各個實體，就是一個個類。
三是分析與設計過程的銜接。
分析過程的內容是用類的結構來表示目標系統，并不設計具體實現，如采用什么編程 語言，在什么操作系統平臺上運行等等。這些具體實現是在設計階段來完成的。面向對象方法的優點是分析、設計、編碼過程表示法統一，能比較好的銜接。但是，是把分析和設 計階段分開，采用瀑布式開發，還是采用其他方式，要看具體的情況。
對于需求潛在變化不大的項目，可以采用瀑布模型，有一個很明顯的設計階段，這樣做的好處是有一份比較完整的分析文檔，這樣以后如果需要采用不同的編程語言、或者采 用其他的平臺時，便可以以這份分析文檔作為開發的基礎。
對于需求變化頻繁的項目，可能采用少量分析;少量設計少量編碼測試的方式更合適，而且隨時可能要返回到前面某個一階段去進行修改。但是這意味著可能沒有一份完整的分析文檔。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
