軟件開(kāi)發(fā)：軟件功能需求分析

發(fā)布日期： 2025-12-04 閱讀量： 作者： 小編

一、需求分析定義

軟件需求分析也稱為系統(tǒng)需求分析或需求分析工程等，是開(kāi)發(fā)人員經(jīng)過(guò)深入細(xì)致的調(diào)研和分析，準(zhǔn)確理解用戶和項(xiàng)目的功能、性能、可靠性等體要求，將用戶非形式的需求表述轉(zhuǎn)化為完整的需求定義，從而確定系統(tǒng)必須做什么的過(guò)程。

軟件開(kāi)發(fā)一般包括：可行性分析、需求分析、軟件設(shè)計(jì)、軟件開(kāi)發(fā)、軟件測(cè)試、軟件實(shí)施、軟件服務(wù)等步驟，需求分時(shí)軟件開(kāi)發(fā)的第一步驟。

用戶需求分析是指在系統(tǒng)設(shè)計(jì)之前和設(shè)計(jì)、開(kāi)發(fā)過(guò)程中對(duì)用戶需求所作的調(diào)查與分析，是系統(tǒng)設(shè)計(jì)、系統(tǒng)完善和系統(tǒng)維護(hù)的依據(jù)。

二、軟件需求分析目標(biāo)

需求分析是軟件計(jì)劃階段的重要活動(dòng)，也是軟件生存周期中的第一步，該階段是分析系統(tǒng)在功能上需要“實(shí)現(xiàn)什么”，而不是考慮如何去“實(shí)現(xiàn)”。

對(duì)客戶的信息化需求進(jìn)行分析，將客戶不規(guī)范的、隨意的需求，轉(zhuǎn)換成規(guī)范的、嚴(yán)謹(jǐn)?shù)?、結(jié)構(gòu)化的需求，將客戶不正確的需求轉(zhuǎn)換成正確的需求、將客戶不切實(shí)際的需求轉(zhuǎn)換成可以實(shí)現(xiàn)的需求，將客戶不必要的需求砍掉，將客戶漏掉的需求補(bǔ)上。

此外，軟件的一些非功能性需求(如軟件性能、可靠性、響應(yīng)時(shí)間、可擴(kuò)展性等)，軟件設(shè)計(jì)的約束條件，運(yùn)行時(shí)與其他軟件的關(guān)系等也是軟件需求分析的目標(biāo)。

三、軟件需求分析原則

需求分析通常來(lái)講它們應(yīng)符合以下一般原則：

1. 能夠表達(dá)和理解問(wèn)題的信息域

信息域反映的是用戶業(yè)務(wù)系統(tǒng)中數(shù)據(jù)的流向和對(duì)數(shù)據(jù)進(jìn)行加工的處理過(guò)程，因此信息域是解決“做什么？”的關(guān)鍵因素。根據(jù)信息域描述的信息流、信息內(nèi)容和信息結(jié)構(gòu)，可以較全面地（完整地）了解系統(tǒng)的功能。

2. 建立描述系統(tǒng)信息、功能和行為的模型

建立模型的過(guò)程是“由粗到精”的綜合分析的過(guò)程。通過(guò)對(duì)模型的不斷深化認(rèn)識(shí)，來(lái)達(dá)到對(duì)實(shí)際問(wèn)題的深刻認(rèn)識(shí)。

3. 能夠?qū)λＰ桶匆欢ㄐ问竭M(jìn)行分解

分解是為了降低問(wèn)題的復(fù)雜性，增加問(wèn)題的可解性和可描述性。分解可以在同一個(gè)層次上進(jìn)行（橫向分解），也可以在多層次上進(jìn)行（縱向分解）。

4. 分清系統(tǒng)的邏輯視圖和物理視圖

軟件需求的邏輯視圖描述的是系統(tǒng)要達(dá)到的功能和要處理的信息之間的關(guān)系，這與實(shí)現(xiàn)細(xì)節(jié)無(wú)關(guān)，而物理視圖描述的是處理功能和信息結(jié)構(gòu)的實(shí)際表現(xiàn)形式，這與實(shí)現(xiàn)細(xì)節(jié)是有關(guān)的。

