如何分析APP功能需求及结构

1、如何分析APP功能需求及结构APP分析过程在工程管理体系PMBOK中归属于工程范围定义Define Scope过程。从PMBOK的角度来看，在完成需求收集Collect Requirements 后，需要对工程和产品的详细范围进行描述，清晰完整的工程/产品范围说明书有利于制定出具有良好执行性的 WBSWork Breakdown Structure，但其更 为重要的意义在于科学的构建了用户所需要的系统功能架构。从业务演变到系统的角度来看，APP是业务在系统的具体呈现，APP的分 析过程是将业务语言翻译为机器语言的表现。只不过这不是普通的翻译，是包含 了智力和经验的过程。所以，对于电脑信息领域的

2、技术专家来说， 更需要去学习 和掌握跨领域的业务语言，并在不同领域的交界处形成明确的定义， 实现不同语 言间的准确对应。举个例子，假设在电子商务领域里有一个业务，我们称之为A :用户通过网站填写了一份购置汽车坐垫的订单，付款成功后可以通过连接电脑的打印机自 动打印一份A4幅面标准格式确实认单。那么在信息系统的世界里，A被翻译为：1、用户通过web表单填写完订单内容后；2、在线支付。2.1、如果支付不成功， 系统提示用户哪里出现错误，并引导用户修正错误。2.2、如果支付成功，系统提示用户：订单已经生效，系统即将打印确认单。3、系统传递打印控制信息，打印机负责打印出指定格式的文件。4、系统提示交易

3、完成。上面的例子说明了不同的领域有不同的表达标准，想要在不同领域都能准 确表达同一个意思，将是非常困难的事情。在电脑领域，信息系统的APP的设计过程非常的复杂，不只是纯粹的描述 电脑处理流程那么简单，还包括了抽象过程建模过程，设计过程包括系统流程设计、功能设计、权限设计、用户体验设计、异常处理设计等等，测试过 程建立demo，必要的验证。而在这些过程中，建模环节是最为重要，也是最为复杂的一个步骤。举个例子来说明为什么说业务建模过程最为关键、也最为复杂：假设家里有很多的杂物被堆放在不同的角落里，有衣服，裤子，鞋子，碗，清洁剂，锤子，可折叠的小凳子等等，家里每个人都会用到其中的某些物品。久 而久之

4、，大家都觉得这些东西胡乱放置，既不利于保管、用时也不方便找到。于 是，大家推举你来解决这个问题，并给你提出了很多好的建议。例如，把这些东 西整理到一个角落放置，给每个物品一个固定的位置，可以请木工打个大木箱子 来放置，也可以去家具商店买个好点的柜子来放置， 又或者买几个大的袋子分类 来装。最后，一家之长告诫你：在投资允许的情况下，尽可能的选择最好的一种 方案来满足家里所有人的需求。那么这个时候，你应该怎么去做呢？让我来试着描绘一种可能成功的做法。?首先，对每个人的需求进行登记。即收集需求的过程Collect Requirements 详细的与每个干系人Stakeholder进行沟通，识别出每个

5、人的一些行为特性， 例如：1、你一般什么时候会去哪儿找哪些物品做哪些事情，什么时候又复原回去？流 程2、 这些物品有些什么 保管的要求？功能需求3、你希望去哪里去取最方便？非功能需求4、有别人和你一起用这些物品吗？权限要求5、大致预算在什么范围，等等限制条件?对需求展开分析，进入设计和构造阶段。即需求的定义过程Define Scope1、 对收集的信息展开分析。保存有用的，去除相同的和无意义的需求。需求 过滤2、对物品进行逐一的分析，整理归类。确定物品分作哪些类别，例如，衣服类， 鞋类，餐具类，清洁剂类，工具类，小家具类等。 分类&抽象3、确定每个类别的行为特性，尺寸大小，放置要求等。

6、例如，衣服类物品要求 存放于封闭、枯燥的环境，拿取方便、好查找，局部衣服要求挂放，需要足够的 空间；鞋类要求每双鞋都单独放置，存放时能具备一定的空气流动性，要方便查 找和拿取；餐具类，要求单独存放，最好放在与水池较近的地方，要求能封闭放置，能在需要的时候进行通风枯燥处理，储物构造的材料要求防水；清洁剂类， 没有特别要求，只需要和衣服类，餐具类分开存放即可；工具类，抽象&分析形成初步的设计方案。设计思路为，配置两个不同的储物柜解决储物的问题。一、 在靠近厨房的角落设计一个三栏式的壁挂组合储物柜，采用防火，防腐蚀的UV板材。设计为挂式的原因是，节省房屋的空间，利于时常翻开柜门通风；大人拿取

