如何做需求分析

如何做需求分析

一、 我們應(yīng)當(dāng)如何做需求分析
需求分析不是一蹴而就的，它應(yīng)當(dāng)貫穿整個開發(fā)周期，不斷的分析確認(rèn)的過程。這就是敏捷開發(fā)倡導(dǎo)的需求反饋。

敏捷開發(fā)認(rèn)為，需求分析階段不可能解決所有的需求問題，因此在設(shè)計、開發(fā)、測試，直到最終交付客戶，這整個過程都應(yīng)當(dāng)不停地用開發(fā)的成果與客戶交流，及時獲得反饋。

只有這樣才能及時糾正需求理解的偏差，保證項目的成功。
二、我們應(yīng)當(dāng)怎樣做需求調(diào)研
1.初識。
我們對客戶提出的需求進(jìn)行深入理解以后，運(yùn)用我們專業(yè)知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。如果能夠這樣，客戶不僅能夠欣然接收你提出的方案，而且會感覺你非常專業(yè)，你在客戶心目中的形象也會無形中提高，使你有更多的機(jī)會提出有利于開發(fā)的可行方案，降低開發(fā)的風(fēng)險。

這毫無疑問會形成一個良性循環(huán)，但要做到這一點并不容易，毫無疑問，在與客戶接觸初期的表現(xiàn)起到了極其關(guān)鍵的作用。
(1)高層**關(guān)心的是宏觀的目標(biāo)，因此軟件研發(fā)目標(biāo)、宏觀統(tǒng)計報表、決策支持功能，我們應(yīng)該怎樣做需求分析,應(yīng)當(dāng)與高層**談。
(2)中層**關(guān)心的是具體的效益，即軟件給各個部門信息化管理方面帶來的效益，因此，中層**是各項業(yè)務(wù)流程、功能模塊的需求決策者。

他們關(guān)心功能的定義、業(yè)務(wù)流轉(zhuǎn)的銜接、查詢報表的設(shè)計，但不太關(guān)心一些具體的操作，以及一些具體業(yè)務(wù)流程的細(xì)節(jié)。
(3)基層人員是每一項業(yè)務(wù)流程的操作者，也是軟件今后真正的使用者。他們是真正了解你所要開發(fā)的軟件的業(yè)務(wù)需求的領(lǐng)域?qū)＜?，是你進(jìn)行需求調(diào)研的重點對象。

但是，基層人員往往受到自身視野的局限，可能只清楚自己工作涉及的十分狹小的一個范圍，因此我們需要努力尋找那些業(yè)務(wù)涉及面廣，經(jīng)驗豐富，又有一定大局觀的真正的專家。另外 ，他們就是軟件今后真正的使用者，讓他們參加，會讓他們成為今后軟件推行的忠實支持者，對其他操作人員的指導(dǎo)者，益處多多。而他們關(guān)心的則是每項操作的細(xì)節(jié)。

俗話說：萬事開頭難。如果你在項目開始的時候總感覺千頭萬緒不知如何著手，在這里我給大家的三點建議：
1）樹立良好的職業(yè)威信;
2）進(jìn)行詳細(xì)角色分析，將與會各方代表對號入座;
3）從宏觀上制訂目標(biāo)與方案。隨后的工作，就是與各方代碼建立聯(lián)系，逐一拜訪他們，將需求調(diào)研工作一步一步進(jìn)行下去。
2.拜訪。

需求調(diào)研不是一蹴而就的事情，是一件持續(xù)數(shù)月甚至數(shù)年的工作（假如項目還有后期維護(hù)） 。在這漫長的時間里，我們需要依靠客戶這個群體的幫助，一步一步掌握真實可靠的業(yè)務(wù)需求 。不僅如此，技術(shù)這東西總有不如意甚至實現(xiàn)不了的地方，我們需要客戶的理解與包容，這都需要有良好的客戶關(guān)系。盡管如此，我們也不能總是期望客戶中的所有人都能與我們合作，很多項目都不可避免地存在阻礙項目開展的人。

