瀑布模型項(xiàng)目中的需求分析之道(一)

2 評論 17366 瀏覽 70 收藏 9 分鐘

在瀑布模型項(xiàng)目中,需求分析的質(zhì)量直接決定了整個(gè)項(xiàng)目的完成質(zhì)量。需求人員需要盡早的將項(xiàng)目需求和客戶及內(nèi)部開發(fā)團(tuán)隊(duì)達(dá)成一致,并做到對問題早發(fā)現(xiàn),早解決。

一、能力模型

說需求分析,不得不先提當(dāng)下比較流行的2種軟件開發(fā)架構(gòu):瀑布模型和敏捷開發(fā)模型。在不同的開發(fā)架構(gòu)中,需求分析角色者的能力模型和方法論也會有較大的差異。

QQ截圖20160714212855

瀑布模型是經(jīng)典的周期模型,社會認(rèn)可度高,通常適合招投標(biāo)類的客戶解決方案項(xiàng)目。它將一個(gè)項(xiàng)目的軟件生命周期分為可研、需求分析、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、實(shí)現(xiàn)、系統(tǒng)測試、驗(yàn)收測試和維護(hù)等階段,各個(gè)階段呈線性推進(jìn),即一個(gè)階段完成通過后才可進(jìn)行下一階段的工作。

而敏捷開發(fā)模型則以用戶的需求進(jìn)化為核心,采用迭代、循序漸進(jìn)的方法進(jìn)行軟件開發(fā)。它強(qiáng)調(diào)適應(yīng)性而非預(yù)設(shè)性,將項(xiàng)目分解成不同的“MVP”周期執(zhí)行。敏捷開發(fā)模型是面向人而不是過程,它更強(qiáng)調(diào)團(tuán)隊(duì)間的充分溝通,更適合那些自主運(yùn)營的互聯(lián)網(wǎng)產(chǎn)品。

圖片1

需求分析角色在瀑布模型中的能力模型偏向項(xiàng)目經(jīng)理,在實(shí)際需求調(diào)研和需求設(shè)計(jì)中需要結(jié)合項(xiàng)目管理的黃金三角(時(shí)間、資源、質(zhì)量)進(jìn)行統(tǒng)籌規(guī)劃;而在敏捷開發(fā)模型中則更偏向于產(chǎn)品經(jīng)理,在產(chǎn)品策劃和交互設(shè)計(jì)中則對自身商業(yè)感和規(guī)劃能力有更高的要求。項(xiàng)目經(jīng)理和產(chǎn)品經(jīng)理的能力模型本身有一定的區(qū)別,產(chǎn)品新人在加入公司后可根據(jù)實(shí)際情況制定符合自身的能力提升計(jì)劃。以下主要以瀑布模型類的項(xiàng)目為例。

二、需求的生命周期

一個(gè)需求的完整生命周期,通常包括產(chǎn)品策劃(問題識別)、需求分析(分析與綜合)、制定規(guī)格說明和評審。

圖片1

(一)產(chǎn)品策劃(問題識別)

圖片2

在解決方案項(xiàng)目中,問題識別通常在可研階段就已經(jīng)開始,項(xiàng)目經(jīng)理(這個(gè)階段也可能是售前工程師)通過高層交流、問題報(bào)告、訪談紀(jì)要、標(biāo)桿對比和準(zhǔn)入標(biāo)準(zhǔn)等方式,初步形成一份“正式需求”,該過程可分解如下:

  1. 以業(yè)主的角度,幫助客戶將項(xiàng)目從BRD梳理成MRD的過程,形成基本方案
  2. 以承建方的角度,初步了解項(xiàng)目的功能邊界和實(shí)現(xiàn)成本

不同企業(yè)的團(tuán)隊(duì)構(gòu)建可能會有不同,需求角色在該階段最好能夠在該階段便參與可研的過程,而非等項(xiàng)目招投標(biāo)完成后,才參與到項(xiàng)目建設(shè),這樣往往會加大項(xiàng)目的不可控性。

圖片3

問題識別時(shí),分類原始需求通常有上述幾種方法,包括#APPEALS分類、四象限分類和BSA法分類,通過#APPEALS的八個(gè)維度來定位整個(gè)項(xiàng)目,為后續(xù)管理中使用黃金三角提供依據(jù);四象限和BSA法通常結(jié)合使用,以判斷項(xiàng)目的功能邊界和項(xiàng)目的里程碑梯度。

