大數(shù)據(jù)應(yīng)用的需求分析方法

張靖笙

傳統(tǒng)方法在大數(shù)據(jù)需求面前遇到問(wèn)題

       需求分析階段關(guān)系到一個(gè)軟件開(kāi)發(fā)的成敗，這已經(jīng)得到了普遍的認(rèn)識(shí),然而，根據(jù)作者實(shí)戰(zhàn)經(jīng)驗(yàn)，在大數(shù)據(jù)應(yīng)用項(xiàng)目中，按照傳統(tǒng)軟件工程規(guī)范要求的需求分析往往是一個(gè)非常尷尬的過(guò)程，為什么呢?

根據(jù)筆者在實(shí)際工作中的經(jīng)驗(yàn),問(wèn)題主要來(lái)自以下方面：

1.需求分析本身的難度。需求的任務(wù)是了解和描述軟件用戶(hù)對(duì)軟件的需求，即明確做什么。但在實(shí)際的軟件開(kāi)發(fā)中，用戶(hù)了解他們的專(zhuān)業(yè)領(lǐng)域，但計(jì)算機(jī)知識(shí)，特別是軟件知識(shí)往往比較薄弱,而開(kāi)發(fā)人員與此恰好相反，而在需求分析的過(guò)程中，雙方面對(duì)的往往不是一個(gè)可見(jiàn)的產(chǎn)品，而只是頭腦中的構(gòu)思和想象，由于專(zhuān)業(yè)的差異和溝通的有限，用戶(hù)的許多需求對(duì)開(kāi)發(fā)人員來(lái)說(shuō)往往是難于理解的和準(zhǔn)確把握。

2.傳統(tǒng)軟件工程規(guī)范在需求分析的嚴(yán)格執(zhí)行有實(shí)際管理上的難度。在廣大的應(yīng)用軟件開(kāi)發(fā)部門(mén)，軟件開(kāi)發(fā)工作的地位往往只是本單位業(yè)務(wù)的輔助，一般沒(méi)有專(zhuān)職的而且非常有經(jīng)驗(yàn)的系統(tǒng)分析員，需求分析往往由主管經(jīng)理和開(kāi)發(fā)程序員簡(jiǎn)單進(jìn)行，而領(lǐng)導(dǎo)往往重成績(jī)多于重過(guò)程，對(duì)于一個(gè)沒(méi)有顯效的需求分析過(guò)程，領(lǐng)導(dǎo)的耐心往往有限，這就造成了對(duì)需求分析缺乏嚴(yán)格的管理和要求。

3.嚴(yán)格按照軟件工程規(guī)范要求進(jìn)行需求分析在時(shí)間和開(kāi)發(fā)成本的限制。由于用戶(hù)對(duì)軟件技術(shù)的認(rèn)識(shí)水平，他們對(duì)軟件的開(kāi)發(fā)在時(shí)間上往往要求過(guò)高，特別當(dāng)用戶(hù)是單位的上層領(lǐng)導(dǎo)，他們往往覺(jué)得這種對(duì)他們而言空洞無(wú)物的分析是開(kāi)發(fā)人員的紙上談兵,時(shí)間一長(zhǎng)不免就會(huì)流露出不滿。這令開(kāi)發(fā)人員非常尷尬，往往非常嚴(yán)重地打擊他們的自信心和士氣。

綜上所述，傳統(tǒng)軟件工程規(guī)范中需求分析理論在實(shí)踐中的矛盾是成本，效率和規(guī)范要求間的矛盾。而忽略規(guī)范要求的代價(jià)也是慘重的，那我們能找到一種方法解決以上矛盾嗎？

大數(shù)據(jù)應(yīng)用的需求特點(diǎn)

 數(shù)據(jù)庫(kù)技術(shù)的核心思想是數(shù)據(jù)的獨(dú)立與共享，所以開(kāi)發(fā)數(shù)據(jù)應(yīng)用，就是利用云計(jì)算、數(shù)據(jù)庫(kù)、數(shù)據(jù)分析等技術(shù)來(lái)組織、管理和使用信息。不同形式的數(shù)據(jù)應(yīng)用可謂多種多樣，但功能需求的核心是圍繞著數(shù)據(jù)分析需求來(lái)展開(kāi)的。筆者曾開(kāi)發(fā)過(guò)多個(gè)不同應(yīng)用領(lǐng)域的數(shù)據(jù)應(yīng)用，我發(fā)現(xiàn)在數(shù)據(jù)應(yīng)用中雖然功能很多，許多功能在邏輯上相似，往往只是處理的數(shù)據(jù)不同，所以，筆者認(rèn)為數(shù)據(jù)應(yīng)用需求分析應(yīng)該圍繞數(shù)據(jù)(信息)，而不是軟件功能展開(kāi)。這與傳統(tǒng)的需求分析中以軟件的功能需求為核心有明顯的不同。從這個(gè)意義上，如果傳統(tǒng)需求分析階段是“做什么”，在數(shù)據(jù)應(yīng)用需求分析階段就是先要解決“有什么”，然后再明確“做什么”。