3.研討會。
(1)由于業(yè)務(wù)人員自身的局限 ，不可能對所有業(yè)務(wù)領(lǐng)域的細(xì)節(jié)全面掌握，往往總是有自己熟悉的部分，也有自己不熟悉的部
分。劃分業(yè)務(wù)組，可以讓業(yè)務(wù)人員分別在自己最熟悉的業(yè)務(wù)范圍內(nèi)參與討論，可以有效提高業(yè)務(wù)討論的質(zhì)量;
(2)集中式的業(yè)務(wù)研討形式和分散式的業(yè)務(wù)研討形式;
(3)有效抑制個性化差異、分模塊組織專項研討會。
4.業(yè)務(wù)研討
在需求分析過程中，客戶存在的**問題就是提不出正確的需求，這表現(xiàn)為幾種形式：
(1)由于對軟件不了解，客戶提不出需求，不知道軟件最終會做成什么樣子。

這類客戶在需求討論過程中，往往只能描述目前自己手工管理的方式是怎樣的，不知道計算機(jī)會怎樣管理。
(2)能提出一些業(yè)務(wù)需求，但當(dāng)軟件做出來擺在自己面前時，需求就變了。這類客戶，他們能熟練使用電腦，對信息化管理是清楚的。

他們提出的業(yè)務(wù)需求從整體上應(yīng)當(dāng)是八九不離十的 。但是，由于沒有實物，在軟件中的一些具體操作并沒有完全想清楚。
(3)能非常詳細(xì)地提出業(yè)務(wù)需求，甚至有時候該怎么做的提出來了。

這類客戶，參與過很多軟件信息化建設(shè)，甚至有些還是軟件開發(fā)的半專業(yè)人士。但是他們提出的業(yè)務(wù)需求過于具體 ，甚至怎樣實現(xiàn)都說出來了，但這些有時候不是**設(shè)計方案、可能在技術(shù)上難于實現(xiàn)，甚至有些就是過于理想化而不可實現(xiàn)。
解決辦法:
業(yè)務(wù)領(lǐng)域分析:客戶現(xiàn)有的業(yè)務(wù)流程是什么樣的，都有些什么操作？客戶在業(yè)務(wù)中都有些什么事物，什么專用名詞，都是怎樣定義的，相互之間的關(guān)系是什么？客戶在每一項操作中的目的是什么，為什么要這樣做，他們制作的手工報表都說明了什么問
題？
(1)我們做需求分析，眼界不能僅僅停留在軟件本身，應(yīng)當(dāng)更開闊一些，應(yīng)當(dāng)擴(kuò)展到跟這個業(yè)務(wù)有關(guān)的那些領(lǐng)域知識中。
(2)在客戶提出的所有原始需求中那些與業(yè)務(wù)實現(xiàn)有關(guān)的需求都是無效的需求，它們僅僅只能作為我們的一個參考。

(3)還有一些是技術(shù)難于實現(xiàn)或者根本就無法實現(xiàn)的需求，我們應(yīng)當(dāng)耐心地說服和引導(dǎo)客戶，并給他提出一個更加合理的方案。
(4)需求分析不是一種簡單的你說我記的收集活動，而是在大量業(yè)務(wù)分析與技術(shù)可行性分析基礎(chǔ)上的分析活動。只有建立在這種分析基礎(chǔ)上的軟件研發(fā)，才能保證需求的正確與變更的可控。

5.迭代
在**次的需求分析階段，我們在一段時期內(nèi)需要與客戶進(jìn)行反復(fù)地討論，這個過程往往是這樣一個反復(fù)循環(huán)的過程：需求捕獲->需求整理->需求驗證->再需求捕獲······
(1)需求捕獲:就是我們與客戶在一起開研討會，討論需求的活動,客戶可能會描述他們的業(yè)務(wù)流程，這時我們在紙上繪制簡單的流程草圖，及時地記錄下來;客戶在描述業(yè)務(wù)的同時，可能會反復(fù)提到一些業(yè)務(wù)名詞，詳細(xì)詢問這些名詞的含義，以及它們與其它名詞的關(guān)系，用類圖或者對象圖繪制簡單的草圖;客戶在描述業(yè)務(wù)的同時，還會提出今后的軟件希望實現(xiàn)的功能，如能夠展示某個報表、能夠?qū)С鑫募?，以需求列表的形式記錄下來。一個功能，在需求列表中會有多個需求，而每個需求應(yīng)當(dāng)能夠用 1、2 句話，在 20 個字以內(nèi)就可以描述清楚 。需求列表是客戶提出的最最原始的需求，他不摻雜任何分析設(shè)計，是我們的每項功能必須實現(xiàn)的內(nèi)容。
(2)需求整理:就是在需求研討會后，需求分析人員對研討內(nèi)容的分析和整理的過程。

