如何將用戶需求轉化為產品需求

Ⅰ 如何進行用戶需求分析

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.需求文檔
需求開發的最終成果是:客戶和開發小組對將要開發的產品達成一致協議.協議綜合了業務需求、用戶需求和軟體功能需求.就像我們早先所看到的,項目視圖和范圍文檔包含了業務需求,而使用實例文檔則包含了用戶需求.你必須編寫從使用實例派生出的功能需求文檔,還要編寫產品的非功能需求文檔,包括質量屬性和外部介面需求.只有以結構化和可讀性方式編寫這些文檔,並由項目的風險承擔者評審通過後,各方面人員才能確信他們所贊同的需求是可靠的.
你可以使用以下三種方法編寫軟體需求規格說明:
用好的結構化和自然語言編寫文本型文檔.
建立圖形化模型,這些模型可以描繪轉換過程、系統狀態和它們之間的變化、數據關系、邏輯流或對象類和它們的關系.
編寫形式化規格說明,這可以通過使用數學上精確的形式化邏輯語言來定義需求.
由於形式化規格說明具有很強的嚴密性和精確度,因此,所使用的形式化語言只有極少數軟體開發人員才熟悉,更不用說客戶了.雖然結構化的自然語言具有許多缺點,但在大多數軟體工程中,它仍是編寫需求文檔最現實的方法.包含了功能和非功能需求的基於文本的軟體需求規格說明已經為大多數項目所接受.圖形化分析模型通過提供另一種需求視圖,增強了軟體需求規格說明.

Ⅱ 用戶運營如何做好用戶需求的建立

首先從馬斯洛需求理論中談談用戶的需求，馬斯洛需要層次主要包含：生理需求、安全需求、愛與歸屬的需求、尊重的需求、自我實現的需求。總結為用戶需求為：基礎需求、期望需求、興奮需求。對於基礎需求，主要是生理和安全的需求；期望需求主要是愛與歸屬的需求和尊重的需求、興奮需求主要是自我實現的需求。

我先從大家親身經歷過的自己被用戶的階段給大家講一下：從qq等級升級之後會有星星、月亮、太陽的現實，我想大家都經歷過為了升級拚命掛號，買鑽的年代。而網路會有一些我們在網路各個平台的網路積分，可以去網路積分商城換取各種網路定製的周邊產品，甚至還有京東消費卡等產品，最後再給大家說說天貓的芝麻信用，現在的芝麻信用已經對我們的生活無孔不入了，從租房、貸款、辦信用卡等各種與錢掛鉤的場景，都會用到你的芝麻信用。這些用戶等級的增長都會給予大家一些心理、生理、生活上的改變，也會促使用戶來進行活躍。

再說一下我運營社群：運營社，運營社的成員分級大概分為新入群成員—經過篩選制留下來的成員—志願工作者/內容輸出者—管理人員。大概是這樣的一種等級，對於心入群的成員，也是通過篩選之後加入運營社的，這些人剛進群處於學習和了解的階段，大概一個月的時間，運營社會根據大家在社群內的活躍度來剔除一部分不活躍的用戶，這樣一期一期篩選留下來的用戶基本上已經是對運營社忠誠度和活躍度較高的用戶了，而這些忠誠度和活躍度較高的用戶後來通過每次的話題和分享的活動以及各個志願者組的招募，運營社就出現了一部分大家耳熟能詳的核心成員：萬能珍寶、廣告達人包子、aso大神子木以及所有分享者和項目支持者，都是運營社的核心成員，最後的管理人員就是這些每個組別的負責人，例如時雨姐負責的視覺設計組，主要對運營社的活動海報、周邊產品的設計，我這邊負責運營社的話題組，主要是對嘉賓分享的邀請，話題主題的制定，以及這些內容輸出的整理和加工。而對於用戶分級的不一樣那麼所謂的需求也是不一樣的，除了第一批進入運營社的小夥伴們是憑運氣，考報名的順序來進群的，後續的每一次招募都是有門檻，因為當你讓用戶的操作成本增加，用戶就會更加珍惜，所以運營社一直有篩選機制，來時刻提醒所有用戶時刻保持活躍，然後運營社會給予更加活躍的每個城市小分隊分發運營社的徽章、還有給予話題討論獲獎者以及分享嘉賓郵寄一些走心的小禮物，一些特別定製的運營社的周邊小產品，這些也都是我這邊主要去製作，每一次的小禮物我都會親自去寫一封走心的明信片，給予每一個陪運營社走過的社員們一個暖心的回憶，賢哥這邊也會不定期給予一些核心成員用心的挑選大家的工作必備物品，也會寫上一些肺腑之言來表達與大家在運營社建立的深厚革命友誼。利用這些等級用戶的維護，來營造一批核心用戶會使運營社的用戶關系更加穩固。

這些給予不一樣等級的用戶的情感運營是用戶運營最需要注意的，每一個細節上的小動作最能體驗出你對用戶是否走心，現在互聯網的發達和滿目玲琅的app的誕生，你只有通過觸達用戶內心最需要的需求，你才能緊緊的抓住用戶，並促使用戶長期活躍下去。