大數(shù)據(jù)需求分析工作方法

 需求分析作為軟件工程的第一階段，是整個(gè)軟件開(kāi)發(fā)項(xiàng)目進(jìn)行設(shè)計(jì)和實(shí)現(xiàn)的基礎(chǔ)，決定了一個(gè)項(xiàng)目的成敗。但是需求分析不能只看成是一個(gè)獨(dú)立的階段，對(duì)需求的了解貫穿整個(gè)項(xiàng)目的始終，了解需求的過(guò)程是一個(gè)逐步細(xì)化，逐步深入的過(guò)程，整個(gè)項(xiàng)目自始而終都需要與用戶(hù)交流。

 既然大數(shù)據(jù)應(yīng)用需求以數(shù)據(jù)為中心，在需求分析階段就強(qiáng)調(diào)數(shù)據(jù)和數(shù)據(jù)結(jié)構(gòu)的分析一點(diǎn)也不過(guò)分。圍繞數(shù)據(jù)應(yīng)用的需求分析大體上分為以下幾個(gè)階段：

1)場(chǎng)景需求分析(總體設(shè)計(jì))

2)概念需求分析(概念設(shè)計(jì))

3)細(xì)節(jié)需求分析(詳細(xì)設(shè)計(jì))

4)界面需求分析(界面設(shè)計(jì))

 這些需求分析貫穿整個(gè)項(xiàng)目的各個(gè)環(huán)節(jié)中，與設(shè)計(jì)是穿插在一起。

大數(shù)據(jù)需求分析過(guò)程活動(dòng)

1)場(chǎng)景需求分析

 這個(gè)階段體現(xiàn)了系統(tǒng)的總體構(gòu)思與設(shè)計(jì)，任務(wù)是了解系統(tǒng)的組織形式和功能需求概貌，解決“是什么”的問(wèn)題。我認(rèn)為場(chǎng)景需求分析主要任務(wù)是用戶(hù)應(yīng)用場(chǎng)景的定義，需要明確用戶(hù)將來(lái)是用何種方式、在什么條件下、如何用哪些數(shù)據(jù)解決什么問(wèn)題的場(chǎng)景，這當(dāng)然也會(huì)涉及到硬件，用戶(hù)環(huán)境，系統(tǒng)功能等多方面的全局考慮。如界面是手機(jī)APP應(yīng)用還是Web 應(yīng)用，如何進(jìn)行功能的分層。這些都需要在場(chǎng)景需求分析過(guò)程中決定。

 場(chǎng)景需求分析工作是大數(shù)據(jù)應(yīng)用項(xiàng)目的早期分析，所以對(duì)功能的描述應(yīng)該有高度的抽象性，在理想的情況下，一個(gè)系統(tǒng)最好由一張紙內(nèi)直觀圖形化描述，便于開(kāi)發(fā)人員對(duì)系統(tǒng)目標(biāo)的整體把握，也保持了與用戶(hù)交流的靈活性和一致性。所以在項(xiàng)目初期，我不贊成用功能模塊圖對(duì)功能需求做太多層次的金字塔式羅列，特別如果是系統(tǒng)的分布式分層設(shè)計(jì)，詳細(xì)的功能模塊圖在項(xiàng)目早期沒(méi)有什么實(shí)際意義，反而容易舍本求末。如對(duì)大數(shù)據(jù)應(yīng)用場(chǎng)景中數(shù)據(jù)范圍的分析中，可以用筆者前文所介紹的商業(yè)模式分析方法，從商業(yè)模式的角度對(duì)于數(shù)據(jù)范圍做明確的界定。

