如何分析APP功能需求及結(jié)構(gòu)

1、如何分析APP功能需求及結(jié)構(gòu)APP分析過程在工程管理體系PMBOK中歸屬于工程范圍定義Define Scope過程。從PMBOK的角度來看，在完成需求收集Collect Requirements 后，需要對工程和產(chǎn)品的詳細(xì)范圍進(jìn)行描述，清晰完整的工程/產(chǎn)品范圍說明書有利于制定出具有良好執(zhí)行性的 WBSWork Breakdown Structure，但其更 為重要的意義在于科學(xué)的構(gòu)建了用戶所需要的系統(tǒng)功能架構(gòu)。從業(yè)務(wù)演變到系統(tǒng)的角度來看，APP是業(yè)務(wù)在系統(tǒng)的具體呈現(xiàn)，APP的分 析過程是將業(yè)務(wù)語言翻譯為機(jī)器語言的表現(xiàn)。只不過這不是普通的翻譯，是包含 了智力和經(jīng)驗(yàn)的過程。所以，對于電腦信息領(lǐng)域的

2、技術(shù)專家來說， 更需要去學(xué)習(xí) 和掌握跨領(lǐng)域的業(yè)務(wù)語言，并在不同領(lǐng)域的交界處形成明確的定義， 實(shí)現(xiàn)不同語 言間的準(zhǔn)確對應(yīng)。舉個(gè)例子，假設(shè)在電子商務(wù)領(lǐng)域里有一個(gè)業(yè)務(wù)，我們稱之為A :用戶通過網(wǎng)站填寫了一份購置汽車坐墊的訂單，付款成功后可以通過連接電腦的打印機(jī)自 動打印一份A4幅面標(biāo)準(zhǔn)格式確實(shí)認(rèn)單。那么在信息系統(tǒng)的世界里，A被翻譯為：1、用戶通過web表單填寫完訂單內(nèi)容后；2、在線支付。2.1、如果支付不成功， 系統(tǒng)提示用戶哪里出現(xiàn)錯誤，并引導(dǎo)用戶修正錯誤。2.2、如果支付成功，系統(tǒng)提示用戶：訂單已經(jīng)生效，系統(tǒng)即將打印確認(rèn)單。3、系統(tǒng)傳遞打印控制信息，打印機(jī)負(fù)責(zé)打印出指定格式的文件。4、系統(tǒng)提示交易

3、完成。上面的例子說明了不同的領(lǐng)域有不同的表達(dá)標(biāo)準(zhǔn)，想要在不同領(lǐng)域都能準(zhǔn) 確表達(dá)同一個(gè)意思，將是非常困難的事情。在電腦領(lǐng)域，信息系統(tǒng)的APP的設(shè)計(jì)過程非常的復(fù)雜，不只是純粹的描述 電腦處理流程那么簡單，還包括了抽象過程建模過程，設(shè)計(jì)過程包括系統(tǒng)流程設(shè)計(jì)、功能設(shè)計(jì)、權(quán)限設(shè)計(jì)、用戶體驗(yàn)設(shè)計(jì)、異常處理設(shè)計(jì)等等，測試過 程建立demo，必要的驗(yàn)證。而在這些過程中，建模環(huán)節(jié)是最為重要，也是最為復(fù)雜的一個(gè)步驟。舉個(gè)例子來說明為什么說業(yè)務(wù)建模過程最為關(guān)鍵、也最為復(fù)雜：假設(shè)家里有很多的雜物被堆放在不同的角落里，有衣服，褲子，鞋子，碗，清潔劑，錘子，可折疊的小凳子等等，家里每個(gè)人都會用到其中的某些物品。久 而久之

4、，大家都覺得這些東西胡亂放置，既不利于保管、用時(shí)也不方便找到。于 是，大家推舉你來解決這個(gè)問題，并給你提出了很多好的建議。例如，把這些東 西整理到一個(gè)角落放置，給每個(gè)物品一個(gè)固定的位置，可以請木工打個(gè)大木箱子 來放置，也可以去家具商店買個(gè)好點(diǎn)的柜子來放置， 又或者買幾個(gè)大的袋子分類 來裝。最后，一家之長告誡你：在投資允許的情況下，盡可能的選擇最好的一種 方案來滿足家里所有人的需求。那么這個(gè)時(shí)候，你應(yīng)該怎么去做呢？讓我來試著描繪一種可能成功的做法。?首先，對每個(gè)人的需求進(jìn)行登記。即收集需求的過程Collect Requirements 詳細(xì)的與每個(gè)干系人Stakeholder進(jìn)行溝通，識別出每個(gè)

