如何分析APP功能需求及結構

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

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

3、的領域有不同的表達標準，想要在不同領域都能準確表達同一個意思，將是非常困難的事情。在計算機領域，信息系統(tǒng)的APP的設計過程非常的復雜，不只是純粹的描述計算機處理流程則簡單，還包括了抽象過程建模過程，設計過程包括系統(tǒng)流程設計、功能設計、權限設計、用戶體驗設計、異常處理設計等等，測試過程建立demo，必要的驗證。而在這些過程中，建模環(huán)節(jié)是最為重要，也是最為復雜的一個步驟。舉個例子來說明為什么說業(yè)務建模過程最為關鍵、也最為復雜：假設家里有很多的雜物被堆放在不同的角落里，有衣服，褲子，鞋子，碗，清潔劑，錘子，可折疊的小凳子等等，家里每個人都會用到其中的*些物品。久而久之，大家都覺得這些東西胡亂放置，既

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

5、找哪些物品做哪些事情，什么時候又復原回去？流程2、這些物品有些什么保管的要求？功能需求3、你希望去哪里去取最方便？非功能需求4、有別人和你一起用這些物品嗎？權限要求5、大致預算在什么圍，等等限制條件對需求展開分析，進入設計和構造階段。即需求的定義過程Define Scope1、對收集的信息展開分析。保存有用的，去除一樣的和無意義的需求。需求過濾2、對物品進展逐一的分析，整理歸類。確定物品分作哪些類別，例如，衣服類，鞋類，餐具類，清潔劑類，工具類，小家具類等。分類&抽象3、確定每個類別的行為特性，尺寸大小，放置要求等。例如，衣服類物品要求存放于封閉、枯燥的環(huán)境，拿取方便、好查找，局部衣服要求掛放

6、，需要足夠的空間；鞋類要求每雙鞋都單獨放置，存放時能具備一定的空氣流動性，要方便查找和拿??；餐具類，要求單獨存放，最好放在與水池較近的地方，要求能封閉放置，能在需要的時候進展通風枯燥處理，儲物構造的材料要求防水；清潔劑類，沒有特別要求，只需要和衣服類，餐具類分開存放即可；工具類，抽象&分析形成初步的設計方案。設計思路為，配置兩個不同的儲物柜解決儲物的問題。一、在靠近廚房的角落設計一個三欄式的壁掛組合儲物柜，采用防火，防腐蝕的UV板材。設計為掛式的原因是，節(jié)省房屋的空間，利于時常翻開柜門通風；大人拿取方便，也防止小孩子隨意拿取玩耍而摔破；三欄構造可以分開放置餐具類、清潔劑類物品和工具類物品，空間

7、設計更為合理。二、在靠近臥室的角落放置一個落地的多功能儲物柜。儲物柜設計為三層的實木構造，下層主要放置鞋類，其后面板和隔檔板采用鏤空設計，置4個隔層，總體高度約占柜體的1/4。鏤空和隔層設計主要起到通風枯燥和分類放置便于取放的作用；中間層為抽屜式設計，主要放置可以摺疊放置的衣物；而一些需要掛置的衣服則掛放在上層。在儲物柜的頂上還可以放置一些小家具，例如摺疊的凳子，卷席等。另外，采用全實木材料還以防止甲醛等有害物質的侵害。建模過程驗證設計的成果是否滿足干系人需要。即圍確認過程Verify Scope形成結論后，召集相關干系人商議、評估方案。一般依據(jù)業(yè)務程度，可以采用簡單的評審團隊部小圍的評審或復

8、雜有客戶、用戶或者專家參與的評審方式。一旦方案得到大家的認可，則可以進入實施過程了，這時可以再推舉一個人作為實施的負責協(xié)調人，由他來控制預算，制定行動方案，確定需求的優(yōu)先級別，落實方案的執(zhí)行。從上面的例子可以看到，設計和構造階段中建模Build Model是整個APP設計過程中最具有技術含量的一個環(huán)節(jié)，不僅需要依靠知識和經(jīng)歷，還需要較強的邏輯能力，構思和籌劃能力。其實，這么多年來我們在做需求分析和建模時，也是有一定的規(guī)律可遵循的，我用一句話來概括就是：從業(yè)務對象入手，識別業(yè)務對象的行為，抽象APP，從而構造系統(tǒng)模型。下面用網(wǎng)上訂票的例子來詳細說明我們的做法：假設，我們已經(jīng)知道了用戶的業(yè)務流程。

9、第一步：用戶通過瀏覽器登錄web，瀏覽和查詢需要的信息。第二步：選擇票，填寫訂單信息，確認個人的信息，以方便取票時核對。第三步：通過提供的支付方式，在線完成支付。第四步：系統(tǒng)生成電子票號，并短信通知訂票人，告知用戶出票相關的信息和兌票方法。具體參見下列圖：前面我們說到：業(yè)務的核心是數(shù)據(jù)。所以，理清業(yè)務的根底是分析清楚業(yè)務下流動的數(shù)據(jù)都有哪些，這些數(shù)據(jù)分別代表了什么意義，對應了哪些業(yè)務對象。所以，第一步我們分析業(yè)務中包含了哪些業(yè)務對象。業(yè)務對象分析確定BO在線訂票業(yè)務中，有登錄、填寫訂單、支付和出票四個環(huán)節(jié)。仔細分析，我們發(fā)現(xiàn)，這四個環(huán)節(jié)分別包括了四個相對獨立的業(yè)務對象：用戶、訂單、賬單和票。這

