如何分析app功能需求、結構
app分析過程在項目管理體系pmbok中歸屬于項目範圍定義（define
scope）過程。從pmbok的角度來看，在完成需求收集（collect requirements）後，需要對項目和産品的詳細範圍進行描述，清晰完整的項目/産品範圍說明書有利于制定出具有良好執行性的wbs（work breakdown structure），但其更為重要的意義在于科學的建構了使用者所需要的系統功能架構。
從業務演變到系統的角度來看，app是業務在系統的具體呈現，app的分析過程是将業務語言翻譯為機器語言的表現。隻不過這不是普通的翻譯，是包含了智力和經驗的過程。是以，對于計算機資訊領域的技術專家來說，更需要去學習和掌握跨領域的業務語言，并在不同領域的交界處形成明确的定義，實作不同語言間的準确對應。
舉個例子，假設在電子商務領域裡有一個業務，我們稱之為a：使用者通過網站填寫了一份購買汽車坐墊的訂單，付款成功後可以通過連接配接電腦的列印機自動列印一份a4幅面标準格式的确認單。那麼在資訊系統的世界裡，a被翻譯為：1、使用者通過web表單填寫完訂單内容後；2、線上支付。2.1、如果支付不成功，系統提示使用者哪裡出現錯誤，并引導使用者修正錯誤。2.2、如果支付成功，系統提示使用者：訂單已經生效，系統即将列印确認單。3、系統傳遞列印控制資訊，列印機負責列印出指定格式的檔案。4、系統提示交易完成。
上面的例子說明了不同的領域有不同的表達标準，想要在不同領域都能準确表達同一個意思，将是非常困難的事情。
在計算機領域，資訊系統的app的設計過程非常的複雜，不隻是純粹的描述計算機處理流程那麼簡單，還包括了抽象過程（模組化過程），設計過程（包括系統流程設計、功能設計、權限設計、使用者體驗設計、異常處理設計等等），測試過程（建立demo，必要的驗證）。而在這些過程中，模組化環節是最為重要，也是最為複雜的一個步驟。
舉個例子來說明為什麼說業務模組化過程最為關鍵、也最為複雜：
假設家裡有很多的雜物被堆放在不同的角落裡，有衣服，褲子，鞋子，碗，清潔劑，錘子，可折疊的小凳子等等，家裡每個人都會用到其中的某些物品。久而久之，大家都覺得這些東西胡亂放置，既不利于保管、用時也不友善找到。于是，大家推舉你來解決這個問題，并給你提出了很多好的建議。例如，把這些東西整理到一個角落放置，給每個物品一個固定的位置，可以請木工打個大木箱子來放置，也可以去家具商店買個好點的櫃子來放置，又或者買幾個大的袋子分類來裝。最後，一家之長告誡你：在投資允許的情況下，盡可能的選擇最好的一種方案來滿足家裡所有人的需求。
那麼這個時候，你應該怎麼去做呢？讓我來試着描繪一種可能成功的做法。
Ø 首先，對每個人的需求進行登記。即收集需求的過程（collect
requirements）
詳細的與每個幹系人（stakeholder）進行溝通，識别出每個人的一些行為特性，例如：
1、 你一般什麼時候會去哪兒找哪些物品做哪些事情，什麼時候又還原回去？（流程）
2、 這些物品有些什麼保管的要求？（功能需求）
3、 你希望去哪裡去取最友善？（非功能需求）
4、 有别人和你一起用這些物品嗎？（權限要求）
5、 大緻預算在什麼範圍，等等（限制條件）
Ø 對需求展開分析，進入設計和構造階段。即需求的定義過程（define
scope）
1、 對收集的資訊展開分析。保留有用的，去除相同的和無意義的需求。（需求過濾）
2、 對物品進行逐一的分析，整理歸類。确定物品分作哪些類别，例如，衣服類，鞋類，餐具類，清潔劑類，工具類，小家具類等。（分類&抽象）
3、 确定每個類别的行為特性，尺寸大小，放置要求等。
例如，
衣服類物品要求存放于封閉、幹燥的環境，拿取友善、好查找，部分衣服要求挂放，需要足夠的空間；
鞋類要求每雙鞋都單獨放置，存放時能具備一定的空氣流動性，要友善查找和拿取；
餐具類，要求單獨存放，最好放在與水池較近的地方，要求能封閉放置，能在需要的時候進行通風幹燥處理，儲物構造的材料要求
防水；
清潔劑類，沒有特别要求，隻需要和衣服類，餐具類分開存放即可；工具類，……（抽象&分析）
形成初步的設計方案。設計思路為，配置兩個不同的儲物櫃解決儲物的問題。
一、在靠近廚房的角落設計一個三欄式的壁挂組合儲物櫃，采用防火，防腐蝕的uv闆材。
設計為挂式的原因是，節省房屋的空間，利于時常打開櫃門通風；大人拿取友善，也防止小孩子随意拿取玩耍而摔破；三欄結構可以分開放置餐具類、清潔劑類物品和工具類物品，空間設計更為合理。
二、在靠近卧室的角落放置一個落地的多功能儲物櫃。
儲物櫃設計為三層的實木結構，下層主要放置鞋類，其後面闆和内隔檔闆采用镂空設計，内置4個隔層，總體高度約占櫃體的1/4。镂空和隔層設計主要起到通風幹燥和分類放置便于取放的作用；中間層為抽屜式設計，主要放置可以摺疊放置的衣物；而一些需要挂置的衣服則挂放在上層。在儲物櫃的頂上還可以放置一些小家具，例如摺疊的凳子，卷席等。另外，采用全實木材料還以防止甲醛等有害物質的侵害。（模組化過程）
Ø 驗證設計的成果是否滿足幹系人需要。即範圍确認過程（verify scope）
形成結論後，召集相關幹系人商議、評估方案。一般依據業務程度，可以采用簡單的評審（團隊内部小範圍的評審）或複雜（有客戶、使用者或者專家參與）的評審方式。
一旦方案得到大家的認可，則可以進入實施過程了，這時可以再推舉一個人作為實施的負責協調人，由他來控制預算，制定行動計劃，确定需求的優先級别，落實方案的執行。
從上面的例子可以看到，設計和構造階段中模組化（build model）是整個app設計過程中最具有技術含量的一個環節，不僅需要依靠知識和經驗，還需要較強的邏輯能力，構思和策劃能力。
其實，這麼多年來我們在做需求分析和模組化時，也是有一定的規律可遵循的，我用一句話來概括就是：
從業務對象入手，識别業務對象的行為，抽象app，進而構造系統模型。
下面用網上訂票的例子來詳細說明我們的做法：
假設，我們已經知道了使用者的業務流程。
第一步：使用者通過浏覽器登入web網站，浏覽和查詢需要的資訊。
第二步：選擇票，填寫訂單資訊，确認個人的資訊，以友善取票時核對。
第三步：通過網站提供的支付方式，線上完成支付。
第四步：系統生成電子票号，并短信通知訂票人，告知使用者出票相關的資訊和兌票方法。
具體參見下圖：
前面我們說到：業務的核心是資料。是以，理清業務的基礎是分析清楚業務下流動的資料都有哪些，這些資料分别代表了什麼意義，對應了哪些業務對象。
是以，第一步我們分析業務中包含了哪些業務對象。
Ø 業務對象分析（确定bo）
線上訂票業務中，有登入、填寫訂單、支付和出票四個環節。
仔細分析，我們發現，這四個環節分别包括了四個相對獨立的業務對象：使用者、訂單、賬單和票。（這裡沒有把手機短信也列為一個業務對象）
訂票過程的所有活動都是圍繞這四個對象來開展的，少了任何一個對象，這個流程都是不完整的。
那麼在識别bo的時候，我總結了幾個簡單的标準：
1、 該業務對象是否有一定的明确業務含義，如果少了這個bo業務流程将不完整。
2、 業務流程中一定有一個或多個環節是有這個bo參與的。
3、 大多數bo往往是可以映射到現實生活中的某一類物體的。例如，人，賬單，公司，電話，系統，卡，存折，車輛，身份證等等。
另外，我們在判斷是否所有的業務對象都被識别時，也有一個很簡單的判斷标準：業務流程中可能涉及的資料内容都與已經識别的業務對象能緊密關聯上。
在确定bo後，需要分析和識别所有與業務對象相關的行為。
Ø 識别與bo相關的行為（bo屬性和行為分析）
bo本身是有意義的，這些意義可以被細化為一些屬性。我了解，屬性就是說明和識别bo某一方面的一些具體辨別或參數。
識别業務對象屬性時，最重要是能厘清楚哪些屬性是與目前工作範圍相關的。例如，使用者有很多屬性，但高矮胖瘦這些與我們正在分析的電子商務系統毫無關系，是以，找到bo屬性并準确過濾才是這個過程的關鍵行為。
（在正式的團隊協作過程中，必須要對每個bo，bo的屬性和bo的行為進行統一編号辨別。）
我們在識别bo的行為時，可以分為三個層次：
1、從業務流程中識别。從流程中隻能識别一部分bo的行為，這一部分行為往往被稱之為業務行為；也是bo最容易确定的一類行為，隻要流程定義清楚了，這類行為就已經被确定了。例如，在上面的例子中，使用者在流程中有登入和注冊行為；針對訂單對象，有填寫訂單，送出訂單行為；賬單對象有支付行為等。
2、從分析bo的完整性來識别。例如，使用者有登入，就一定有登出行為；訂單能新增，一定可以修改和查詢；賬單能支付，也可以退款。
3、從外部的需要來識别。例如，電子票本身是沒有核對識别需要的，但考慮到安全性，一些營運商還是考慮了将電子票号進行了加密處理，票号本身含有身份識别資訊。一旦電子票号遺失，隻要有身份證資訊，則電子票仍能使用。
通過三個層次的分析，一般能識别出絕大部分的bo行為，當然，還需要對這些識别的行為進行統一的描述。描述的内容包括行為名稱，行為說明，涉及的bo屬性和變化。例如，
在識别bo行為的過程中，我們往往會遇到一些模棱兩可的境地，例如，商品和購物車是兩個不同的業務對象，那麼将商品添加到購物車的行為，是歸屬商品的行為，還是購物車的行為呢？
有人說是購物車的行為；有人反問，為何這個行為主要出現在商品的單頁上？
我的意見是：當行為涉及到兩個對象，一般把其歸屬到擁有管理職能的對象。購物車管理被放入的商品，管理放入的數量，也可以從購物車中删除。是以，放入購物車的行為主體對象是購物車。識别了bo，bo的屬性以及bo的行為後，我們可以開始建立app了。
Ø 建立app
建立app的過程是明确系統範圍的過程，同時也是生成系統模型的過程。
建立app有兩種視角：
1、一種是以bo為視角，聚合bo的行為，以管理bo的功能組成一個app；例如，我們将針對訂單的所有行為，組合成為一個app，稱為訂單管理。
2、另外一種是以業務為視角，聚合一個流程的所有環節，以實作流程的功能組成一個app。例如，我們将針對打折票的預定流程中的所有行為環節，組合成為一個app，稱為折扣票預定app。
但不管怎麼組織app的構成，在bo層面看，都是一樣的：系統都是由操作bo的一堆行為構成的。
上面是從業務分析bo，分析bo的屬性行為，然後組織app。
然而，此刻還不能完成系統模型的建構，因為還需要思考這些已經被識别的app是否足夠支撐一個應用系統？
這裡需要引入兩個重要設計分析過程：一個是使用者體驗設計，一個是非功能設計。
使用者體驗設計（user experience）是以使用者為中心的設計，是一種經驗與創造相結合的設計過程，主要目的是提升使用者的操作舒适感，增強在同類産品中的競争力。在web2.0時代，使用者體驗設計将不再局限于展現流程和完成資料操作方面，還承載了不同角色之間的資訊多元化互動的設計需要，以使用者為核心将不再是簡單的資訊提供（推送）而已。
那麼，在建構系統的app時，也要充分的考慮ue設計的需要，加入一些用于提升使用者體驗的app，例如，dashboard。
非功能設計來源于使用者的非功能需求，例如，系統的可管理要求，靈活擴充要求，性能要求，安全要求等。這些設計除了在系統的架構設計時需要充分的考慮和滿足，在功能app設計時也需要做相應的響應。例如，最常見的一個app-系統管理，通常包含資料管理，日志管理，參數管理，模型管理，模版管理，接口管理，app管理等等。這些來源于ue設計和非功能設計的app與最早被識别的業務app共同構成了系統，行成了系統模型。
系統模型建構完成，進入設計app的階段。在設計app時，我們發現大型項目中的單個app往往都很巨大，内部包含了很多行為和内容，如果不進行拆分細化，則很難展開有效的設計。
已經被我們熟知的拆分方法有很多，可沒有一個标準去衡量一定要拆分為多少層級才合适，這往往需要視系統的複雜程度和設計需要而定。
我建議把較大的app拆分為三個層次，即：app層，module層和function層，這樣拆分的原因是為了與系統層面的功能子產品-頁面-和頁面裡的操作（或者一個單獨處理單元）逐一對應。
參考：
<a target="_blank" href="http://blog.sina.com.cn/s/blog_5f63e3d80102v7f7.html">http://blog.sina.com.cn/s/blog_5f63e3d80102v7f7.html</a>