以上觀點也僅僅代表個人的建議，可能不太准確。希望大家可以添加個人微信私下交流：zhen826696371（備註：網路派）

Ⅲ 需求是如何變成產品原型的

說其曖昧，是因為在很多互聯網公司裡面，這兩個環節所做的事情是有重合的，這就意味著，他們或許也是整個流程中合作最緊密的兩個環節。相對比之下，產品經理更關注的是產品的內部邏輯、操作流程、策略等；而交互設計師更關注的是產品的易用性、流暢度和操作感受。總的來看，似乎可以認為，產品經理是從一個更加宏觀的角度去設計產品，而交互設計師，則是從更多的細節出發，去提升用戶體驗。這兩種不同的視角決定了只有產品經理和交互設計師密切配合，深入溝通，才能夠最高效最合理的將產品策略轉化為產品原型，從而為流水線的後面環節提供精確的參考資料。下面以人人網廣告平台的一些產品和交互細節為例，使用對話的形式來分享一下我個人在做交互設計過程中的一些體會和想法。入門級文章，高手請繞行。在廣告平台其中一個投放系統中，有一個產品需求，是要根據廣告受眾所在的地區做廣告的定向投放。也就是說，可以控制廣告只展示給固定地域的受眾。這就意味著，需要設計一個「區域選擇器」，供用戶選擇區域。產品經理的原始需求是這樣的：產品經理：「我們這次的投放系統需要設計一個區域選擇器，就是讓用戶選擇廣告定向投放的區域的。可以精確到城市，可以多選。另外，『區域』作為一個投放廣告的限制條件，如果用戶沒有選擇任何選項，那就代表用戶忽略該條件，則該廣告會面向全國投放。」交互設計師：「哦。」產品經理：「嗯，我能夠想到的這個東西的原型，可以提供兩個下拉框，讓用戶分別選擇省和城市。當用戶在第一個下拉框裡面選定了省以後，第二個下拉框中會顯示該省下面的地級市。我做了一個簡單的框圖，大家看一下。」產品經理：「大概就是這個樣子。每選定一個城市，點擊後面的添加按鈕，可以將該城市添加到下面的列表中。同時，如果點擊已經添加的城市名稱後面的「刪除」鏈接，則會將該城市從已選列表抹去。」交互設計師：「等一下，我有一個問題。按照產品的策略，如果用戶一個城市都不選，那麼就會默認投放全國。但是這個概念很難表達給用戶，比如說，如果在「區域選擇器」旁邊放提示，估計沒有多少人會注意到。」產品經理：「一個都沒選，就是等於忽略條件啊。因為這些都是限制條件。」 交互設計師：「問題是用戶很難意識到是這樣。在中國人的觀念中，大家都是覺得，選上的，是我要的。但是大家沒有「不選就等於全要」這種思維習慣。」交互設計師：「我覺得可以這樣。我們在現在的「區域選擇器」上面放兩個單選按鈕。一個叫「全國」，另一個叫做「指定」。打開頁面時，默認選中「全國」項，並隱藏「區域選擇器」。只有用戶選擇「指定」項時，區域選擇器才會出現。這樣表達就很明確了，你不是「全國」就是「指定」。」產品經理：「哦~聽起來不錯。試試。」於是得到了下面這個版本的原型圖：交互設計師：「嗯，我想，現在這個版本已經基本上從界面的層面解決了全國投放的選項問題，我想，用戶應該不會因為不知道怎麼選而卡在這里了。」交互設計師：「我看下一步，需要對一些關鍵的元素做一定的視覺設計，以便於引導用戶操作。比如「添加」按鈕，應該更明顯些。我覺得可以請UI設計師出一個簡單版本的UI了。」產品經理：「稍等一下，我看咱們還是把細節再討論清楚一些再去找UI吧。比如，字的顏色啊什麼的都沒定呢。而且，我覺得選中的區域中，每個城市名稱後面都跟著一個刪除鏈接，很奇怪。」交互設計師：「嗯。的確。我的想法是這樣，字的顏色，就用黑色吧，或者是深一些的灰色也行。雖然從視覺設計的角度來看，視覺設計師覺得稍淺一些的灰色比較養眼，可能黑色太『搶』。但是咱們的系統畢竟是給人用的，灰色的話，可能會讓人誤認為這些選項是不可操作的。你看如何？」 產品經理：「同意。」 交互設計師：「關於已經選中的區域列表。我看可以把「刪除」鏈接換成×，事實上，用戶對於×這種符號比漢字更敏感。你看，大家不論是用Windows還是 Mac，關閉窗口的時候都是×，早就習慣了。另外，為了讓所選定的城市名稱看起來是一個整體，並且跟其他城市名稱區分開。我看，可以給每一個城市加上背景色，每個城市一個色塊，這樣也一目瞭然。」 產品經理：「顏色呢？」交互設計師：「藍色吧，人人網都是藍色的風格。」產品經理：「ok」於是，配合UI設計師，得到了下面的界面：產品經理：「我看現在這個地方已經基本上成型了。咱們也已經討論很很久了。該問問別人的意見。」———-時間分割線———-產品經理：「Hi~ 各位。我收集了一些內部測試的意見。有用戶提出，搞不太清楚兩個下拉菜單和「添加」按鈕之間的關系。」交互設計師：「什麼意思？」產品經理：「就是說，有人意識不到選完了省，選完了城市以後，還得點「添加」。他們覺得，選完了就完事了。」 交互設計師：「暈。」交互設計師：「可能是已選列表框在空著的時候長得太秀氣了，大家沒意識到它是用來裝東西的。」交互設計師：「好吧，我有兩個方案。1、把「添加」按鈕上面加一個向下的箭頭。指向已選列表框。2、在已選列表空著的時候，添加一條提示語，來提示用戶他並沒有完成區域選擇操作。」產品經理：「提示語那個，你的意思是說，當用戶添加了城市以後，會自動消失是吧？」交互設計師：「是的。」產品經理：「我覺得加提示吧。感覺放箭頭有點兒傻。」交互設計師：「嗯，而且，可能放了箭頭以後，用戶依然不知所雲。」產品經理：「那提示語怎麼說呢？您尚未添加任何區域，請選定城市後，點擊上面的「添加」按鈕，該城市會被添加到…」交互設計師：「停！太長了，大部分人不會認真看完的。」產品經理：「的確…」交互設計師：「我看就一句話就可以。寫『您尚未添加任何區域。』」交互設計師：「你看。下拉列表後面的按鈕叫「添加」。提示中又明確的傳達出了尚未「添加」的狀態。這樣既說明了這個框框是用來放東西的，又可以告訴用戶，這個東西是可以選多個的。因為「添加」的概念就是一個一個往裡面放。如果只能放一個，那應該叫「選擇」。」產品經理：「頂。」 交互設計師：「而且，我覺得這個控制項最初的原型你設計的不錯。嗯，用戶只要成功的進行一次操作，以後就可以非常高效的進行操作了。這個東西的學習成本和認知成本都比較低。」產品經理：「oh,yeah~」那麼，現在的UI是這樣的：產品經理：「哎，對了。話說，我最開始的策略是，用戶如果不選，相當於全選，要全國投放的。你說如果用戶選了「指定」，但是並沒有添加具體的城市，直接提交表單，怎麼辦？系統是應該直接把用戶的廣告設置成全國投放，還是報錯，阻止用戶繼續？」交互設計師：「我看啊，報錯吧。因為現在「全國」和「指定」這兩項，已經明確的把整體和局部給分開了。我覺得你那個策略沒必要再應用了，因為現在這種已經達到了你最初的目的，而且還好理解。再有就是，咱們的平台是涉及到錢的，是要讓用戶花錢的，如果讓用戶不明不白花了冤枉錢，本來想投北京的投了全國，那我們會被用戶罵死的。雖然感覺上報錯會讓用戶有挫敗感，但是在這種細節上，還是用戶利益應該放在第一位，用戶體驗，可以稍微往後放一放了。」產品經理：「好吧。」交互設計師：「呵呵，你看，這個故事告訴我們，不能每件事情都聽產品的。產品提的只是需求，但是如何實現需求，還是得從多個角度來討論。」產品經理：「好吧。那麼，技術兄弟們，下面的工作就拜託你們了。」個人觀點：1、產品經理和交互設計師需要時刻密切配合，深入溝通。2、有時候，產品策略和用戶體驗會發生沖突，這時應該從多種角度去考慮和探討最終解決方案，不應該有誰一定比誰重要的說法。3、優秀的產品經理，相當於半個交互。同樣，優秀的交互設計師，相當於半個產品。二者雖然職位不同，但是應該在一定程度上考慮對方的工作內容。4、產品提出的只是策略和需求，並不是一定要按照產品人員所描述的細節去設計具體的產品細節。交互設計師以及團隊中其他所有成員，有義務有權利對產品需求提出自己的見解和更好的設計方案。有不同意見可以討論，但是最終決定權，應該依然屬於產品經理。5、產品經理之所以叫經理，是因為，他們除了設計產品，還需要時刻把握整個流程。比如，當細節沒討論清楚的時候，不要去找UI做設計。更多列印 | 類別：信息和交互 | 源地址

