增員需求分析

㈠ 如何做需求分析

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

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

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

按照筆者的經驗，網站項目管理可以分為以下l六個階段進行控制：
1. 需求分析及變更管理
2. 項目模型及業務流程分析
3. 系統分析及軟體建模
4. 界面設計、交互設計及程序開發
5. 系統測試和文檔編寫
6. 客戶培訓、技術支持和售後服務

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

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

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

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

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

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

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

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

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

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

筆者曾負責一個大型新聞網站的設計，當客戶拿著將近五十頁厚的一本設計要求報告時，我發現有四十頁的內容對程序開發來說都是重復的，而在其中一頁的角落卻畫了個「搜索其他網站相關新聞」的按鈕，並且沒有做任何說明，僅僅這10個字所完成的工作量完全頂的上其他整整四十頁重復贅述所做的工作，客戶完全不知道這個要求引發的問題實際就是一個搜索引擎的開發，通過協商，客人同意了修改成站內搜索的引擎。

三：利用自然的語言描述項目模型

在業務員與客戶進行溝通和調查時撰寫的需求分析，盡可能用自然的語言進行描述，雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項目開發的各個成員都能清楚地理解需求含義，不至於在理解上產生偏差。對客戶而言，這樣的模型描述最接近真實，容易參與修訂，並能以此為測試和驗收的依據。

請比較以下兩份關於需求的描述，
「用戶在訪問首頁的時候可以在點擊『客戶通道』按鈕，彈出填寫『用戶名』和『密碼』的窗口，輸入正確後在新窗口打開客戶通道的首頁，在該頁顯示所有可操作的功能的導航條和最新的導讀新聞鏈接列表 。」

「站點分為公開和加密兩種狀態，通過身份驗證機制使特有的用戶可以訪問到加密信息，並提供不同於普通用戶的功能。」

前段描述我們就很容易想像的出來設計完成的網站是什麼樣子，而後一段的描述可能會做出無數不同的版本，造成對需求理解的歧意。

四：利用示意圖和圖表將用戶的需求表現出來

需求分析無論文字上怎麼樣表述都還是抽象的，對客戶而言理解畢竟是困難的，將基本確定的需求製作出示意圖是最直觀有效的。

製作示意圖可以有很多種方式，用PowerPoint或Visio製作流程示意，用Html文檔製作界面示意都是可行的，最簡單利用畫圖和Word表格方式也完全可以，關鍵是利用示意圖將客戶的需求和即將開始設計的系統體現起來，在進行系統分析和程序開發之前，雙方對今後要完成的產品就能夠有直觀的認識，換言之，就是在產品還沒有真正進入開發階段的時候，雙方就對工作的結果達成統一的意見，這將大大地減輕需求變更所帶來的困擾，同時客戶更容易地參與到項目的開發過程，保證項目往正確的方向進行。

在RUP中有這樣的描述：

利用電影、卡通、圖片、表格和動畫片等製作示意圖開始，告訴我們用戶是誰，要發生什麼事情，如何發生。

以用戶友好的方式幫助收集並改進用戶需求。

鼓勵更有創造性、更加創新的設計解決方案。

鼓勵團隊復審，並避免所有人都不希望出現的特徵。

確保以可理解、直觀的方式實施特徵。

使訪談過程變得輕松，避免出現訪談沒有結果的現象。

簡單地說，製作示意圖就是使用工具向用戶 (主角) 說明（有時是動畫演示）系統如何適應組織的需要，並表明系統將如何運轉。協調員將初始示意板展示給小組，小組成員提供意見。之後，在舉辦研討班期間，示意板也進行「實時」演進。所以，您需要一種可以輕松更改示意板的畫圖工具。為了避免分散注意力，一般最好使用簡單的工具，比如圖表、白板或PowerPoint。

五：什麼人要看需求分析報告

項目經理、系統分析員、開發經理、交互設計師、測試人員、文檔人員包括客戶代表都應該看需求分析，並進行共同的討論，達成一致的意見。

我們經常會遇到業務人員辛辛苦苦談下來的項目，對開發人員來說卻是難以實現的，而技術人員設計的產品卻常常得不到客戶的認可，甚至發生糾紛，因此參與項目開發的人員都應該對這份需求有統一清晰的認識，並根據自己的工作對需求提出意見，通過與客戶的溝通修訂，最終確定項目實現的目標。

例如：

項目經理通過需求分析才能組建所需要的團隊包括配置工作環境，制定開發周期。
開發周期的限制和功能上的要求可能會影響到程序員採用什麼樣的語言和工具進行編寫；
操作用戶的技能水平將影響到交互設計師進行前台設計時做到什麼樣的精度；
界面設計人員根據項目的性質和定位確定表現方式。
測試人員了解測試環境和條件後才能對項目質量進行跟蹤和檢測；

通過下表，我們可以看的出不同角色根據需求的變更所進行的工作流程：

六：建立需求變更日誌，製作新版本的需求分析報告

盡管我們費了許多功夫在需求分析進行了最大可能的努力，但幾乎可以肯定的是，這份需求分析在開發過程中一定會發生變化，也許是出自客戶的遺漏，也可能是在開發過程中被激發出來的，這種變更有時是如此的頻繁和瑣碎，以至於往往不能將變更及時反饋到項目的各個角色中，那麼做好需求變更日誌就顯得非常重要。

在需求分析後面附上變更日誌，並將修改後的需求分析製作成新版本，保留每次更改過的版本，而不是覆蓋，這樣就比較容易地跟蹤到需求變更過程中所帶來的工作調整。

在新版本的需求分析中，將變更多部分用特殊方式表明出來，並在日誌中記錄變更多重的明細。

關於需求分析和變更管理可以參照下圖示意：

七：本階段重點工作角色

在需求分析和變更管理的過程中，工作量最大的角色為客戶代表、業務員和項目經理。

客戶代表提出需求，業務員幫助整理和分析，項目經理對整個項目進行評估。

在實際工作中，很多項目失敗的起因都和需求分析有關。 客戶代表和業務員通常並非從事技術開發的專業人員，在討論需求的時候往往對項目的技術難度、工作量、時間進度把握不準確，這時候需要項目經理或技術人員進行參謀。

為了降低項目的風險，提高工作效率，有必要設計規范的需求管理計劃書，幫助客戶代表和業務員更好的完成任務。

以下提供一份需求管理計劃的模板可作為參考：

八：總結

根據筆者的經驗，要盡快做好需求分析掌握以下要點，也許能事半功倍：

仔細聆聽，羅列客戶的所有要求；
將需求進行分析，確認可操作的系統模型；
利用最自然的語言將系統進行描述，使每個開發人員不會產生歧意；
迅速確定網站的用戶角色；
比如訪客、會員、重要客戶、前台管理員、網站管理員、業務員等；
分析確定每個角色的許可權及可操作的功能；
比如會員可以查看特別信息、修改個人信息、退出登陸等；
前台管理員能夠登錄管理系統，能夠發布編輯修改信息，能夠審查會員資格等；
網站管理員可以更改欄目、修改網站界面等；
製作流程圖和示意圖將需求表現出來；
讓客戶參與到示意圖的設計中，及時正確的反應出需求變更。
製作需求變更日誌，保留升級版本，通過版本控制進行需求管理；
通過需求《管理計劃書》使每個參與人員看到共同的努力目標。

㈡ 如何進行用戶需求分析

