app的功能不是你想多就多的届慈，也不是參照你的主觀來確定功能的陵像，如果是這樣的話呀伙，app的開發(fā)效果可想而知知举，app的功能確定是要經(jīng)過用戶需求分析瞬沦，這個功能的添加對整個app的作用來確定的，下面為大家介紹如何分析APP功能需求雇锡、結(jié)構(gòu)逛钻。
APP分析過程在項目管理體系PMBOK中歸屬于項目范圍定義（Define Scope）過程。從PMBOK的角度來看遮糖，在完成需求收集（Collect Requirements）后绣的，需要對項目和產(chǎn)品的詳細范圍進行描述，清晰完整的項目/產(chǎn)品范圍說明書有利于制定出具有良好執(zhí)行性的WBS（Work Breakdown Structure），但其更為重要的意義在于科學(xué)的構(gòu)建了用戶所需要的系統(tǒng)功能架構(gòu)屡江。
從業(yè)務(wù)演變到系統(tǒng)的角度來看芭概，APP是業(yè)務(wù)在系統(tǒng)的具體呈現(xiàn)，APP的分析過程是將業(yè)務(wù)語言翻譯為機器語言的表現(xiàn)惩嘉。只不過這不是普通的翻譯罢洲，是包含了智力和經(jīng)驗的過程。所以文黎，對于計算機信息領(lǐng)域的技術(shù)專家來說惹苗，更需要去學(xué)習(xí)和掌握跨領(lǐng)域的業(yè)務(wù)語言，并在不同領(lǐng)域的交界處形成明確的定義耸峭，實現(xiàn)不同語言間的準(zhǔn)確對應(yīng)桩蓉。
舉個例子，假設(shè)在電子商務(wù)領(lǐng)域里有一個業(yè)務(wù)劳闹，我們稱之為A：用戶通過網(wǎng)站填寫了一份購買汽車坐墊的訂單院究，付款成功后可以通過連接電腦的打印機自動打印一份A4幅面標(biāo)準(zhǔ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)即將打印確認單窿冯。3骗奖、系統(tǒng)傳遞打印控制信息，打印機負責(zé)打印出指定格式的文件醒串。4执桌、系統(tǒng)提示交易完成。
上面的例子說明了不同的領(lǐng)域有不同的表達標(biāo)準(zhǔn)芜赌，想要在不同領(lǐng)域都能準(zhǔn)確表達同一個意思仰挣，將是非常困難的事情。
在計算機領(lǐng)域缠沈，信息系統(tǒng)的APP的設(shè)計過程非常的復(fù)雜膘壶，不只是純粹的描述計算機處理流程那么簡單错蝴，還包括了抽象過程（建模過程），設(shè)計過程（包括系統(tǒng)流程設(shè)計颓芭、功能設(shè)計顷锰、權(quán)限設(shè)計、用戶體驗設(shè)計亡问、異常處理設(shè)計等等）官紫，測試過程（建立demo，必要的驗證）州藕。而在這些過程中束世，建模環(huán)節(jié)是最為重要，也是最為復(fù)雜的一個步驟床玻。
舉個例子來說明為什么說業(yè)務(wù)建模過程最為關(guān)鍵毁涉、也最為復(fù)雜：
假設(shè)家里有很多的雜物被堆放在不同的角落里，有衣服笨枯，褲子薪丁，鞋子，碗馅精，清潔劑，錘子粱檀，可折疊的小凳子等等洲敢，家里每個人都會用到其中的某些物品。久而久之茄蚯，大家都覺得這些東西胡亂放置压彭，既不利于保管、用時也不方便找到渗常。于是壮不，大家推舉你來解決這個問題，并給你提出了很多好的建議皱碘。例如询一，把這些東西整理到一個角落放置，給每個物品一個固定的位置癌椿，可以請木工打個大木箱子來放置健蕊，也可以去家具商店買個好點的柜子來放置，又或者買幾個大的袋子分類來裝踢俄。最后缩功，一家之長告誡你：在投資允許的情況下，盡可能的選擇最好的一種方案來滿足家里所有人的需求都办。
那么這個時候嫡锌，你應(yīng)該怎么去做呢虑稼？讓我來試著描繪一種可能成功的做法。
? 首先势木，對每個人的需求進行登記蛛倦。即收集需求的過程（Collect Requirements）
詳細的與每個干系人（Stakeholder）進行溝通，識別出每個人的一些行為特性跟压，例如：
1胰蝠、 你一般什么時候會去哪兒找哪些物品做哪些事情，什么時候又還原回去震蒋？（流程）
2茸塞、 這些物品有些什么保管的要求？（功能需求）
3查剖、 你希望去哪里去取最方便钾虐？（非功能需求）
4、 有別人和你一起用這些物品嗎笋庄？（權(quán)限要求）
5效扫、 大致預(yù)算在什么范圍，等等（限制條件）
? 對需求展開分析直砂，進入設(shè)計和構(gòu)造階段菌仁。即需求的定義過程（Define Scope）
1、 對收集的信息展開分析静暂。保留有用的济丘，去除相同的和無意義的需求。（需求過濾）
2洽蛀、 對物品進行逐一的分析摹迷，整理歸類。確定物品分作哪些類別郊供，例如峡碉，衣服類，鞋類驮审，餐具類鲫寄，清潔劑類，工具類头岔，小家具類等塔拳。（分類&抽象）
3、 確定每個類別的行為特性峡竣，尺寸大小靠抑，放置要求等。
例如适掰，
衣服類物品要求存放于封閉颂碧、干燥的環(huán)境荠列，拿取方便、好查找载城，部分衣服要求掛放肌似，需要足夠的空間；
鞋類要求每雙鞋都單獨放置诉瓦，存放時能具備一定的空氣流動性川队，要方便查找和拿取睬澡；
餐具類固额，要求單獨存放，最好放在與水池較近的地方煞聪，要求能封閉放置斗躏，能在需要的時候進行通風(fēng)干燥處理，儲物構(gòu)造的材料要求 防水昔脯；
清潔劑類啄糙，沒有特別要求，只需要和衣服類云稚，餐具類分開存放即可隧饼；工具類，……（抽象&分析）
形成初步的設(shè)計方案静陈。設(shè)計思路為桑李，配置兩個不同的儲物柜解決儲物的問題。
一窿给、在靠近廚房的角落設(shè)計一個三欄式的壁掛組合儲物柜，采用防火率拒，防腐蝕的UV板材崩泡。
設(shè)計為掛式的原因是，節(jié)省房屋的空間猬膨，利于時常打開柜門通風(fēng)角撞；大人拿取方便，也防止小孩子隨意拿取玩耍而摔破勃痴；三欄結(jié)構(gòu)可以分開放置餐具類谒所、清潔劑類物品和工具類物品，空間設(shè)計更為合理沛申。
二劣领、在靠近臥室的角落放置一個落地的多功能儲物柜。
儲物柜設(shè)計為三層的實木結(jié)構(gòu)铁材，下層主要放置鞋類尖淘，其后面板和內(nèi)隔檔板采用鏤空設(shè)計奕锌，內(nèi)置4個隔層，總體高度約占柜體的1/4村生。鏤空和隔層設(shè)計主要起到通風(fēng)干燥和分類放置便于取放的作用惊暴；中間層為抽屜式設(shè)計，主要放置可以摺疊放置的衣物趁桃；而一些需要掛置的衣服則掛放在上層辽话。在儲物柜的頂上還可以放置一些小家具，例如摺疊的凳子卫病，卷席等油啤。另外，采用全實木材料還以防止甲醛等有害物質(zhì)的侵害忽肛。（建模過程）
<noscript>
</noscript>
? 驗證設(shè)計的成果是否滿足干系人需要村砂。即范圍確認過程（Verify Scope）
形成結(jié)論后，召集相關(guān)干系人商議屹逛、評估方案础废。一般依據(jù)業(yè)務(wù)程度，可以采用簡單的評審（團隊內(nèi)部小范圍的評審）或復(fù)雜（有客戶罕模、用戶或者專家參與）的評審方式评腺。
一旦方案得到大家的認可，則可以進入實施過程了淑掌，這時可以再推舉一個人作為實施的負責(zé)協(xié)調(diào)人蒿讥，由他來控制預(yù)算，制定行動計劃抛腕，確定需求的優(yōu)先級別芋绸，落實方案的執(zhí)行。
從上面的例子可以看到担敌，設(shè)計和構(gòu)造階段中建模（Build Model）是整個APP設(shè)計過程中最具有技術(shù)含量的一個環(huán)節(jié)摔敛，不僅需要依靠知識和經(jīng)驗，還需要較強的邏輯能力全封，構(gòu)思和策劃能力马昙。
其實，這么多年來我們在做需求分析和建模時刹悴，也是有一定的規(guī)律可遵循的行楞，我用一句話來概括就是：
從業(yè)務(wù)對象入手，識別業(yè)務(wù)對象的行為土匀，抽象APP子房，從而構(gòu)造系統(tǒng)模型。
下面用網(wǎng)上訂票的例子來詳細說明我們的做法：
假設(shè)恒削，我們已經(jīng)知道了用戶的業(yè)務(wù)流程池颈。
第一步：用戶通過瀏覽器登錄web網(wǎng)站尾序，瀏覽和查詢需要的信息。
第二步：選擇票躯砰，填寫訂單信息每币，確認個人的信息，以方便取票時核對琢歇。
第三步：通過網(wǎng)站提供的支付方式兰怠，在線完成支付。
第四步：系統(tǒng)生成電子票號李茫，并短信通知訂票人揭保，告知用戶出票相關(guān)的信息和兌票方法。
具體參見下圖：
<noscript>
</noscript>
前面我們說到：業(yè)務(wù)的核心是數(shù)據(jù)魄宏。所以秸侣，理清業(yè)務(wù)的基礎(chǔ)是分析清楚業(yè)務(wù)下流動的數(shù)據(jù)都有哪些，這些數(shù)據(jù)分別代表了什么意義宠互，對應(yīng)了哪些業(yè)務(wù)對象味榛。
所以，第一步我們分析業(yè)務(wù)中包含了哪些業(yè)務(wù)對象予跌。
? 業(yè)務(wù)對象分析（確定BO）
在線訂票業(yè)務(wù)中搏色，有登錄、填寫訂單券册、支付和出票四個環(huán)節(jié)频轿。
仔細分析，我們發(fā)現(xiàn)烁焙，這四個環(huán)節(jié)分別包括了四個相對獨立的業(yè)務(wù)對象：用戶航邢、訂單、賬單和票骄蝇。（這里沒有把手機短信也列為一個業(yè)務(wù)對象）
訂票過程的所有活動都是圍繞這四個對象來開展的翠忠，少了任何一個對象，這個流程都是不完整的乞榨。
那么在識別BO的時候，我總結(jié)了幾個簡單的標(biāo)準(zhǔn)：
1当娱、 該業(yè)務(wù)對象是否有一定的明確業(yè)務(wù)含義吃既，如果少了這個BO業(yè)務(wù)流程將不完整。
2跨细、 業(yè)務(wù)流程中一定有一個或多個環(huán)節(jié)是有這個BO參與的鹦倚。
3、 大多數(shù)BO往往是可以映射到現(xiàn)實生活中的某一類物體的冀惭。例如震叙，人掀鹅，賬單，公司媒楼，電話乐尊，系統(tǒng)，卡划址，存折扔嵌，車輛，身份證等等夺颤。
另外痢缎，我們在判斷是否所有的業(yè)務(wù)對象都被識別時，也有一個很簡單的判斷標(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本身是有意義的寥裂，這些意義可以被細化為一些屬性嵌洼。我理解，屬性就是說明和識別BO某一方面的一些具體標(biāo)識或參數(shù)抚恒。
識別業(yè)務(wù)對象屬性時咱台，最重要是能分清楚哪些屬性是與目前工作范圍相關(guān)的。例如俭驮，用戶有很多屬性回溺，但高矮胖瘦這些與我們正在分析的電子商務(wù)系統(tǒng)毫無關(guān)系，所以混萝，找到BO屬性并準(zhǔn)確過濾才是這個過程的關(guān)鍵行為遗遵。
<noscript>
</noscript>
（在正式的團隊協(xié)作過程中，必須要對每個BO逸嘀，BO的屬性和BO的行為進行統(tǒng)一編號標(biāo)識车要。）
我們在識別BO的行為時，可以分為三個層次：
1崭倘、從業(yè)務(wù)流程中識別翼岁。從流程中只能識別一部分BO的行為，這一部分行為往往被稱之為業(yè)務(wù)行為司光；也是BO最容易確定的一類行為琅坡，只要流程定義清楚了，這類行為就已經(jīng)被確定了残家。例如榆俺，在上面的例子中，用戶在流程中有登錄和注冊行為；針對訂單對象茴晋，有填寫訂單陪捷，提交訂單行為；賬單對象有支付行為等诺擅。
2市袖、從分析BO的完整性來識別。例如掀虎，用戶有登錄凌盯，就一定有注銷行為；訂單能新增烹玉，一定可以修改和查詢驰怎；賬單能支付，也可以退款二打。
3县忌、從外部的需要來識別。例如继效，電子票本身是沒有核對識別需要的症杏，但考慮到安全性，一些運營商還是考慮了將電子票號進行了加密處理瑞信，票號本身含有身份識別信息厉颤。一旦電子票號遺失，只要有身份證信息凡简，則電子票仍能使用逼友。
通過三個層次的分析，一般能識別出絕大部分的BO行為秤涩，當(dāng)然帜乞，還需要對這些識別的行為進行統(tǒng)一的描述。描述的內(nèi)容包括行為名稱筐眷，行為說明黎烈，涉及的BO屬性和變化。例如匀谣，
<noscript>
</noscript>
在識別BO行為的過程中照棋，我們往往會遇到一些模棱兩可的境地，例如武翎，商品和購物車是兩個不同的業(yè)務(wù)對象必怜，那么將商品添加到購物車的行為，是歸屬商品的行為后频，還是購物車的行為呢？
有人說是購物車的行為；有人反問卑惜，為何這個行為主要出現(xiàn)在商品的單頁上膏执？
我的意見是：當(dāng)行為涉及到兩個對象，一般把其歸屬到擁有管理職能的對象露久。購物車管理被放入的商品更米，管理放入的數(shù)量，也可以從購物車中刪除毫痕。所以征峦，放入購物車的行為主體對象是購物車。識別了BO消请，BO的屬性以及BO的行為后栏笆，我們可以開始建立APP了。
? 建立APP
建立APP的過程是明確系統(tǒng)范圍的過程臊泰，同時也是生成系統(tǒng)模型的過程蛉加。
建立APP有兩種視角：
1、一種是以BO為視角缸逃，聚合BO的行為针饥，以管理BO的功能組成一個APP；例如需频，我們將針對訂單的所有行為丁眼，組合成為一個APP，稱為訂單管理昭殉。
2苞七、另外一種是以業(yè)務(wù)為視角，聚合一個流程的所有環(huán)節(jié)饲化，以實現(xiàn)流程的功能組成一個APP莽鸭。例如，我們將針對打折票的預(yù)定流程中的所有行為環(huán)節(jié)吃靠，組合成為一個APP硫眨，稱為折扣票預(yù)定APP。
但不管怎么組織APP的構(gòu)成巢块，在BO層面看礁阁，都是一樣的：系統(tǒng)都是由操作BO的一堆行為構(gòu)成的。
上面是從業(yè)務(wù)分析BO族奢，分析BO的屬性行為姥闭，然后組織APP。
然而越走，此刻還不能完成系統(tǒng)模型的構(gòu)建棚品，因為還需要思考這些已經(jīng)被識別的APP是否足夠支撐一個應(yīng)用系統(tǒng)靠欢？
這里需要引入兩個重要設(shè)計分析過程：一個是用戶體驗設(shè)計，一個是非功能設(shè)計铜跑。
用戶體驗設(shè)計（User Experience）是以用戶為中心的設(shè)計门怪，是一種經(jīng)驗與創(chuàng)造相結(jié)合的設(shè)計過程，主要目的是提升用戶的操作舒適感锅纺，增強在同類產(chǎn)品中的競爭力掷空。在web2.0時代，用戶體驗設(shè)計將不再局限于展現(xiàn)流程和完成數(shù)據(jù)操作方面囤锉，還承載了不同角色之間的信息多元化交互的設(shè)計需要坦弟，以用戶為核心將不再是簡單的信息提供（推送）而已。
那么官地，在構(gòu)建系統(tǒng)的APP時酿傍，也要充分的考慮UE設(shè)計的需要，加入一些用于提升用戶體驗的APP区丑，例如拧粪，Dashboard。
非功能設(shè)計來源于用戶的非功能需求沧侥，例如可霎，系統(tǒng)的可管理要求，靈活擴展要求宴杀，性能要求癣朗，安全要求等。這些設(shè)計除了在系統(tǒng)的架構(gòu)設(shè)計時需要充分的考慮和滿足旺罢，在功能APP設(shè)計時也需要做相應(yīng)的響應(yīng)旷余。例如，最常見的一個APP-系統(tǒng)管理扁达，通常包含數(shù)據(jù)管理正卧，日志管理，參數(shù)管理跪解，模型管理炉旷，模版管理，接口管理叉讥，APP管理等等窘行。這些來源于UE設(shè)計和非功能設(shè)計的APP與最早被識別的業(yè)務(wù)APP共同構(gòu)成了系統(tǒng)，行成了系統(tǒng)模型图仓。
系統(tǒng)模型構(gòu)建完成罐盔，進入設(shè)計APP的階段。在設(shè)計APP時救崔，我們發(fā)現(xiàn)大型項目中的單個APP往往都很巨大惶看，內(nèi)部包含了很多行為和內(nèi)容捏顺，如果不進行拆分細化，則很難展開有效的設(shè)計纬黎。
已經(jīng)被我們熟知的拆分方法有很多草丧，可沒有一個標(biāo)準(zhǔn)去衡量一定要拆分為多少層級才合適，這往往需要視系統(tǒng)的復(fù)雜程度和設(shè)計需要而定莹桅。
建議把較大的APP拆分為三個層次，即：APP層烛亦，Module層和Function層诈泼，這樣拆分的原因是為了與系統(tǒng)層面的功能模塊-頁面-和頁面里的操作（或者一個單獨處理單元）逐一對應(yīng)。