Ⅳ 如何將用戶需求轉換為產品功能特性需求

客戶需求、市場需求、產品需求、設計需求、業務需求、內部需求、外部需求、特性、規格、功能需求 --- 需求工程的基本術語說明
需求分析和管理對產品開發成敗至關重要，這一點大家都非常清楚，正因如此，相關的管理體系都對需求進行詳細定義和描述，不同體系不同的定義，導致需求術語混亂，筆者結合10多年的需求工程經驗，詳細分析不同術語區別如下：
客戶/用戶需求：基於客戶認知，更多是客戶的直觀要求，體現了用戶個體的訴求，往往是理想狀態，例如：「需要一個功能強大的手機，同時價格要相對便宜」、「我想要的汽車要外觀時尚，性能卓越。」，用戶需求往往無法直接開發實現，同時用戶對自己的需求往往也是模糊的，實際開發中就需要藉助類似原型（demo）、參照物等方法，使客戶需求具體化。
市場需求：很多人理解的市場需求就是客戶需求，個人認為市場需求和客戶需求還是有很大差別的，客戶需求更多描述客戶的訴求，而市場需求不但要描述目標客戶的訴求，更需要描述競爭對手針對此需求的反應，例如，競爭對手是如何實現的？如果我們不實現被競爭對手替代的可能性有多大？如果實現我們是否如何做才能超越競爭對手？所以可以理解市場需求是經過產品經理分析後的客戶需求，體現了客戶和競爭的情況。
產品需求：針對產品需求，個人認為IPD的定義是合理的，IPD把產品需求定義為「產品包需求」，之所以叫「產品包需求」是因為我們給客戶交付的不是孤立的產品，而是一個解決方案，同時客戶是否購買一個產品不僅僅看產品本身，還會關注品牌、服務、渠道等因素，產品需求要廣而不深，需要把產品相關的方方面面都考慮清楚，而不是要針對一點定義的多麼精細，需要更多從客戶購買決定的全過程來思考，所以一般就會涉及：價格、渠道、包裝、性能、易用性、保證、服務、社會接受程度、品牌等；另根據需求理論一般產品需求會在25~99條之間，實際研發項目時，產品需求會直接讓領導層來判斷該產品的價值、競爭地位等，最終判斷該產品是否值得繼續做下去。
設計需求：設計需求故名詞意就是 設計 + 需求，經常遇到研發人員說設計與需求有時候很難區分開來，其實到了設計需求階段，設計和需求已經融合在一起了，同時也正是融合在一起，需求才能落實為設計，設計也才能承載需求;對比產品需求，設計需求定義時一定要在深度上下功夫，細化到能夠通過設計來實現，並且能落實到具體的物理模塊來承載。那麼設計需求怎麼來的呢？根據需求工程理論設計需求是通過產品需求分解而來，業界常用HD（層次分析法）來分解產品需求，關鍵問題是大家一定要掌握，一個產品需求需要從哪些方面來分解，從而保證分解的完整性，根據IPD需求工程定義，一個產品需求通常需要從如下：功能、環境、性能、強健性（魯棒性）、可靠性、可維護性、可用性、安全性、重量、電源、尺寸大小、可運輸性/可移動性、靈活性等方面進行分解，當然並不是每個產品需求都要一定分解為這些方面，分解後就形成了與此產品需求相對應的設計需求清單。
規格：我們經常講：產品需求規格說明書，說明需求和規格本來就是一體化的，規格就是需求的具體說明，例如：「OA要支持IE瀏覽器」 是需求，那麼如果具體定義：「需要具體支持Ie6、Ie7、Ie8」，那麼就叫規格；「聲音要達到120分貝~190分貝」，這本身就需求 + 規格。
特性：軟體行業和軍工標准中，經常提到特性這個詞語，例如國軍標中定義：「特性 --- 識別和區分各類產品或服務的屬性，這種屬性包含物理、化學、功能或其他可識別的性質。」；所以模糊來講特性就是產品需求，如果更精確來講，特性是產品需求中的與其他產品有明顯差異的個性化需求，通常我們把產品需求劃分為3類：BSA（Basic、Satisfied、Attractive），分別為基本需求、最好滿足的需求、更具有吸引力的需求；所以可以理解特性為：A的需求。
測試需求：什麼叫測試需求，很多人認為測試需求是基於對產品需求的分析，測試人員提煉出來的需要重點測試的點，故名詞意：測試需求。不管別人怎麼認為，本人認為測試需求是本身是個變態和錯誤的做法，只所以有測試需求，原因是實際研發中產品需求、設計需求定義不清晰，開發人員就糊里糊塗地進行設計和開發了，但測試人員無法基於需求提煉出來測試點，迫於無奈，不得不給需求定義人員擦屁股，將需求細化到能夠提煉到測試點的級別。正規做法應該如此：需求定義人員詳細定義產品需求和設計需求，而同時測試設計人員直接針對此需求分析該需求如何測試，重點測試哪些內容，所以測試需求，本身應該叫：需求的可測試性分析，其實是需求的屬性之一，這樣做的好處是：可以直接判斷需求定義是否具體，是否可驗證，凡是不能驗證的需求都是錯誤的需求；後續測試用例開發人員針對需求的可測試性分析，直接編寫對應的測試用例。
內部需求：實際產品需求定義時，我們更關注的是外部客戶的需求，因為外部客戶直接給我們錢，但其實產品也有內部客戶，也需要關注內部客戶的需求，誰是內部客戶呢？例如製造、客服就是內部客戶，如果設計時，沒有考慮到製造的要求，直接導致製造效率低下、良品率低，最終影響產品的市場表現；製造部門的需求、客服部門的需求，也需要在產品開發前期就識別，成為產品需求和設計需求的一部分，並在設計開發中實現。
外部需求：對照內部需求，外部需求是客戶、渠道、合作商、用戶等，外部關聯單位的需求，具體分析時就需要通過銷售過程分析，詳細分析產品從生產線下來，到最終客戶手裡需要經過哪些環節，而這些所有環節的需求統稱外部需求，所有外部需求都是我們需要重點關注的，一個環節不滿足，產品可能就到不了最終客戶手裡，就無法轉化為實實在在的商業利益。
業務需求：針對業務需求業界缺少標准一致清晰的定義，個人認為業務需求更多是從客戶的業務發展、財務、戰略出發，更多體現了客戶高層的要求，涉及產品整體宏觀上的要求；例如針對ERP，「庫存周轉率提高50%」，針對電信設備，「能夠無縫升級到下一代網路，從而節約投資成本」，針對銀行系統，「提高客戶的資金周轉效率30%」；針對網路游戲，「使單個用戶的費用貢獻提高50%」，等等，這些業務需求更多體現客戶經營的需要，具體業務需求需要通過產品需求、設計需求去細化和實現；例如ERP，為了是實現「庫存周轉率提高50%」，就要求ERP系統實現：相應的報表統計功能、告警通知能力、訂單預期功能等，這些可以成為產品需求或設計需求。
功能需求：功能需求其實是設計需求的一個類別，為什麼這么有名呢？核心原因還是軟體行業鼓吹、宣傳的原因，因為軟體行業基本都是功能需求，就是第一步干什麼，下一步做什麼，然後再做什麼的場景描述，所以功能需求就這樣出名了，功能需求與其他設計需求定義時，核心不同點是，功能需求需要詳細定義場景描述，其中包含正常場景、異常場景，業界通用定義方法是Usecase法。
-----------
（作者： Tiger.dong