(二)需求分析

圖片4

需求分析的過程,是將用戶需求轉(zhuǎn)化為產(chǎn)品需求的過程,本質(zhì)上也是信息系統(tǒng)的建模過程,包括結(jié)構(gòu)化方法,面向?qū)ο蠓椒ê驮头ǖ?。在?shí)際需求分析中,這幾種方法通常綜合使用。

  1. 結(jié)構(gòu)化方法:是相對最早和最傳統(tǒng)的軟件開發(fā)方法,它采用模塊化技術(shù)、分而治之的方法,將系統(tǒng)按功能分解為若干模塊;模塊內(nèi)部由順序、分支和循環(huán)等基本控制結(jié)構(gòu)組成,主要工具為數(shù)據(jù)流圖,適用于一些不太復(fù)雜的、需求相對比較明確的中小型系統(tǒng)。目前該已經(jīng)比較少用。
  2. 面向?qū)ο蠓椒?/strong>:是目前運(yùn)用最為廣泛的一類軟件開發(fā)方法。通常使用UML建模工具,比較常用的有用例視圖(Use-Case View)和邏輯視圖(順序圖、狀態(tài)圖、泳道圖等),用例視圖可結(jié)合場景
  3. 原型法:隨著以互聯(lián)網(wǎng)產(chǎn)品用戶思維的興起,越來越多的需求分析采用原型法,使用Axure等工具進(jìn)行設(shè)計(jì)。

(三)制定規(guī)格說明和評審

許多時(shí)候,制定規(guī)格說明在需求分析完成時(shí)也同步完成,這里推薦使用Volere需求說明模板。

需求評審是項(xiàng)目正式開發(fā)前的必經(jīng)之路,通過需求評審,項(xiàng)目組成員針自將要開展的工作,進(jìn)行檢查并提出問題,并最終做出評審邊界,形成項(xiàng)目開發(fā)的基線版本。

三、其他常見問題

(一)需求引導(dǎo)

許多客戶有時(shí)并不知道自己想要什么?有時(shí)并不清楚自己缺少什么?所以就需要我們?nèi)ヒ龑?dǎo)客戶的需求。造成這種現(xiàn)象的原因很多,主要體現(xiàn)在用戶對軟件信息系統(tǒng)并不是很了解,客戶的語言表達(dá),客戶只關(guān)心自身的問題等。

引導(dǎo)客戶需求通常從引導(dǎo)客戶分析、向客戶確認(rèn)需求細(xì)節(jié)和回絕客戶提出的不合理需求等幾個(gè)維度出發(fā),幾種常見方法如下:

  • 向客戶講述基本的軟件信息系統(tǒng)
  • 提示客戶在全局的地位及作用
  • 向客戶演示將要實(shí)施的系統(tǒng)的原型
  • 從軟件開發(fā)中需求考慮的幾個(gè)方面入手

總而言之,在瀑布模型項(xiàng)目中,需求分析的質(zhì)量直接決定了整個(gè)項(xiàng)目的完成質(zhì)量。需求人員需要盡早的將項(xiàng)目需求和客戶及內(nèi)部開發(fā)團(tuán)隊(duì)達(dá)成一致,并做到對問題早發(fā)現(xiàn),早解決;另一方面,有時(shí)候客戶的“需求”不一定是功能需求,需求人員只有從項(xiàng)目經(jīng)理的維度分析問題,才能夠篩選并最終推進(jìn)項(xiàng)目的實(shí)施。

#專欄作家#

蘭色拉面(微信:lanselamian),人人都是產(chǎn)品經(jīng)理專欄作家。關(guān)注城市服務(wù)、互聯(lián)網(wǎng)+和智能硬件,對市民融合服務(wù)、移動進(jìn)銷存、物聯(lián)網(wǎng)和支付 POS有一定的淺見。歡迎互聯(lián)網(wǎng)愛好者們一起交流探討。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,不得轉(zhuǎn)載。

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 需求的生命周期是否可以包含一個(gè)“驗(yàn)證”的階段呢?在需求評審?fù)ㄟ^并實(shí)現(xiàn)后,對這個(gè)需求的帶來的影響和變化進(jìn)行評估。

    來自北京 回復(fù)
  2. 都在研究道,道法自然~!

    來自上海 回復(fù)