需求分析面試

需求分析面試用時可以刪除你為什么干這一行，而不干其他行當呢你一生中做出的最有意義的決定是什么那個決定為什么有意義那個決定是怎樣做出來的當你要決定是否試做全新的事情時，你對成功的把握性有多大在你的前任工作中，你根據什么標準決定是否做些不屬于你工作任務的任務項目你為什么在事業(yè)的這個階段決定尋找新的機會假設你想要給自己找一位助手，有兩位候選人，你怎樣決定聘用哪一個呢假如另一部門的某位員工經常來打擾你部門員工的工作，你有哪些辦法可以解決這個問題你會選擇哪個辦法為什么綜合分析能力面試題沙漠救生記湯老師，我面試的時候遇到這樣一道題：沙漠中遇難，有四樣東西，帳篷，兩瓶水，繩子，刀。只能選擇其中三樣帶走，你選擇哪三樣，并把每種選擇都給分析一下。請問該怎么選擇答案：，如果用對個人進行測試，通常是要測試求職者的綜合分析能力。題目本身逐一對所有的東西進行分析，最后，匯總自己的分析，選擇最有利于救備時間要遠遠大于正式會面溝通的時間。一般情況下，用戶在和你連續(xù)交談熟悉的準備工作和對具體業(yè)務進行調研前的準備工作。項目整體環(huán)境的目的目的、項目的利益相關方等信息，以便對當前項目的鷹缽情況有準備工作包括:需求調研問題的準備、需求調研模板的設計、需求調研時間安排等2主動積極了解客戶業(yè)務和相關知識有哪些功能。筆者曾在經銷商管理系統調研過程中，由于財務方面的知識有限，使得在對經銷商財務部門識是無邊無際的，在各種項目的調研過程中，肯定會出現由于需求分析者缺乏某一領域的知識而影響需求遇到此類問題時，需求分析者應虛心向用戶請教，同時應及時補充應用領域的知識。最好能夠在調研3對用戶進行正確分類項目管理培訓組織中的用戶在很多方面存在差異，例如:使用系統的頻度和程度、計算機系統知識、所進行的業(yè)務過不同的問題需要詢問不同的人，對于操作細節(jié)的問題，要和實際負責操作的用戶進行溝通，而對于關主、發(fā)貨理貨員、系統操作員。主要業(yè)務執(zhí)行人;系統操作員則是倉庫管理系統的直接操作者。若我們調研的目的是搞清該部門的整體性流程，我們會很自然地選擇倉庫主管作為訪談的對象。項目經理圈子引導用戶說出他們的需求是非常關鍵的。恰當的提問，會使用戶滔滔不絕，充恰當的提問，可能會導致用戶無法回答或敷衍了事地進行回答。提問可分。如:現在你們的送貨單是手工填寫還是電腦打印但過多使用封閉式提問，會導致自己好像在接受審問。開放式提問是請對方對某一事物做進一步的解釋，可使談話以改進的地方開放式提問缺點是容易使談話內容偏離主題。因此在5應實地了解用戶工作流程項目管理論壇實地觀察用戶執(zhí)行業(yè)務任務的過程。了解用戶什么時候獲得什么數據，并怎樣使用這些數據，業(yè)務處經驗證明，與人們面談關于他們如何完成任務時會有許多限制和不準確性，而這是任務觀察可以直接一個主觀的領域，很大程度上依賴于需求分析者的經驗。通過觀察發(fā)現:某些客戶要求送貨單中的商品價格為含稅價格，而有些客戶則要求送貨單上的商品價格可行性這樣的事也不干。”柳傳志為聯想集團的決策確立了上述準則，同時也為可以行性分析指明了重點。可行性分析主要是針需求決定是做還是不做。一般可行性主要考慮兩個方面的因素:技術和人。技術方面主要是分析在給定的時間段內是否可實現所需的功能并滿足產品的質量要求等相關指標。項目的后續(xù)工作帶來很大的風險。因此應盡量避免在需求分析中包含技術實施上有難度的功能。如在筆者曾經負責的一個項目中，用戶要求新的管理系統應實現和用友、金蝶等管理系統的數據接口，以方便這些系的管理系統。統的數據接口，將為新系統的成功實施帶來很大的風險。因為熟悉這些系也需要時間，而且用友、金蝶等這些系統存在多個不同的版本。因此與外否具有相應的素質和能力。在實際項目中，筆者曾對快速消費品行業(yè)經了分析。首先，批次管理將涉及到所有產品的出入庫操作，并存在一個產品有管理對操作人員的能力和素質要求比較高。點決定了產品的出入庫操作極為頻繁，因此，操作人員的工作強度比較性定義為低。定需求的優(yōu)先級別沖突、安排階段性交付并做出必要的取舍。建立每個需求的重要性有助于規(guī)劃軟件的構造，以最少的費用并且交付日期不可改變，一些低優(yōu)先級的需求就需要推遲到后續(xù)版本中進行實現或直接取消。當眾多用戶因期望不同而就某些需求優(yōu)先級的設定難以達成一致意見時，需求分析者可指出每一需求8正確理解需求分析文檔確認需求分析是一項繁瑣枯燥的工作，需要和用戶不斷的商討、確認和反復。但大部分用戶并不只做這項用庫存十分關注，因此可用庫存的優(yōu)先級被定義為:高優(yōu)先級。仔細考慮或回答你的問題。這很容易使你錯誤地認為用戶已經真正地了解并認可了你的分析文檔。確認工作并未得到用戶的充分重視。“他們要求我在需求文檔上簽名，于是我就簽了，否則開發(fā)人員不開對于需要用戶確認的需求分析文檔，最好在用戶確認前，就文檔內容對用戶進行一定的講解，以確保對文檔中的內容存在修改意見，則修改后再與用戶進行確認，直至用戶完全認可文檔中的內容為止。、準確的理解，需求分析所包含的內容通常大于項目范圍所包含的內容。因些功能的討論并不意味著即將在系統中實現它。應使用戶明白對需求分析文檔的句號，并有助于形成一個持續(xù)良好的用戶與需9結語將知識從一個地方傳送到另一個地方并不是一件簡單的事情，而且原始的需求通常是以不完整的形式認等方面對需求分析中應注意的主要問題進行了研究分析。同時需求分析工作者也應在日常工作中加強學習，不斷總結，使自己的需求分析能力得到不斷的提業(yè)務需求訪談中需要注意的重要法則(轉)功能和局限性。系統需求肯定不是生來求分析員的腦海中，那么業(yè)務需要又在哪里呢它它存在與企業(yè)實踐運作體系中?；蛘哒f它們并不一定于通過包括業(yè)務需求訪談在內的各種方法使系統知識遷移過程,通過業(yè)務需求訪談需求分析員最終完,是做好了“準備”,假設王五是某家貿易公工作職責是對公司已有的訂單管理系統進行改進,為此結構圖,我們得知業(yè)務部門通常地認識,我們會發(fā)現所謂主管，即總是對搞清業(yè)務部門接著,我們要確定訪談時間。主管一般都是比較忙的,他不會時時都在等你。因此,現在,我們只剩下一個訪談的內容需要準備了。我們可以擬定一些具體問題，這很有必要?！胺彩骂A則立”,這是先賢站在哲學的高度對我們的啟示。由于篇幅所限就不在此一一列明,可以在相關資料上找到很般而言有兩種方法。第一,選擇工作角色，比如從業(yè)務主線入手，召集這條線上的角色。很顯然，前入見點不見主線的陷阱。也就是說這個角色的主主線，你必須心知肚明。否則，訪談活動就變成的業(yè)務訪談者是訪談游戲的規(guī)則制定者，他必須錯誤。假設他也已完成了第一次對業(yè)務主管的訪談工作,用應用聯席會議的方式做為業(yè)務訪談的一種有效這條業(yè)務主線上的每個角色比如,王五所在的貿易的訂單業(yè)務主線一般流程為：接訂單->購->入庫->收款。那么，他應該做出相應的訪談路線圖。這樣,他訪談過程中我們要保持理性，自始至終以我為主,牢牢掌握訪談的主動權。因為優(yōu)秀的需求分析員應該是有理性的人,我們不能因為被訪談對象的情緒便打亂了計劃很可能損害到他的潛在利益,他會變得情緒化,會找些借口,比經常以“這是某某習慣”作答，那么你必須意識到這不是真實的答案，并且可以這樣談下去才能談得更深入。一個好的分析訪談人員能夠從表面挖掘出背后的夠引導對方,達到既定的訪談目標。4、訪談過程中要善于尋求異常和錯誤情況。談對象的話總是對的，他經常會說“應該”或者“可能”是這樣只有這樣你才能挖掘到更多的業(yè)務細節(jié)。多問問“如果條件沒，在于能否更深入地探討業(yè)務需求問唯唯諾諾的人,如果用戶說什么你都只會說“是”,則意味著訪談應戶說什么,你首先要分析,然后置疑,從所在。其實也需要耐心,我們覺得可以向優(yōu)秀的5、業(yè)務需求訪談要搞清“4W1H”。WH”。6、業(yè)務需求訪談要深入調查細節(jié)。現代系統分析員重要責任是調查系統需求細節(jié)，而細節(jié)不會憑空出現的，而是，也要知道“如果不這樣那會是怎樣”。做需求下結論前要事先調查和掌握好所有正反兩個方向的商業(yè)細節(jié)，如此以來需求分析結論和解決方案才有現實可行性。這里有一個很好的實例，一般而言，物料編碼都是系統自動提供規(guī)則實現的，而某貿易公司的訂單系統偏偏不提供系統自編碼。面對此問題，我們必須搞清兩個問題：其一是該企業(yè)的編碼規(guī)則，其二是該企業(yè)的編碼規(guī)則牽涉到的前置條件和后置條件。知其然也知其。所以說僅僅滿足于看到了業(yè)務現象是遠遠不夠的,我們更要搞清楚現象背后的原因,我們還要有能力能夠提供諸多方案以解釋和改造目層層發(fā)問法也是深入調查而經常采用到的方法。8、時刻要記得的四個字"膽大心細"一旦本次訪談結束，有必要回去做一番總結，不僅要總結出提煉的需求結論，更重要的是要回憶還原出整個訪談過程，以便事后仔細研摩得失，這對提高業(yè)盤過程也是一絲不茍，好的需求分析員亦然。仁。仁圖，并的措施是事先編制一個問卷調查之類的文免這種情況發(fā)生。e都要讓客戶明白和理解，客戶在理解之旦出現問題不致出現雙方互相推托責任糾纏不清的f)需求報告一定要經過一個有技術人員和業(yè)務人員參加的評審，要充分發(fā)揮團隊的力量，重視每個人的才智，一個模塊一個功能的逐一的過，讓大家來g能夠在軟件開發(fā)中，大家都會遇到過這樣的問題：客戶的一個新想法，畢竟功能性需求不實現的的變更,而且許多是看起來無關痛癢(1)什么是非功能性需求戶需求、功能需求、行業(yè)隱含需客戶對系統、產品高層次須實現的軟件功能。所謂而必須具有除功能需求以護性、易用性和對技術和面、操作方便等一系列要(2)非功能性需求變更的特點求的特點。首大，但是實際的。原因是非功能那樣，可以通過結構化和時候，我們經常采用軟件美觀大方等較模糊的描述詞類描述詞語都是脫離了軟的描述，因此很難體現到軟件為什么非功能性需求變更會頻繁發(fā)生了呢通?？蛻魰r，他可能就(1)非功能性需求容易產生理解分歧發(fā)人員對非功能性需求的理解呈現"一般跟分析員的知識、背。即使通過反是永遠不夠清還只存在于大他所需要的軟件在當前的工作所需，或者是求分析人員提出需求的時表達的，這樣的表達結果斷進展，系統開始展現雛時候，客戶就會對系統的就有可能提出需求變更要為的因素?？傊麄兞?2)沒有明確的需求變更管理流程更不要一味的抱怨，也不和控制需求變更。但令執(zhí)行常常只停留在口無論是當事人還是開和開發(fā)質量。變更都要立刻修改，更需要修改和什么時或者規(guī)劃一下修改(3)沒有讓客戶知道需求變更的代價根本原因。變更都是有代了解需求變更的后果。如發(fā)人員的辛苦就會難以體更認識不足，認為他此，客戶對需求變更往往，隨個人喜好隨意變更需求。所是要讓他們清楚需求隨意代價太大，那么開發(fā)人員但仍要記錄變更，待下一如何有效控制非功能性需求的變更影響面是很廣的。因容小視的事情。(1)建立明確的非功能性需求基線性需求基線是一件重要的圍就含糊不清，就容易被更。如果非功能性需求基么后期客戶提出的非功能需求基線的時候千萬不能讓客戶養(yǎng)成經常變更的習(2)建立需求變更管理流程的不是控制變更