如何做好系統需求分析?

如何才能把軟件需求分析做好

我的第一個故事來自大名鼎鼎的東軟。我在2005年接一個項目的時候，聽說這個項目之前是東軟做的。當時東軟在做這個項目的時候，整個過程經歷了10多次結構性的大變更，局部性的調整更是不計其數。據說某天早上，客戶對某個功能不滿意，他們不得不對幾百處程序進行修改。之後客戶對修改的內容還是不滿意，又不得不將幾百處修改重新改回來。最後這個項目導致的結果是，整個這個項目組的所有成員都離開了東軟，並似乎從此不願涉足軟件開發領域。多麼慘痛的教訓啊!我常常聽到網友抱怨客戶總是對需求改來改去，但客戶對需求改來改去的真正原因是什麼呢?當我們對客戶的需求沒有真正理解清楚時，我們做出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢?他不知道，於是就在一點兒一點兒試，於是這種反覆變更就這樣發生了。如果我們明白了這一點，深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。記住，當客戶提出業務變更的時候，我們一定不能被客戶牽著走，客戶說啥就是啥。我們要從業務角度深入的去分析，他為什麼提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。當我們提出更加合理的方案時，客戶是樂於接受的，變更也變得可控了。

從哪些方面如何具體做好需求分析

1. 訪問並與有潛力的用戶探討

為找出新軟件產品的用戶需求，最直截了當的方法是詢問他們。本章討論如何尋找合適的用戶代表，而在第8章講述從這些代表中獲取需求的技巧。

2. 把對目前的或競爭產品的描述寫成文檔

文檔可以描述一種所必須遵循的標準或產品所必須遵循的政府或工業規則。

3. 系統需求規格說明

一個包含軟、硬件的產品需要一個高檔次的系統需求規格說明以介紹整個產品。系統需求的子集被分配到每個軟件子系統中（ Nelsen 1990）。附加的詳細軟件功能需求將從有關軟件的系統需求裡獲得。

4. 對當前系統的問題報告和增強要求

指導用戶和提供技術支持的工作人員是最有價值的需求來源。他們收集了用戶在使用現有系統過程中所遇到問題的信息，還接受了用戶關於系統改進的想法。

5. 市場調查和用戶問卷調查

調查有助於從廣大有潛力的用戶那裡獲得大量定量的數據，務必調查相關的用戶並詢問一些能產生反響的好問題。

6. 觀察正在工作的用戶

對當前系統的用戶和將來系統的有潛力的用戶，分析員觀察“日常工作”以獲得經驗，這些經驗能提供很有價值的信息。分析員可通過觀察用戶與所關聯的任務環境的工作流程來預見用戶在使用當前系統時所遇到的問題，並能分析新的系統可有效支持工作流程的方面（McGraw and Harbison 1997; Beyer and Holtzblatt 1998）。比起僅僅簡單地詢問用戶，並記下用戶在處理任務時的步驟來說，直接觀察用戶的工作流程可以對他們的活動有更正確的理解。分析員必須抽象和總結用戶的直接活動，以確保所獲得的需求具有普遍性，而不僅僅代表單個用戶。一個富有技巧的分析員還可以為改進用戶的當前事務處理過程提出一些見解。

7. 用戶任務的內容分析

通常通過開發具體的情節（ s c e n a r i o）或活動順序（有時稱作“情節”），可以確定用戶利用系統需要完成的任務，分析員由此可以獲得用戶用於處理任務的必要的功能需求。

系統的需求分析怎麼做

個人認為需求分析要根據你所設計的程序的使用方（即客戶）的要求來定，通常有：

1.要考慮到系統的應用性，要求有良好的人機界面。

2.原始數據修改簡單方便,支持多條件修改

3.方便的數據查詢，支持多條件查詢;

4.刪除數據方便簡單，數據穩定性好；

5.數據計算自動完成，儘量減少人工干預;

6.強大的報表打印功能;

7.退出系統

如何進行軟件需求分析

1.概念

需求的定義包括從用戶角度(系統的外部行為),以及從開發者角度(一些內部特性)來闡述需求.