5、人的一些行為特性， 例如：1、你一般什么時(shí)候會去哪兒找哪些物品做哪些事情，什么時(shí)候又復(fù)原回去？流 程2、 這些物品有些什么 保管的要求？功能需求3、你希望去哪里去取最方便？非功能需求4、有別人和你一起用這些物品嗎？權(quán)限要求5、大致預(yù)算在什么范圍，等等限制條件?對需求展開分析，進(jìn)入設(shè)計(jì)和構(gòu)造階段。即需求的定義過程Define Scope1、 對收集的信息展開分析。保存有用的，去除相同的和無意義的需求。需求 過濾2、對物品進(jìn)行逐一的分析，整理歸類。確定物品分作哪些類別，例如，衣服類， 鞋類，餐具類，清潔劑類，工具類，小家具類等。 分類&抽象3、確定每個(gè)類別的行為特性，尺寸大小，放置要求等。

6、例如，衣服類物品要求 存放于封閉、枯燥的環(huán)境，拿取方便、好查找，局部衣服要求掛放，需要足夠的 空間；鞋類要求每雙鞋都單獨(dú)放置，存放時(shí)能具備一定的空氣流動性，要方便查 找和拿??；餐具類，要求單獨(dú)存放，最好放在與水池較近的地方，要求能封閉放置，能在需要的時(shí)候進(jìn)行通風(fēng)枯燥處理，儲物構(gòu)造的材料要求防水；清潔劑類， 沒有特別要求，只需要和衣服類，餐具類分開存放即可；工具類，抽象&分析形成初步的設(shè)計(jì)方案。設(shè)計(jì)思路為，配置兩個(gè)不同的儲物柜解決儲物的問題。一、 在靠近廚房的角落設(shè)計(jì)一個(gè)三欄式的壁掛組合儲物柜，采用防火，防腐蝕的UV板材。設(shè)計(jì)為掛式的原因是，節(jié)省房屋的空間，利于時(shí)常翻開柜門通風(fēng)；大人拿取

7、方便，也防止小孩子隨意拿取玩耍而摔破； 三欄結(jié)構(gòu)可以分開放置餐具類、 清 潔劑類物品和工具類物品，空間設(shè)計(jì)更為合理。二、在靠近臥室的角落放置一個(gè) 落地的多功能儲物柜。儲物柜設(shè)計(jì)為三層的實(shí)木結(jié)構(gòu)，下層主要放置鞋類，其后 面板和內(nèi)隔檔板采用鏤空設(shè)計(jì)，內(nèi)置 4個(gè)隔層，總體高度約占柜體的1/4。鏤空 和隔層設(shè)計(jì)主要起到通風(fēng)枯燥和分類放置便于取放的作用；中間層為抽屜式設(shè)計(jì),主要放置可以摺疊放置的衣物；而一些需要掛置的衣服那么掛放在上層。在儲物柜的頂上還可以放置一些小家具，例如摺疊的凳子，卷席等。另外，采用全實(shí)木材料還以防止甲醛等有害物質(zhì)的侵害。建模過程?驗(yàn)證設(shè)計(jì)的成果是否滿足干系人需要。即范圍確認(rèn)過程

8、Verify Scope 形成結(jié)論后，召集相關(guān)干系人商議、評估方案。一般依據(jù)業(yè)務(wù)程度，可以采用簡 單的評審團(tuán)隊(duì)內(nèi)部小范圍的評審或復(fù)雜有客戶、用戶或者專家參與的評 審方式。一旦方案得到大家的認(rèn)可，那么可以進(jìn)入實(shí)施過程了，這時(shí)可以再推舉一個(gè)人作為 實(shí)施的負(fù)責(zé)協(xié)調(diào)人，由他來控制預(yù)算，制定行動方案，確定需求的優(yōu)先級別，落 實(shí)方案的執(zhí)行。從上面的例子可以看到，設(shè)計(jì)和構(gòu)造階段中建模Build Model是整個(gè)APP 設(shè)計(jì)過程中最具有技術(shù)含量的一個(gè)環(huán)節(jié)， 不僅需要依靠知識和經(jīng)驗(yàn)，還需要較強(qiáng) 的邏輯能力，構(gòu)思和籌劃能力。其實(shí)，這么多年來我們在做需求分析和建模時(shí)， 也是有一定的規(guī)律可遵循的，我 用一句話來概括就