Ⅳ 如何將用戶需求轉化為產品功能特性需求

客戶需求、市場需求、產品需求、設計需求、業務需求、內部需求、外部需求、特性、規格、功能需求 --- 需求工程的基本術語說明
需求分析和管理對產品開發成敗至關重要，這一點大家都非常清楚，正因如此，相關的管理體系都對需求進行詳細定義和描述，不同體系不同的定義，導致需求術語混亂，筆者結合10多年的需求工程經驗，詳細分析不同術語區別如下：
客戶/用戶需求：基於客戶認知，更多是客戶的直觀要求，體現了用戶個體的訴求，往往是理想狀態，例如：「需要一個功能強大的手機，同時價格要相對便宜」、「我想要的汽車要外觀時尚，性能卓越。」，用戶需求往往無法直接開發實現，同時用戶對自己的需求往往也是模糊的，實際開發中就需要藉助類似原型（demo）、參照物等方法，使客戶需求具體化。
市場需求：很多人理解的市場需求就是客戶需求，個人認為市場需求和客戶需求還是有很大差別的，客戶需求更多描述客戶的訴求，而市場需求不但要描述目標客戶的訴求，更需要描述競爭對手針對此需求的反應，例如，競爭對手是如何實現的？如果我們不實現被競爭對手替代的可能性有多大？如果實現我們是否如何做才能超越競爭對手？所以可以理解市場需求是經過產品經理分析後的客戶需求，體現了客戶和競爭的情況。
產品需求：針對產品需求，個人認為IPD的定義是合理的，IPD把產品需求定義為「產品包需求」，之所以叫「產品包需求」是因為我們給客戶交付的不是孤立的產品，而是一個解決方案，同時客戶是否購買一個產品不僅僅看產品本身，還會關注品牌、服務、渠道等因素，產品需求要廣而不深，需要把產品相關的方方面面都考慮清楚，而不是要針對一點定義的多麼精細，需要更多從客戶購買決定的全過程來思考，所以一般就會涉及：價格、渠道、包裝、性能、易用性、保證、服務、社會接受程度、品牌等；另根據需求理論一般產品需求會在25~99條之間，實際研發項目時，產品需求會直接讓領導層來判斷該產品的價值、競爭地位等，最終判斷該產品是否值得繼續做下去。
設計需求：設計需求故名詞意就是 設計 + 需求，經常遇到研發人員說設計與需求有時候很難區分開來，其實到了設計需求階段，設計和需求已經融合在一起了，同時也正是融合在一起，需求才能落實為設計，設計也才能承載需求;對比產品需求，設計需求定義時一定要在深度上下功夫，細化到能夠通過設計來實現，並且能落實到具體的物理模塊來承載。那麼設計需求怎麼來的呢？根據需求工程理論設計需求是通過產品需求分解而來，業界常用HD（層次分析法）來分解產品需求，關鍵問題是大家一定要掌握，一個產品需求需要從哪些方面來分解，從而保證分解的完整性，根據IPD需求工程定義，一個產品需求通常需要從如下：功能、環境、性能、強健性（魯棒性）、可靠性、可維護性、可用性、安全性、重量、電源、尺寸大小、可運輸性/可移動性、靈活性等方面進行分解，當然並不是每個產品需求都要一定分解為這些方面，分解後就形成了與此產品需求相對應的設計需求清單。
規格：我們經常講：產品需求規格說明書，說明需求和規格本來就是一體化的，規格就是需求的具體說明，例如：「OA要支持IE瀏覽器」 是需求，那麼如果具體定義：「需要具體支持Ie6、Ie7、Ie8」，那麼就叫規格；「聲音要達到120分貝~190分貝」，這本身就需求 + 規格。
特性：軟體行業和軍工標准中，經常提到特性這個詞語，例如國軍標中定義：「特性 --- 識別和區分各類產品或服務的屬性，這種屬性包含物理、化學、功能或其他可識別的性質。」；所以模糊來講特性就是產品需求，如果更精確來講，特性是產品需求中的與其他產品有明顯差異的個性化需求，通常我們把產品需求劃分為3類：BSA（Basic、Satisfied、Attractive），分別為基本需求、最好滿足的需求、更具有吸引力的需求；所以可以理解特性為：A的需求。
測試需求：什麼叫測試需求，很多人認為測試需求是基於對產品需求的分析，測試人員提煉出來的需要重點測試的點，故名詞意：測試需求。不管別人怎麼認為，本人認為測試需求是本身是個變態和錯誤的做法，只所以有測試需求，原因是實際研發中產品需求、設計需求定義不清晰，開發人員就糊里糊塗地進行設計和開發了，但測試人員無法基於需求提煉出來測試點，迫於無奈，不得不給需求定義人員擦屁股，將需求細化到能夠提煉到測試點的級別。正規做法應該如此：需求定義人員詳細定義產品需求和設計需求，而同時測試設計人員直接針對此需求分析該需求如何測試，重點測試哪些內容，所以測試需求，本身應該叫：需求的可測試性分析，其實是需求的屬性之一，這樣做的好處是：可以直接判斷需求定義是否具體，是否可驗證，凡是不能驗證的需求都是錯誤的需求；後續測試用例開發人員針對需求的可測試性分析，直接編寫對應的測試用例。
內部需求：實際產品需求定義時，我們更關注的是外部客戶的需求，因為外部客戶直接給我們錢，但其實產品也有內部客戶，也需要關注內部客戶的需求，誰是內部客戶呢？例如製造、客服就是內部客戶，如果設計時，沒有考慮到製造的要求，直接導致製造效率低下、良品率低，最終影響產品的市場表現；製造部門的需求、客服部門的需求，也需要在產品開發前期就識別，成為產品需求和設計需求的一部分，並在設計開發中實現。
外部需求：對照內部需求，外部需求是客戶、渠道、合作商、用戶等，外部關聯單位的需求，具體分析時就需要通過銷售過程分析，詳細分析產品從生產線下來，到最終客戶手裡需要經過哪些環節，而這些所有環節的需求統稱外部需求，所有外部需求都是我們需要重點關注的，一個環節不滿足，產品可能就到不了最終客戶手裡，就無法轉化為實實在在的商業利益。
業務需求：針對業務需求業界缺少標准一致清晰的定義，個人認為業務需求更多是從客戶的業務發展、財務、戰略出發，更多體現了客戶高層的要求，涉及產品整體宏觀上的要求；例如針對ERP，「庫存周轉率提高50%」，針對電信設備，「能夠無縫升級到下一代網路，從而節約投資成本」，針對銀行系統，「提高客戶的資金周轉效率30%」；針對網路游戲，「使單個用戶的費用貢獻提高50%」，等等