關鍵的問題是一定要編寫需求文檔.我曾經目睹過一個項目中途更換了所有的開發者,客戶被迫與新的需求分析者坐到一起.系統的分析人員說:"我們想與你談談你的需求."客戶的第一反應便是:"我已經將我的要求都告訴你們前任了,現在我要的就是給我編一個系統".

百事通

而實際上,UGGs,需求並未編寫成文檔,因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話,你就確信你已明白用戶的需求,那完全是自欺欺人.

需求的另外一種定義認為需求是"用戶所需要的並能觸發一個程序或系統開發工作的說明".有些需求分析專家拓展了這個概念:"從系統外部能發現系統所具有的滿足於用戶的特點、功能及屬性等".這些定義強調的是產品是什麼樣的,而並非產品是怎樣設計、構造的.而下面的定義則從用戶需要進一步轉移到了系統特性:

需求是指明必須實現什麼的規格說明.它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束.

從上面這些不同形式的定義不難發現:並沒有一個清晰、毫無二義性的"需求"術語存在,真正的"需求"實際上在人們的腦海中,這個人們主要是指客戶,但一般情況下,用戶並不能描述自己的需要,只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對.系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識.

任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型,一種描述.

2.需求分析的任務

開發軟件系統最為困難的部分就是準確說明開發什麼.最為困難的概念性工作便是編寫出詳細技術需求,這包括所有面向用戶、面向機器和其它軟件系統的接口.同時這也是一旦做錯,將最終會給系統帶來極大損害的部分,並且以後再對它進行修改也極為困難.

目前,國內產品的龐雜,一家企業可能有幾個系統並立運行,它們之間接口是系統開發人員最頭痛的問題.

對於商業最終用戶應用程序,企業信息系統和軟件作為一個大系統的一部分的產品是顯而易見的.但是對於我們開發人員來說,並沒有編寫出客戶認可的需求文檔,我們如何知道項目於何時結束?而如果我們不知道什麼對客戶來說是重要的,那我們又如何能使客戶感到滿意呢?

然而,即便並非出於商業目的的軟件需求也是必須的.例如庫、組件和工具這些供開發小組內部使用的軟件.當然你可能偶爾勿需文檔說明就能與其他人意見較為一致,但更常見的是出現重複返工這種不可避免的後果,而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價,這些血的教訓正在國內的軟件開發者身上發生.

近來,我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟件.不幸的是,當他們開發完這個工具後,發現這個工具不能打印出源代碼文件,使用者當然希望有這個功能.結果這個小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤並構思準確,如果我們沒有編寫文檔,軟件達不到期望目標也只能是咎由自取了.

相反的情況,我曾見一個要集成到"錯誤跟蹤系統"中的簡單界面寫了一頁需求說明.而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用.他們依據需求對系統進行測試時,此係統不僅非常清晰地實現了所有必需功能,而且未發現任何錯誤.

事實上,需求文檔在開發過程中一直起指導作用.

3.需求分析過程

......

如何做好需求分析，需求調研

轉載以下資料供參考

從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。

狹義上理解需求分析指需求的分析、定義過程。

原因

需求分析就是分析軟件用戶的需求是什麼。如果投入大量的人力，物力、財力、時間，開發出的軟件卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟件，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的(相信大家都有體會)。比如：用戶需要一個for linux的軟件，而你在軟件開發前期忽略了軟件的運行環境，忘了向用戶詢問這個問題，而想當然的認為是開發for windows的軟件。當你千辛萬苦地開發完成向用戶提交時才發現出了問題，那時候你是欲哭無淚了，恨不得找塊豆腐一頭撞死。

需求分析之所以重要，就因為他具有決策性、方向性、策略性的作用，他在軟件開發的過程中具有舉足輕重的地位，大家一定要對需求分析具有足夠的重視。在一個大型軟件系統的開發中，他的作用要遠遠大於程序設計。

任務

簡言之，需求分析的任務就是解決“做什麼"的問題，就是要全面地理解用戶的各項要求，並準確地表達所接受的用戶需求。

過程

需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。