7、方便，也防止小孩子随意拿取玩耍而摔破； 三栏结构可以分开放置餐具类、 清 洁剂类物品和工具类物品，空间设计更为合理。二、在靠近卧室的角落放置一个 落地的多功能储物柜。储物柜设计为三层的实木结构，下层主要放置鞋类，其后 面板和内隔档板采用镂空设计，内置 4个隔层，总体高度约占柜体的1/4。镂空 和隔层设计主要起到通风枯燥和分类放置便于取放的作用；中间层为抽屉式设计,主要放置可以摺叠放置的衣物；而一些需要挂置的衣服那么挂放在上层。在储物柜的顶上还可以放置一些小家具，例如摺叠的凳子，卷席等。另外，采用全实木材料还以防止甲醛等有害物质的侵害。建模过程?验证设计的成果是否满足干系人需要。即范围确认过程

8、Verify Scope 形成结论后，召集相关干系人商议、评估方案。一般依据业务程度，可以采用简 单的评审团队内部小范围的评审或复杂有客户、用户或者专家参与的评 审方式。一旦方案得到大家的认可，那么可以进入实施过程了，这时可以再推举一个人作为 实施的负责协调人，由他来控制预算，制定行动方案，确定需求的优先级别，落 实方案的执行。从上面的例子可以看到，设计和构造阶段中建模Build Model是整个APP 设计过程中最具有技术含量的一个环节， 不仅需要依靠知识和经验，还需要较强 的逻辑能力，构思和筹划能力。其实，这么多年来我们在做需求分析和建模时， 也是有一定的规律可遵循的，我 用一句话来概括就