1.概念
需求的定義包括從用戶角度(系統的外部行為),以及從開發者角度(一些內部特性)來闡述需求.
關鍵的問題是一定要編寫需求文檔.我曾經目睹過一個項目中途更換了所有的開發者,客戶被迫與新的需求分析者坐到一起.系統的分析人員說:"我們想與你談談你的需求."客戶的第一反應便是:"我已經將我的要求都告訴你們前任了,現在我要的就是給我編一個系統".
百事通
而實際上,UGGs,需求並未編寫成文檔,因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話,你就確信你已明白用戶的需求,那完全是自欺欺人.
需求的另外一種定義認為需求是"用戶所需要的並能觸發一個程序或系統開發工作的說明".有些需求分析專家拓展了這個概念:"從系統外部能發現系統所具有的滿足於用戶的特點、功能及屬性等".這些定義強調的是產品是什麼樣的,而並非產品是怎樣設計、構造的.而下面的定義則從用戶需要進一步轉移到了系統特性:
需求是指明必須實現什麼的規格說明.它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束.
從上面這些不同形式的定義不難發現:並沒有一個清晰、毫無二義性的"需求"術語存在,真正的"需求"實際上在人們的腦海中,這個人們主要是指客戶,但一般情況下,用戶並不能描述自己的需要,只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對.系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識.
任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型,一種描述.
2.需求分析的任務
開發軟體系統最為困難的部分就是准確說明開發什麼.最為困難的概念性工作便是編寫出詳細技術需求,這包括所有面向用戶、面向機器和其它軟體系統的介面.同時這也是一旦做錯,將最終會給系統帶來極大損害的部分,並且以後再對它進行修改也極為困難.
目前,國內產品的龐雜,一家企業可能有幾個系統並立運行,它們之間介面是系統開發人員最頭痛的問題.
對於商業最終用戶應用程序,企業信息系統和軟體作為一個大系統的一部分的產品是顯而易見的.但是對於我們開發人員來說,並沒有編寫出客戶認可的需求文檔,我們如何知道項目於何時結束?而如果我們不知道什麼對客戶來說是重要的,那我們又如何能使客戶感到滿意呢?
然而,即便並非出於商業目的的軟體需求也是必須的.例如庫、組件和工具這些供開發小組內部使用的軟體.當然你可能偶爾勿需文檔說明就能與其他人意見較為一致,但更常見的是出現重復返工這種不可避免的後果,而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價,這些血的教訓正在國內的軟體開發者身上發生.
近來,我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟體.不幸的是,當他們開發完這個工具後,發現這個工具不能列印出源代碼文件,使用者當然希望有這個功能.結果這個小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤並構思准確,如果我們沒有編寫文檔,軟體達不到期望目標也只能是咎由自取了.
相反的情況,我曾見一個要集成到"錯誤跟蹤系統"中的簡單界面寫了一頁需求說明.而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用.他們依據需求對系統進行測試時,此系統不僅非常清晰地實現了所有必需功能,而且未發現任何錯誤.
事實上,需求文檔在開發過程中一直起指導作用.
3.需求分析過程
可把整個軟體需求工程研究領域劃分為需求開發和需求管理兩部分更合適,如圖4-1所示:
圖4-1 需求工程域的層次分解示意圖
需求開發可進一步分為:問題獲取、分析、編寫規格說明和驗證四個階段.這些子項包括軟體類產品中需求收集、評價、編寫文檔等所有活動.需求開發活動包括以下幾個方面:
確定產品所期望的用戶類別.
獲取每個用戶類的需求.
了解實際用戶任務和目標以及這些任務所支持的業務需求.
分析源於用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息.
將系統級的需求分為幾個子系統,並將需求中的一部份分配給軟體組件.
了解相關質量屬性的重要性.
商討實施優先順序的劃分.
將所收集的用戶需求編寫成文檔和模型.
評審需求規格說明,確保對用戶需求達到共同的理解與認識,並在整個開發小組接受說明之前將問題都弄清楚.
需求管理需要"建立並維護在軟體工程中同客戶達成的合同" .這種合同都包含在編寫的需求文檔與模型中.客戶的接受僅是需求成功的一半,開發人員也必須能夠接受他們,並真正把需求應用到產品中.通常的需求管理活動包括:
定義需求基線(迅速制定需求文檔的主體).
評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它.
以一種可控制的方式將需求變更融入到項目中.
使當前的項目計劃與需求一致.
估計變更需求所產生影響並在此基礎上協商新的承諾,這種承諾具體體現在項目解決方案上.
讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤.
在整個項目過程中跟蹤需求狀態及其變更情況.
以上幾點說明是我總結了成功實施項目後系統分析人員的經驗,同時也根據國內外的其他系統實施的相關成功經驗,進行了總結.
4.需求的類型
下面這些定義是需求工程領域中常見術語的定義.
軟體需求包括三個不同的層次:業務需求、用戶需求和功能需求(也包括非功能需求).
1.業務需求(business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求,它們在項目視圖與范圍文檔中予以說明.
2.用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務,這在使用實例(use case)文檔或方案腳本說明中予以說明.
3.功能需求(functional requirement)定義了開發人員必須實現的軟體功能,使得用戶能完成他們的任務,從而滿足了業務需求.
在軟體需求規格說明書 (SRS)中說明的功能需求充分描述了軟體系統所應具有的外部行為.軟體需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用.對一個大型系統來說,軟體功能需求也許只是系統需求的一個子集,因為另外一些可能屬於子系統(或軟體部件).
作為功能需求的補充,軟體需求規格說明還應包括非功能需求,它描述了系統展現給用戶的行為和執行的操作等.它包括產品必須遵從的標准、規范和合約;外部界面的具體細節;性能要求;設計或實現的約束條件及質量屬性.所謂約束是指對開發人員在軟體產品設計和構造上的限制.質量屬性是通過多種角度對產品的特點進行描述,從而反映產品功能.多角度描述產品對用戶和開發人員都極為重要.
下面以一個字處理程序為例來說明需求的不同種類.業務需求可能是:"用戶能有效地糾正文檔中的拼寫錯誤",該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器.而對應的用戶需求可能是"找出文檔中的拼寫錯誤並通過一個提供的替換項列表來供選擇替換拼錯的詞".同時,該拼寫檢查器還有許多功能需求,如找到並高亮度提示錯詞的操作;顯示提供替換詞的對話框以及實現整個文檔范圍的替換.
從以上定義可以發現,需求並未包括設計細節、實現細節、項目計劃信息或測試信息.需求與這些沒有關系,它關注的是充分說明你究竟想開發什麼.項目也有其它方面的需求,如開發環境需求或發布產品及移植到支撐環境的需求.盡管這些需求對項目成功也至關重要,但它們並非本書所要討論的.
5.需求分析的原則
不重視需求過程的項目隊伍將自食其果.需求工程中的缺陷將給項目成功帶來極大風險,這里的"成功"是指推出的產品能以合理的價格、及時地在功能、質量上完全滿足用戶的期望.下面將討論一些需求風險.
不適當的需求過程所引起的一些風險:
1. 無足夠用戶參與
客戶經常不明白為什麼收集需求和確保需求質量需花費那麼多功夫,開發人員可能也不重視用戶的參與.究其原因:一是因為開發人員感覺與用戶合作不如編寫代碼有意思;二是因為開發人員覺得已經明白用戶的需求了.在某些情況下,與實際使用產品的用戶直接接觸很困難,而客戶也不太明白自己的真正需求.但還是應讓具有代表性的用戶在項目早期直接參與到開發隊伍中,並一同經歷整個開發過程.
系統人員在實踐過程中,也有些感覺,在實施一家公司的項目時,若無足夠的用戶參與,系統人員獲得的需求是片面的,不完整的,這樣系統在需求之初就埋下風險.
2. 用戶需求的不斷增加
在開發中若不斷地補充需求,項目就越變越龐大以致超過其計劃及預算范圍.計劃並不總是與項目需求規模與復雜性、風險、開發生產率及需求變更實際情況相一致,這使得問題更難解決.實際上,問題根源在於用戶需求的改變和開發者對新需求所作的修改.
要想把需求變更范圍控制到最小,必須一開始就對項目視圖、范圍、目標、約束限制和成功標准給予明確說明,並將此說明作為評價需求變更和新特性的參照框架.說明中包括了對每種變更進行變更影響因素分析的變更控制過程,有助於所有風險承擔者明白業務決策的合理性,即為何進行某些變更,相應消耗的時間、資源或特性上的折中.
產品開發中不斷延續的變更會使其整體結構日漸紊亂,補丁代碼也使得整個程序難以理解和維護.插入補丁代碼使模塊違背強內聚、松耦合的設計原則,特別是如果項目配置管理工作不完善的話,收回變更和刪除特性會帶來問題.如果你盡早地區別這些可能帶來變更的特性,你就能開發一個更為健壯的結構,並能更好地適應它.這樣設計階段需求變更不會直接導致補丁代碼,同時也有利於減少因變更導致質量的下降.
3. 模稜兩可的需求
模稜兩可是需求規格說明中最為可怕的問題.它的一層含義是指諸多讀者對需求說明產生了不同的理解;另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明.
模稜兩可的需求會使不同的風險承擔者產生不同的期望,它會使開發人員為錯誤問題而浪費時間,並且使測試者與開發者所期望的不一致.一位系統測試人員曾告訴我,她所在的測試組經常對需求理解有誤,以致不得不重寫許多測試用例並重做許多測試.
處理模稜兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍.僅僅簡單瀏覽一下需求文檔是不能解決模稜兩可問題的.如果不同的評審者從不同的角度對需求說明給予解釋,但每個評審人員都真正了解需求文檔,這樣二義性就不會直到項目後期才被發現,那時再發現的話會使得更正代價很大.
4. 不必要的特性
"畫蛇添足"是指開發人員力圖增加一些"用戶欣賞"但需求規格說明中並未涉及的新功能.經常發生的情況是用戶並不認為這些功能性很有用,以致在其上耗費的努力"白搭"了.開發人員應當為客戶構思方案並為他們提供一些具有創新意識的思路,具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡,開發人員應努力使功能簡單易用,而不要未經客戶同意,擅自脫離客戶要求,自作主張.
同樣,客戶有時也可能要求一些看上去很"酷",但缺乏實用價值的功能,而實現這些功能只能徒耗時間和成本.為了將"畫蛇添足"的危害盡量減小,應確信:你明白為什麼要包括這些功能,以及這些功能的"來龍去脈",這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能.
5. 過於精簡的規格說明
有時,客戶並不明白需求分析有如此重要,於是只作一份簡略之至的規格說明,僅涉及了產品概念上的內容,然後讓開發人員在項目進展中去完善,結果很可能出現的是開發人員先建立產品的結構之後再完成需求說明.這種方法可能適合於尖端研究性的產品或需求本身就十分靈活的情況.但在大多數情況下,這會給開發人員帶來挫折(使他們在不正確的假設前提和極其有限的指導下工作),也會給客戶帶來煩惱(他們無法得到他們所設想的產品).
6. 忽略了用戶分類
大多數產品是由不同的人使用其不同的特性,使用頻繁程度也有所差異,使用者受教育程度和經驗水平也不盡相同.如果你不能在項目早期就針對所有這些主要用戶進行分類的話,必然導致有的用戶對產品感到失望.例如,菜單驅動操作對高級用戶太低效了,但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難.
7. 不準確的計劃
據統計,導致需求過程中軟體成本估計極不準確的原因主要有以下五點:頻繁的需求變更、遺漏的需求、與用戶交流不夠、質量低下的需求規格說明和不完善的需求分析.
對不準確的要求所提問題的正確響應是"等我真正明白你的需求時,我就會來告訴你".基於不充分信息和未經深思的對需求不成熟的估計很容易為一些因素左右.要作出估計時,最好還是給出一個范圍.未經准備的估計通常是作為一種猜測給出的,聽者卻認為是一種承諾.因此我們要盡力給出可達到的目標並堅持完成它.
6.需求分析人員和用戶的合作關系
優秀的軟體產品是建立在優秀的需求基礎之上的.而高質量的需求來源於客戶與開發人員之間有效的交流與合作.通常,開發人員與客戶或客戶代理人,如市場人員間的關系反而會成為一種對立關系.雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產生摩擦,在這種情況下,不會給雙方帶來一點益處.
只有當雙方參與者都明白要成功自己需要什麼,同時也應知道要成功合作方需要什麼時,才能建立起一種合作關系.由於項目壓力與日漸增,所有風險承擔者有著一個共同的目標這一點容易被遺忘.其實大家都想開發出一個既能實現商業價值,又能滿足用戶需要,還能使開發者感到滿足的優秀軟體產品.
軟體客戶需求權利書列出了十條關於客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求.每一項權利都對應著軟體開發人員、分析人員的義務.而軟體客戶需求義務書也列出了十條關於客戶在需求過程中應承擔的義務.如果願意,可以將其作為開發人員的權利書.
客戶有如下權利:
1:要求分析人員使用符合客戶語言習慣的表達
需求討論應集中於業務需要和任務,故要使用業務術語,你應將其教給分析人員,而你 不一定要懂得計算機的行業術語.
2:要求分析人員了解客戶的業務及目標
通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業務任務和怎樣才能使產品更好地滿足你的需要.這將有助於開發人員設計出真正滿足你的需要並達到你期望的優秀軟體.為幫助開發人員和分析人員,可以考慮邀請他們觀察你或你的同事是怎樣工作的.如果新開發系統是用來替代已有的系統,那麼開發人員應使用一下目前的系統,這將有利於他們明白目前系統是怎樣工作的,其工作流程的情況,以及可供改進之處.
3:要求分析人員編寫軟體需求規格說明
分析人員要把從你和其他客戶那裡獲得的所有信息進行整理,以區分開業務需求及規范、功能需求、質量目標、解決方法和其它信息.通過這些分析就能得到一份軟體需求規格說明.而這份軟體需求規格說明便在開發人員和客戶之間針對要開發的產品內容達成了協議.軟體需求規格說明書可以用一種你認為易於翻閱和理解的方式組織編寫.要評審編寫出的規格說明以確保它們准確而完整地表達了你的需求.一份高質量的軟體需求規格說明能有助於開發人員開發出真正需要的產品.
4:要求得到需求工作結果的解釋說明
分析人員可能採用了多種圖表作為文字性軟體需求規格說明的補充.因為如工作流程圖那樣的圖表能很清楚地描述出系統行為的某些方面.所以需求說明中的各種圖表有著極高的價值.雖然它們不太難於理解,但是你很可能對此並不熟悉.因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發工作結果和符號的意義,及怎樣檢查圖表有無錯誤及不一致等.
5:要求開發人員尊重你的意見
如果用戶與開發人員之間不能相互理解,那關於需求的討論將會有障礙,共同合作能使大家"兼聽則明".參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為項目成功所付出的時間.同樣,客戶也應對開發人員為項目成功這一共同目標所作出的努力表示尊重與感激.
6:要求開發人員對需求及產品實施提供建議,拿出主意
通常,客戶所說的"需求"已是一種實際可能的實施解決方案,分析人員將盡力從這些解決方法中了解真正的業務及其需求,同時還應找出已有系統不適合當前業務之處,以確保產品不會無效或低效.在徹底弄清業務領域內的事情後,分析人員有時就能提出相當好的改進方法.有經驗且富有創造力的分析人員還能提出增加一些用戶並未發現的很有價值的系統特性.
7:描述產品易使用的特性
你可以要求分析人員在實現功能需求的同時還要注重軟體的易用性.因為這些易用特性或質量屬性能使你更准確、高效地完成任務.例如,客戶有時要求產品要"用戶友好"或"健壯"或"高效率",但這對於開發人員來說,太主觀了並無實用價值.正確的應是:分析人員通過詢問和調查了解客戶所要的友好、健壯、高效所包含的具體特性.
8:調整需求,允許重用已有的軟體組件
需求通常要有一定的靈活性.分析人員可能發現已有的某個軟體組件與你描述的需求很相符.在這種情況下,分析人員應提供一些修改需求的選擇以便開發人員能夠在新系統開發中重用一些已有的軟體.如果有可重用的機會出現,同時你又能調整你的需求說明,那就能降低成本和節省時間,而不必嚴格按原有的需求說明開發.所以說,如果想在產品中使用一些已有的商業常用組件,而它們並不完全適合你所需的特性,這時一定程度上的需求靈活性就顯得極為重要了.
9:獲得滿足客戶功能和質量要求的系統
每個人都希望項目獲得成功.但這不僅要求你要清晰地告知開發人員關於系統"做什麼"所需的所有信息,而且還要求開發人員能通過交流了解清楚取捨與限制.一定要明確說明你的假設和潛在的期望.否則,開發人員開發出的產品很可能無法讓你滿意.
客戶有下列義務:
1:給分析人員講解你的業務
分析人員要依靠你給他們講解的業務概念及術語.但你不能指望分析人員會成為該領域的專家,而只能讓他們真正明白你的問題和目標.不要期望分析人員能把握你們業務的細微與潛在之處,他們很可能並不知道那些對於你和你的同事來說理所當然的"常識".
2:抽出時間清楚地說明並完善需求
客戶很忙,經常在最忙的時候還得參與需求開發.但無論如何,你有義務抽出時間參與"頭腦風暴"會議的討論,接受采訪或其它獲取需求的活動.有時分析人員可能先以為明白了你的觀點,而過後發現還需要你的講解.這時,請耐心一些對待需求和需求的精化工作過程中的反復,因為它是人們交流中的很自然的現象,何況這對軟體產品的成功極為重要.
3:准確而詳細地說明需求
編寫一份清晰、准確的需求文檔是很困難的.由於處理細節問題不但煩人而且又耗時,故很容易留下模糊不清的需求.但是,在開發過程中,必須得解決這種模糊性和不準確性.而你恰是為解決這些問題作出決定的最佳人選.不然的話,你就只好靠開發人員去正確猜測了.在需求規格說明中暫時加上待定(to be determined, TBD也可採用漢語拼音略寫"DQD:待確定")的標志是個不錯的辦法.用該標志可指明了哪些需要進一步探討、分析或增加信息的地方.不過,有時也可能因為某個特殊需求難以解決或沒有人願意處理它而註上TBD標志.盡量將每項需求的內容都闡述清楚,以便分析人員能准確的將其寫進軟體需求規格說明中.如果你一時不能准確表述,那就得允許獲取必要的准確信息這樣一個過程.通常使用所謂的原型技術.通過開發的原型,你可以同開發人員一起反復修改,不斷完善需求定義.
4:及時地作出決定
正如一位建築師為你修建房屋,分析人員將要求你做出一些選擇和決定.這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息准確度中選擇折衷方案等.有權做出決定的客戶必須積極地對待這一切,盡快做處理、做決定.因為開發人員通常只有等你做出了決定才能行動,而這種等待會延誤項目的進展.
5:尊重開發人員的需求可行性及成本評估
所有的軟體功能都有其成本價格,開發人員最適合預算這些成本(盡管許多開發人員並不擅長評估預測).你所希望的某些產品特性可能在技術上行不通,或者實現它要付出極為高昂的代價.而某些需求試圖在操作環境中要求不可能達到的性能或試圖得到一些根本得不到的數據,開發人員會對此作出負面的評價意見,你應該尊重他們的意見.有時,你可以重新給出一個在技術上可行、實現上便宜的需求,例如,要求某個行為在"瞬間"發生是不可行的,但換種更具體的時間需求說法("在50ms以內",但若沒有準確的技術分析不能輕易下結論),這就可以實現了.
6: 劃分需求優先順序別
大多數項目沒有足夠的時間或資源來實現功能性的每個細節.決定哪些特性是必要的,哪些是重要的,哪些是好的,是需求開發的主要部分.只能由你來負責設定需求優先順序,因為開發者並不可能按你的觀點決定需求優先順序.開發者將為你確定優先順序提供有關每個需求的花費和風險的信息.當你設定優先順序時,你幫助開發者確保在適當的時間內用最小的開支取得最好的效果.在時間和資源限制下,關於所需特性能否完成或完成多少應該尊重開發人員的意見.盡管沒有人願意看到自己所希望的需求在項目中未被實現,但畢竟是要面對這種現實的.業務決策有時不得不依據優先順序來縮小項目范圍或延長工期,或增加資源,或在質量上尋找折衷.
7:評審需求文檔和原型
正如我們將在第1 4章討論的,無論是正式的還是非正式的方式,對需求文檔進行評審都會對軟體質量提高有所幫助.讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性.評審也給客戶代表提供一個機會,給需求分析人員帶來反饋信息以改進他們的工作.如果你認為編寫的需求文檔不夠准確,就有義務盡早告訴分析人員並為改進提供建議.通過閱讀需求規格說明,很難想像實際的軟體是什麼樣子的.更好的方法是先為產品開發一個原型.這樣你就能提供更有價值的反饋信息給開發人員,幫助他們更好地理解你的需求.必須認識到:原型並非是一個實際產品,但開發人員能將其轉變、擴充成功能齊全的系統.
8:需求出現變更要馬上聯系
不斷的需求變更會給在預定計劃內完成高質量產品帶來嚴重的負面影響.變更是不可避免的,但在開發周期中變更越在晚期出現,其影響越大.變更不僅會導致代價極高的返工,而且工期也會被迫延誤,特別是在大體結構已完成後又需要增加新特性時.所以一旦你發現需要變更需求時,請一定立即通知分析人員.
9:應遵照開發組織處理需求變更的過程
為了將變更帶來的負面影響減少到最低限度,所有的參與者必須遵照項目的變更控制過程.這要求不放棄所有提出的變更,對每項要求的變更進行分析、綜合考慮,最後作出合適的決策以確定將某些變更引入項目中.
10:尊重開發人員採用的需求工程過程
軟體開發中最具挑戰性的莫過於收集需求並確定其正確性.分析人員採用的方法有其合理性.也許你認為需求過程不太劃算,但請相信花在需求開發上的時間是"很有價值"的.如果你理解並支持分析人員為收集、編寫需求文檔和確保其質量所採用的技術,那麼整個過程將會更為順利.盡管去詢問分析人員為什麼他們要收集某些信息,或參與與需求有關的活動.
系統分析人員在開發過程中可能會遇到以下問題,一些很忙的客戶可能不願意積極參與需求過程,而缺少客戶參與將很可能導致不理想的產品.故一定要確保需求開發中的主要參與者都了解並接受他們的義務.如果遇到分歧,通過協商以達成對各自義務的相互理解,這樣能減少今後的摩擦.
7.需求文檔
需求開發的最終成果是:客戶和開發小組對將要開發的產品達成一致協議.協議綜合了業務需求、用戶需求和軟體功能需求.就像我們早先所看到的,項目視圖和范圍文檔包含了業務需求,而使用實例文檔則包含了用戶需求.你必須編寫從使用實例派生出的功能需求文檔,還要編寫產品的非功能需求文檔,包括質量屬性和外部介面需求.只有以結構化和可讀性方式編寫這些文檔,並由項目的風險承擔者評審通過後,各方面人員才能確信他們所贊同的需求是可靠的.
你可以使用以下三種方法編寫軟體需求規格說明:
用好的結構化和自然語言編寫文本型文檔.
建立圖形化模型,這些模型可以描繪轉換過程、系統狀態和它們之間的變化、數據關系、邏輯流或對象類和它們的關系.
編寫形式化規格說明,這可以通過使用數學上精確的形式化邏輯語言來定義需求.
由於形式化規格說明具有很強的嚴密性和精確度,因此,所使用的形式化語言只有極少數軟體開發人員才熟悉,更不用說客戶了.雖然結構化的自然語言具有許多缺點,但在大多數軟體工程中,它仍是編寫需求文檔最現實的方法.包含了功能和非功能需求的基於文本的軟體需求規格說明已經為大多數項目所接受.圖形化分析模型通過提供另一種需求視圖,增強了軟體需求規格說明.

㈢ 企業如何進行員工招聘需求分析

用人部門提出招聘需求，作為招聘負責人根據什麼確定招人是否真需求，是否合理性？千萬不要他們說招你就招。所以，做好招聘需求分析是當務之急。

一、我們為什麼要招聘？原因有五個：
1. 有人離職
2. 工作量增加
3. 新崗位
4. 儲備
5. 准備換人

二、判斷是否真需求的方法，有五句話：
1. 工作內容不明確的不招。
要招的這個人，打算具體讓他做什麼，不要籠統的，要具體的工作內容描述；

2. 招來沒有人管的不招。
誰將是他的師傅，師傅是怎麼想的，做好准備沒有？

3. 能內部協調調配的不招。
如果不能按計劃招到，用人部門的負責人，有什麼備選方案，備選方案有沒有可能成為主方案？

4. 不可能完成的需求不招。
能不能制定出招聘計劃，做不出招聘計劃的需求，不要說「試試看，想辦法」，應該立即調整；

5. 簡單的換人需求不招。
對現有人員不滿意，如果只是管理問題，管理問題改善前，不招新人。

對上述5句話，後兩句可能有爭議，這樣表達，是為了倒逼用人部門和HR部門一起，不要老想著換人，用新人；要著眼培養人，用人長處，不斷提升管理水平，將人才資產盤活。

三、招聘需求分析步驟
嚴格地講，招聘需求分析尚未形成特別科學和准確的方法，但可以嘗試採用以下思路：

第一步：崗位信息的採集搜集
現有的崗位說明書、組織機構、團隊結構、用人機制等資料是崗位信息的重要來源，實地考察、任職者訪談、績優者分析等是採集搜集崗位信息的有效方法。

第二步：崗位信息的整理提煉
所有與崗位相關的信息可以被整合成四個方面：
1. 崗位職責要求：崗位的關鍵產出是什麼？崗位對人的行為要求是什麼？這些要求哪些是對人的，哪些是對事的？
2. 工作環境特點：是否要求承擔較大的工作壓力？工作節奏快慢如何？崗位在公司中的地位如何？任職人所在團隊氛圍如何？
3. 公司文化要求：公司倡導什麼樣的價值觀？公司體現什麼樣的精神風貌？公司需要體現什麼樣的工作風格？
4. 公司發展需要：公司未來的業務方向是什麼？在可預見的未來，業務發展對人的要求將發生什麼樣的變化？

第三步：匯總崗位的用人要求
從「知識、技能、經驗」、「能力」、「動機/價值觀」三個維度，對上述信息加以匯總，形成崗位用人要求。

第四步：有效招聘要素的選擇
上述崗位用人要求是一種理想狀態，但企業需要的是最合適的人，而不是「完美」的人。在招聘過程中，不需要面面俱到，只需要重點選擇若干個核心要素作為考察點。考察點的衡量標准如下：

1. 培養成本：某項考察點在短期內進行培養的難易程度。易於培養的，作為考察的次要標准或不予考察;不易培養的，則作為主要考察點。

2. 人群區分度：某項考察點在應聘者群體中的差異度和區分度。區分度小的，作為次要標准或不予考察；區分度大的，則作為主要考察點。

3. 環境約束度：某項考察點因環境因素對職責發揮的影響程度。環境約束度高的，作為次要標准或不予考察；約束度低的，則作為主要考察點。

4. 可衡量度：某項考察點能用現有方式進行衡量的程度。不能或不易衡量的，作為次要標准或不予考察；易於衡量的，則作為主要考察點。

需求不合理下的招聘工作，會拖死HR部門，我們的HR部門將永遠忙於人事事務工作，沒有精力來思考和落實人力資源管理工作，最後的結果只能是，天天招人，始終無人可用。所以，判斷招聘需求是否合理性是一個有必要性的工作。

㈣ 怎樣用勞動力需求的原理分析 減員增效,下崗分流

「精幹主體，分離輔助」，實現企業勞動力資源的合理配置，是企業提高勞動效率，適應市場經濟發展的重要舉措。在實施減員增效的過程中，必須要把減員增效與企業內部機構改革、行業結構調整結合起來，以減員促改革，以改革求效益，並用科學的標准規范減員行為和程序。

(一)調整產業結構、合理配置勞動力

根據現代化企業制度的要求、社會主義市場經濟的需要及國家局擴大優勢企業生產規模、「一業為主、多種經營」的發展戰略的要求，按照精幹、高效、科學的原則，進行戰略性企業重組。要搞好企業的定崗、定編、定員、定責、定薪工作，建立一個適應市場經濟的用人機制，搞好人力資源的合理配置。

(二)完善定額定員標准、加大實施力度

加強工業企業定標達標工作的實施，優化工種、崗位，優化定員分布結構，制定相應的實施管理辦法，督促企業自覺按最優化人力資源配置組織生產，以最小的人工成本投入取得最大的經濟效益，提高企業在市場經濟條件下的競爭力。

在調整研究的基礎上，盡快編制出台商業企業定額定員標准，改變商業企業因用人無標准而造成的不科學、不規范用人的局面。同時，避免因工業企業減員分流，人員盲目轉向商業企業，造成商業企業人員無序膨脹的不良循環狀況。

(三)引進競爭機制、擇優上崗

加強在職職工培訓工作，提高職工素質。組織廣大職工加強學習，更新就業觀念，增強競爭意識。通過學習，提高其專業技術水平和實際操作能力。根據崗位在企業生產活動中的地位、作用和上崗人員應具備的條件、職責，制定上崗標准。只要是符合上崗條件，不分幹部工人，不論是否在崗，均可公平競爭、擇優上崗。對那些不參加競爭上崗、不符合上崗條件和標准或沒有崗位上崗的，即視為下崗人員。

三、行業減員增效的措施

減員增效、下崗分流，形成「優勝劣汰」的競爭機制，是國有企業深化改革、實施產業結構調整的重要舉措。減員，一方面是對勞動力資源的階段性閑置，造成一定的失業和社會壓力；另一方面，可以提高勞動生產率，降低成本，增強企業產品在市場上的競爭能力，提高經濟效益，從而相應增強對勞動力的吸納需求。

下崗職工同樣是一部分重要的人力資源，是社會主義現代化建設的重要力量。重新就業是《勞動法》賦予他們的勞動權利。黨的十五大報告中明確指出：「黨和政府要採取積極措施，依靠社會各方面的力量，關心和安排好下崗職工的生活，搞好職業培訓，拓寬就業門路，推進再就業工程。」國家局黨組也指出：「現有的多元化經營企業以及今後新開辦的項目，都要優先考慮煙草職工的分流問題，特別是要為下崗職工創造再就業的機會和條件，使多元化經營為增強行業的凝聚力和維護職工隊伍的穩定做出積極貢獻。」因此，企業有責任、有義務為下崗職工創造條件，幫助他們轉變就業觀念，增強就業能力，以期盡快重新就業，充分發揮他們的作用。為實現行業持續良性發展，注入新的生機和活力，在操作過程中，要做到摸清底數，制定規劃，明確任務。具體可採取以下措施：

(一)精幹主體

1．積極研究、探索下崗職工的再就業途徑，發揮勞動者在就業擇崗上的積極性。鼓勵下崗職工或調出、或辭職、或自謀職業。對由職工本人提出申請，要求自謀職業，同時解除勞動合同的職工，可給予一定的扶持政策。

2．對已醫療期滿，符合退職條件的病休及長期不能正常上班的人員，辦理退職、退養手續。

3．對距法定退休年齡五年以內的職工，可辦理廠內退休手續，待達到退休年齡時，再辦理正式退休手續。

4．挖掘企業內部潛力。對不該外聘、可以不聘企業外人員的崗位，要堅持清退外聘人員。

5．充分運用法律手段，加大職工隊伍整頓力度。嚴格按照《勞動法》中有關解除、終止勞動合同規定，對嚴重違反勞動紀律和有關規章制度的人，堅決予以解除勞動合同。

(二)分離輔助

對企業內部具有辦社會性質的輔助部門，或具有一定分流條件的部門和單位，要與主體剝離，使其成為立足市場、自主經營、獨立核算、自負盈虧的經濟實體。

(三)理順管理體制

積極發展第三產業和其它經濟實體，對長期存在的全民支援集體企業的職工實行「脫崗」管理，把對集體企業的人力支援納入人員流動的正常軌道管理。

(四)建立企業內部勞動力管理中心

辦好勞動力管理服務中心，對下崗職工實行託管。託管期間，要制定相應的職工培訓計劃，對下崗職工進行各種轉業轉崗培訓；加強職業介紹，提供就業指導和就業需求信息。並為職工發放基本生活費，辦理社會保險，為下崗職工解除後顧之憂。同時，企業要制定相應的上崗、待崗、下崗工資待遇政策和待崗、下崗託管時間期限。對待崗期間兩次不服從分配，或待崗一定時間(一年或兩年)通過培訓仍不能上崗的，可解除勞動合同。

(五)開辟新的就業渠道

發展多種經營企業，興辦第三產業等經濟實體，積極主動為下崗職工提供安置就業崗位。

㈤ 為什麼進行需求分析

A 戰略層需求（一般來自老闆）
一個公司的方向性需求，一般不是產品經理所能決策的，這個層面的需求一般來自於決策層。老闆一般會根據自己擁有的資源優勢，以及對市場的分析，決定產品的戰略方向。

比如為什麼微信是做熟人社交，陌陌是做陌生人社交，360是做殺毒。對於這個層面的需求，一般不會有太具體的需求。通常產品經理會聽到的需求會是，產品大概要面向什麼樣的用戶，幫助用戶解決什麼樣的問題，這種類型的需求可能在初期的創業公司會聽的更多，例如餓了么的誕生是來自於他的創始人想要解決校園里叫外賣不便的現狀 。

在相對成熟的公司孵化新項目時，你聽到的需求可能會變成：公司有哪些資源優勢，我們利用這樣的優勢能切入哪個行業，解決什麼問題。比如小程序的誕生，一定是（wo cai de） 微信的決策層在思考自己擁有這個體量的用戶後 ，產品能做更多的事情。在這個思路下，逐漸衍生出了小程序的概念。利用小程序，微信實現了流量的轉化，實現了自己平台化、系統化的想法。

在這個階段產品經理更多的事情應該是去了解老闆提出的方向。基於這樣的需求，可以確定人群，確定要需求范圍（就是要做啥事），以及手裡面可用的一些資源。（比如流量資源，內容資源，演算法資源等）。

簡單的來說，如果把做產品比作開店，那麼這個階段差不多菜系（要解決問題）和大廚（資源）應該是選好了，以及賣給什麼樣的人。但是開在什麼地方，面積選擇，店面裝潢，詳細的菜品和定價都還沒有確認。

B 用戶需求調研
在接到了戰略層的需求，接下來要做的事情是分解和完善需求，將需求細化。這個時候你要做的事情包括：找到目標人群、了解目標人群的使用習慣。

比如你要做一個外賣平台，你的用戶群里可能包含了兩個人群，商家和用戶。針對這兩個人群，又會派生出很多需求。你需要考慮商家的使用環境，普通的小店很可能收銀、送貨、點餐全部加起來只有一到兩個人。他們可能就沒有辦法專職的關注下單情況，這種情況下你的推送機制，語音提醒可能就要保證時效性。同樣的因為生產環境的原因，訂單管理需要人工來確認，保證不會過載，影響用戶的體驗。商品的上架和下架就要盡可能簡單、清晰，在商家沒有貨的時需要及時下架。（不同於客戶端的豐富、種類繁多）。

用戶端則面對學生群體，不同於在食堂購買，在PC或者手機上，如何展示有哪些商家，每個商家又有什麼樣的特色，如何幫助用戶去挑選商家，怎麼評判商家的口味，價格如何展示。需求和商家端有很大的不同。

文章中舉例的外賣軟體，在我們日常生活中比較常見。很多需求依託常識就可以做出判斷。但是如果遇到小眾的需求，例如二次元社區、情趣用品等，如果產品經理沒有這些產品經驗，則需要去找到用戶群體，比較常見的做法有聯系公司內部的工作人員，例如運營和客服，這些經常需要和用戶去打交道的職位，能給夠你一些最真實的意見。還可以維護種子用戶微信群，做調研問卷等。

但是小公司一般不太會採用這些方式，因為這些方式成本高，耗時長。最好的辦法還是產品經理能變成產品的忠實用戶，去真實的使用產品。而不是假想自己是產品。

在這個環節，其實產品經理基本上可以將方向性的需求轉變為更詳細的功能范圍，以及對應的優先順序。還是拿開飯店的那個例子，在這里其實我們根據老闆給的菜系和大廚以及開店預算。

我們基本上確認了我們的菜是要賣給什麼人，這些人來吃飯的需求是工作餐還是周末聚會，還是情侶約會，以及他們大概的預算會在什麼范圍（目標人群及核心需求） 。在這些條件的支撐下，我們基本可以確定菜譜上的內容，要設置冷盤、熱菜、招牌菜、主食（需求轉化為對應的功能列表）。根據這些人的性格特點，店面的裝潢也可以確定了（頁面風格，排版）

C 協作部門的需求
確定了用戶的需求之後，我們要繼續確認內部的工作流程。產品不僅是用於服務用戶，同時還要服務自己內部體系的其他部門。例如：

運營部門日常的內容和活動維護，那你就會需要一個管理後台；
客服要可以收集和解答用戶的問題，那我們的頁面上就會需要客服的展示位以及後台給客服回復的頁面；
像餓了么這個例子，它的協作部門還包括了外賣配送人員，這個時候就需要給配送員一個可以快速查看和管理訂單的頁面（體量足夠，可以變成app）；
網站類的產品可能收到來自seo部門的需求，他會要求的你的頁面上增加很多的內鏈、會要求一些搜索詞要有落地頁面。（這個可能會直接影響你的網站結構，seo會讓你做很多專門給爬蟲抓取的頁面）。
可能還會有一些頁面上看不到的需求:比如財務可能有做賬的需求，BI有數據統計的需求。
確定了你可能需要協作的部門之後，有的時候你還需要繼續確認他們的人員配置和工作流程是什麼樣的，這些會影響到前後端的設計。

以我所在的公司為例，產品是垂直領域的內容類產品，在我規劃內容展示的時候，首先需要明確我們內容的生產的范圍和內容數量、以及內容的展示形式（音頻、視頻？），這些東西決定了你的頁面如何展示。

㈥ 人員需求報告怎麼寫

這是一個人員需求預測的報告模板，你可以參考一下，其中的一些表格復制不過來，沒有顯示表格的形式，但是不影響框架的體現。
公司年度人員需求預測報告

文本名稱 ××公司年度人員需求預測報告 受控狀態
編 號
一、目錄（略）
二、呈送文（略）
三、報告正文
（一）人力資源現狀分析
1．員工構成情況
伴隨公司成立以來的發展和積累，目前在生產和經營領域初步形成了一支素質較好、層次較高的人才隊伍，共有在職職工368人。具體人員構成情況見下表所示。
××公司員工構成情況表
類別 具體分布情況
職能分布 公司高層 管理中層 管理人員 生產人員
人數 比例 人數 比例 人數 比例 人數 比例
5 1.4 15 4.1% 38 10.3% 310 84.2%
學歷分布 碩士及以上 本科 大專 大專以下
人數 比例 人數 比例 人數 比例 人數 比例
6 1.6% 40 10.9% 135 36.7% 187 50.8%
年齡構成 30歲及以下 31～40 41～50 50以上
人數 比例 人數 比例 人數 比例 人數 比例
186 50.5% 116 31.5% 41 11.1% 25 6.8%
2．定崗定編情況
本公司目前各部門定崗定編情況如下表所示。（表略）
3．人力資源現狀分析結果說明
（1）87．5%的員工集中在大專及以下學歷，具有中高級技術職稱的人員不多。
（2）員工年齡在40歲以下的占總人數的82.1%，具備進一步學習的能力。
（3）隨著公司的發展、業務規模的擴大，專業技術人才、一線生產人員、市場拓展人員均應有較大需求。
（二）人力資源需求預測結果
1．未來人力資源流失預測
（1）未來退休人員預測：公司2004年至2006年退休13人，其中2人內退，11人正常退休。2007年公司51歲以上人員僅有25人，相對公司人員規模來說，退休人員很少，不會影響公司的人員數量變化，建議不作考慮。
（2）未來離職人員預測：公司2004年至2006年共有15人，其中12人主動離職，3人被開除，離職人員人數較少，基本集中在一線生產工人類別上，在未來離職人員預測中不作考慮。
2．未來新增人員及主要崗位需求
為滿足公司的戰略發展要求，未來人員需求將集中於投融資管理人才和專業技術人才、經營人才等。
（1）投融資管理人才：公司未來幾年內將積累大量財務資源，急需投融資管理方面人才，初步估計投融資管理人才需2人。
（2）專業技術人才：公司預計2008年將新增產品品種，新增1條生產線，初步估計具有生產專業技術中級及以上職稱的人才3人，生產工人20人。
（3）業務經營人才：隨著公司業務規模的擴大，將擴展銷售領域和市場份額，可引進具有豐富業務管理經驗、極具市場開拓精神的高級經營人才，初步估計業務經營人才需10人。
3．未來人員凈需求
公司2008年各部門人員需求表
部門名稱 新增崗位及人數 部門名稱 新增崗位及人數
決策層 設置戰略發展部，2人 生產部 車間主任1人，生產崗位工人20人
財務部 投融資主管1人，專員1人 市場部 策劃專員1人
技術部 技術研發人員2 銷售部 銷售區域經理3人，銷售專員7人
產品部 產品設計人員2人 質量部 檢驗員1人
行政部 人員不變 采購部 采購專員1人
人力資源部 人員不變 倉儲部 不變
人員凈需求 42人

相關說明
編制人員 審核人員 批准人員
編制日期 審核日期 批准日期

㈦ 簡述員工需求分析各個層面的內容及需求分析方法

【柯氏四級評估】

第一級：反應評估

第二級：學習效果評估

第三級：行為評估

第四級：成果評估

關於柯氏四級評估，有兩個注意點：

1）4321做規劃，1234看效果

培訓後，我們會按柯氏1→2→3→4級來做培訓效果評估。在培訓前期的規劃階段，應該反過來，按照4→3→2→1做規劃。

需求分析及調研怎麼做？大神教你從這3個層次入手
首先，應該明確需要達到的業績成果（成果評估）。其次，反思支持績效達成所要進行的行為改變（行為評估），最後再匹配、規劃並開展培訓。

2）一定要自上而下做分析

問：作為培訓經理，如果你只有一個客戶，TA會是誰？

答：老闆。

需要區分開來的是——老闆是客戶，你的管理者、員工是用戶。

培訓需求的調查一定是自上而下做分析，了解老闆的需求在哪裡，然後再進行傳達、執行和落地。老闆認為什麼是重要的，我們就要去跟隨和支持。

需求分析及調研怎麼做？大神教你從這3個層次入手
戰略層面「找方向」

1）清晰界定需要改善的業務問題

組織的戰略和發展在哪裡？組織沒有很清晰的戰略怎麼辦？這里有兩個方法可以參考——

① 錢從哪裡來？錢會去哪裡？

未來什麼地方可以賺錢？ 即分析企業經營發展戰略，以確定今後的培訓重點；

現在什麼地方賺錢？什麼地方該賺錢而沒有賺錢？ 即分析企業當前整體績效，找出存在問題並分析原因，以確定當前企業培訓的重點。

② 資料信息分析法

從既往資料、方案等分析培訓需要（包括企業年報、發展計劃書、年底績效總結等）。

舉個例子

資料一：公司從今年6月至9月，公司並購3家公司發展太陽能新業務；員工從1500餘人發展到4000餘人；

資料二：管理隊伍新提拔或轉化崗位56人，其中新提拔23人；

資料三：由總裁主講「公司發展與管理者的要求」；舉辦一次「如何有效溝通」；培訓部組織3次新員工培訓。

資料分析：

1.關鍵詞「新業務」，新業務需要培訓，這是一次機遇也是挑戰；

2.關鍵詞「從1500餘人發展到4000餘人」，人數的增長暗示文化融合問題，需要提前進行規劃；

3.關鍵詞「管理者人數上升」，新進管理者需要培養；

4.關鍵詞「高管授課及活動」，發掘未來培訓的方向以及可用的資源。

人力資源部門的一些報告，看似跟我們關系不大，但如果我們沒有去關注這些信息，等到半年之後，潛在問題像轟洶涌的洪水朝我們沖過來的時候，我們只能被沖走。

所以我們一定要離開當前培訓部的位置，嘗試站出去看經營，看組織的規模發展，看行業的趨勢，在更好地了解組織發展後，才能作為一個組織的投資者去幫助組織，通過人才投資的方式不斷得到增長和發展。

2）對企業戰略了解程度的測試

要做戰略落地的培訓計劃，一定要從戰略層面去思考，不單是停留在職能部門。可以通過以下問題了解——

1.我們公司最重要的收入來源是？2.我們公司最重要的業務增長驅動因素是？3.我們公司的核心戰略是？4.我們公司的主要競爭對手是？5.我們公司面臨的最大威脅是？6.我們公司面臨的最大人力資源挑戰是？

當我們看的更加清楚之後，才知道接下來風向在哪裡。站在風口，豬也會飛起來。

需求分析及調研怎麼做？大神教你從這3個層次入手
組織層面「找方法」

既然知道重點，該用什麼樣的方式設計培訓？

1）培訓的邊界

什麼是培訓能解決的問題？——知識、技能和態度問題。其中，態度問題是一個大難題，它不是通過單一一次培訓能夠去解決的，需要通過系統、不斷的培訓、影響和改變，才可以達到。

需求分析及調研怎麼做？大神教你從這3個層次入手
2）能力需求調研問卷

市面上有很多有很多勝任力模型/能力素質清單，大家可以參考並設計出屬於自己的培訓需求分析問卷。

需求分析及調研怎麼做？大神教你從這3個層次入手
3）部門培訓業務需求面談

現在的組織架構發生了一些改變，譬如OD（組織發展）、HRBP（業務部門的合作夥伴）。這種轉變把培訓和人力資源下放到業務部門之下，直接對業務負責，增進了培訓和專業部門的相互理解，可以對於業務了解之後再輸出學習。

需求分析及調研怎麼做？大神教你從這3個層次入手
員工層面「量體裁衣」

這個部分對於多半企業來講還不太現實，暫時只在一些較關鍵的群體，比如說領導力，或者在一些企業的專家或高管啟動。

員工層面還需要做調查嗎？

需要，要做需求培訓的方式和周期的需求分析。按照四級評估模型來說，這一步叫做一級評估調查。

什麼時間，什麼方式學習比較有效？培訓先找到「葯」，再思考怎麼樣讓學生能願意吃下去。

1）淡季開展培訓，旺季開發課程

不同行業在處理這個問題時的方式不太一樣，比如說服裝快銷的行業，很多時候以季度為單位——分季前、季中和季後。季前和季後都都是比較忙的，所以第一季度2月份比較適合做培訓， 1月份3月份的時間就不要打擾他們了。

2）根據群體特性開展培訓

70後、80後、90後偏好學習的方式不太一樣，同樣課程內容，如果群體對象不一樣，為了保證有效培訓，還要考慮不同的方式。如按年齡、專業線條等特性，給他們提供比較適合的方式方法進行培訓。

㈧ 需求分析如何來做

隨著技術的不斷發展和用戶對網站功能性的需求不斷提高，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟體工程，也越來越復雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規范的、有效的、健壯的開發機制，才能適應用戶不斷變化的需要，達到預期的計劃目標。
網站項目管理（WPM）的含義為Web-based Project Management，即以Web 應用程序為主要表現方式的架構來進行的項目設計及管理，這樣的架構中包含了瀏覽器、網路和Web
伺服器等關鍵主體，主要體現在網站設計、以瀏覽器為客戶端的Web應用程序開發（例如信息類網站、網上商店、虛擬郵局、客戶關系管理。）等項目管理中。
按照筆者的經驗，網站項目管理可以分為以下l六個階段進行控制： 1. 需求分析及變更管理 2. 項目模型及業務流程分析 3. 系統分析及軟體建模 4. 界面設計、交互設計及程序開發 5. 系統測試和文檔編寫 6. 客戶培訓、技術支持和售後服務
需要說明的是，這些階段雖然具有一定的延續性，但是並非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。
（一）如何做好需求分析及變更管理？
業務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。
一：讓客戶暢所欲言，羅列出所有的需求
讓用戶將所有的想法盡可能的闡述清楚，並把所有的要求羅列出來，不要遺漏。這時候不應該害怕「勾引」起客戶的潛在需求而增加設計開發的工作量，從而被今後客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求准確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時可能會產生意想之外的變更，甚至這個變更會破壞已經做的模型及結構，那麼這個項目從開始就註定了會失敗；比如站點所有的功能都實現了，本地測試起來也沒有什麼問題了，但是你卻不知道客戶的系統是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經驗的開發人員都會明白這樣的設計是個災難，無論是應用伺服器、資料庫還是程序全部要重新開發！
二：透過現象分析潛在的需求
很多情況下客戶並非專業人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術難關，這需要我們去為客戶進行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現難度和強度很高的地方特別值得注意。
客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統而且尺度難以控制的，這就要求業務人員在傾聽了客戶的詳細說明以後，幫助客戶進行整理和分析，同時預測客戶在開發過程中變更及今後應用中可能進行修改升級的潛在需求。
比如在為客戶設計辦公自動化系統的時候，也許就要為客戶預留將來與他們的業務單位進行交互的通道；在設計郵件系統的時候要考慮可能會需要廣告管理伺服器；設計網路電子商店時今後增加庫存產品進銷存統計分析等等；限於時間財力的考慮，客戶通常能夠接受分階段實施的開發過程，在需求分析時，提早為客戶設想到今後的需求變更除了使項目開發更加順利以外，也為今後業務的進一步深入打下了更好的基礎。
筆者曾負責一個大型新聞網站的設計，當客戶拿著將近五十頁厚的一本設計要求報告時，我發現有四十頁的內容對程序開發來說都是重復的，而在其中一頁的角落卻畫了個「搜索其他網站相關新聞」的按鈕，並且沒有做任何說明，僅僅這10個字所完成的工作量完全頂的上其他整整四十頁重復贅述所做的工作，客戶完全不知道這個要求引發的問題實際就是一個搜索引擎的開發，通過協商，客人同意了修改成站內搜索的引擎。
三：利用自然的語言描述項目模型
在業務員與客戶進行溝通和調查時撰寫的需求分析，盡可能用自然的語言進行描述，雖然客戶的水平和資歷有所不同，但是最自然的描述能夠使項目開發的各個成員都能清楚地理解需求含義，不至於在理解上產生偏差。對客戶而言，這樣的模型描述最接近真實，容易參與修訂，並能以此為測試和驗收的依據。
請比較以下兩份關於需求的描述， 「用戶在訪問首頁的時候可以在點擊『客戶通道』按鈕，彈出填寫『用戶名』和『密碼』的窗口，輸入正確後在新窗口打開客戶通道的首頁，在該頁顯示所有可操作的功能的導航條和最新的導讀新聞鏈接列表 。」
「站點分為公開和加密兩種狀態，通過身份驗證機制使特有的用戶可以訪問到加密信息，並提供不同於普通用戶的功能。」 前段描述我們就很容易想像的出來設計完成的網站是什麼樣子，而後一段的描述可能會做出無數不同的版本，造成對需求理解的歧意。
四：利用示意圖和圖表將用戶的需求表現出來
需求分析無論文字上怎麼樣表述都還是抽象的，對客戶而言理解畢竟是困難的，將基本確定的需求製作出示意圖是最直觀有效的。
製作示意圖可以有很多種方式，用PowerPoint或Visio製作流程示意，用Html文檔製作界面示意都是可行的，最簡單利用畫圖和Word表格方式也完全可以，關鍵是利用示意圖將客戶的需求和即將開始設計的系統體現起來，在進行系統分析和程序開發之前，雙方對今後要完成的產品就能夠有直觀的認識，換言之，就是在產品還沒有真正進入開發階段的時候，雙方就對工作的結果達成統一的意見，這將大大地減輕需求變更所帶來的困擾，同時客戶更容易地參與到項目的開發過程，保證項目往正確的方向進行。
在RUP中有這樣的描述：
利用電影、卡通、圖片、表格和動畫片等製作示意圖開始，告訴我們用戶是誰，要發生什麼事情，如何發生。
以用戶友好的方式幫助收集並改進用戶需求。
鼓勵更有創造性、更加創新的設計解決方案。 鼓勵團隊復審，並避免所有人都不希望出現的特徵。
確保以可理解、直觀的方式實施特徵。
使訪談過程變得輕松，避免出現訪談沒有結果的現象。
簡單地說，製作示意圖就是使用工具向用戶 (主角) 說明（有時是動畫演示）系統如何適應組織的需要，並表明系統將如何運轉。協調員將初始示意板展示給小組，小組成員提供意見。之後，在舉辦研討班期間，示意板也進行「實時」演進。所以，您需要一種可以輕松更改示意板的畫圖工具。為了避免分散注意力，一般最好使用簡單的工具，比如圖表、白板或PowerPoint。
五：什麼人要看需求分析報告
項目經理、系統分析員、開發經理、交互設計師、測試人員、文檔人員包括客戶代表都應該看需求分析，並進行共同的討論，達成一致的意見。
我們經常會遇到業務人員辛辛苦苦談下來的項目，對開發人員來說卻是難以實現的，而技術人員設計的產品卻常常得不到客戶的認可，甚至發生糾紛，因此參與項目開發的人員都應該對這份需求有統一清晰的認識，並根據自己的工作對需求提出意見，通過與客戶的溝通修訂，最終確定項目實現的目標。
例如：
項目經理通過需求分析才能組建所需要的團隊包括配置工作環境，制定開發周期。 開發周期的限制和功能上的要求可能會影響到程序員採用什麼樣的語言和工具進行編寫； 操作用戶的技能水平將影響到交互設計師進行前台設計時做到什麼樣的精度； 界面設計人員根據項目的性質和定位確定表現方式。 測試人員了解測試環境和條件後才能對項目質量進行跟蹤和檢測；
通過下表，我們可以看的出不同角色根據需求的變更所進行的工作流程：

六：建立需求變更日誌，製作新版本的需求分析報告
盡管我們費了許多功夫在需求分析進行了最大可能的努力，但幾乎可以肯定的是，這份需求分析在開發過程中一定會發生變化，也許是出自客戶的遺漏，也可能是在開發過程中被激發出來的，這種變更有時是如此的頻繁和瑣碎，以至於往往不能將變更及時反饋到項目的各個角色中，那麼做好需求變更日誌就顯得非常重要。
在需求分析後面附上變更日誌，並將修改後的需求分析製作成新版本，保留每次更改過的版本，而不是覆蓋，這樣就比較容易地跟蹤到需求變更過程中所帶來的工作調整。
在新版本的需求分析中，將變更多部分用特殊方式表明出來，並在日誌中記錄變更多重的明細。
關於需求分析和變更管理可以參照下圖示意：

七：本階段重點工作角色
在需求分析和變更管理的過程中，工作量最大的角色為客戶代表、業務員和項目經理。
客戶代表提出需求，業務員幫助整理和分析，項目經理對整個項目進行評估。
在實際工作中，很多項目失敗的起因都和需求分析有關。 客戶代表和業務員通常並非從事技術開發的專業人員，在討論需求的時候往往對項目的技術難度、工作量、時間進度把握不準確，這時候需要項目經理或技術人員進行參謀。
為了降低項目的風險，提高工作效率，有必要設計規范的需求管理計劃書，幫助客戶代表和業務員更好的完成任務。
以下提供一份需求管理計劃的模板可作為參考：

八：總結
根據筆者的經驗，要盡快做好需求分析掌握以下要點，也許能事半功倍：
仔細聆聽，羅列客戶的所有要求； 將需求進行分析，確認可操作的系統模型； 利用最自然的語言將系統進行描述，使每個開發人員不會產生歧意； 迅速確定網站的用戶角色； 比如訪客、會員、重要客戶、前台管理員、網站管理員、業務員等； 分析確定每個角色的許可權及可操作的功能； 比如會員可以查看特別信息、修改個人信息、退出登陸等； 前台管理員能夠登錄管理系統，能夠發布編輯修改信息，能夠審查會員資格等； 網站管理員可以更改欄目、修改網站界面等； 製作流程圖和示意圖將需求表現出來； 讓客戶參與到示意圖的設計中，及時正確的反應出需求變更。 製作需求變更日誌，保留升級版本，通過版本控制進行需求管理； 通過需求《管理計劃書》使每個參與人員看到共同的努力目標。

㈨ 需求分析的詳細分析

從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解需求分析指需求的分析、定義過程。 需求分析就是分析軟體用戶的需求是什麼。如果投入大量的人力，物力、財力、時間，開發出的軟體卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟體，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的(相信大家都有體會)。比如：用戶需要一個for linux的軟體，而你在軟體開發前期忽略了軟體的運行環境，忘了向用戶詢問這個問題，而想當然的認為是開發for windows的軟體。當你千辛萬苦地開發完成向用戶提交時才發現出了問題，那時候你是欲哭無淚了，恨不得找塊豆腐一頭撞死。
需求分析之所以重要，就因為他具有決策性、方向性、策略性的作用，他在軟體開發的過程中具有舉足輕重的地位，大家一定要對需求分析具有足夠的重視。在一個大型軟體系統的開發中，他的作用要遠遠大於程序設計。 需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規格說明、評審。
問題識別：就是從系統角度來理解軟體，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標准。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、操作系統等)、可靠性需求(不發生故障的概率）、安全保密需求、用戶界面需求、資源使用需求(軟體運行是所需的內存、CPU等)、軟體成本消耗與開發進度需求、預先估計以後系統可能達到的目標。
分析與綜合： 逐步細化所有的軟體功能，找出系統各元素間的聯系，介面特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。
制訂規格說明書： 即編制文檔，描述需求的文檔稱為軟體需求規格說明書。請注意，需求分析階段的成果是需求規格說明書，向下一階段提交。
評審： 對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。 需求分析的方法有很多，這里只強調原型化方法，其它的方法如：結構化方法、動態分析法等，從來沒用過這些方法在此不討論。
原型化方法是十分重要的，原型就是軟體的一個早期可運行的版本，它實現了目標系統的某些或全部功能。
原型化方法就是盡可能快地建造一個粗糙的系統，這系統實現了目標系統的某些或全部功能。但是這個系統可能在可靠性、界面的友好性或其他方面上存在缺陷。建造這樣一個系統的目的是為了考察某一方面的可行性，如演算法的可行性、技術的可行性或考察是否滿足用戶的需求等。如：為了考察是否滿足用戶的要求，可以用某些軟體工具快速的建造一個原型系統，這個系統只是一個界面，然後聽取用戶的意見，改進這個原型。以後的目標系統就在原型系統的基礎上開發。
原型主要有三種類型：探索型、實驗型、進化型。
探索型：目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。
實驗型：用於大規模開發和實現前，考核方案是否合適，規格說明是否可靠。
進化型：目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。
在使用原型化方法時有兩種不同的策略：廢棄策略、追加策略。
廢棄策略：先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好的思想，據此設計出較完整、准確、一致、可靠的最終系統。系統構造完成後，原來的模型系統就被廢棄不用。探索型和實驗型屬於這種策略。
追加策略：先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心，然後通過不斷地擴充修改，逐步追加新要求，發展成為最終系統。進化型屬於這種策略。 客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以後的磨擦（如一方要求而另一方不願意或不能夠滿足要求）。
1、 分析人員要使用符合客戶語言習慣的表達
需求討論集中於業務需求和任務，因此要使用術語。客戶應將有關術語（例如：采價、印花商品等采購術語）教給分析人員，而客戶不一定要懂得計算機行業的術語。
2、分析人員要了解客戶的業務及目標
只有分析人員更好地了解客戶的業務，才能使產品更好地滿足需要。這將有助於開發人員設計出真正滿足客戶需要並達到期望的優秀軟體。為幫助開發和分析人員，客戶可以考慮邀請他們觀察自己的工作流程。如果是切換新系統，那麼開發和分析人員應使用一下舊系統，有利於他們明白系統是怎樣工作的，其流程情況以及可供改進之處。
3、 分析人員必須編寫軟體需求報告
分析人員應將從客戶那裡獲得的所有信息進行整理，以區分業務需求及規范、功能需求、質量目標、解決方法和其他信息。通過這些分析，客戶就能得到一份「需求分析報告」，此份報告使開發人員和客戶之間針對要開發的產品內容達成協議。報告應以一種客戶認為易於翻閱和理解的方式組織編寫。客戶要評審此報告，以確保報告內容准確完整地表達其需求。一份高質量的「需求分析報告」有助於開發人員開發出真正需要的產品。
4、 要求得到需求工作結果的解釋說明
分析人員可能採用了多種圖表作為文字性「需求分析報告」的補充說明，因為工作圖表能很清晰地描述出系統行為的某些方面，所以報告中各種圖表有著極高的價值；雖然它們不太難於理解，但是客戶可能對此並不熟悉，因此客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和需求開發工作的結果，以及怎樣檢查圖表有無錯誤及不一致等。
5、 開發人員要尊重客戶的意見
如果用戶與開發人員之間不能相互理解，那關於需求的討論將會有障礙。共同合作能使大家「兼聽則明」。參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為項目成功所付出的時間，同樣，客戶也應對開發人員為項目成功這一共同目標所做出的努力表示尊重。
6、 開發人員要對需求及產品實施提出建議和解決方案
通常客戶所說的「需求」已經是一種實際可行的實施方案，分析人員應盡力從這些解決方法中了解真正的業務需求，同時還應找出已有系統與當前業務不符之處，以確保產品不會無效或低效；在徹底弄清業務領域內的事情後，分析人員就能提出相當好的改進方法，有經驗且有創造力的分析人員還能提出增加一些用戶沒有發現的很有價值的系統特性。
7、 描述產品使用特性
客戶可以要求分析人員在實現功能需求的同時還注意軟體的易用性，因為這些易用特性或質量屬性能使客戶更准確、高效地完成任務。例如：客戶有時要求產品要「界面友好」或「健壯」或「高效率」，但對於開發人員來講，太主觀了並無實用價值。正確的做法是，分析人員通過詢問和調查了解客戶所要的「友好、健壯、高效所包含的具體特性，具體分析哪些特性對哪些特性有負面影響，在性能代價和所提出解決方案的預期利益之間做出權衡，以確保做出合理的取捨。
8、 允許重用已有的軟體組件
需求通常有一定靈活性，分析人員可能發現已有的某個軟體組件與客戶描述的需求很相符，在這種情況下，分析人員應提供一些修改需求的選擇以便開發人員能夠降低新系統的開發成本和節省時間，而不必嚴格按原有的需求說明開發。所以說，如果想在產品中使用一些已有的商業常用組件，而它們並不完全適合您所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。
9、 要求對變更的代價提供真實可靠的評估
有不同的選擇。而這時，對需求變更的影響進行評估從而對業務決策提供幫助，是十分必要的。所以，客戶有權利要求開發人員通過分析給出一個真實可信的評估，包括影響、成本和得失等。開發人員不能由於不想實施變更而隨意誇大評估成本。
10、 獲得滿足客戶功能和質量要求的系統
每個人都希望項目成功，但這不僅要求客戶要清晰地告知開發人員關於系統「做什麼」所需的所有信息，而且還要求開發人員能通過交流了解清楚取捨與限制，一定要明確說明您的假設和潛在的期望，否則，開發人員開發出的產品很可能無法讓您滿意。
11、 給分析人員講解您的業務
分析人員要依靠客戶講解業務概念及術語，但客戶不能指望分析人員會成為該領域的專家，而只能讓他們明白您的問題和目標；不要期望分析人員能把握客戶業務的細微潛在之處，他們可能不知道那些對於客戶來說理所當然的「常識」。
12、 抽出時間清楚地說明並完善需求
客戶很忙，但無論如何客戶有必要抽出時間參與「頭腦高峰會議」的討論，接受采訪或其他獲取需求的活動。有些分析人員可能先明白了您的觀點，而過後發現還需要您的講解，這時請耐心對待一些需求和需求的精化工作過程中的反復，因為它是人們交流中很自然的現象，何況這對軟體產品的成功極為重要。
13、 准確而詳細地說明需求
編寫一份清晰、准確的需求文檔是很困難的。由於處理細節問題不但煩人而且耗時，因此很容易留下模糊不清的需求。但是在開發過程中，必須解決這種模糊性和不準確性，而客戶恰恰是為解決這些問題作出決定的最佳人選，否則，就只好靠開發人員去正確猜測了。
在需求分析中暫時加上「待定」標志是個方法。用該標志可指明哪些是需要進一步討論、分析或增加信息的地方，有時也可能因為某個特殊需求難以解決或沒有人願意處理它而標註上「待定」。客戶要盡量將每項需求的內容都闡述清楚，以便分析人員能准確地將它們寫進「軟體需求報告」中去。如果客戶一時不能准確表達，通常就要求用原型技術，通過原型開發，客戶可以同開發人員一起反復修改，不斷完善需求定義。
14、 及時作出決定
分析人員會要求客戶作出一些選擇和決定，這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息准確度中選擇折衷方案等。有權作出決定的客戶必須積極地對待這一切，盡快做處理，做決定，因為開發人員通常只有等客戶做出決定才能行動，而這種等待會延誤項目的進展。
15、 尊重開發人員的需求可行性及成本評估
所有的軟體功能都有其成本。客戶所希望的某些產品特性可能在技術上行不通，或者實現它要付出極高的代價，而某些需求試圖達到在操作環境中不可能達到的性能，或試圖得到一些根本得不到的數據。開發人員會對此作出負面的評價，客戶應該尊重他們的意見。
16、 劃分需求的優先順序
絕大多數項目沒有足夠的時間或資源實現功能性的每個細節。決定哪些特性是必要的，哪些是重要的，是需求開發的主要部分，這只能由客戶負責設定需求優先順序，因為開發者不可能按照客戶的觀點決定需求優先順序；開發人員將為您確定優先順序提供有關每個需求的花費和風險的信息。
在時間和資源限制下，關於所需特性能否完成或完成多少應尊重開發人員的意見。盡管沒有人願意看到自己所希望的需求在項目中未被實現，但畢竟是要面對現實，業務決策有時不得不依據優先順序來縮小項目范圍或延長工期，或增加資源，或在質量上尋找折衷。
17、 評審需求文檔和原型
客戶評審需求文檔，是給分析人員帶來反饋信息的一個機會。如果客戶認為編寫的「需求分析報告」不夠准確，就有必要盡早告知分析人員並為改進提供建議。更好的辦法是先為產品開發一個原型。這樣客戶就能提供更有價值的反饋信息給開發人員，使他們更好地理解您的需求；原型並非是一個實際應用產品，但開發人員能將其轉化、擴充成功能齊全的系統。
18、 需求變更要立即聯系
不斷的需求變更，會給在預定計劃內完成的質量產品帶來嚴重的不利影響。變更是不可避免的，但在開發周期中，變更越在晚期出現，其影響越大；變更不僅會導致代價極高的返工，而且工期將被延誤，特別是在大體結構已完成後又需要增加新特性時。所以，一旦客戶發現需要變更需求時，請立即通知分析人員。
19、 遵照開發小組處理需求變更的過程
為將變更帶來的負面影響減少到最低限度，所有參與者必須遵照項目變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最後做出合適的決策，以確定應將哪些變更引入項目中。
20、 尊重開發人員採用的需求分析過程
軟體開發中最具挑戰性的莫過於收集需求並確定其正確性，分析人員採用的方法有其合理性。也許客戶認為收集需求的過程不太劃算，但請相信花在需求開發上的時間是非常有價值的；如果您理解並支持分析人員為收集、編寫需求文檔和確保其質量所採用的技術，那麼整個過程將會更為順利。
「需求確認」意味著什麼
在「需求分析報告」上簽字確認，通常被認為是客戶同意需求分析的標志行為，然而實際操作中，客戶往往把「簽字」看作是毫無意義的事情。「他們要我在需求文檔的最後一行下面簽名，於是我就簽了，否則這些開發人員不開始編碼。」
這種態度將帶來麻煩，譬如客戶想更改需求或對產品不滿時就會說：「不錯，我是在需求分析報告上簽了字，但我並沒有時間去讀完所有的內容，我是相信你們的，是你們非讓我簽字的。」
同樣問題也會發生在僅把「簽字確認」看作是完成任務的分析人員身上，一旦有需求變更出現，他便指著「需求分析報告」說：「您已經在需求上簽字了，所以這些就是我們所開發的，如果您想要別的什麼，您應早些告訴我們。」
這兩種態度都是不對的。因為不可能在項目的早期就了解所有的需求，而且毫無疑問地需求將會出現變更，在「需求分析報告」上簽字確認是終止需求分析過程的正確方法，所以我們必須明白簽字意味著什麼。
對「需求分析報告」的簽名是建立在一個需求協議的基線上，因此我們對簽名應該這樣理解：「我同意這份需求文檔表述了我們對項目軟體需求的了解，進一步的變更可在此基線上通過項目定義的變更過程來進行。我知道變更可能會使我們重新協商成本、資源和項目階段任務等事宜。」對需求分析達成一定的共識會使雙方易於忍受將來的摩擦，這些摩擦來源於項目的改進和需求的誤差或市場和業務的新要求等。 需求確認將迷霧撥散，顯現需求的真面目，給初步的需求開發工作畫上了雙方都明確的句號，並有助於形成一個持續良好的客戶與開發人ONT> 要想說什麼是好的需求分析，不如說什麼是不好的需求分析，知道什麼是不好的，自然也就知道了什麼是好的。以下就是一些不好的情況：
（1）創意和求實 毋庸質疑的，每個人都會為自己的一個新的Idea而激動萬分，特別是當這個Idea受到一些根本不知道你原本要幹嘛的人的驚贊時。但是請注意，當你激動得意的時候，你可能已經忘了你原本是在描述一個需求，而不是在策劃一個創意、創造一個概念。很多剛開始做需求分析的人員都或多或少的會犯這樣的錯誤，陶醉在自己的新想法和新思路中，卻違背了需求的原始客觀性和真實性原則。 永遠別忘了：需求不是空中樓閣，是實實在在的一磚一瓦。
（2）解剖的快感 幾乎所有搞軟體的人，做需求分析的時候，一上來就會把用戶告訴你的要求，完完整整的作個解剖，切開分成幾個塊，再細分成幾個子塊，然後再條分縷析。可是當用戶迷惑的看著你辛辛苦苦做出來的分析結果問你：我想作一個數據備份的任務，怎麼做？這時，你會發現，需要先後打開三個窗口才能完成這個任務。 永遠別忘了：分解是必需的，但最終的目的是為了更好的組合，而不是為了分解。
（3）角度和思維 經常聽到這樣的抱怨：「用戶怎麼可以提出這樣苛刻的要求呢？」。細細一了解，你會發現，用戶只不過是要求把一個需要兩次點擊的功能，改成只有一次點擊。這樣會導致需要改變需求、改變編碼、甚至重新測試，增加工作量。可是，如果換個角度來想想，這個功能，開發的時候只用了幾次、幾十次，可是用戶每天都要用幾百次甚 至幾千次幾萬次，改動一下就減少了一半的工作量，對他來說，這樣的需求難道會苛刻嗎？ 永遠別忘了：沒有任何需求是不對的，不對的只是你的需求分析。試著站在用戶的思維角度想想，你的需求分析就會更加的貼近用戶，更加的合理。軟體應該是以人為本的。
（4）程序員邏輯 從程序員成長為系統分析員是一個普遍的軌跡，但並不是一個好的程序員就必然能成為一個好的系統分析員。一些程序員的固化邏輯，使得他們在做需求分析的時候往往鑽進了一些牛角裡面。比如說1/0邏輯（或者是說黑白邏輯），認為不是這樣就是那樣，沒有第三種情況。可實際情況往往是，在一定的時候是這樣，其它時候是那樣。又比如窮舉邏輯，喜歡上來就把所有一二三可能的情況列舉出來，然後一個一個分別處理，每個佔用三分之一的時間；可是實際的情況往往是，三分之一的情況佔了99%的比例，其它兩種情況一年都不會遇到一次。實際中還有很多這樣的例子，不一一列舉了。 永遠別忘了：需求分析和程序設計不盡相同，合理、可行是才是重要的。跳出程序設計的圈子，站在系統的角度上來看問題，你的結論會截然不同。