Ⅵ 對交互設計的看法，怎樣把用戶需求轉化為實際產品

1、分析階段
需求分析、用戶場景模擬、競品分析（聆聽用戶心聲）。
需求分析：對於一個產品來說，必然有對用戶需求的分析內容，更多的是從MRD與PRD獲得，或者從產品需求評審會議上得到需求分析的內容，當然可以直接與產品經理交流獲得相關產品需求。如果說設計原則是所有設計的出發點的話，那麼用戶需求就是本次設計的出發點。
用戶場景模擬：好的設計建立在對用戶深刻了解之上。因此用戶使用場景分析就很重要，了解產品的現有交互以及用戶使用產品習慣等，但是設計人員在分析的時候一定要站在用戶角度思考：如果我是用戶，這里我會需要什麼。
競品分析（聆聽用戶心聲）：競爭產品能夠上市並且被UI設計者知道，必然有其長處。這就是所謂三人行必有我師的意思。每個設計者的思維都有局限性，看到別人的設計會有觸類旁通的好處。當市場上存在競品時，去聽聽用戶的評論，哪怕是罵聲都好，別沉迷於自己的設計中，讓真正的用戶說話。
輸入物：MRD、PRD、市場調查報告、競品分析文檔（或其一或全部）
輸出物：設計初稿（或許只是幾個簡單的界面）
2、設計階段
設計方法採用面向場景、面向事件驅動和面向對象的設計方法。面向場景是針對該產品使用場所等模擬，模擬用戶在多種情況下產品使用的模擬。面向事件驅動則是對產品響應與觸發事件的設計，一個提示框，一個提交按鈕……這類都是對事件驅動的設計。面向對象，產品面向的用戶不同對於產品的設計要求不同，不同年齡層的用戶對於產品的要求不同，產品的用戶定位將對UI設計師影響因素。
輸入物：交互文檔（高保真原型）
輸出物：設計終稿（所有的設計稿）
3、配合
UI設計師交出產品設計圖時，更多的配合開發人員、測試人員進行截圖配合。配合開發人員對於PSD格式的圖片切圖操作，對於不同的開發人員的要求，切圖方式也有不同，UI設計師需配合相關的開發人員進行最適合的切圖配合。
輸入物：設計終稿
輸出物：設計修改稿（設計稿切片）
4、驗證
產品出來後，UI設計師需對產品的效果進行驗證，與當初設計產品時的想法是否一致，是否可用，用戶是否接受，以及與需求是否一致。都需要UI設計師驗證，UI設計師是將產品需求用圖片展現給用戶最直接的經手人，對於產品的理解會更加深刻。
輸入物：產品
輸出物：產品（面向用戶最終版本）
產品UI設計中夾雜著許多設計原則要求，統一公司UI設計流程，使UI設計師參與到產品設計整個環節中來，對產品的易用性進行全流程負責，使UI設計的流程規范化，保證UI設計流程的可操作性。UI設計師應該分析公司產品的特點，制定符合產品生命周期的UI設計流程。每個產品的生命周期中，UI設計師應該嚴格按照流程，完成每個環節的職責，確保流程准確有效的得到執行，從而提高產品的可用性，提升產品質量。