需求分析只研究軟件系統(tǒng)“做什么？”，而不考慮“怎樣做？”。

四、軟件需求分析內(nèi)容

需求分析的內(nèi)容是針對(duì)待開(kāi)發(fā)軟件提供完整、清晰、具體的要求，確定軟件必須實(shí)現(xiàn)哪些任務(wù)。

具體分為功能性需求、非功能性需求與設(shè)計(jì)約束三個(gè)方面：

1. 功能性需求

功能性需求即軟件必須完成哪些事，必須實(shí)現(xiàn)哪些功能，以及為了向其用戶提供有用的功能所需執(zhí)行的動(dòng)作。

功能性需求是軟件需求的主體，開(kāi)發(fā)人員需要親自與用戶進(jìn)行交流，核實(shí)用戶需求，從軟件幫助用戶完成事務(wù)的角度上充分描述外部行為，形成軟件需求規(guī)格說(shuō)明書(shū)。

2. 非功能性需求

作為對(duì)功能性需求的補(bǔ)充，軟件需求分析的內(nèi)容中還應(yīng)該包括一些非功能需求。

主要包括軟件使用時(shí)對(duì)性能方面的要求、運(yùn)行環(huán)境要求，軟件設(shè)計(jì)必須遵循的相關(guān)標(biāo)準(zhǔn)、規(guī)范、用戶界面設(shè)計(jì)的具體細(xì)節(jié)、未來(lái)可能的擴(kuò)充方案等。

3. 設(shè)計(jì)約束

一般也稱做設(shè)計(jì)限制條件，通常是對(duì)一些設(shè)計(jì)或?qū)崿F(xiàn)方案的約束說(shuō)明。

例如：要求待開(kāi)發(fā)軟件必須使用Oracle數(shù)據(jù)庫(kù)系統(tǒng)完成數(shù)據(jù)管理功能，運(yùn)行時(shí)必須基于Linux環(huán)境等。

五、軟件需求分析過(guò)程

需求分析階段的工作,可以分為四個(gè)方面：?jiǎn)栴}識(shí)別、分析與綜合、制訂規(guī)格說(shuō)明、評(píng)審。

1. 問(wèn)題識(shí)別

就是從系統(tǒng)角度來(lái)理解軟件，確定對(duì)所開(kāi)發(fā)系統(tǒng)的綜合要求，并提出這些需求的實(shí)現(xiàn)條件，以及需求應(yīng)該達(dá)到的標(biāo)準(zhǔn)。

這些需求包括：功能需求（做什么）、性能需求（要達(dá)到什么指標(biāo)）、環(huán)境需求（如機(jī)型、操作系統(tǒng)等）、可靠性需求（不發(fā)生故障的概率）、安全保密需求、用戶界面需求、資源使用需求（軟件運(yùn)行是所需的內(nèi)存、CPU等）、軟件成本消耗與開(kāi)發(fā)進(jìn)度需求、預(yù)先估計(jì)以后系統(tǒng)可能達(dá)到的目標(biāo)。

2. 分析與綜合

逐步細(xì)化所有的軟件功能，找出系統(tǒng)各元素間的聯(lián)系，接口特性和設(shè)計(jì)上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。

最后綜合成系統(tǒng)的解決方案，給出要開(kāi)發(fā)的系統(tǒng)的詳細(xì)邏輯模型（做什么的模型）。

3. 制訂規(guī)格說(shuō)明書(shū)

即編制文檔，描述需求的文檔稱為軟件需求規(guī)格說(shuō)明書(shū)。請(qǐng)注意，需求分析階段的成果是需求規(guī)格說(shuō)明書(shū)，向下一階段提交。

4. 評(píng)審

對(duì)功能的正確性，完整性和清晰性，以及其它需求給予評(píng)價(jià)。評(píng)審?fù)ㄟ^(guò)才可進(jìn)行下一階段的工作，否則重新進(jìn)行需求分析。