首先，需求分析人員應(yīng)當(dāng)通過用例模型，劃分整個系統(tǒng)的功能模塊，以及各個模塊的業(yè)務(wù)流程。用例模型分析是一個由粗到細(xì)的過程，這樣一個過程也是符合人類認(rèn)識世界的思維習(xí)慣的一個過程。**，我們應(yīng)當(dāng)對整個系統(tǒng)繪制用例圖，設(shè)計用例場景，并依次對這些用例進(jìn)行用例描述、流程分析、角色分析等分析過程。

當(dāng)然，在整體用例分析的同時，我們還應(yīng)當(dāng)進(jìn)行一個整體的角色分析，繪制一個角色分析圖，進(jìn)行一個流程分析，繪制一個流程分析圖（可以是傳統(tǒng)的流程圖、UML 中的行動圖，甚至一個簡單的示意圖，等等）,再在整體用例圖的基礎(chǔ)上，依次對每個用例繪制用例圖。每個用例圖中，會更細(xì)致地劃分出多個用例，并依次進(jìn)行用例描述、流程分析、角色分析等分析工作。如此這般地不斷細(xì)化，直到我們認(rèn)為需求已經(jīng)描述清楚為止。
(3)領(lǐng)域模型 :是對用戶業(yè)務(wù)領(lǐng)域中相關(guān)事物、相互關(guān)系、相互行為操作的描述，它是以對象圖和類?。

需求分析方法有哪些?

問題一：需求分析有哪些方法 三種需求分析的方法：結(jié)構(gòu)化分析方法、面向?qū)ο蟮姆治龇椒?、面向問題域的分析方法。 結(jié)構(gòu)化的分析方法是傳統(tǒng)的分析法，它的好處是在需求階段可以不需要**地定義系統(tǒng)，只需要根據(jù)業(yè)務(wù)框架確定系統(tǒng)的功能范圍，以及每個功能的處理邏輯和業(yè)務(wù)規(guī)則，功能需求規(guī)格書等。

因為不需要**描述，因此描述系統(tǒng)的方式比較靈活多樣，可以采用圖表、示例圖、文字等等方式來描述系統(tǒng)。

在系統(tǒng)開發(fā)以前，一般還可以采用更為直觀的原型系統(tǒng)方式和最終用戶進(jìn)行交流和確認(rèn)，因此對業(yè)務(wù)需求的要求會低一些，業(yè)務(wù)需求階段的周期相對容易控制;通過業(yè)務(wù)全景圖，最終用戶也能了解系統(tǒng)的功能;通過功能活動圖和業(yè)務(wù)規(guī)則的描述，也可以相對**地描述業(yè)務(wù)系統(tǒng);因為沒有嚴(yán)格的標(biāo)記語言，可以采用適當(dāng)?shù)钠枋鲞m當(dāng)?shù)南到y(tǒng)。當(dāng)然，這種方法的缺點也是明顯的，分析人員和業(yè)務(wù)人員之間可能缺乏共同語言，機(jī)器不能識別業(yè)務(wù)需求書，在設(shè)計階段還需要繼續(xù)和用戶確認(rèn)一部分功能。 面向?qū)ο蟮姆治龇椒ǖ?*好處是在需求階段，就能夠非常**地描述一個系統(tǒng)，采用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發(fā)現(xiàn)很多問題，避免在開發(fā)的過程中出現(xiàn)需求的反復(fù)，而且在系統(tǒng)設(shè)計和開發(fā)階段不需要最終用戶參與。在實施上，一般可以采用場景、業(yè)務(wù)功能等方式來描述，比較適合于業(yè)務(wù)流程環(huán)節(jié)多的系統(tǒng)，或者軟件產(chǎn)品的開發(fā)。