Ⅶ 如何發現用戶需求如何分析轉化產品需求如何判斷需求優先順序

1）用戶調研，挖掘本質；
2）需求與產品定位和核心功能的契合度，帶來的價值，進行灰度測試；
3）性價比=價值/成本；不同階段需求優先順序排期不同。
傳智播客官網視頻庫裡面忘記是哪個基礎視頻講過，我都會偶爾去那逛逛，找找資源。

Ⅷ 如何將顧客需求轉化為產品特性

如何將顧客需求轉化為產品特性
3、顧客需求轉化為產品需求的方法——QFD（質量功能展開）
作為一種面向顧客需求的產品開發思想和方法論的質量功能展開（QFD），在將顧客需求轉化為產品特性的過程中，它提供了有力的理論指導和操作方法，並已經得到實踐的檢驗。QFD藉助質量屋，量化分析顧客需求與工程措施之間的關系，通過對顧客需求進行多次展開，轉化為產品的設計要求、零部件特性、工藝要求和生產要求，已經指導產品設計和質量保證，充分體現了以市場為導向的產品開發指導思想。
QFD是一種顧客驅動的產品開發系統化方法，採用系統化、規范化的方法調查和分析顧客需求，並以矩陣或圖表的形式將顧客需求轉化成產品開發階段的工程特徵、零部件特徵、工藝特徵和質量控制參數和方法等產品特性信息，以使產品能真正全面的滿足顧客需求。
QFD包括兩個基本過程：顧客需求的提取和顧客需求的瀑布式分解過程。顧客需求的提取時通過各種市場調查和各種渠道收集原始的顧客需求，然後進行分類和整理，並用加權表示顧客需求的相對重要度。顧客需求的提取是QFD中最關鍵的一步，他直接關繫到QFD的成功與否。顧客需求的瀑布式分解過程由產品規劃、零件規劃、工藝規劃和生產規劃四個階段組成。通過四個過程，顧客需求逐步展開為設計要求、零件特性、工藝特性和生產要求等一系列可測量的、可操作的活動或指標。在展開過程中，上一步的輸出就是下一步的輸入，構成瀑布式分解的過程。
在顧客需求逐步展開過程中，QFD採用了質量屋（HOQ）.質量屋是實現QFD思想的一種工具，是QFD基本原理的核心組成部分，質量屋提供了將顧客需求轉換為產品技術需求和零部件特性並配置到整個研發過程的結構。
現以產品規劃過程來說明質量屋的構成，在這一階段的質量屋中，顧客需求被展開為設計要求。
產品規劃矩陣用於將顧客需求轉換成技術需求，並分別從顧客角度和技術要求對市場上的同類產品進行評估，在分析舉證的各部分信息的基礎上，確定各個技術需求的目標價值以及在零件配置階段需要的技術需求 。對上圖各部分的解釋說明：
1）顧客需求及權重是矩陣最基本的輸入，他們是通過廣泛的市場調查得到的，在確定顧客需求是應避免主觀想像，注意真實性和全面性。在圖中（1）是顧客需求欄。
2）根據市場調查得到的顧客需求，確定最終產品所應具有的技術需求，他們直接與顧客有關，並將有重點的配置到設計、工藝、製造中去。在圖中（2）為技術需求欄。
3）通常用一組符號或數字來表示顧客需求和技術需求之間的相關程度。如用5表示技術需求與滿足其對應的顧客需求強相關程度；3表示中等程度相關；1表示弱相關。如果關系矩陣中相關符號很大部分是弱相關，則表示技術需求沒有足夠的滿足顧客需求，應對應進行修正。圖中（3）為顧客需求和技術需求的關系矩陣欄。
4）顧客競爭性評估，是指從顧客的角度對本公司產品和競爭者產品在滿足顧客需求方面的評估。他反映了現有產品的優勢和弱點以及產品需要改進的地方。評估數據一般通過顧客調查獲得。圖中（4）為顧客競爭性評估欄。
5）技術性競爭評估，與顧客競爭性評估不同，是從技術角度對產品的競爭力進行評估。在圖中（5）是技術競爭性評估欄。
6）技術需求之間常常是相互影響的，改善其中的某一項技術需求的措施可能有助於改善另外一個技術需求，或者將對另外一個技術需求產生負影響。有助於改善的叫正相關，影響另一技術需求的叫負相關。如圖（6）中為技術需求相互關系欄。
7）技術需求目標值，根據顧客需求及權重、顧客需求與技術需求的關系矩陣以及產品的優勢和弱點，確定技術需求的目標值。在圖中（7）為技術需求目標值欄。
基於下道工序就是上道工序的顧客的思想，QDF還包括其他矩陣，如零件配置舉證，工藝規劃矩陣和質量控制規劃矩陣等，以進一步把顧客需求展開到產品的全過程。
零配件配置矩陣從產品規劃中獲得技術需求，並作為零件配置矩陣的輸入。包括：技術需求、關鍵性零件特性、技術需求與關鍵性零件特性關系矩陣、關鍵性零件特性目標值等，其質量屋的構成與產品規劃相似。
工藝規劃矩陣和林間配置矩陣相似，他從零件規劃中獲取去零件特性作為輸入。主要包括關鍵零件特性、關鍵工藝特性、關鍵零件特性和工藝特性關系矩陣，工藝規范等。
質量控制規劃矩陣以工藝規劃矩陣輸出的關鍵工藝特性作為輸入，將其轉化為相應的質量控制要求和具體控制辦法。