9、是：从业务对象入手，识别业务对象的行为，抽象 APP，从 而构造系统模型。下面用网上订票的例子来详细说明我们的做法：假设，我们已经知道了用户的业务流程。第一步：用户通过浏览器登录 web网站，浏览和查询需要的信息。第二步：选择票，填写订单信息，确认个人的信息，以方便取票时核对。第三步：通过网站提供的支付方式，在线完成支付。第四步：系统生成电子票号，并短信通知订票人，告知用户出票相关的信息和兑 票方法。具体参见以下图：业务I (Booking Tkkets1 t t« tI1:谢f承HI«11 tA p P分析4丁 - J&7an almi *aJtU日君 取十 r4

10、*71 *»紀.m.dAppg：业村HttlfeO AtBM1出皋fW董忖珈 磨低0屏鬲殓理EnntiofiS:前面我们说到：业务的核心是数据。所以，理清业务的根底是分析清楚业务下流动的数据都有哪些，这些数据分别代表了什么意义，对应了哪些业务对象 所以，第一步我们分析业务中包含了哪些业务对象。?业务对象分析确定BO在线订票业务中，有登录、填写订单、支付和出票四个环节。仔细分析，我们发现，这四个环节分别包括了四个相对独立的业务对象：用户、订单、账单 和票。这里没有把短信也列为一个业务对象订票过程的所有活动都是围绕这四个对象来开展的， 少了任何一个对象，这个流 程都是不完整的。那么在识别

11、BO的时候，我总结了几个简单的标准：1、该业务对象是否有一定的明确业务含义， 如果少了这个BO业务流程将不完 整。2、业务流程中一定有一个或多个环节是有这个 BO参与的。3、大多数BO往往是可以映射到现实生活中的某一类物体的。 例如，人，账单，公司，系统，卡，存折，车辆，身份证等等。另外，我们在判断是否所有的业务对象都被识别时， 也有一个很简单的判断标准： 业务流程中可能涉及的数据内容都与已经识别的业务对象能紧密关联上。在确定BO后，需要分析和识别所有与业务对象相关的行为。?识别与BO相关的行为BO属性和行为分析BO本身是有意义的，这些意义可以被细化为一些属性。我理解，属性就是说明 和识别BO

12、某一方面的一些具体标识或参数。识别业务对象属性时，最重要是能分清楚哪些属性是与目前工作范围相关的。例如，用户有很多属性，但高矮胖瘦这些与我们正在分析的电子商务系统毫无关系，所以，找到BO属性并准确过滤才是这个过程的关键行为BO属H整阵BOh属性希用户人HBO-1用户 g(BO-l-Al>在系筑内唯一禎*国际标准男j女F未MR3在正式的团队协作过程中，必须要对每个 BO，BO的属性和BO的行为进行 统一编号标识。我们在识别BO的行为时，可以分为三个层次：1、从业务流程中识别。从流程中只能识别一局部 BO的行为，这一局部行为往 往被称之为业务行为；也是 BO最容易确定的一类行为，只要流程定义

13、清楚了， 这类行为就已经被确定了。例如，在上面的例子中，用户在流程中有登录和注册 行为；针对订单对象，有填写订单，提交订单行为；账单对象有支付行为等。2、从分析BO的完整性来识别。例如，用户有登录，就一定有注销行为；订单 能新增，一定可以修改和查询；账单能支付，也可以退款。3、从外部的需要来识别。例如，电子票本身是没有核对识别需要的，但考虑到平安性，一些运营商还是考虑了将电子票号进行了加密处理，票号本身含有身份识别信息。一旦电子票号遗失，只要有身份证信息，那么电子票仍能使用。通过三个层次的分析，一般能识别出绝大局部的 BO行为，当然，还需要对这些 识别的行为进行统一的描述。描述的内容包括行为名

14、称，行为说明，涉及的 BO 属性和变化。例如，B0行为整擲88说明属性状态变化用户人屮BO-1*3CBO-1-01 ) 口输入用户笆、密码、校验 码后与身份息犠对无 误f允许登录到杀统存用户状态未登录已登录4在识别BO行为的过程中，我们往往会遇到一些模棱两可的境地，例如，商品和购物车是两个不同的业务对象， 那么将商品添加到购物车的行为，是归属商品的行为，还是购物车的行为呢？有人说是购物车的行为；有人反问，为何这个行为主要出现在商品的单页上？我的意见是：当行为涉及到两个对象，一般把其归属到拥有管理职能的对象。购物车管理被放入的商品，管理放入的数量，也可以从购物车中删除。所以， 放入购物车的行为主

15、体对象是购物车。识别了 BO，BO的属性以及BO的行为 后，我们可以开始建立 APP 了。?建立APP建立APP的过程是明确系统范围的过程，同时也是生成系统模型的过程。建立APP有两种视角：1、一种是以BO为视角，聚合BO的行为，以管理BO的功能组成一个APP ； 例如，我们将针对订单的所有行为，组合成为一个 APP，称为订单管理。2、另外一种是以业务为视角，聚合一个流程的所有环节，以实现流程的功能组 成一个APP。例如，我们将针对打折票的预定流程中的所有行为环节，组合成 为一个APP，称为折扣票预定APP。具体参见以下图：聚合B0的行为jff行为Xpp视图、BO二 BO以BO为中心BO但不管

16、怎么组织APP的构成，在BO层面看，都是一样的：系统都是由操作BO 的一堆行为构成的 上面是从业务分析B0,分析BO的属性行为，然后组织 APP。然而，此刻还不能完成系统模型的构建，因为还需要思考这些已经被识别的APP是否足够支撑一个应用系统？这里需要引入两个重要设计分析过程：一个是用户体验设计，一个是非功能设计 用户体验设计User Experienee丨是以用户为中心的设计，是一种经验与创造 相结合的设计过程，主要目的是提升用户的操作舒适感，增强在同类产品中的竞 争力。在web2.0时代，用户体验设计将不再局限于展现流程和完成数据操作方 面，还承载了不同角色之间的信息多元化交互的设计需要，以用户为核心将不再是简单的信息提供推送而已。那么，在构建系统的APP时，也要充分的考虑UE设计的需要，参加一些 用于提升用户体验的APP，例如，Dashboard。非功能设计来源于用户的非功能需求，例如，系统的可管理要求，灵活扩展 要求，性能要求，平安要求等。这些设计除了在系统的架构设计时需要充分的考 虑和满足，在功能APP设计时也需要做相应的响应。 例如，最常见的一个APP- 系统管理，通常包含数据管理，日志管理，参数管理，模型管理，模版管理，接 口管理，APP管理等等。这些来源于 UE设计和非功能设计的APP与最早被识