但是，我們也要看到，在現(xiàn)實中，絕大多數(shù)的應(yīng)用系統(tǒng)都很難在需求階段就可以被**地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業(yè)務(wù)系統(tǒng)應(yīng)該是什么樣，或者采用一種抽象的方式能夠確定最終的應(yīng)用系統(tǒng);其次，因為最終用戶不需要參與設(shè)計和開發(fā)階段的工作，所以雙方確定業(yè)務(wù)需求的過程也會比較長;同時，因為是**描述，因此描述系統(tǒng)的語言是非常邏輯化的，一般通過某種方式可以使機(jī)器識別業(yè)務(wù)需求，采用這種方式寫的業(yè)務(wù)需求是非常格式化的，一方面描述一個系統(tǒng)需要的信息非常多，可能使需求說明的篇幅非常長，不便于理解和閱讀;另外由于通過抽象的方式來推演最終系統(tǒng)的運(yùn)行方式，對業(yè)務(wù)人骸的要求非常高。 問題二：項目需求分析的分析方法 需求分析的方法有很多.這里只強(qiáng)調(diào)原型化方法,其它的方法如:結(jié)構(gòu)化方法,動態(tài)分析法等(個人認(rèn)為,對初學(xué)者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.原型化方法是十分重要的(是軟考等?？嫉闹R點).原型就是軟件的一個早期可運(yùn)行的版本,它實現(xiàn)了目標(biāo)系統(tǒng)的某些或全部功能.原型化方法就是盡可能快地建造一個粗糙的系統(tǒng),這系統(tǒng)實現(xiàn)了目標(biāo)系統(tǒng)的某些或全部功能,但是這個系統(tǒng)可能在可靠性,界面的友好性或其他方面上存在缺陷.建造這樣一個系統(tǒng)的目的是為了考察某一方面的可行性,如算法的可行性,技術(shù)的可行性,或考察是否滿足用戶的需求等.如,為了考察是否滿足用戶的要求,可以用某些軟件工具快速的建造一個原型系統(tǒng),這個系統(tǒng)只是一個界面,然后聽取用戶的意見,改進(jìn)這個原型.以后的目標(biāo)系統(tǒng)就在原型系統(tǒng)的基礎(chǔ)上開發(fā).原型主要有三種類型(軟考考過):探索型,實驗型,進(jìn)化型.探索型:目的是要弄清楚對目標(biāo)系統(tǒng)的要求,確定所希望的特性,并探討多種方案的可行性.實驗型:用于大規(guī)模開發(fā)和實現(xiàn)前,考核方案是否合適,規(guī)格說明是否可靠.進(jìn)化型:目的不在于改進(jìn)規(guī)格說明,而是將系統(tǒng)建造得易于變化,在改進(jìn)原型的過程中,逐步將原型進(jìn)化成最終系統(tǒng)。在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質(zhì)量要求不高的模型系統(tǒng)，針對這個系統(tǒng)反復(fù)進(jìn)行修改,形成比較好的思想,據(jù)此設(shè)計出較完整,準(zhǔn)確,一致,可靠的最終系統(tǒng).系統(tǒng)構(gòu)造完成后,原來的模型系統(tǒng)就被廢棄不用.探索型和實驗型屬于這種策略。

追加策略:先構(gòu)造一個功能簡單而且質(zhì)量要求不高的模型系統(tǒng)，作為最終系統(tǒng)的核心,然后通過不斷地擴(kuò)充修改,逐步追加新要求，發(fā)展成為最終系統(tǒng)。進(jìn)化型屬于這種策略. 問題三：如何做好需求分析，需求調(diào)研 轉(zhuǎn)載以下資料供參考 從廣義上理解：需求分析包括需求的獲取、分析、規(guī)格說明、變更、驗證、管理的一系列需求工程。 狹義上理解需求分析指需求的分析、定義過程。

原因 需求分析就是分析軟件用戶的需求是什么。如果投入大量的人力，物力、財力、時間，開發(fā)出的軟件卻沒人要，那所有的投入都是徒勞。如果費(fèi)了很大的精力，開發(fā)一個軟件，**卻不滿足用戶的要求，從而要重新開發(fā)過，這種返工是讓人痛心疾首的(相信大家都有體會)。

比如：用戶需要一個for linux的軟件，而你在軟件開發(fā)前期忽略了軟件的運(yùn)行環(huán)境，忘了向用戶詢問這個問題，而想當(dāng)然的認(rèn)為是開發(fā)for windows的軟件。當(dāng)你千辛萬苦地開發(fā)完成向用戶提交時才發(fā)現(xiàn)出了問題，那時候你是欲哭無淚了，恨不得找塊豆腐一頭撞*。 需求分析之所以重要，就因為他具有決策性、方向性、策略性的作用，他在軟件開發(fā)的過程中具有舉足輕重的地位，大家一定要對需求分析具有足夠的重視。在一個大型軟件系統(tǒng)的開發(fā)中，他的作用要遠(yuǎn)遠(yuǎn)大于程序設(shè)計。

任務(wù) 簡言之，需求分析的任務(wù)就是解決“做什么的問題，就是要全面地理解用戶的各項要求，并準(zhǔn)確地表達(dá)所接受的用戶需求。 過程 需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規(guī)格說明、評審。 問題識別：就是從系統(tǒng)角度來理解軟件，確定對所開發(fā)系統(tǒng)的綜合要求，并提出這些需求的實現(xiàn)條件，以及需求應(yīng)該達(dá)到的標(biāo)準(zhǔn)。這些需求包括：功能需求(做什么)、性能需求(要達(dá)到什么指標(biāo))、環(huán)境需求(如機(jī)型、操作系統(tǒng)等)、可靠性需求(不發(fā)生故障的概率）、安全保密需求、用戶界面需求、資源使用需求(軟件運(yùn)行是所需的內(nèi)存、CPU等)、軟件成本消耗與開發(fā)進(jìn)度需求、預(yù)先估計以后系統(tǒng)可能達(dá)到的目標(biāo)。

分析與綜合： 逐步細(xì)化所有的軟件功能，找出系統(tǒng)各元素間的聯(lián)系，接口特性和設(shè)計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。**綜合成系統(tǒng)的解決方案，給出要開發(fā)的系統(tǒng)的詳細(xì)邏輯模型(做什么的模型)。 制訂規(guī)格說明書： 即編制文檔，描述需求的文檔稱為軟件需求規(guī)格說明書。請注意，需求分析階段的成果是需求規(guī)格說明書，向下一階段提交。

評審： 對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審?fù)ㄟ^才可進(jìn)行下一階段的工作,否則重新進(jìn)行需求分析。 方法 需求分析的方法有很多，這里只強(qiáng)調(diào)原型化方法，其它的方法如：結(jié)構(gòu)化方法、動態(tài)分析法等，從來沒用過這些方法在此不討論。

原型化方法是十分重要的，原型就是軟件的一個早期可運(yùn)行的版本，它實現(xiàn)了目標(biāo)系統(tǒng)的某些或全部功能。 原型化方法就是盡可能快地建造一個粗糙的系統(tǒng)，這系統(tǒng)實現(xiàn)了目標(biāo)系統(tǒng)的某些或全部功能。但是這個系統(tǒng)可能在可靠性、界面的友好性或其他方面上存在缺陷。

建造這樣一個系統(tǒng)的目的是為了考察某一方面的可行性，如算法的可行性、技術(shù)的可行性或考察是否滿足用戶的需求等。如：為了考察是否滿足用戶的要求，可以用某些軟件工具快速的建造一個原型系統(tǒng)，這個系統(tǒng)只是一個界面，然后聽取用戶的意見，改進(jìn)這個原型。以后的目標(biāo)系統(tǒng)就在原型系統(tǒng)的基礎(chǔ)上開發(fā)。 原型主要有三種類型：探索型、實驗型、進(jìn)化型。

探索型：目的是要弄清楚對目標(biāo)系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性。 實驗型：用于大規(guī)模開發(fā)和實現(xiàn)前，考核方案是否合適，規(guī)格說明是否可靠。 進(jìn)化型：目的不在于改進(jìn)規(guī)格說明，而是將系統(tǒng)建造得易于變化，在改進(jìn)原型的過程中，逐步將原型進(jìn)化成最終系統(tǒng)。

在使用原型化方法時有兩種不同的策略：廢棄策略、追加策略。 廢棄策略：先建造一個功能簡單而且質(zhì)量要求不高的模型系統(tǒng)，針對這個系統(tǒng)反復(fù)進(jìn)行修改,形成……>> 問題四：請問常用的需求分析方法有哪些？ 結(jié)構(gòu)分析方法和面向?qū)ο蠓治龇?問題五：培訓(xùn)需求分析的方法有哪幾種 組織資源分析 如果沒有確定可被利用的人力、物力和財力資源，就難以確立培訓(xùn)目標(biāo)。組織資源分析包括對組織的金錢、時間、人力等資源的描述。一般情況下，通過對下面問題的分析，就可了解一個組織資源的大致情況。