2)概念需求分析

 概念需求分析的任務(wù)是對(duì)系統(tǒng)中涉及的概念、數(shù)據(jù)范圍和內(nèi)容等進(jìn)行調(diào)查和分析，分析有什么信息、從什么地方可以可靠獲得，如何組織和描述數(shù)據(jù)，數(shù)據(jù)由那些數(shù)據(jù)項(xiàng)組成，各數(shù)據(jù)項(xiàng)是什么含義，數(shù)據(jù)的走向是什么樣的？概念需求分析的目的是建立系統(tǒng)的概念模型，主要是建立描述數(shù)據(jù)的靜態(tài)模型和描述系統(tǒng)運(yùn)行流程的動(dòng)態(tài)模型，解決“有什么”問(wèn)題。

 當(dāng)完成模型需求分析后，就要進(jìn)入到概念需求分析。做概念需求分析，首先要收集原始資料，然后請(qǐng)用戶(hù)講述手工的工作流程，根據(jù)用戶(hù)提供的原始資料和對(duì)工作流程的了解的基礎(chǔ)上，我們才可以著手進(jìn)行概念設(shè)計(jì)。

3)細(xì)節(jié)需求分析

 細(xì)節(jié)需求分析要在進(jìn)行了概念設(shè)計(jì)之后進(jìn)行，這個(gè)階段是分析如何具體實(shí)現(xiàn)用戶(hù)需求,就是解決“怎么做”的問(wèn)題。這個(gè)階段要對(duì)用戶(hù)的需求完整而清晰地確定下來(lái)，所以與用戶(hù)的交流比前兩個(gè)階段多，交流的內(nèi)容應(yīng)該更加具體。

 細(xì)節(jié)分析的具體任務(wù)是要根據(jù)概念設(shè)計(jì)定義的概念模型制定具體的實(shí)現(xiàn)細(xì)節(jié)。對(duì)于靜態(tài)模型，要給出詳細(xì)的數(shù)據(jù)字典，包括了表，數(shù)據(jù)項(xiàng)，數(shù)據(jù)項(xiàng)限制條件等詳細(xì)信息。對(duì)于動(dòng)態(tài)模型，要給出具體的狀態(tài)定義，事件定義，狀態(tài)改變的流程，對(duì)數(shù)據(jù)所有操作的定義等等詳細(xì)的設(shè)計(jì)信息。要求根據(jù)細(xì)節(jié)需求分析的成果應(yīng)該能成為編碼和建庫(kù)的依據(jù)。

   對(duì)于大數(shù)據(jù)應(yīng)用，可能還要明確的是采用怎樣的大數(shù)據(jù)技術(shù)架構(gòu)（例如Hadoop）和數(shù)據(jù)挖掘模型，隨著開(kāi)源技術(shù)的普及，目前成熟的大數(shù)據(jù)工具和數(shù)據(jù)挖掘模型選擇已經(jīng)很多，實(shí)際上很多數(shù)據(jù)應(yīng)用的開(kāi)發(fā)工作就是在現(xiàn)有的一些大數(shù)據(jù)分析工具的基礎(chǔ)上結(jié)合應(yīng)用場(chǎng)景需求來(lái)做些配置性的簡(jiǎn)單編碼就可以了，沒(méi)有必要做一些重新發(fā)明輪子的事情。

4)界面需求分析

 用戶(hù)能否用好軟件最終決定項(xiàng)目的成敗，良好的用戶(hù)使用界面是不可忽視的。用戶(hù)界面的好壞并不是追求界面的花巧(這是程序員經(jīng)常犯的毛病),而是界面的設(shè)計(jì)是否能提高用戶(hù)使用軟件的效率，這需要了解用戶(hù)的使用環(huán)境，操作水平，操作習(xí)慣，個(gè)人喜好等多方面。輸入輸出需求分析要做到界面設(shè)計(jì)和概念設(shè)計(jì)的相互獨(dú)立，不能因?yàn)榻缑娴谋硎居绊懜拍钤O(shè)計(jì)的穩(wěn)定，同時(shí)也要保持能適應(yīng)用戶(hù)各種不同操作要求的靈活性。具體可以先和用戶(hù)共同草擬一些界面設(shè)計(jì)大綱，在開(kāi)發(fā)過(guò)程中邀請(qǐng)用戶(hù)試用軟件，根據(jù)反饋意見(jiàn)不斷改進(jìn)和修改。