9、是：從業(yè)務(wù)對象入手，識別業(yè)務(wù)對象的行為，抽象 APP，從 而構(gòu)造系統(tǒng)模型。下面用網(wǎng)上訂票的例子來詳細(xì)說明我們的做法：假設(shè)，我們已經(jīng)知道了用戶的業(yè)務(wù)流程。第一步：用戶通過瀏覽器登錄 web網(wǎng)站，瀏覽和查詢需要的信息。第二步：選擇票，填寫訂單信息，確認(rèn)個(gè)人的信息，以方便取票時(shí)核對。第三步：通過網(wǎng)站提供的支付方式，在線完成支付。第四步：系統(tǒng)生成電子票號，并短信通知訂票人，告知用戶出票相關(guān)的信息和兌 票方法。具體參見以下圖：業(yè)務(wù)I (Booking Tkkets1 t t« tI1:謝f承HI«11 tA p P分析4丁 - J&7an almi *aJtU日君 取十 r4

10、*71 *»紀(jì).m.dAppg：業(yè)村HttlfeO AtBM1出皋fW董忖珈 磨低0屏鬲?dú)毨鞥nntiofiS:前面我們說到：業(yè)務(wù)的核心是數(shù)據(jù)。所以，理清業(yè)務(wù)的根底是分析清楚業(yè)務(wù)下流動的數(shù)據(jù)都有哪些，這些數(shù)據(jù)分別代表了什么意義，對應(yīng)了哪些業(yè)務(wù)對象 所以，第一步我們分析業(yè)務(wù)中包含了哪些業(yè)務(wù)對象。?業(yè)務(wù)對象分析確定BO在線訂票業(yè)務(wù)中，有登錄、填寫訂單、支付和出票四個(gè)環(huán)節(jié)。仔細(xì)分析，我們發(fā)現(xiàn)，這四個(gè)環(huán)節(jié)分別包括了四個(gè)相對獨(dú)立的業(yè)務(wù)對象：用戶、訂單、賬單 和票。這里沒有把短信也列為一個(gè)業(yè)務(wù)對象訂票過程的所有活動都是圍繞這四個(gè)對象來開展的， 少了任何一個(gè)對象，這個(gè)流 程都是不完整的。那么在識別

11、BO的時(shí)候，我總結(jié)了幾個(gè)簡單的標(biāo)準(zhǔn)：1、該業(yè)務(wù)對象是否有一定的明確業(yè)務(wù)含義， 如果少了這個(gè)BO業(yè)務(wù)流程將不完 整。2、業(yè)務(wù)流程中一定有一個(gè)或多個(gè)環(huán)節(jié)是有這個(gè) BO參與的。3、大多數(shù)BO往往是可以映射到現(xiàn)實(shí)生活中的某一類物體的。 例如，人，賬單，公司，系統(tǒng)，卡，存折，車輛，身份證等等。另外，我們在判斷是否所有的業(yè)務(wù)對象都被識別時(shí)， 也有一個(gè)很簡單的判斷標(biāo)準(zhǔn)： 業(yè)務(wù)流程中可能涉及的數(shù)據(jù)內(nèi)容都與已經(jīng)識別的業(yè)務(wù)對象能緊密關(guān)聯(lián)上。在確定BO后，需要分析和識別所有與業(yè)務(wù)對象相關(guān)的行為。?識別與BO相關(guān)的行為BO屬性和行為分析BO本身是有意義的，這些意義可以被細(xì)化為一些屬性。我理解，屬性就是說明 和識別BO

12、某一方面的一些具體標(biāo)識或參數(shù)。識別業(yè)務(wù)對象屬性時(shí)，最重要是能分清楚哪些屬性是與目前工作范圍相關(guān)的。例如，用戶有很多屬性，但高矮胖瘦這些與我們正在分析的電子商務(wù)系統(tǒng)毫無關(guān)系，所以，找到BO屬性并準(zhǔn)確過濾才是這個(gè)過程的關(guān)鍵行為BO屬H整陣BOh屬性希用戶人HBO-1用戶 g(BO-l-Al>在系筑內(nèi)唯一禎*國際標(biāo)準(zhǔn)男j女F未MR3在正式的團(tuán)隊(duì)協(xié)作過程中，必須要對每個(gè) BO，BO的屬性和BO的行為進(jìn)行 統(tǒng)一編號標(biāo)識。我們在識別BO的行為時(shí)，可以分為三個(gè)層次：1、從業(yè)務(wù)流程中識別。從流程中只能識別一局部 BO的行為，這一局部行為往 往被稱之為業(yè)務(wù)行為；也是 BO最容易確定的一類行為，只要流程定義

13、清楚了， 這類行為就已經(jīng)被確定了。例如，在上面的例子中，用戶在流程中有登錄和注冊 行為；針對訂單對象，有填寫訂單，提交訂單行為；賬單對象有支付行為等。2、從分析BO的完整性來識別。例如，用戶有登錄，就一定有注銷行為；訂單 能新增，一定可以修改和查詢；賬單能支付，也可以退款。3、從外部的需要來識別。例如，電子票本身是沒有核對識別需要的，但考慮到平安性，一些運(yùn)營商還是考慮了將電子票號進(jìn)行了加密處理，票號本身含有身份識別信息。一旦電子票號遺失，只要有身份證信息，那么電子票仍能使用。通過三個(gè)層次的分析，一般能識別出絕大局部的 BO行為，當(dāng)然，還需要對這些 識別的行為進(jìn)行統(tǒng)一的描述。描述的內(nèi)容包括行為名

14、稱，行為說明，涉及的 BO 屬性和變化。例如，B0行為整擲88說明屬性狀態(tài)變化用戶人屮BO-1*3CBO-1-01 ) 口輸入用戶笆、密碼、校驗(yàn) 碼后與身份息犠對無 誤f允許登錄到殺統(tǒng)存用戶狀態(tài)未登錄已登錄4在識別BO行為的過程中，我們往往會遇到一些模棱兩可的境地，例如，商品和購物車是兩個(gè)不同的業(yè)務(wù)對象， 那么將商品添加到購物車的行為，是歸屬商品的行為，還是購物車的行為呢？有人說是購物車的行為；有人反問，為何這個(gè)行為主要出現(xiàn)在商品的單頁上？我的意見是：當(dāng)行為涉及到兩個(gè)對象，一般把其歸屬到擁有管理職能的對象。購物車管理被放入的商品，管理放入的數(shù)量，也可以從購物車中刪除。所以， 放入購物車的行為主