六、軟件需求評(píng)估方法

需求評(píng)估分析方法通常有：模糊聚類(lèi)分析、質(zhì)量功能展開(kāi)、KANO模型分析、A/B測(cè)試。其中以卡諾（KANO）模型最常用。

1. 聚類(lèi)分析法

聚類(lèi)分析指將物理或抽象對(duì)象的集合分組為由類(lèi)似的對(duì)象組成的多個(gè)類(lèi)的分析過(guò)程。它是一種重要的人類(lèi)行為。

聚類(lèi)是將數(shù)據(jù)分類(lèi)到不同的類(lèi)或者簇這樣的一個(gè)過(guò)程，所以同一個(gè)簇中的對(duì)象有很大的相似性，而不同簇間的對(duì)象有很大的相異性。

在聚類(lèi)分析的時(shí)候，要根據(jù)變量的性質(zhì)選擇聚類(lèi)模型。如果關(guān)鍵屬性是使用問(wèn)卷收集的分類(lèi)變量，一般選擇兩步聚類(lèi)法，因?yàn)橛脩舻娜丝趯W(xué)特征和使用某產(chǎn)品行為偏好等特征一般都是分類(lèi)變量。檢驗(yàn)聚類(lèi)變量差異性：如下2. 質(zhì)量功能展開(kāi)

是指把用戶對(duì)產(chǎn)品的需求進(jìn)行多層次的演繹分析，轉(zhuǎn)化為產(chǎn)品的設(shè)計(jì)需求、工程部件特征、工藝要求、生產(chǎn)要求，用來(lái)指導(dǎo)產(chǎn)品設(shè)計(jì)并保證產(chǎn)品的質(zhì)量，是一種以用戶為導(dǎo)向的質(zhì)量管理工具。

由于該方法所使用的主要圖形就像房屋，所以它也被稱為“質(zhì)量屋”，如下圖：

3.卡諾KANO 模型

是 Noriaki Kano 博士提出的與產(chǎn)品性能有關(guān)的用戶滿意度模型，該模型能對(duì)用戶需求進(jìn)行很好的識(shí)別和分類(lèi)，是對(duì)用戶需求分類(lèi)和優(yōu)先排序的有用工具，以分析用戶需求對(duì)用戶滿意的影響為基礎(chǔ)，體現(xiàn)了產(chǎn)品性能和用戶滿意之間的非線性關(guān)系。

Noriaki Kano 將影響滿意度的因素劃分為五個(gè)類(lèi)型，包括：必備需求、期望需求、魅力需求、無(wú)差異需求、反向需求。

興奮（魅力）需求：

用戶意想不到的，如果不提供次需求，用戶滿意度不會(huì)降低，但是提供次需求，用戶滿意度會(huì)有很大的提升；
期望（意愿）需求：
當(dāng)提供此需求，用戶滿意度會(huì)提升，當(dāng)不提供此需求，用戶滿意度會(huì)降低；
基本（必備）需求：
當(dāng)優(yōu)化此需求，用戶滿意度不會(huì)提升，當(dāng)不提供此需求，用戶滿意度會(huì)大幅下降；
無(wú)差異需求：
無(wú)論提供或者不提供此需求，用戶滿意度都不會(huì)有變化，而且根本不會(huì)在意；
反向（逆向）需求：
用戶根本沒(méi)有這個(gè)需求，提供之后用戶滿意度反而會(huì)下降。

利用KANO模型進(jìn)行需求評(píng)估主要集中于對(duì)用戶需求類(lèi)型的分類(lèi)討論。為了便于分析可以設(shè)計(jì)相應(yīng)的調(diào)研問(wèn)卷。

問(wèn)卷中需要對(duì)產(chǎn)品的某項(xiàng)功能分別設(shè)置正向和負(fù)向兩個(gè)問(wèn)題：“如果產(chǎn)品有這個(gè)功能，您覺(jué)得如何？” 、“如果產(chǎn)品的這個(gè)功能不存在，您覺(jué)得如何？”