10、里沒有把手機短信也列為一個業(yè)務對象訂票過程的所有活動都是圍繞這四個對象來開展的，少了任何一個對象，這個流程都是不完整的。則在識別BO的時候，我總結了幾個簡單的標準：1、該業(yè)務對象是否有一定的明確業(yè)務含義，如果少了這個BO業(yè)務流程將不完整。2、業(yè)務流程中一定有一個或多個環(huán)節(jié)是有這個BO參與的。3、大多數(shù)BO往往是可以映射到現(xiàn)實生活中的*一類物體的。例如，人，賬單，公司，系統(tǒng)，卡，存折，車輛，等等。另外，我們在判斷是否所有的業(yè)務對象都被識別時，也有一個很簡單的判斷標準：業(yè)務流程中可能涉及的數(shù)據(jù)容都與已經(jīng)識別的業(yè)務對象能嚴密關聯(lián)上。在確定BO后，需要分析和識別所有與業(yè)務對象相關的行為。識別與BO相關

11、的行為BO屬性和行為分析BO本身是有意義的，這些意義可以被細化為一些屬性。我理解，屬性就是說明和識別BO*一方面的一些具體標識或參數(shù)。識別業(yè)務對象屬性時，最重要是能分清楚哪些屬性是與目前工作圍相關的。例如，用戶有很多屬性，但高矮胖瘦這些與我們正在分析的電子商務系統(tǒng)毫無關系，所以，找到BO屬性并準確過濾才是這個過程的關鍵行為。在正式的團隊協(xié)作過程中，必須要對每個BO，BO的屬性和BO的行為進展統(tǒng)一編號標識。我們在識別BO的行為時，可以分為三個層次：1、從業(yè)務流程中識別。從流程中只能識別一局部BO的行為，這一局部行為往往被稱之為業(yè)務行為；也是BO最容易確定的一類行為，只要流程定義清楚了，這類行為就

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

13、如，在識別BO行為的過程中，我們往往會遇到一些模棱兩可的境地，例如，商品和購物車是兩個不同的業(yè)務對象，則將商品添加到購物車的行為，是歸屬商品的行為，還是購物車的行為呢？有人說是購物車的行為；有人反問，為何這個行為主要出現(xiàn)在商品的單頁上？我的意見是：當行為涉及到兩個對象，一般把其歸屬到擁有管理職能的對象。購物車管理被放入的商品，管理放入的數(shù)量，也可以從購物車中刪除。所以，放入購物車的行為主體對象是購物車。識別了BO，BO的屬性以及BO的行為后，我們可以開場建立APP了。建立APP建立APP的過程是明確系統(tǒng)圍的過程，同時也是生成系統(tǒng)模型的過程。建立APP有兩種視角：1、一種是以BO為視角，聚合BO

14、的行為，以管理BO的功能組成一個APP；例如，我們將針對訂單的所有行為，組合成為一個APP，稱為訂單管理。2、另外一種是以業(yè)務為視角，聚合一個流程的所有環(huán)節(jié)，以實現(xiàn)流程的功能組成一個APP。例如，我們將針對打折票的預定流程中的所有行為環(huán)節(jié)，組合成為一個APP，稱為折扣票預定APP。具體參見下列圖：但不管怎么組織APP的構成，在BO層面看，都是一樣的：系統(tǒng)都是由操作BO的一堆行為構成的。上面是從業(yè)務分析BO，分析BO的屬性行為，然后組織APP。然而，此刻還不能完成系統(tǒng)模型的構建，因為還需要思考這些已經(jīng)被識別的APP是否足夠支撐一個應用系統(tǒng)？這里需要引入兩個重要設計分析過程：一個是用戶體驗設計，一

15、個是非功能設計。用戶體驗設計User E*perience是以用戶為中心的設計，是一種經(jīng)歷與創(chuàng)造相結合的設計過程，主要目的是提升用戶的操作舒適感，增強在同類產品中的競爭力。在web2.0時代，用戶體驗設計將不再局限于展現(xiàn)流程和完成數(shù)據(jù)操作方面，還承載了不同角色之間的信息多元化交互的設計需要，以用戶為核心將不再是簡單的信息提供推送而已。則，在構建系統(tǒng)的APP時，也要充分的考慮UE設計的需要，參加一些用于提升用戶體驗的APP，例如，Dashboard。非功能設計來源于用戶的非功能需求，例如，系統(tǒng)的可管理要求，靈活擴展要求，性能要求，平安要求等。這些設計除了在系統(tǒng)的架構設計時需要充分的考慮和滿足，在功能APP設計時也需要做相應的響應。例如，最常見的一個APP-系統(tǒng)管理，通常包含數(shù)據(jù)管理，日志管理，參數(shù)管理，模型管理，模版管理，接口管理，APP管理等等。這些來源于UE設計和非功能設計的APP與最早被識別的業(yè)務APP共同構成了系