如何分析APP功能需求、结构
举个例子来说明为什么说业务建模过程最为关键、也最为复杂：
那么这个时候，你应该怎么去做呢？让我来试着描绘一种可能成功的做法。
Ø
详细的与每个干系人（Stakeholder）进行沟通，识别出每个人的一些行为特性，例如：
1、 你一般什么时候会去哪儿找哪些物品做哪些事情，什么时候又还原回去？（流程）
2、 这些物品有些什么保管的要求？（功能需求）
3、 你希望去哪里去取最方便？（非功能需求）
4、 有别人和你一起用这些物品吗？（权限要求）
5、 大致预算在什么范围，等等（限制条件）
Ø
1、 对收集的信息展开分析。保留有用的，去除相同的和无意义的需求。（需求过滤）
2、 对物品进行逐一的分析，整理归类。确定物品分作哪些类别，例如，衣服类，鞋类，餐具类，清洁剂类，工具类，小家具类等。（分类&抽象）
3、 确定每个类别的行为特性，尺寸大小，放置要求等。
例如，
衣服类物品要求存放于封闭、干燥的环境，拿取方便、好查找，部分衣服要求挂放，需要足够的空间；
鞋类要求每双鞋都单独放置，存放时能具备一定的空气流动性，要方便查找和拿取；
餐具类，要求单独存放，最好放在与水池较近的地方，要求能封闭放置，能在需要的时候进行通风干燥处理，储物构造的材料要求 防水；
清洁剂类，没有特别要求，只需要和衣服类，餐具类分开存放即可；工具类，……（抽象&分析）
形成初步的设计方案。设计思路为，配置两个不同的储物柜解决储物的问题。
一、在靠近厨房的角落设计一个三栏式的壁挂组合储物柜，采用防火，防腐蚀的UV板材。
设计为挂式的原因是，节省房屋的空间，利于时常打开柜门通风；大人拿取方便，也防止小孩子随意拿取玩耍而摔破；三栏结构可以分开放置餐具类、清洁剂类物品和工具类物品，空间设计更为合理。
二、在靠近卧室的角落放置一个落地的多功能储物柜。
储物柜设计为三层的实木结构，下层主要放置鞋类，其后面板和内隔档板采用镂空设计，内置4个隔层，总体高度约占柜体的1/4。镂空和隔层设计主要起到通风干燥和分类放置便于取放的作用；中间层为抽屉式设计，主要放置可以摺叠放置的衣物；而一些需要挂置的衣服则挂放在上层。在储物柜的顶上还可以放置一些小家具，例如摺叠的凳子，卷席等。另外，采用全实木材料还以防止甲醛等有害物质的侵害。（建模过程）
Ø
形成结论后，召集相关干系人商议、评估方案。一般依据业务程度，可以采用简单的评审（团队内部小范围的评审）或复杂（有客户、用户或者专家参与）的评审方式。
一旦方案得到大家的认可，则可以进入实施过程了，这时可以再推举一个人作为实施的负责协调人，由他来控制预算，制定行动计划，确定需求的优先级别，落实方案的执行。
其实，这么多年来我们在做需求分析和建模时，也是有一定的规律可遵循的，我用一句话来概括就是：
从业务对象入手，识别业务对象的行为，抽象APP，从而构造系统模型。
下面用网上订票的例子来详细说明我们的做法：
假设，我们已经知道了用户的业务流程。
第一步：用户通过浏览器登录web网站，浏览和查询需要的信息。
第二步：选择票，填写订单信息，确认个人的信息，以方便取票时核对。
第三步：通过网站提供的支付方式，在线完成支付。
第四步：系统生成电子票号，并短信通知订票人，告知用户出票相关的信息和兑票方法。
具体参见下图：
所以，第一步我们分析业务中包含了哪些业务对象。
Ø
在线订票业务中，有登录、填写订单、支付和出票四个环节。
仔细分析，我们发现，这四个环节分别包括了四个相对独立的业务对象：用户、订单、账单和票。（这里没有把手机短信也列为一个业务对象）
订票过程的所有活动都是围绕这四个对象来开展的，少了任何一个对象，这个流程都是不完整的。
那么在识别BO的时候，我总结了几个简单的标准：
1、 该业务对象是否有一定的明确业务含义，如果少了这个BO业务流程将不完整。
2、 业务流程中一定有一个或多个环节是有这个BO参与的。
3、 大多数BO往往是可以映射到现实生活中的某一类物体的。例如，人，账单，公司，电话，系统，卡，存折，车辆，身份证等等。
另外，我们在判断是否所有的业务对象都被识别时，也有一个很简单的判断标准：业务流程中可能涉及的数据内容都与已经识别的业务对象能紧密关联上。
在确定BO后，需要分析和识别所有与业务对象相关的行为。
Ø
BO本身是有意义的，这些意义可以被细化为一些属性。我理解，属性就是说明和识别BO某一方面的一些具体标识或参数。
识别业务对象属性时，最重要是能分清楚哪些属性是与目前工作范围相关的。例如，用户有很多属性，但高矮胖瘦这些与我们正在分析的电子商务系统毫无关系，所以，找到BO属性并准确过滤才是这个过程的关键行为。
（在正式的团队协作过程中，必须要对每个BO，BO的属性和BO的行为进行统一编号标识。）
我们在识别BO的行为时，可以分为三个层次：
1、从业务流程中识别。从流程中只能识别一部分BO的行为，这一部分行为往往被称之为业务行为；也是BO最容易确定的一类行为，只要流程定义清楚了，这类行为就已经被确定了。例如，在上面的例子中，用户在流程中有登录和注册行为；针对订单对象，有填写订单，提交订单行为；账单对象有支付行为等。
2、从分析BO的完整性来识别。例如，用户有登录，就一定有注销行为；订单能新增，一定可以修改和查询；账单能支付，也可以退款。
3、从外部的需要来识别。例如，电子票本身是没有核对识别需要的，但考虑到安全性，一些运营商还是考虑了将电子票号进行了加密处理，票号本身含有身份识别信息。一旦电子票号遗失，只要有身份证信息，则电子票仍能使用。
通过三个层次的分析，一般能识别出绝大部分的BO行为，当然，还需要对这些识别的行为进行统一的描述。描述的内容包括行为名称，行为说明，涉及的BO属性和变化。例如，
有人说是购物车的行为；有人反问，为何这个行为主要出现在商品的单页上？
Ø
建立APP的过程是明确系统范围的过程，同时也是生成系统模型的过程。
建立APP有两种视角：
1、一种是以BO为视角，聚合BO的行为，以管理BO的功能组成一个APP；例如，我们将针对订单的所有行为，组合成为一个APP，称为订单管理。
2、另外一种是以业务为视角，聚合一个流程的所有环节，以实现流程的功能组成一个APP。例如，我们将针对打折票的预定流程中的所有行为环节，组合成为一个APP，称为折扣票预定APP。
具体参见下图：
但不管怎么组织APP的构成，在BO层面看，都是一样的：系统都是由操作BO的一堆行为构成的。
这里需要引入两个重要设计分析过程：一个是用户体验设计，一个是非功能设计。
用户体验设计（User Experience）是以用户为中心的设计，是一种经验与创造相结合的设计过程，主要目的是提升用户的操作舒适感，增强在同类产品中的竞争力。在web2.0时代，用户体验设计将不再局限于展现流程和完成数据操作方面，还承载了不同角色之间的信息多元化交互的设计需要，以用户为核心将不再是简单的信息提供（推送）而已。
已经被我们熟知的拆分方法有很多，可没有一个标准去衡量一定要拆分为多少层级才合适，这往往需要视系统的复杂程度和设计需要而定。
参考：
http://blog.sina.com.cn/s/blog_5f63e3d80102v7f7.html