問題識別：就是從系統角度來理解軟件，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標準。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、操作系統等)、可靠性需求(不發生故障的概率）、安全保密需求、用戶界面需求、資源使用需求(軟件運行是所需的內存、CPU等)、軟件成本消耗與開發進度需求、預先估計以後系統可能達到的目標。

分析與綜合： 逐步細化所有的軟件功能，找出系統各元素間的聯繫，接口特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。

制訂規格說明書： 即編制文檔，描述需求的文檔稱為軟件需求規格說明書。請注意，需求分析階段的成果是需求規格說明書，向下一階段提交。

評審： 對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。

方法

需求分析的方法有很多，這裡只強調原型化方法，其它的方法如：結構化方法、動態分析法等，從來沒用過這些方法在此不討論。

原型化方法是十分重要的，原型就是軟件的一個早期可運行的版本，它實現了目標系統的某些或全部功能。

原型化方法就是儘可能快地建造一個粗糙的系統，這系統實現了目標系統的某些或全部功能。但是這個系統可能在可靠性、界面的友好性或其他方面上存在缺陷。建造這樣一個系統的目的是為了考察某一方面的可行性，如算法的可行性、技術的可行性或考察是否滿足用戶的需求等。如：為了考察是否滿足用戶的要求，可以用某些軟件工具快速的建造一個原型系統，這個系統只是一個界面，然後聽取用戶的意見，改進這個原型。以後的目標系統就在原型系統的基礎上開發。

原型主要有三種類型：探索型、實驗型、進化型。

探索型：目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。

實驗型：用於大規模開發和實現前，考核方案是否合適，規格說明是否可靠。

進化型：目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。

在使用原型化方法時有兩種不同的策略：廢棄策略、追加策略。

廢棄策略：先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反覆進行修改,形成......

怎樣做軟件的需求分析？

軟件需求的定義：

（1）用戶解決問題或達到目標所需的條件或能力。

（2）系統或系統部件要滿足合同、標準、規範或其它正式規定文檔所需具有的條件或能力。

（3）一種反映上面(1)或(2)所描述的條件或權能的文檔說明。 實通俗的講，“需求”就是用戶的需要，它包括用戶要解決的問題、達到的目標、以及實現這些目標所需要的條件，它是一個程序或系統開發工作的說明，表現形式一般為文檔形式。

需求工程的定義：

需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發和需求管理兩個部分。需求開發是指從情況收集、分析和評價到編寫文檔、評審等一系列產生需求的活動，分為四個階段：情況獲取、分析、制訂規格說明和評審。這四個階段不一定是遵循線性順序的，他們的活動是相互獨立和反覆的。需求管理是軟件項目開發過程中控制和維持需求約定的活動，它包括：變更控制、版本控制、需求跟蹤、需求狀態跟蹤等工作。

需求開發與管理的一些方法：

（1）繪製關聯圖：繪製系統關聯圖是用於定義系統與系統外部實體間的界限和接口的簡單模型。

（2）可行性分析：在允許的成本、性能要求下，分析每項需求實施的可行性，提出需求實現相關風險，包括與其它需求的衝突，對外界因素的依賴和技術障礙。

（4）系統原型：當用戶自身對有的需求不十分清楚時，我們可以建立一個系統原型，用戶通過評價原型更好地理解所要解決的問題。。

（5）圖形分析模型：繪製圖形分析模型是編制軟件需求規格說明重要手段。它們能幫助分析人員理清數據、業務模式、工作流程以及他們之間的關係，找出遺漏、冗餘和不一致的需求。這樣的模型包括數據流圖、實體關係圖、狀態變換圖、對話框圖、對象類及交互作用圖。

（6）數據字典：數據字典是對系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶數據項，確保客戶與開發小組是使用一致的定義和術語。

需求管理的方法主要包括以下一些方面：

1）確定需求變更控制過程。制定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此過程。

2）進行需求變更影響分析。評估每項需求變更，以確定它對項目計劃安排和其它需求的影響，明確與變更相關的任務並評估完成這些任務需要的工作量。通過這些分析將有助於需求變更控制部門做出更好的決策。

3）建立需求基準版本和需求控制版本文檔。確定需求基準，這是項目各方對需求達成一致認識時刻的一個快照，之後的需求變更遵循變更控制過程即可。每個版本的需求規格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。

4）維護需求變更的歷史記錄。將需求變更情況寫成文檔，記錄變更日期、原因、負責人、版本號等內容，及時通知到項目開發所涉及的人員。為了儘量減少困惑、衝突、誤傳，應指定專人來負責更新需求。

5）跟蹤每項需求的狀態。可以把每一項需求的狀態屬性（如已推薦的，已通過的，已實施的，或已驗證的）保存在數據庫中，這樣可以在任何時候得到每個狀態類的需求數量。

6）衡量需求穩定性。可以定期把需求數量和需求變更（添加、修改、刪除）數量進行比較。過多的需求變更"是一個報警信號"，意味著問題並未真正弄清楚。

4.需求分析評價標準

（1）清晰：目前大多數的需求分析採用的仍然是自然語言，自然語言對需求分析最大的弊病就是它的二義性，所以開發人員需要對需求分析中採用的語言做某些限制。例如儘量採用主語＋動作的簡單表達方式。需求分析中的描述一定要簡單，千萬不要採用疑問句、修飾這些複雜的表達方式。 除了語言的二義性之外，注意不要使用行話，就是計算機術語。需求分析最重要......

如何才能提高系統分析（需求分析）的質量

幾天前我的部下告訴我說，鄰居的一家軟件公司（主要做外包的公司）全體員工加班一晚上沒有睡都沒有回家，我就問為什麼，他講，聽他們說他們做的不符合客戶的要求，客戶要求返工，所以全體加班。我的部下與鄰居的公司的人是煙友，有時會在走廊上一塊兒吸菸，我估計鄰居公司的員工加班一定是很鬱悶的事了，由於項目經理的錯，卻讓他們買單。他們公司的工資比我們公司的高，但他們的加班也通常比我們多的多了。 目前由於需求分析很難量化，而需求分析的結果也不好考核，所以大多公司都採取了學而優則仕的選擇人才的方式，從公司裡代碼開發好的人選擇培養做項目經理，做需求分析人員。這樣的結果有些冒險，有些代碼優秀的人員並不一定做好需求分析的，因為需求分析角度與技術解決方案並不相同。那麼什麼才是優秀的需求分析人員呢？我以前參加高級項目經理的培訓，一再地進行總結，並且努力提高需求分析的高度，以下是我的一點兒體會： 1、需求分析的考慮應該多角度，多維度去考慮一個問題。這是一件很重要的關鍵點，客戶提出的需求一般主要面臨的問題，也許是當年最要解決的困難，但他往往不會考慮以後的需求，以不會考慮與其他業務系統的關連，只關心解決他的問題。所以一定要多維度地考慮，對潛在的需求也要考慮。對關聯的業務更要注意。 2、操作人員關心日常的業務能不能勝任，而領導卻關心大的方向，能不能提供更多的數據，具體的業務操作和數據採集能不能實現都不會考慮那麼細，所以需求分析人員就需求多維度地考慮，不僅要考慮操作級的，也要考慮管理級的需求，同時也要考慮決策級的需求，這樣產品也才能適應面更廣泛。但一般開發人員往往注意操作級的需求了，等與管理的需求衝突時才發現需求變更很大，維護很痛苦。 3、需求要進行反覆的勾通和確認。調研人員總以為自己瞭解了客戶的需求，但實際上總是有一定的偏差的，所以寫成文字讓客戶確認或者重複把理解記錄的需求以及解決的辦法重複講客戶聽是減少誤差的很好的辦法，這類工作將很好地讓客戶理解他的業務。 4、原型開發也很重要，不要一開始就想著滿足客戶的所有需求，所以等你把所有的需求都設計開發完成了，客戶卻發現你所做的不是他所要的，那就慘了，所以不要一開始就完成所有的功能，而把主要的功能完成就可以了，讓客戶有一個反饋的可能性。這是一個很難把握的事，做到多少去讓客戶認可和試用呢，做的少，客戶會說無法使用，做的多，返工的損失會更大。這種事只有先要搞好客戶關係的前題下把握度了。

如何做好測試需求分析

測試需求主要通過以下途徑來收集：

1） 與待測軟件相關的各種文檔資料。如軟件需求規格、Use case、界面設計、項目會議或與客戶溝通時有關於需求信息的會議記錄、其他技術文檔等。 2） 與客戶或系統分析員的溝通。

3） 業務背景資料。如待測軟件業務領域的知識等。 4） 正式與非正式的培訓。

5） 其他。如果以舊系統為原型，以全新的架構方式來設計或完善軟件，那麼舊系統的原有功能跟特性就成為了最有效的測試需求收集途徑。

在整個信息收集過程中，務必確保軟件的功能與特性被正確理解。因此，測試需求分析人員必須具備優秀的溝通能力與表達能力。

參考：wenku.baidu.com/...pWekse

如何做需求分析

隨著技術的不斷髮展和用戶對網站功能性的需求不斷提高，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟件工程，也越來越複雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規範的、有效的、健壯的開發機制，才能適應用戶不斷變化的需要，達到預期的計劃目標。

網站項目管理（WPM）的含義為Web-based Project Management，即以Web 應用程序為主要表現方式的架構來進行的項目設計及管理，這樣的架構中包含了瀏覽器、網絡和Web

服務器等關鍵主體，主要體現在網站設計、以瀏覽器為客戶端的Web應用程序開發（例如信息類網站、網上商店、虛擬郵局、客戶關係管理。）等項目管理中。

按照筆者的經驗，網站項目管理可以分為以下l六個階段進行控制：

1. 需求分析及變更管理

2. 項目模型及業務流程分析

3. 系統分析及軟件建模

4. 界面設計、交互設計及程序開發

5. 系統測試和文檔編寫

6. 客戶培訓、技術支持和售後服務

需要說明的是，這些階段雖然具有一定的延續性，但是並非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。

（一）如何做好需求分析及變更管理？

業務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。

一：讓客戶暢所欲言，羅列出所有的需求

讓用戶將所有的想法儘可能的闡述清楚，並把所有的要求羅列出來，不要遺漏。這時候不應該害怕“勾引”起客戶的潛在需求而增加設計開發的工作量，從而被今後客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求準確地記錄下來就完成了第一步的工作。

很明顯，假如客戶的需求做的都不完整，隨時可能會產生意想之外的變更，甚至這個變更會破壞已經做的模型及結構，那麼這個項目從開始就註定了會失敗；比如站點所有的功能都實現了，本地測試起來也沒有什麼問題了，但是你卻不知道客戶的系統是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經驗的開發人員都會明白這樣的設計是個災難，無論是應用服務器、數據庫還是程序全部要重新開發！

二：透過現象分析潛在的需求

很多情況下客戶並非專業人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術難關，這需要我們去為客戶進行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現難度和強度很高的地方特別值得注意。

客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統而且尺度難以控制的，這就要求業務人員在傾聽了客戶的詳細說明以後，幫助客戶進行整理和分析，同時預測客戶在開發過程中變更及今後應用中可能進行修改升級的潛在需求。

比如在為客戶設計辦公自動化系統的時候，也許就要為客戶預留將來與他們的業務單位進行交互的通道；在設計郵件系統的時候要考慮可能會需要廣告管理服務器；設計網絡電子商店時今後增加庫存產品進銷存統計分析等等；限於時間財力的考慮，客戶通常能夠接受分階段實施的開發過程，在需求分析時，提早為客戶設想到今後的需求變更除了使項目開發更加順利以外，也為今後業務的進一步深入打下......

怎麼做好需求分析整理

需求分析是介於系統分析和軟件設計階段之間的重要橋樑。一方面，需求分析以系統規格說明和項目規劃作為分析活動的基本出發點，並從軟件角度對它們進行檢查與調整；另一方面，需求規格說明又是軟件設計、實現、測試直至維護的主要基礎。良好的分析活動有助於避免或儘早剔除早期錯誤，從而提高軟件生產率，降低開發成本，改進軟件質量。需求分析階段的基本任務是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其它系統元素的接口細節，定義軟件其它有效的需求。最主要的原因是對於開發小組的使用成員（包括用戶）來說，需求確定是極具認知性和創造性的活動。需求確定也許是仍在苦苦等待人工智能支持的最後領域之一。具體表現如下：系統分析員對問題域的瞭解程度也是一大困難。系統分析員感到需求確定很困難的另一個原因是問題域的動態性。生活是動態的，公司也是。項目團隊成員之間的溝通也一直是需求確定的另一大困難。每個問題域都有術語。最後，需求確定過程還會受到其它因素的影響。例如勞累、不舒服、開會時室內和窗外的干擾、團隊成員的壓力等等。