15、體對象是購物車。識別了 BO，BO的屬性以及BO的行為 后，我們可以開始建立 APP 了。?建立APP建立APP的過程是明確系統(tǒng)范圍的過程，同時(shí)也是生成系統(tǒng)模型的過程。建立APP有兩種視角：1、一種是以BO為視角，聚合BO的行為，以管理BO的功能組成一個(gè)APP ； 例如，我們將針對訂單的所有行為，組合成為一個(gè) APP，稱為訂單管理。2、另外一種是以業(yè)務(wù)為視角，聚合一個(gè)流程的所有環(huán)節(jié)，以實(shí)現(xiàn)流程的功能組 成一個(gè)APP。例如，我們將針對打折票的預(yù)定流程中的所有行為環(huán)節(jié)，組合成 為一個(gè)APP，稱為折扣票預(yù)定APP。具體參見以下圖：聚合B0的行為jff行為Xpp視圖、BO二 BO以BO為中心BO但不管

16、怎么組織APP的構(gòu)成，在BO層面看，都是一樣的：系統(tǒng)都是由操作BO 的一堆行為構(gòu)成的 上面是從業(yè)務(wù)分析B0,分析BO的屬性行為，然后組織 APP。然而，此刻還不能完成系統(tǒng)模型的構(gòu)建，因?yàn)檫€需要思考這些已經(jīng)被識別的APP是否足夠支撐一個(gè)應(yīng)用系統(tǒng)？這里需要引入兩個(gè)重要設(shè)計(jì)分析過程：一個(gè)是用戶體驗(yàn)設(shè)計(jì)，一個(gè)是非功能設(shè)計(jì) 用戶體驗(yàn)設(shè)計(jì)User Experienee丨是以用戶為中心的設(shè)計(jì)，是一種經(jīng)驗(yàn)與創(chuàng)造 相結(jié)合的設(shè)計(jì)過程，主要目的是提升用戶的操作舒適感，增強(qiáng)在同類產(chǎn)品中的競 爭力。在web2.0時(shí)代，用戶體驗(yàn)設(shè)計(jì)將不再局限于展現(xiàn)流程和完成數(shù)據(jù)操作方 面，還承載了不同角色之間的信息多元化交互的設(shè)計(jì)需要，以用戶為核心將不再是簡單的信息提供推送而已。那么，在構(gòu)建系統(tǒng)的APP時(shí)，也要充分的考慮UE設(shè)計(jì)的需要，參加一些 用于提升用戶體驗(yàn)的APP，例如，Dashboard。非功能設(shè)計(jì)來源于用戶的非功能需求，例如，系統(tǒng)的可管理要求，靈活擴(kuò)展 要求，性能要求，平安要求等。這些設(shè)計(jì)除了在系統(tǒng)的架構(gòu)設(shè)計(jì)時(shí)需要充分的考 慮和滿足，在功能APP設(shè)計(jì)時(shí)也需要做相應(yīng)的響應(yīng)。 例如，最常見的一個(gè)APP- 系統(tǒng)管理，通常包含數(shù)據(jù)管理，日志管理，參數(shù)管理，模型管理，模版管理，接 口管理，APP管理等等。這些來源于 UE設(shè)計(jì)和非功能設(shè)計(jì)的APP與最早被識