如何進行軟件需求分析?

怎樣做軟件的需求分析？

軟件需求的定義：

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

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

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

需求工程的定義：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.需求分析評價標準

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

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

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

如何進行軟件需求分析

1.概念

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

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

百事通

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

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

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

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

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

2.需求分析的任務

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

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

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

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

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

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

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

3.需求分析過程

......

軟件工程中需求分析是對哪些方面進行分析

需求分析是指理解用戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目代價，最終形成開發計劃的一個複雜過程在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之後的軟件設計打下基礎。需求分析階段包括： ·業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在項目定義與範圍文檔中予以說明。 ·用戶需求——描述了用戶使用產品必須要完成的任務，這在使用實例或方案腳本中予以說明。 ·功能需求——定義了開發人員必須實現的軟件功能，使用戶利用系統能夠完成他們的任務，從而滿足了業務需求。 ·非功能性的需求——描述了系統展現給用戶的行為和執行的操作等，它包括產品必須遵從的標準、規範和約束，操作界面的具體細節和構造上的限制。 ·需求分析報告——報告所說明的功能需求充分描述了軟件系統所應具有的外部行為。“需求分析報告”在開發、測試、質量保證、項目管理以及相關項目功能中起著重要作用。 還有一個網頁去看看吧，也許對你可能有幫助。 hi.baidu.com/...0.html 還有在軟件工程的書籍上說的更清楚。

如何進行軟件需求分析

需求分析可分為需求提出、需求描述及需求評審三個階段。 在問題分析階段分析人員的主要任務是：對用戶的需求進行鑑別、綜合和建模，清除用戶需求的模糊性、歧義性和不一致性，分析系統的數據要求，為原始問題及目標軟件建立邏輯模型。分析人員要將對原始問題的理解與軟件開發經驗結合起來，以便發現哪些要求是由於用戶的片面性或短期行為所導致的不合理要求，哪些是用戶尚未提出但具有真正價值的潛在需求。

如何進行軟件需求分析

如何進行軟件需求分析，簡而言之不是幾句話可以描述清楚的，這裡給你一些方法功能參考。

首先，在進行軟件需求分析之前，得有一份軟件說明書或者軟件需求規格說明書，因為這個是我們進行需求分析的對象。但是這個需求規格書寫的質量怎麼樣，實際上是決定了軟件項目的進度、成本甚至成敗的？為什麼這麼說呢？因為當前軟件開發這個行業最大的問題是需求質量低下，這個導致了項目成本至少增加了30%以上，這也是為什麼軟件這個行業有錢的公司不多的主要原因。或者說能做出一份有質量的需求規格說明書將體現這個企業的掙錢能力，但現實是絕大多數企業都像人月神話中描述的一樣：一步一步踏入了泥潭。。。由於這個工作產品如此重要，因此通過過個步驟來保證它的質量：需求策劃、獲取、分析、確認以及後期需求管理，尤其是變更管理。如果想了解具體的每個步驟的詳細內容可以聯繫我。

其次，如果需求規格說明書有了，我們怎麼分析呢？在具體說明分析方法之前，首先我們要明確一個問題：需求分析到底是在分析什麼？其目的是什麼？其實我們絕大多數的需求工程師都不太清楚或者不能明確的回答這些問題，從而導致他們花費了大量的時間來寫用例（user case），寫了很多關係複雜甚至連需求人員都看不明白或者越看越糊塗的東西，因為他們認為這樣後續的開發、測試人員就能開明白了，事實上是這樣的嗎？根本不是，如果是的話，我們的軟件行業中的絕大多數企業活的普遍不那麼悲慘了。。。回到軟件開發，我們來想一下，我們開發這個東西給誰用？是自己嗎？？？如果是自己事情就簡單了，因為需求都在自己腦子裡面了，就算不完整起碼也不會缺多少，但問題正好相反，99.999999%的情況下我們是為別人或者說我們的用戶開發的，也就是說需求其實是在客戶的腦子了，而不是我們的腦子裡！！！我們的首要目的應該是如何通過一套完整的套路把需求從客戶的腦子裡面傳輸到我們的腦子裡面，然後按照規格化（這個是另外一個重點）的方式把它按照說明書一樣描述出來讓後續人員能夠看得清清楚楚、明明白白，這個步驟是最關鍵的一環，因為我們的絕大多數客戶都不會寫需求規格說明書，所以這個任務落在我們的身上。那麼我們到底都問什麼不會丟需求呢？這個是有一套方法和模板來指導需求人員和UI工程師（調研時就需要畫原型，可以稍微想一下這麼做的好處）來獲取完整的需求。只有這樣，才能獲取有質量的需求。

那麼說了這麼多，分析到底是幹什麼的呢？分析就是需求人員首先自己要系統的檢查一下需求來保障需求的質量，記住不是保證，是保障，它就像軟件開發中的評審或測試一樣，是保障產品的質量進行的檢查活動，它們不能保證質量，只是保障作用。就像我們考試一樣，你認真的答完題了，還是需要認真的檢查一遍，因為這個是人的天性之一。那麼問題來了，怎麼進行檢查或者從哪些方面進行檢查呢？我推薦的策略是先外後內、先系統後模塊、先功能後非功能、先業務後屬性，通過整套方法下來可以幫我們查到不少之前遺漏、寫錯、或者矛盾的地方，當然也包括可能不是客戶需要的needs，只是expectation。這個工作比獲取要簡單一些，但是是一個繁雜的活，要逐項逐項的檢查每一個需求的內容以保障需求的質量。到底檢查哪些內容呢？這個太多了，就不羅列了，需要的網友可聯繫我。

