軟體為什麼要做需求調研

⑴ 如何進行軟體需求分析

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

首先，在進行軟體需求分析之前，得有一份軟體說明書或者軟體需求規格說明書，因為這個是我們進行需求分析的對象。但是這個需求規格書寫的質量怎麼樣，實際上是決定了軟體項目的進度、成本甚至成敗的？為什麼這么說呢？因為當前軟體開發這個行業最大的問題是需求質量低下，這個導致了項目成本至少增加了30%以上，這也是為什麼軟體這個行業有錢的公司不多的主要原因。或者說能做出一份有質量的需求規格說明書將體現這個企業的掙錢能力，但現實是絕大多數企業都像人月神話中描述的一樣：一步一步踏入了泥潭。。。由於這個工作產品如此重要，因此通過過個步驟來保證它的質量：需求策劃、獲取、分析、確認以及後期需求管理，尤其是變更管理。如果想了解具體的每個步驟的詳細內容可以聯系我。
其次，如果需求規格說明書有了，我們怎麼分析呢？在具體說明分析方法之前，首先我們要明確一個問題：需求分析到底是在分析什麼？其目的是什麼？其實我們絕大多數的需求工程師都不太清楚或者不能明確的回答這些問題，從而導致他們花費了大量的時間來寫用例（user case），寫了很多關系復雜甚至連需求人員都看不明白或者越看越糊塗的東西，因為他們認為這樣後續的開發、測試人員就能開明白了，事實上是這樣的嗎？根本不是，如果是的話，我們的軟體行業中的絕大多數企業活的普遍不那麼悲慘了。。。回到軟體開發，我們來想一下，我們開發這個東西給誰用？是自己嗎？？？如果是自己事情就簡單了，因為需求都在自己腦子裡面了，就算不完整起碼也不會缺多少，但問題正好相反，99.999999%的情況下我們是為別人或者說我們的用戶開發的，也就是說需求其實是在客戶的腦子了，而不是我們的腦子里！！！我們的首要目的應該是如何通過一套完整的套路把需求從客戶的腦子裡面傳輸到我們的腦子裡面，然後按照規格化（這個是另外一個重點）的方式把它按照說明書一樣描述出來讓後續人員能夠看得清清楚楚、明明白白，這個步驟是最關鍵的一環，因為我們的絕大多數客戶都不會寫需求規格說明書，所以這個任務落在我們的身上。那麼我們到底都問什麼不會丟需求呢？這個是有一套方法和模板來指導需求人員和UI工程師（調研時就需要畫原型，可以稍微想一下這么做的好處）來獲取完整的需求。只有這樣，才能獲取有質量的需求。
那麼說了這么多，分析到底是干什麼的呢？分析就是需求人員首先自己要系統的檢查一下需求來保障需求的質量，記住不是保證，是保障，它就像軟體開發中的評審或測試一樣，是保障產品的質量進行的檢查活動，它們不能保證質量，只是保障作用。就像我們考試一樣，你認真的答完題了，還是需要認真的檢查一遍，因為這個是人的天性之一。那麼問題來了，怎麼進行檢查或者從哪些方面進行檢查呢？我推薦的策略是先外後內、先系統後模塊、先功能後非功能、先業務後屬性，通過整套方法下來可以幫我們查到不少之前遺漏、寫錯、或者矛盾的地方，當然也包括可能不是客戶需要的needs，只是expectation。這個工作比獲取要簡單一些，但是是一個繁雜的活，要逐項逐項的檢查每一個需求的內容以保障需求的質量。到底檢查哪些內容呢？這個太多了，就不羅列了。

⑵ 為什麼進行需求分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

⑶ 軟體開發步驟包括哪些過程

軟體開發一般分為五個階段：問題的定義及規劃、需求分析、軟體設計、程序編碼、軟體測試。

⑷ 為什麼需求分析是軟體發展的第一步

我想提問者可能想問的是：需求分析是軟體開發的第一步。。。估計是英文單詞 development 翻譯的問題。。
從軟體工程和需求工程的角度來講，需求分析並不是第一步，而且也不可能是第一步，為什麼這么說呢？
做任何事之前需要先知道做什麼，這個對軟體開發來講就是需要先知道客戶需求！那麼獲取客戶需求就是必需的，然後通過對客戶需求進行「翻譯」並且進行 規格化編寫後 成為開發人員（如設計人員和代碼編寫人員）以及測試人員能夠理解的軟體需求規格說明書來用。那問題來了，怎麼獲取客戶需求呢？從大的角度來講兩個方面：1 做好需求獲取准備，包括客戶初步需求的研究（合同）、用戶模型（哪些人會使用開發的產品）的搭建、調研人員和被訪談人員的選定和協調、類似產品的了解 2 調研客戶的策略和制定規范化的問卷， 這些步驟都非常關鍵！！！為什麼這么說呢？ 因為對於軟體應用開發來講，目前最大的問題是需求質量低下問題！需求質量低下體現在不斷的需求變更上。然後對齊分析發現：其中引起需求變更最大的三個來源就是：需求不完整、需求描述不清晰 和需求丟失，分析這三個來源背後的主要原因有：准備工作不足、不會調研進行需求、不會分析需求、不會描述客戶需求和不會規格化軟體需求，從而導致需求變更的非常頻繁，結果就是項目組靠不斷的加班來趕進度和降低成本。所以從這個角度來講，需求准備工作或者需求開發是軟體開發的第一步。
希望能對你有幫助。