將問(wèn)題結(jié)果術(shù)語(yǔ)模型矩陣中，就能夠比較明確地看到，哪些用戶需求是必須有的，哪些是用戶期望的，哪些是可有可無(wú)的，哪些需求又是用戶自己不確定的。

將用戶需求進(jìn)行分類(lèi)，在產(chǎn)品開(kāi)發(fā)時(shí)，功能優(yōu)先級(jí)的排序一般是：基本屬性>期望屬性>興奮屬性>無(wú)差異屬性，去掉可疑結(jié)果的需求和相反的需求。

4. A/B測(cè)試

是為Web或App界面或流程制作兩個(gè)或多個(gè)版本，分別讓組成成分相同（相似）的訪客群組（目標(biāo)人群）隨機(jī)的訪問(wèn)這些版本，收集各群組的用戶體驗(yàn)數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)，最后分析、評(píng)估出最好版本并且實(shí)現(xiàn)的綜合成本低，正式采用。

比較常見(jiàn)的案例是對(duì)網(wǎng)站注冊(cè)頁(yè)進(jìn)行A/B測(cè)試，確定哪一個(gè)方案的注冊(cè)率高，更加滿足用戶的需求，實(shí)現(xiàn)的商業(yè)利益最大化。

需要注意在進(jìn)行A/B測(cè)試時(shí)，每次必須只測(cè)量一個(gè)變量，多個(gè)變量測(cè)試，則無(wú)法判斷是哪個(gè)變量導(dǎo)致的結(jié)果；測(cè)試的環(huán)境應(yīng)當(dāng)一直，例如測(cè)量時(shí)間應(yīng)一致。

因?yàn)樵诓煌臅r(shí)間段，用戶的訪問(wèn)量會(huì)有變動(dòng)；測(cè)量的樣本量要具有統(tǒng)計(jì)學(xué)意義，樣本流量太小時(shí)，無(wú)法體現(xiàn)在線用戶的真實(shí)行為。

七、需求分析優(yōu)先級(jí)的方法

需求優(yōu)先級(jí)的分析方法大致可以分成兩大類(lèi)：定性分析方法、定量分析方法；

一類(lèi)是根據(jù)分析人員的經(jīng)驗(yàn)主觀地對(duì)需求進(jìn)行優(yōu)先級(jí)分類(lèi)，稱之為定性的分析方法，比如：四象限分析法、波士頓矩陣分析法；另一類(lèi)是根據(jù)調(diào)查數(shù)據(jù)，對(duì)調(diào)查數(shù)據(jù)進(jìn)行分析，得出需求的優(yōu)先級(jí)分類(lèi)，稱之為定量的分析方法，比如：KANO模型。

1. 四象限分析法

根據(jù)需求對(duì)于業(yè)務(wù)的影響，以及需求實(shí)現(xiàn)的緊迫程度，我們可以按照如下方式將需求歸為4個(gè)象限，這也是需求歸類(lèi)的經(jīng)典4分法。四象限分析法是很常見(jiàn)的一種定性分析需求優(yōu)先級(jí)的方法，如下：

重要且緊急的事，影響業(yè)務(wù)正常進(jìn)行，需要盡快處理；
不重要但緊急的事，雖然對(duì)業(yè)務(wù)影響不大，但是需要盡快處理；
重要且不緊急的事，對(duì)業(yè)務(wù)影響大，但不需要短期內(nèi)就完成；
不緊急且不重要的，對(duì)業(yè)務(wù)影響不大，也不需要短期內(nèi)完成。

2. 波士頓矩陣

波斯頓矩陣是由波士頓咨詢公司發(fā)明的一種方法，最早用于分析市場(chǎng)增長(zhǎng)率和市場(chǎng)份額，現(xiàn)在也被經(jīng)常用于對(duì)需求的分析之中，波士頓矩陣由用戶價(jià)值維度和公司價(jià)值兩個(gè)維度將需求分成了四個(gè)象限：