大數(shù)據(jù)需求表達(dá)工具的考慮

 我們分析“有什么”信息，傳統(tǒng)的需求分析理論用數(shù)據(jù)流圖和數(shù)據(jù)字典來(lái)表達(dá)“有什么”信息對(duì)大數(shù)據(jù)應(yīng)用可能不是特別合適。傳統(tǒng)的數(shù)據(jù)流圖核心是面向軟件功能的，而在許多大數(shù)據(jù)數(shù)據(jù)庫(kù)應(yīng)用系統(tǒng)開(kāi)發(fā)初期，在沒(méi)有清晰完整的大數(shù)據(jù)信息內(nèi)容構(gòu)成分析前，功能的需求往往難以穩(wěn)定。在大數(shù)據(jù)應(yīng)用的需求分析初期，我不提倡使用數(shù)據(jù)流圖，因?yàn)樵诖髷?shù)據(jù)應(yīng)用中，數(shù)據(jù)流圖往往不能令人滿意地說(shuō)明信息構(gòu)成問(wèn)題，而且隨著數(shù)據(jù)的增加，功能流程的變遷需要經(jīng)常修改早期的設(shè)計(jì)，這會(huì)造成工作的反復(fù)。數(shù)據(jù)字典可以表達(dá)數(shù)據(jù)的構(gòu)成，但卻沒(méi)有定義數(shù)據(jù)的類(lèi)型。在一個(gè)大數(shù)據(jù)應(yīng)用中，數(shù)據(jù)的類(lèi)型的通過(guò)字段類(lèi)型表達(dá)，有開(kāi)發(fā)經(jīng)驗(yàn)的人應(yīng)該知道，清楚每一個(gè)數(shù)據(jù)字段的含義和類(lèi)型在開(kāi)發(fā)數(shù)據(jù)庫(kù)應(yīng)用中有重要的意義，試想一下，如果一個(gè)數(shù)據(jù)格式是視頻或者圖像，對(duì)數(shù)據(jù)的功能需求不言而喻。而傳統(tǒng)的需求分析過(guò)程不要求確定數(shù)據(jù)的具體類(lèi)型，而在開(kāi)發(fā)一個(gè)數(shù)據(jù)應(yīng)用時(shí)，需求分析階段忽略了這一步就會(huì)毫無(wú)疑問(wèn)地造成對(duì)需求理解的模糊，并使得需求分析變成空洞無(wú)物的紙上談兵。所以，對(duì)于數(shù)據(jù)應(yīng)用需求分析的表達(dá)，最好還是和業(yè)務(wù)場(chǎng)景的分析結(jié)合在一起，筆者推薦使用質(zhì)量管理大師戴明(Deming)博士發(fā)明的SPIOC方法。

   SIPOC模型是一代質(zhì)量大師戴明提出來(lái)的組織系統(tǒng)模型，是一門(mén)最有用而且最常用的，用于流程管理和改進(jìn)的技術(shù)。是過(guò)程管理和改進(jìn)的常用技術(shù)，作為識(shí)別核心過(guò)程的首選方法。

   為什么筆者推薦這個(gè)貌似是跟IT界不太搭邊的管理學(xué)方面的模型呢？從接下來(lái)的示例可以看到，在SPIOC里面，我們可以看清楚兩方面的數(shù)據(jù)需求，一方面是業(yè)務(wù)流程工作本身要處理的數(shù)據(jù)，另外一方面是更有應(yīng)用前景的分析業(yè)務(wù)過(guò)程效率中的條件測(cè)量指標(biāo)（KPI）和成果測(cè)量指標(biāo)（KPO）數(shù)據(jù)，這兩個(gè)指標(biāo)性數(shù)據(jù)是支持不斷優(yōu)化業(yè)務(wù)流程、最終達(dá)到精益目的的必要手段，數(shù)字孿生理念之父Michael Grieves說(shuō)得好：“信息是被浪費(fèi)的物理資源的替代品;在精益的理念世界里，我們最終能實(shí)現(xiàn)用最少的資源數(shù)生產(chǎn)產(chǎn)品的目標(biāo)”。沒(méi)有數(shù)據(jù)支撐的精益是無(wú)法落地的，這樣數(shù)據(jù)應(yīng)用的價(jià)值就不言而喻了。

產(chǎn)品光有精益是不夠的，產(chǎn)品也必須是創(chuàng)新的，不僅要減少資源的浪費(fèi)，同時(shí)也要?jiǎng)?chuàng)造新的信息和知識(shí)，使得創(chuàng)新產(chǎn)品成為可能。從這個(gè)方面來(lái)說(shuō)，今天做業(yè)務(wù)的過(guò)程也是一個(gè)不斷積累數(shù)據(jù)資源的過(guò)程，這樣才能為創(chuàng)新奠基大數(shù)據(jù)的基礎(chǔ)。

（本稿完成于2018年9月30日，如需要引用，請(qǐng)注明出處）