Ⅸ 如何取得用戶需求

你好：
● 數據分析
通過一些客觀數據，例如，流量、檢索量等，能很好的說明問題； 數據分析依賴人員，同樣的數據被不同的人解讀結果完全不同； 以數據說話，是產品管理人員的基本素質之一； 數據分析的結論，往往是最可信、最可靠的結論。
● 邀請用戶進行訪談，觀察或者讓用戶說出自己的需求與偏好。
這樣的方法能夠與用戶面對面的交流，也能夠在旁邊靜靜地觀察用戶的使用習慣； 但是，由於用戶是明確知道了此次訪談的目的，因此，用戶在思考問題和使用方面會受到心裡影響的偏差，導致結果的不可信；
其次，有很多產品，無法准確的獲取用戶的信息，導致，被邀請的用戶，往往不是產品的核心用戶，或者說，用戶並不是經常使用這個產品；
不經意之間與朋友之間的聊天會比邀請用戶來訪談效果好很多。
● 用戶反饋
1）在網站上提供讓明顯的讓用戶給網站提意見的鏈接或者郵箱地址；
2）認真對待每一個用戶的反饋，因為大部分情況來說，有時間填寫用戶反饋的用戶（也就是會抱怨的用戶），今後往往可能成為忠誠的用戶； 3）從用戶反饋中發現產品的不足、發現用戶的需求；
4）不是每一個用戶反饋的需求都需要滿足，根據反饋的程度制定優先順序。 ● 搜索
這是產品管理人員一種主動收集信息的方式，通過各種搜索引擎，如博客搜索 、網頁搜索 、博客空間 等渠道獲得用戶的評論；
要能夠自主的區分何為「普通用戶」的反饋、何為「評測人員」的試用報告； 搜索出來的原始內容相對於數據分析來說，更加依賴於人的分析與理解； 這種方法依賴於長期的觀察與收集，短期的內容沒有足夠的說服力。

Ⅹ 工作中，該如何做需求分析

需求分析的過程

（1）用戶分析通過用戶生活形態分群的方法，按照用戶的價值觀和生活形態特徵，對用戶進行分群，形成具有典型性的細分群組，並且總結提煉出該群組用戶的一般特徵，清晰定位目標市場與目標用戶群體，指導產品開發和創新。主要解決目標用戶是誰，市場預期容量有多大的問題。

（2）需求挖掘根據上一階段選定的目標用戶群，進行抽樣研究，通過記錄某一特定類型用戶的生活場景或業務使用體驗，洞察用戶的典型行為或生活習慣，了解他們在特定場景下的需求，結合企業自身的能力，拓展業務創新的空間。

（3）需求驗證在定性挖掘用戶需求碎片的基礎上，要通過定量的調查從兩個方面對需求進行驗證：首先，要驗證需求的普遍性，目標用戶群中是否大部分用戶都有類似的需求；其次，要驗證需求的迫切性，目標用戶群中大部分用戶對需求的排列順序。經過驗證排序後的需求，就可以作為用戶需求的最後輸入。當然，要最終成為產品需求並且轉化成產品功能，還需要從其他幾個方面進行分析和篩選，在此就不詳細介紹