組織特質(zhì)與環(huán)境分析 組織特質(zhì)與環(huán)境對培訓(xùn)的成功與否也起重要的影響作用。因為，當(dāng)培訓(xùn)規(guī)劃和組織的價值不一致時，培訓(xùn)的效果則很難保證。組織特質(zhì)與環(huán)境分析主要是對組織的系統(tǒng)結(jié)構(gòu)、文化、資訊傳播情況的了解。

主要包括如下內(nèi)容： 系統(tǒng)特質(zhì)指組織的輸入、運(yùn)作、輸出、次級系統(tǒng)互動以及與外界環(huán)境間的交流特質(zhì)，使管理者能夠系統(tǒng)地面對組織，避免組織分析中以偏概全的缺失。 文化特質(zhì)。指組織的軟硬體設(shè)施、規(guī)章、制度、組織經(jīng)營運(yùn)作的方式、組織成員待人處事的特殊風(fēng)格，使管理者能夠深入了解組織，而非僅僅停留在表面。 資訊傳播特。

如何做需求分析？

你這個問題問的有點太大了，不知道怎么回答，需求的工作存在很多靈活性，很難整理出一個流程性的東西，我也是正在學(xué)習(xí)，最近在學(xué)習(xí)徐峰老師的《軟件需求實踐》，把我知道的拿出來分享，錯了的話請大家糾正，但是不要噴我??！妹子心里素質(zhì)不行，嘿嘿1、需求是有層次的，分為業(yè)務(wù)需求、用戶需求以及系統(tǒng)需求，所以在進(jìn)百科行需求分析時肯定是要根據(jù)不同層次階段進(jìn)行不同方式、內(nèi)容以及側(cè)重點的需求調(diào)研。1）業(yè)務(wù)需求，一般是公司的高層提出的，就是我們這個系統(tǒng)的指導(dǎo)需求，這個需求比較空，但是卻是整個系統(tǒng)需求的指導(dǎo)思想，在做需求時經(jīng)常想想這個知道思想，可以防止需求跑偏。

2）用戶需求，一般是公司的中層和操作層提出的需求。

中層突出流程，就是整個框架，而操作層提出具體的細(xì)節(jié)性需求。就是往中層的框架里面添加需求細(xì)節(jié)。
3）系統(tǒng)需求，就是針對前兩種需求調(diào)研之后得結(jié)果進(jìn)行需求分析和業(yè)務(wù)建模之后，得到了系統(tǒng)開發(fā)的需求。
2、需求的步驟分為：需求定義（對應(yīng)上面的業(yè)務(wù)需求）、需求捕獲（對應(yīng)上面的用戶需求）、需求分析與需求建模（對應(yīng)上面的系統(tǒng)需求）、需求驗證、需求跟蹤、需求管理。

3、做需求工程中可以使用的工具：AXURE（用來制作原型，讓用戶更直觀的了解即將做成什么狀態(tài)的系統(tǒng)，便于需求確認(rèn)）、EA（是建模工具，用來繪制UML圖，“一圖抵千言”為了更好的表達(dá)需求和溝通需求）、word、Excel、Visio等工具。