明星需求：
對(duì)用戶體驗(yàn)有價(jià)值，對(duì)公司戰(zhàn)略也有價(jià)值的需求。
明星需求是雙贏的需求，需要優(yōu)先得到滿足，如一些促進(jìn)用戶活躍、轉(zhuǎn)化的需求，具體的有，活躍度排名、優(yōu)惠提醒等功能；
問(wèn)題需求：
對(duì)用戶體驗(yàn)有價(jià)值，但對(duì)公司戰(zhàn)略和目標(biāo)沒(méi)價(jià)值的需求。
此類(lèi)需求雖然看似對(duì)公司沒(méi)直接價(jià)值，但是提升用戶體驗(yàn)有助于提升用戶的忠誠(chéng)度，如一些提升用戶體驗(yàn)的需求。
具體的有，提供多種快捷登陸方式、提供輔助輸入功能等；
金牛需求：
對(duì)用戶體驗(yàn)沒(méi)價(jià)值甚至?xí)?duì)用戶造成困擾，但是對(duì)公司戰(zhàn)略有價(jià)值的需求。
公司價(jià)值的體現(xiàn)，此類(lèi)需求應(yīng)該盡量考慮避免對(duì)用戶造成影響。
如一些運(yùn)營(yíng)需求等。
具體的有，收集用戶信息等；
瘦狗需求：
對(duì)用戶體驗(yàn)無(wú)價(jià)值，對(duì)公司戰(zhàn)略也無(wú)價(jià)值的需求。
此類(lèi)需求應(yīng)該過(guò)濾掉，例如一些偽需求。

3. 卡諾KANO 模型法

Noriaki Kano 將影響滿意度的因素劃分為五個(gè)類(lèi)型，包括：必備需求、期望需求、魅力需求、無(wú)差異需求、反向需求（詳情見(jiàn)上文）。

八、如何確定軟件需求

經(jīng)過(guò)大量的需求調(diào)研工作之后，手上可能有客戶提出的大量的、各種各樣的需求。

這些需求有的是技術(shù)上可以實(shí)現(xiàn)的，有的是技術(shù)上不可以實(shí)現(xiàn)的；有些是管理上需要的，有的是管理上不需要的；有些是合理的，有些是不合理的，如何處理這些需求呢？

以“實(shí)現(xiàn)用戶正確的需求”為原則，對(duì)于用戶提出的需求進(jìn)行嚴(yán)格的分析、甄別。

為了認(rèn)清用戶的需求，先要認(rèn)清用戶。在進(jìn)行需求調(diào)研的時(shí)候，會(huì)跟各種各樣的人員溝通，他們的技術(shù)、只是、性格、職位、工作內(nèi)容各不相同。

但他們也有相似的地方：他們不是做軟件的，也不是分析需求的，他們永遠(yuǎn)不會(huì)像你希望的那樣去描述需求，他們的需求是用自然語(yǔ)言描述的，是抽象的、概略的、隨性的。

那個(gè)這些抽象、概略、隨性的用戶需求轉(zhuǎn)化成具體、詳細(xì)、結(jié)構(gòu)化的軟件需求，是需求分析的重點(diǎn)，通常從以下幾點(diǎn)著手認(rèn)清和控制需求：

1. 將抽象的需求具體化

在需求調(diào)研的時(shí)候會(huì)發(fā)現(xiàn)，用戶提出自己的需求時(shí)總是不會(huì)按照你希望方式去提出來(lái)，有的人因?yàn)椴恢滥阆胍裁?，只為了?yīng)付領(lǐng)導(dǎo)布置的任務(wù)，有的是處于比較高的職位，習(xí)慣了從宏觀的角度去講問(wèn)題，所以我們?cè)谡硇枨蟮臅r(shí)候要將抽象的要求具體化。

2. 將自然語(yǔ)言描述的需求結(jié)構(gòu)化

用戶描述需求總是非常隨意的，他們使用平常正常溝通的語(yǔ)言描述，這種需求的主要特點(diǎn)就是不嚴(yán)謹(jǐn)，容易有其一，這種需求不能直接讓開(kāi)發(fā)者處理的，開(kāi)發(fā)者需要的需求是描述明確的、精準(zhǔn)的、沒(méi)有歧義的。