同樣，需求評審就是另外一幫人幫我我們再次檢查一下需求，看看裡面是否有什麼問題存在，是進行需求質量保障的另外一個重要環節。

因此，分析與評審其實是很類似的工作，只是參加檢查的人員角色從單一角色變為多角色，因為需求規格說明書要被他們拿來進行實現和測試。

我們常規的需求分析，基本上可以認為是在 盲人摸象，在主觀......

如何進行軟件需求分析

軟件工程這門學科隨著發展越來越顯得重要,是一個專業的軟件開發人員所應該具有的品質,沒有需求分析就不可以有一個完整而又經濟的軟件出現和發展!這門學科特別的好,應該好好體會其中的理念,為你個人以後的成長和做人處事都是有幫助的!我們做什麼事情都應該事前做好需求分析才能立二不敗之地!特別你要是一個軟件開發人員更應該深入體會其中的奧祕!

軟件需求分析的過程

軟件需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其它系統元素的接口細節，定義軟件的其它有效性需求。進行需求分析時，應注意一切信息與需求都是站在用戶的角度上。儘量避免分析員的主觀想象，並儘量將分析進度提交給用戶。在不進行直接指導的前提下，讓用戶進行檢查與評價。從而達到需求分析的準確性。分析員通過需求分析，逐步細化對軟件的要求，描述軟件要處理的數據域，並給軟件開發提供一種可轉化為數據設計、結構設計和過程設計的數據和功能表示。在軟件完成後，制定的軟件規格說明還要為評價軟件質量提供依據。

需求分析的作用及如何進行需求分析

通過對應問題及其環境的理解與分析，為問題涉及的信息、功能及系統行為建立模型，將用戶需求精確化、完全化，最終形成需求規格說明，這一系列的活動即構成軟件開發生命週期的需求分析階段。

需求分析是介於系統分析和軟件設計階段之間的橋樑。一方面，需求分析以系統規格說明和項目規劃作為分析活動的基本出發點，並從軟件角度對它們進行檢查與調整；另一方面，需求規格說明又是軟件設計、實現、測試直至維護的主要基礎。良好的分析活動有助於避免或儘早剔除早期錯誤，從而提高軟件生產率，降低開發成本，改進軟件質量。

需求工程是隨著計算機的發展而發展的，在計算機發展的初期，軟件規模不大，軟件開發所關注的是代碼編寫，需求分析很少受到重視。後來軟件開發引入了生命週期的概念，需求分析成為其第一階段。隨著軟件系統規模的擴大，需求分析與定義在整個軟件開發與維護過程中越來越重要，直接關係到軟件的成功與否。人們逐漸認識到需求分析活動不再僅限於軟件開發的最初階段，它貫穿於系統開發的整個生命週期。80年代中期，形成了軟件工程的子領域——需求工程(requirementengineering,RE)。進入90年代以來，需求工程成為研究的熱點之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發行了一新的刊物——《RequirementsEngineering》。一些關於需求工程的工作小組也相繼成立，如歐洲的RENOIR(RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups)，並開始開展工作。　　需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。它通過合適的工具和記號系統地描述待開發系統及其行為特徵和相關約束，形成需求文檔，並對用戶不斷變化的需求演進給予支持。RE可分為系統需求工程（如果是針對由軟硬件共同組成的整個系統）和軟件需求工程（如果僅是專門針對純軟件部分）。軟件需求工程是一門分析並記錄軟件需求的學科，它把系統需求分解成一些主要的子系統和任務，把這些子系統或任務分配給軟件，並通過一系列重複的分析、設計、比較研究、原型開發過程把這些系統需求轉換成軟件的需求描述和一些性能參數。

需求工程是一個不斷反覆的需求定義、文檔記錄、需求演進的過程，並最終在驗證的基礎上凍結需求。80年代，HerbKrasner定義了需求工程的五階段生命週期：需求定義和分析、需求決策、形成需求規格、需求實現與驗證、需求演進管理。近來，MatthiasJarke和KlausPohl提出了三階段週期的說法：獲取、表示和驗證。

綜合了幾種觀點，可以把需求工程的活動劃分為以下5個獨立的階段：

（1）需求獲取：通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求；

（2）需求建模：為最終用戶所看到的系統建立一個概念模型，作為對需求的抽象描述，並儘可能多的捕獲現實世界的語義；

（3）形成需求規格：生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；

（4）需求驗證：以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性；

（5）需求管理：支持系統的需求演進，如需求變化和可跟蹤性問題。...

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

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）或活動順序（有時稱作“情節”），可以確定用戶利用系統需要完成的任務，分析員由此可以獲得用戶用於處理任務的必要的功能需求。