需求分析分析者作為用戶與開(kāi)發(fā)者的橋梁，有義務(wù)將用戶用自然語(yǔ)言描述的需求結(jié)構(gòu)化。將用戶的描述轉(zhuǎn)換成更精確的語(yǔ)言，更接近IT人使用的語(yǔ)言。

3. 注意避免理解偏差

理解偏差主要是需求分析者對(duì)用戶所提的需求沒(méi)有理解到位，用戶明明想表達(dá)的是這個(gè)意思，卻被理解成了另外一個(gè)意思。

這是一個(gè)溝通問(wèn)題，說(shuō)的人覺(jué)得自己說(shuō)的很清楚了，可偏偏雙方就是沒(méi)有真正理解對(duì)方，所以下面是我們需要注意的：

提高溝通能力：
多從對(duì)方的立場(chǎng)考慮問(wèn)題，當(dāng)雙方描述某件事時(shí)，要從對(duì)方的角度思考這些描述；
提高溝通頻次：
一方面要引導(dǎo)對(duì)方多說(shuō)話，另一方面對(duì)不理解的或者覺(jué)得理解起來(lái)有困難的內(nèi)容，多向?qū)Ψ皆儐?wèn)，換成你的表達(dá)方式讓對(duì)方確認(rèn)是不是這個(gè)意思；
學(xué)習(xí)對(duì)方領(lǐng)域的知識(shí)：
用戶有自己的知識(shí)領(lǐng)域，需求分析者也有自己的知識(shí)領(lǐng)域，前者滿腦子是業(yè)務(wù)術(shù)語(yǔ)，后者滿腦子是IT術(shù)語(yǔ)，有的時(shí)候兩者真難溝通。
每個(gè)人的知識(shí)面不同，要想溝通順暢，兩個(gè)人的知識(shí)面重疊的地方越多越好。

4. 識(shí)別超出項(xiàng)目范圍的需求

用戶的需求不能是漫無(wú)邊際的，所有的需求都應(yīng)該在項(xiàng)目范圍之內(nèi)，做需求分析的時(shí)候首先要確定好項(xiàng)目目標(biāo)，要讓用戶知道需求邊界在什么地方。

這個(gè)項(xiàng)目應(yīng)該在項(xiàng)目啟動(dòng)時(shí)雙方經(jīng)過(guò)討論達(dá)成共識(shí)，后面所有的工作都應(yīng)該圍繞這個(gè)目標(biāo)展開(kāi)。原則是即使在這個(gè)階段的目標(biāo)實(shí)現(xiàn)了以后再設(shè)置新目標(biāo)，也不要不停的修改一個(gè)目標(biāo)。

5. 識(shí)別錯(cuò)誤的需求

對(duì)于那些毫無(wú)邏輯性、前后矛盾或者在技術(shù)上根本無(wú)法實(shí)現(xiàn)，類(lèi)似這樣的統(tǒng)統(tǒng)歸為錯(cuò)誤需求。

6. 識(shí)別技術(shù)上不能實(shí)現(xiàn)的需求。

當(dāng)需求者面向用戶時(shí)，代表的是身后的整個(gè)研發(fā)團(tuán)隊(duì)，要做好需求分析，需要對(duì)自己團(tuán)隊(duì)的技術(shù)能力有非常清楚的了解，哪些事情能做/不能做，又或者可以做但是需要太大的代價(jià)等，每個(gè)團(tuán)隊(duì)都有自己的技術(shù)邊界。

九、整理需求

前期做了那么多的收集工作并確定需求之后，要做好需求的整理工作。需求整理是不是簡(jiǎn)單的將用戶所提的需求全部一條條寫(xiě)下來(lái)就好了，而是一個(gè)綜合分析的的整理過(guò)程。

通過(guò)整理，使得需求更有目的性、更系統(tǒng)性、更明確、更容易理解。需求經(jīng)過(guò)整理后一般會(huì)生成需求調(diào)研報(bào)告與業(yè)務(wù)流程圖，這是后面工作的綱領(lǐng)性文件。

當(dāng)完成用戶需求調(diào)查后，首先對(duì)《用戶需求說(shuō)明書(shū)》進(jìn)行細(xì)化，對(duì)比較復(fù)雜的用戶需求進(jìn)行建模分析，以幫助軟件開(kāi)發(fā)人員更好地理解需求。

十、如何做好需求自查

需求文檔不限呈現(xiàn)形式，但必須包括以下信息，如果某些信息在前期需求階段已出并且通用，比如如全站定位、用戶畫(huà)像等，可省去。

如果在需求階段無(wú)法明確某些信息可以與設(shè)計(jì)、開(kāi)發(fā)等共同討論并細(xì)化需求，具體交互設(shè)計(jì)工作必須在以下信息明確后才可執(zhí)行，包括：需求基本信息（必有）、全站概況、需求概要說(shuō)明（必有）、需求詳情（必有）、流程類(lèi)需求詳情、展示類(lèi)需求詳情、輸入類(lèi)需求詳情、其他需求等。

十一、需求不明確帶來(lái)的影響

1. 項(xiàng)目失控甚至爛尾

在開(kāi)發(fā)時(shí)間和開(kāi)發(fā)費(fèi)用上的失控，因?yàn)樾枨蟮牟煌晟?，?dǎo)致啟動(dòng)開(kāi)發(fā)前無(wú)法準(zhǔn)確預(yù)估需求的工作量和確定技術(shù)實(shí)現(xiàn)方案，走一步看一步開(kāi)發(fā)過(guò)程中，發(fā)現(xiàn)需求有坑，不斷發(fā)現(xiàn)新的問(wèn)題。

有時(shí)因?yàn)橐粋€(gè)簡(jiǎn)單的邏輯或設(shè)計(jì)不明確，在溝通明確后最終發(fā)現(xiàn)需要技術(shù)方案大調(diào)整，很多項(xiàng)目會(huì)變得失控甚至爛尾。

2. 技術(shù)腦補(bǔ)需求

假如需求不是明確的話，靠譜的技術(shù)同學(xué)，就會(huì)自己考慮邏輯和設(shè)計(jì)，就按他自己的理解和想法實(shí)現(xiàn)。

看上去省心，但一千個(gè)觀眾就一千個(gè)哈姆雷特，一旦實(shí)現(xiàn)的邏輯可能并不是產(chǎn)品期望的邏輯，到了測(cè)試環(huán)節(jié)，測(cè)試同學(xué)也有自己的理解，導(dǎo)致又要花時(shí)間溝通統(tǒng)一意見(jiàn)，或浪費(fèi)時(shí)間返工修改。

3. 溝通成本高

項(xiàng)目規(guī)模越大，參與人數(shù)越多，矛盾越凸顯。

在面對(duì)的是人數(shù)眾多的設(shè)計(jì)師，前端團(tuán)隊(duì)、后端團(tuán)隊(duì)、外部團(tuán)隊(duì)、測(cè)試團(tuán)隊(duì)等時(shí)，產(chǎn)品經(jīng)理需經(jīng)常與設(shè)計(jì)、技術(shù)和測(cè)試溝通需求邏輯，溝通的成本會(huì)很高。

4. 產(chǎn)品邏輯難以后續(xù)追溯

移動(dòng)互聯(lián)網(wǎng)時(shí)代，產(chǎn)品上線迭代節(jié)奏非?？欤a(chǎn)品不斷的迭代更新，或是人員的交接，經(jīng)常需要回溯之前的線上邏輯，需求文檔的缺失或不完善，會(huì)導(dǎo)致線上邏輯不明確，甚至后續(xù)的產(chǎn)品需求設(shè)計(jì)的邏輯與線上矛盾或沖突，為項(xiàng)目的開(kāi)發(fā)帶來(lái)麻煩。

上一篇: 后端知識(shí)那么多，重點(diǎn)要學(xué)啥？

下一篇: Supabase：Google Firebase 免費(fèi)開(kāi)源替

軟件開(kāi)發(fā)：軟件功能需求分析

隨便看看