一 : 实例化需求的优点

在互联网时代，交付速度是当今的主题。十年前，项目通常要持续好几年，并且项目阶段是以月来衡量的。如今，多数团队的项目周期是按月来衡量的，而项目阶段则减少到几周甚至几天。任何需要长远规划的东西都将被抛弃，比如大量的前期软件设计和详细的需求分析。超过项目阶段平均周期的任务将不复存在。跟代码冻结（Code Freeze）以及数周的手动回归测试说再见吧！

变化频率如此之高，文档很快就会过时。不断更新详细需求说明和测试计划（Test Plan）需要投入大量精力，相当浪费。那些以往在日常工作中依赖于此的人们，如业务分析师或者测试人员，在这个每周迭代的新环境中经常会无所适从。开发人员原本以为不会受到纸质文档缺失的影响，现在却要把时间浪费在不必要的返工与功能维护上。他们不是花时间去制订宏伟的计划，而是要浪费数周的时间去修正有问题的产品。

在过去的十年里，软件开发社区致力于使用“正确”的方式来构建软件，关注使用技术实践和思想来确保质量。但是，正确地构建产品和构建正确的产品是两码事。我们要二者兼顾才能取得成功。

图1-1

图1-1　实例化需求说明可以帮助团队构建正确的软件产品，而技术实践 可以确保正确地构建产品

想要有效地构建正确的产品，软件开发实践必须满足以下几点。

保证所有项目干系人和交付团队的成员都对需要交付哪些东西有一致的理解。

有准确的需求说明，这样交付团队才能避免由模棱两可和功能缺失造成的无谓返工。

有用来衡量某项工作是否已经完成的客观标准。

具有引导软件功能或团队结构变更的文档。

传统意义上，构建正确的产品需要庞大的功能需求说明、文档以及漫长的测试阶段。如今，软件每周都要有交付，这一套已经行不通了。我们寻求的方案要能带来如下好处。

避免过度说明需求从而产生浪费，避免花时间在开发前会发生改变的细节上。

有一种可靠的文档，可以解释系统的行为，据此我们能容易修改系统行为。

可以有效地检查系统行为与需求说明的描述是否一致。

以最少的维护成本维持文档的相关性与可靠性。

适合短迭代和基于流的过程，这样能为即将开展的工作提供即时足够的信息。

图1-2

图1-2　对于敏捷项目，构建正确文档的关键因素

乍一看，这些目标似乎互相冲突，但有很多团队已经成功地达成了所有目标。在做调研时，我采访了30个团队，他们完成了大约50个项目。我试图找出一些模式与通用做法，并挖掘出这些方式背后的基本原则。这些项目的共同思想，定义了一种构建正确软件的好方法：实例化需求说明。

实例化需求说明是一组过程模式，它帮助团队构建正确的软件产品。使用实例化需求说明，团队编写的文档数量恰到好处，在短迭代或基于流的开发中可以有效地协助变更。

实例化需求说明的关键过程模式将在下一章介绍。本章我将阐述实例化需求说明的好处。我将使用实例化需求说明的风格来进行阐述，而不是以理论介绍的方式来构建一个案例，我将展示18个真实的例子，它们都来自于那些大大受益于实例化需求说明的团队。

在开始之前，我想强调一下，在一个项目中很难孤立地看待某种思想的影响或作用。本文所描述的实践，可以与已经开展的敏捷软件开发实践[例如测试驱动开发（TDD）、持续集成以及使用用户故事做计划等]共同使用，而且可以增强其他实践的效用。当我们转而去看那些有着不同背景的项目时，很多模式浮现了出来。我采访的团队中，有些在实施实例化需求说明前一直使用敏捷过程，而有些团队则是在过渡到敏捷过程的过程中实施了实例化需求说明。大多数团队使用基于迭代的过程，例如Scrum和极限编程，或者是基于流的过程，例如看板。但是有些团队，尽管他们使用了这些实践，但他们的过程以任何标准来看都不是敏捷的过程。然而，他们大多都收获了如下类似的收益。

更有效地实施变更。他们拥有活文档——系统功能的可靠信息来源——让他们得以分析潜在变更的影响，同时可以有效地分享知识。

更高的产品质量。他们清晰地定义了预期，使得验证过程很有效率。

更少的返工。他们在需求说明上协作得更好，并确保所有团队成员对预期达成共识。

同一项目不同角色的活动协调得更好。改善协作形成定期的交付流程。

在接下来的4个小节中，我们将通过现实世界的例子，近距离地审视这些收益。

更有效地实施变更

在做调研的过程中，我获得的最重要的经验是关于活文档（living documentation）的长期收益的——事实上，我认为这是一个最重要信息，本文广泛地涵盖了这部分内容。活文档是系统功能的一个信息源，它与程序代码一样可靠，但更容易使用和理解。活文档帮助团队共同分析变更所带来的影响并讨论潜在的方案。团队还可以为新的需求扩展已有的文档。长此以往，可以使需求说明和实施变更更有效。大多数成功的团队都发现活文档的长期收益是实施实例化需求说明所带来的结果。

总部设在美国西得梅因市的爱荷华州助学贷款流动资产管理公司（Iowa Student Loan Liquidity Corporation，下文简称Iowa Student Loan），在2009年进行了一项相当重要的商业模式变更。过去一年，金融市场动荡使得贷款方几乎无法为私人学生贷款找到资金来源，因此，许多贷款方被迫放弃私人学生贷款市场或改变自己的商业模式。该公司适应了当时的市场。它从银行和其他金融机构募集资金来支助私人助学贷款，而不是使用债券收益。

Tim Andersen是一位软件分析师，同时也是一名开发人员，他说为了有效地适应市场，他们不得不“有声有色地进行系统核心大检修”。在开发软件时，他们的团队把活文档作为一项主要机制来编写业务需求文档。活文档系统让他们可以探悉新需求所带来的影响、帮助他们确定所需的变更，而且可以确保系统的其余部分仍旧正常工作。他们当时只花了一个月时间就对系统实施了根本性的变更并将其发布到了生产环境，活文档系统是做这项变更的根本。Andersen说：

任何未进行这些测试（活文档）的系统，都必将导致开发停顿和重写。

在加拿大魁北克省的蒙特利尔市，Pyxis技术公司的Talia项目团队也有类似的经验。Talia是企业系统的一个虚拟助理，它是一个拥有复杂规则、能与员工交流的聊天机器人。从最初开始，Talia团队就使用实例化需求说明来构建一个活文档系统。一年之后，他们不得不从头开始编写虚拟代理引擎的核心——而此时，正是在活文档方面的投资大显成效的时候。Talia的产品总监André Brissette是这样说的：

如果没有活文档，任何重大重构都无疑是自寻死路。

他们的活文档系统使得团队在变更完成时可以自信地说，新系统具有和老系统一样的功能。该活文档系统还能帮助Brissette管理并追踪项目的进度。

总部位于伦敦的现场音乐消费性网站Songkick的团队在重新开发网站活动摘要时，使用了一个活文档系统来协助变更。他们意识到目前的摘要系统无法扩展到所需的容量，活文档在重新构建摘要系统时就提供了有力的支持。Phil Cownas是Songkick的CTO，据他估计，因为拥有了活文档系统，他们的团队在实施变更时节省了至少50％的时间。据Cowans所述：

因为我们拥有让人满意的覆盖率，并且我们确实信任这些（在活文档系统里的）测试，所以我们很有信心可以快速地对基础结构进行大的变更。我们知道，系统功能不会改变，即使变了，测试也会发现。

ePlan Services是一个养老金服务机构，位于科罗拉多州的丹佛市，它的开发团队从2003年开始就已经使用了实例化需求说明。他们构建并维护一个金融服务系统，该系统涉及众多的项目干系人、复杂的业务逻辑以及复杂的监管需求。在项目开始三年之后，其中一位经理搬去了印度，而对于系统遗留部分，有些内容是只有他才掌握的。根据ePlan Services的测试人员及Agile Testing: A Practical Guide for Testers and Teams一书作者Lisa Crispin的描述，当时，团队努力地学习那位经理所拥有的知识并将其构建成活文档。活文档系统帮助他们获得了业务流程的专业知识，并立即提供给所有的团队成员。他们借此消除了知识传递的瓶颈，可以有效地支持并扩展系统。

在比利时Oostkamp的IHC集团，病人管理中心项目组实施了一个活文档系统，并取得了类似的结果。该项目开始时重写了一个大型机系统，它是从2000年开始的，目前还在进行中。Pascal Mestdach是该项目的方案架构师，他说团队从中受益匪浅：

当时遗留系统中的一部分功能只有少数几个人了解，而现在情况已经好很多了，那是因为团队拥有一套针对那部分功能的、不停增长的测试套件（活文档），它描述了该遗留系统的功能。当专家休假时，还可以从活文档系统中寻找问题的答案。对其他开发人员来说，可以更清晰地了解软件中某部分的功能。并且还是测试过的。

这些例子阐述了活文档系统如何帮助交付团队分享知识并应付人员变动。它还使得业务可以更有效地响应市场变化。我将在第3章里对此做更具体的说明。

更高的产品质量

实例化需求说明可以改善交付团队成员之间的协作，促进商业用户更好地参与，并为交付提供清晰客观的目标——大幅提高产品质量。

有两个突出的案例，分别来自Wes Williams[来自世博控股（Sabre Holdings）的敏捷教练]以及Andrew Jackman[为法国巴黎银行（BNP Paribas）的一个项目工作的顾问开发人员]，他们将描述之前失败过多次的项目如何通过实例化需求说明走向成功。本文中描述的方法帮助他们的团队克服了业务领域的复杂性，之前这种复杂性是很难处理的。同时还帮助他们确保了交付的高质量。

在世博控股，Wes Williams工作的项目是一个为期两年的航班订票项目，团队分布在全球各地，流程又是数据驱动的，这使得项目十分复杂。项目有3个团队，30名开发人员，分布于两个洲。据Williams说，系统头两次构建都失败了，但是第三次使用实例化需求说明后就成功了。Williams说：

我们在一家大客户（一家大型航空公司）上线时缺陷非常少，在（业务验收）测试阶段只有1个缺陷是比较严重的，是故障切换（fail-over）相关的问题。

Williams认为实例化需求说明是他们取得成功的一个关键因素。除了保证高质量外，实例化需求说明还有助于建立开发人员和测试人员之间的信任。

在法国巴黎银行，Sierra项目是另一个很好的例子，可以展现实例化需求说明如何带来高质量的产品。Sierra是一个债券的数据仓库，整合了一些内部系统、评级机构和其他来自外部的信息，并将它们分发给银行内部的各种系统。许多系统和组织使用相同的术语，表达的意思却不尽相同，这导致了许多误解。最初两次实现系统的尝试都失败了，据Channing Walton说，团队中的一个开发人员促使了第三次尝试的成功。第三次努力的成功部分归功于实例化需求说明帮助团队处理了复杂性问题，并且确保了团队的共识。最终的产品质量令人印象深刻。项目从2005年上线以来一直在运行，Sierra项目的顾问开发人员Andrew Jackman说：“生产环境中没有出现大的问题。”现在Sierra项目中的大多数工作人员都不是项目启动时的那些人，但是质量水平一直都很高。

Bekk咨询公司在为一家大型法国银行支行开发租车系统时也取得了类似的成果。Aslak Helles?y曾是那个团队的成员，还是Cucumber——一个支持实例化需求说明的热门自动化工具的创造者，据他说，尽管现在维护这个软件的是一个全新的团队，但他们在系统上线后的两年中却只发现了5个缺陷。

Lance Walton曾在一家大型瑞士银行伦敦分行的一个项目中担任过程顾问，这个项目是要开发一个订单管理系统，开始的几次也都失败了。Walton进入这个项目时，大家都认为实现这个系统需要至少和开发团队一样大的支持团队。他的团队使用了实例化需求说明，项目开始9个月后就交付了生产系统，一天内就通过了业务验收测试，之后6个月内没有发现任何缺陷。Walton说新的系统不需要额外的支持人员，成本比预期要低，而且团队更早地交付了成品。相比之下，他们旁边的团队需要10倍于开发团队的支持人员。Walton指出：

现在团队依然每周发布一次，用户总是对它非常满意。从质量上看，它棒极了。

实例化需求说明的技术不仅仅适合于新建项目，同时也适用于改建项目。建立起值得信赖的文档、清理遗留的系统，都需要一定的时间，但是团队很快就能看到诸多的好处，并对新的交付充满信心。

还有一个不错的例子是伦敦摩根大通的外汇交易系统。Martin Jackson是该项目的自动化测试顾问，他说业务分析员预计项目会推迟，然而事实上，项目提前两个星期就交付了。高质量的产品让他们成功地在一个星期内完成了业务验收测试阶段，而不是原先计划的4个星期。Jackson说：

我们部署好系统后，系统工作正常。业务人员向董事会报告说这是他们经历过的最好的用户验收测试（UAT）。

实例化需求说明还使Jackson的团队在项目开发晚期快速实现了“一次重大的技术改动”，提高了计算的精确度。Jackson称：

FitNesse套件（活文档）覆盖的所有功能，通过了完整的系统测试和用户验收测试，在生产环境上线时也没有发现任何缺陷。系统测试时发现了几个核心计算组件以外的错误。业务人员之所以觉得用户验收测试非常好，是因为出现计算错误时，我们都非常确定根本问题是在计算代码的上游。使用了FitNesse后，很容易诊断出缺陷的根源，从而可以更加利落快速地交付到生产环境中。

科罗拉多州丹佛市的惠好公司有个软件开发团队，他们编写并维护一些工程应用和木制框架的计算引擎。在使用实例化需求说明以前，结构工程师通常不会参与到软件开发过程中，即使团队正在处理一些复杂的科学计算公式和规则。这导致了一些质量问题和延误，由于使用这个引擎的应用程序有好几个，计算过程变得更加复杂。项目的软件质量保证主管Pierre Veragen认为发布前的艰难时期会拖累项目，版本发布出去后很少会没问题。

实施实例化需求说明后，团队现在和结构工程师合作制定需求说明，并自动化验证结果。当有变更需求进来时，测试人员和结构工程师一起得出期望的计算结果，并在开发开始前用实例把结果记录在需求说明中。之后批准变更的工程师会编写需求说明和测试。

Veragen说新方法的主要好处是他们在做改动时有信心了。到2010年初，他们的活文档系统中已经有超过30 000个检查，而且几年内都没有发现大的缺陷，现在已经停止追踪缺陷了。Veragen指出：

我们不需要（缺陷数）这个指标了，因为我们知道它不会再回来了……工程师们喜欢测试先行的方式，并且能直接访问自动化测试。

Lance Walton参与过一家大型法国银行伦敦分行的信用风险管理程序的开发。项目刚开始的时候，有外来的顾问帮助团队采用极限编程的实践，但是他们没有采用任何实例化需求说明的做法（虽然极限编程包括客户测试，这个与可执行的需求说明很接近）。6个月后，Walton加入了这个项目，他发现代码质量很低。虽然团队每两个星期都会有交付，但是写出来的代码使验证变得很复杂。开发人员只测试最近实现的功能，随着系统的增长，这样的做法就不够了。“当有版本发布时，大家都紧张地围坐着，想确保所有功能都能正常运行，并且期望可以在几个小时内发现一些问题。”Walton如此说。在实施实例化需求说明后，产品的质量和人员的信心都有了显著的提高。他补充道：

我们十分确信我们发布的版本没有问题。我们高兴地部署完以后就出去享受午餐了，不用再担心是否会出问题。

与此形成鲜明对比的是，英国贸易者传媒（Trader Media）集团的网站重写项目停止使用实例化需求说明后，却遭遇了质量问题。起初团队协作完成需求说明和自动化验证。在管理层的压力下，他们为了更早更快地交付更多的功能而没有继续下去。测试团队的主管Stuart Taylor说：“我们注意到质量出现了大幅下滑……以前我们（测试人员）很难找到缺陷，而后来我们却发现一个用户故事会有四五个缺陷。”

并不局限于敏捷团队

不是只有敏捷团队才可以从协作制定需求说明中获益。在Bridging the Communication Gap一书中，我建议在更为传统的结构过程中应用类似的实践。

英国Sopra集团的高级测试顾问Matthew Steer帮助一个大型电信公司的第三方离岸软件交付伙伴实现了这些实践。他们意识到项目需求定义不明确后，决定作出改变。Steer比较了实施实例化需求说明前后一年的交付成本。不出意料，这些项目使用瀑布方式开发，没能达到零缺陷的级别，但是这些改变“提高了上游缺陷的发现率，减少了下游的返工和成本”。Steer说：

我们在软件生命周期早期发现的很多缺陷，传统上要到晚期才能发现，这足以证明这个方法行之有效。缺陷数在生命周期的晚期有明显的下降，而在早期则有所提升。

最后结果是，交付成本仅在2007年就节省了170万英镑。

减少返工

一般来讲，频繁地发布会促进快速反馈，使得开发团队能够更快地发现错误、修复错误。但是快速迭代并不能避免错误。通常情况下，团队实现一个功能时会有三四次反复。开发人员称，这是因为客户在拿到产品试用前并不知道自己想要什么。我并不这么认为。使用实例化需求说明后，通常团队第一次实现的就是客户所要的，无需返工。这可以节省大量的时间，并使得交付流程更具可预测性、更加可靠。

位于伦敦的英国天空广播公司（British Sky Broadcasting）的天空网络服务（SNS）部门负责宽带和电话的服务配置（provisioning）软件，它的业务流程和系统集成都极为复杂。该部门由6个团队组成，他们使用实例化需求说明已经有好几年了。据他们的资深敏捷Java程序员Rakesh Patel说：“当我们说交付时，确实是能马上交付的。”并且该部门在Sky公司内具有很高的声望。Patel曾和其他公司的团队一起工作了一段短暂的时间，他对两个团队做了比较，他说：

他们（其他公司的程序员）每次在迭代（sprint）快要结束的时候才把软件交给测试人员，测试人员总是发现问题并退回给程序员。而在这里（Sky），我们不会如此反复。如果有错误，我们会编写一个测试，而后在开发过程中使测试变绿——要么通过，要么不过。我们可以当场发现问题。

其他不少团队注意到了返工的大量减少，其中包含LeanDog，它为一家美国大型保险机构开发聚合应用软件。他们的应用软件为很多大型主机和基于Web的服务提供统一的用户界面，而且由于拥有来自全国各地的大量项目干系人，该软件变得更加复杂。最初，在需求方面，该项目遭受了很多功能缺失的问题。Rob Park是LeanDog里帮助团队转型的敏捷教练，他说：

刚开始理清头绪时，我们需要澄清需求，而后我们发现不得不切实做些改变。

该团队实施了实例化需求说明，结果需求说明改善了，返工也减少了。据Park说，虽然当程序员针对某个故事卡开展工作时，有些问题还要向业务分析师咨询，但是“问题已经大为减少，而且重复性工作少了，只剩下不同的问题”。对他来说，实例化需求说明最有价值的方面在于“当着手实现一个故事时，你可以领会它的意图，并了解它的范围。”

很多团队还发现在开发周期的起始阶段，使用实例化需求说明会让需求更加精确，这样管理产品功能清单（product backlog）会更加容易。例如，能够尽早识别太含糊或有太多功能缺失的故事，这样可以防止以后出现问题。如果没有实例化需求说明，团队经常要到迭代中期才发现问题，这会中断流程而且需要耗费时间重新讨论——在大公司，决定功能范围的项目干系人往往无法轻易预约到。

实例化需求说明能帮助团队建立一个协作制定需求的过程，这可以减少迭代中期的问题。此外，实例化需求说明适用于短迭代，并且不需要花费数月的时间来编写冗长的文档。

Ultimate软件公司位于佛罗里达州的韦斯顿，对于它的全球智能管理（Global Talent Management）团队来说，减少返工是一个主要的优点。协作制定需求说明在专注开发工作方面有着显著的影响。据Ultimate软件公司的资深测试开发工程师Scott Berger所述：

在团队认可一个故事之前，与产品负责人一起审核测试场景可以使工作小组（产品负责人、开发人员和测试人员）澄清模棱两可或缺失的需求。有时，会议结果甚至会把故事给撤销了，例如，测试场景会揭露出系统隐藏的复杂性或相互矛盾的需求。有一次，进行这样的讨论之后，大家做出的决定是几乎重新设计整个功能！产品负责人获得了重写和重新分割需求的机会，而不是在开发进行之后，中途停止或取消该故事。通过举行这些会议，我们发现自己的生产力和效率都提高了，因为减少了浪费，而且模糊和需求缺失的程度降到了最低。同时还让团队对预期达成了共识。

大多数团队显著地减少或完全消除了由于误解需求或忽视客户的期望而造成的返工。本文所描述的实践，可以让团队更好地与商业用户打交道，并确保大家对结果达成共识。

作者Gojko Adzic，战略软件交付顾问，专注于敏捷和精益开发，尤其擅长敏捷测试、实例化需求和行为驱动开发。Gojko经常在国际上重要的软件开发和测试会议上发言，并运营着英国的敏捷测试用户小组。最近这十多年来，他一直在财务和能源交易平台、移动定位、电子商务、在线游戏和复杂配置管理系统等行业项目中，从事程序员、架构师、技术指导和顾问等工作。

译者张昌贵，软件开发经理，CSM, CSPO, CSP，敏捷软件开发参与者，软件开源运动拥护者。译者张博超，软件开发工程师，CSM, CSPO, CSP。关注敏捷开发，积极实践并推广各种敏捷方法。译者石永超，软件开发工程师，CSM，CSPO，敏捷爱好者，InfoQ中文站编辑。关注高效、高质量的软件开发方法。

本文节选自《实例化需求：团队如何交付正确的软件》一书，Gojko Adzic著，张昌贵、张博超、石永超译，人民邮电出版社出版。

“www.61k.com。

未完待续，更多精彩请关注比比读小说网微信公众号

二 : 用一个公众号为例 说基于使用需求的记账分析

　　目前充斥着的app大体上是浮躁和多余的，都是被人为想像出来的自以为是的“解决用户痛点”，而真正满足用户需求的，不浮夸的App应该是小而美的，不给用户造成过多的困扰。

　　

 

　　前段时间看到一篇文章，作者认为“app生态已经趋于饱和，低频产品已经没有开发app的必要，转而开发微信公众号(未来是应用号)将是最佳选择。”并且对微信app进行了简单的定义：为满足用户某种需求开发的，完全基于微信的消息或网页应用，入口是公众号，用户无需离开微信即可完成所有操作，所有需求都在公众号里被满足。

　　就我个人看来，微信公众号除了本身的作为推广宣传的渠道之外(如自媒体)，以及服务号本身提供的一些接口服务(如招商银行的服务号)，更适合的是小而美的应用。最近，发现了一个订阅号——记账机器人，刚好符合这个微信app的定义。

　　记账机器人

　　记账机器人是一个记账类的微信公众号，它的功能也很简单，只需在聊天窗口输入每次的花费，就会帮你统计你的花费。例如：

　　

 

　　记账机器人记账示例

　　机器人就会提取数字，帮你记录。将每一次的支出发给机器人后，就会收到统计数据，返回您的花费总额和日平均值。

　　基于使用需求的记账分析

　　根据马斯洛的需求层次理论，我觉得记账行为一样存在着不同层次的需求满足，我称之为记账需求层次，粗略的分为三个需求层次：基本需求、进阶需求、高级需求。事实上，每个App的迭代更新，就是一种满足用户更高需求的迭代。

　　1.记账的基本需求

　　记账的基本需求，就是满足我们的消费支出统计，也就是消费流水统计的需求。简单直白的说，就是我想知道我每天，每个月花了多少钱，这是用户记账行为最基本也是最核心的一个诉求。

　　目前，所有的记账类App都可以满足这个需求，但随着每个App用户数量的增加，为了提高自己的产品竞争力，功能也做得越来越全越来越复杂。我相信，所有记账类App最初的记账做法，“什么消费花了多少钱，即消费项目+金额，就可以完成一笔消费记录”，但发展到如今，记录一笔支出，可以记录的尽可能的详细。

　　以随手记为例，用户除了最基本的支出金额，还需要设置消费分类等。除此外，用户自行自行选择还可以尽可能的详细到包括消费时间、消费商家、消费项目等。

　　

 

　　随手记记账示例

　　对于很多用户来说，你所给予的已经超出了他所需要的，之所以，很多用户的记账都难以持续，很大程度上就是因为记录的过于复杂和琐碎。大众用户的记账需求，实际上依然没有太多的变动，“即消费项目+金额”即可满足。太多的选择，反而会让用户迷茫，并且也很难持续进行记录。就这点来说，记账机器人就是基于用户这一最基本需求出发，也只有这一最基本的“消费项目+金额”的记账功能。

　　2.记账的进阶需求

　　当我们有了消费流水记录以后，就希望能够分析自己的消费支出情况，看一下自己每个月的主要消费是什么，有哪些意外的消费支出等。记账的进阶需求，就是满足用户的消费分析，通过统计每日、每月的消费图标分析，了解自己的消费构成。也就是通过消费数据统计功能，清晰地了解自己的消费情况，并通过数据改变自己的消费行为。

　　图表分析，也已成了记账类App的标配，通过你自己的每笔记账记录，来输出统计报表，以让用户能够更直观的了解自己的消费情况，并用来指导用户有意识的培养自己的理财规划习惯。不过，图表分析功能的实现效果一定是基于用户能够如实并且详实的记录自己的每一笔消费支出的前提下的，如果用户的消费记录难以持续或者存在瑕疵，图表分析的作用就有限。

　　

 

　　随手记图标分析

　　现在的记账类App都已经有了丰富的图标分析功能，支持按周、按月、自定义时间周期的消费情况分析，消费类别分析等，并且具有丰富的统计展示形式，如饼图、柱状图、曲线图等，除此外有的还支持自定义统计指标、不同之处账户统计、成员统计等。就统计分析功能而言，这是记账机器人所不具备的，其目前也只就简单的统计功能。

　　3.记账的高级需求

　　记账的高级需求，就是满足不同的账户(场景)消费统计，例如现金账户消费统计、信用卡账户消费统计、股票账户消费统计、公交卡消费统计等。这种更为细致的记账账户区分，我个人认为已经不是简单的记账需求，而是可以归类到个人理财规划的层面，是在用户养成了最基本的记账需求，并且已经有了理财规划意识，开始进行消费预算、投资理财的一种行为。这是针对记账高阶人群的需求，绝大多数用户可能都不会去使用或者涉及到。

　　

 

　　随手记账户分类示例

　　就记账的三个需求层次而言，绝大多数用户依然停留在基本需求层面，当消费记录习惯养成后，会逐渐地有图表统计分析的需求，而至于更高级的账户区分需求，仅仅覆盖极少数的用户。但目前的基本需求我觉得依然是很多记账类App难以解决的问题：如何让用户养成记账习惯?

　　就我个人的经验而言，一直想养成支出记账的习惯，但所有的记账方式都觉得过于繁琐而难以长久的坚持下去，因为记账本身是一种高频的但又令人厌烦的行为，所以简介快速的记账步骤是核心中的核心。虽然，很多记账App的记账方式在不断地丰富，如拍照记账、语音记账、模板记账、周期记账等，方式很多样，但不知效果如何。

　　基于场景的记账分析

　　谈完了记账的需求分析，我想在从使用场景来分析一下。通常，我们记账的时间都是比较碎片化的，在消费发生后，马上记录支出的金额。例如我在上班路上买完早餐，然后我需要立即记录我的这笔早餐支出，而在用手机记录的时候，通常我是处于短暂停留或者步行移动的过程。在这种场景下，我们记一笔支出所耗费的时间应该是以秒为计算单位来完成，在记账的过程中，不需要通过太多的头脑思考，而是条件反射式的机械化操作，简单记录每笔花销即可。

　　如使用随手记等记账类App的话，那么这笔花费需要记录的时候，我需要

　　打开app

　　点击记一笔

　　输入金额、选择消费分类，选择账户

　　点击保存

　　整个过程，尤其是在记账的过程是比较复杂的，当我在记录这笔指出的时候，还需要思考这笔支出需要归类到什么消费类型，而这种选择，对绝大多数然来说都是比较困难的，需要一定的思考转化过程，特别是对一些强迫症患者来说，可能选择消费类型内心会非常的纠结。

　　而如果使用记账机器人的话，那么这笔花费的记录是：

　　打开微信

　　选择记账机器人

　　输入消费金额

　　对比二者的记账过程，关键点就在于记账的这一核心环节。如我前面提到的，随手记等记账类App，其记账过程是较为复杂的，更适合在一个安静，用户能够有一定思考的环境使用，如用户每天晚上花费10几分钟的时间，统计今日的花费记录。而记账机器人的记账过程，是极简的过程，基本只要有一笔消费完成，最多10几秒的时间就可以完成。

　　好产品的三要素

　　在接触了这个公众号后，和其背后的开发者也进行了沟通。其之所以做这个产品，是因为其不知道自己每个月、每年的花销情况，而使用记账类App过于的繁琐(果然程序员的习惯就是极致的简洁)。所以萌生了做这个记账机器人的想法。

　　一个好的产品，需要满足三个条件：有价值、可用性、可行性。从这三点来说，这个记账机器人是满足的小而美的应用：

　　有价值：记账机器人是为了解决日常的用户消费流水记录，想知道自己每天(月)花了多少钱的需求。从功能上来说，基本可以满足绝大多数用户的记账的基本需求。

　　可用性：与其他记账类App的繁琐记账来说，通过消息发送的方式进行记账，是更方便并且用户习以为常的一种操作交互，而这种交互在前文的场景分析中我也提到更适合用户常见的记账场景。

　　可行性：相较于开发一个App，需要考虑前后端的设计，数据库设计，UI设计，考虑系统适配、机型适配等，需要多个人的配合完成。在微信上开发一个人即可完成，不需要考虑系统平台的客户端开发、服务端开发，可以利用微信本身提供的功能接口(例如语音输入接口、关键词回复接口等)，可以极大地减少开发和维护成本

　　总体而言，如果觉得目前的记账类App太过繁琐，不追求详细的消费流水记录，作为一个轻量化应用，它能够很好地满足简单记账的需求，以及简单的支出统计功能。但如果想要有意识的通过记账的分析来进行理财规划，那么这个应用是达不到的。

　　所以这是一个小而美的聚焦于某个大众需求的简单应用，我觉得目前实际上我们缺少的正是这种单一的简单的应用，现在的App功能实在是太重太重，都追求大而全，追求界面、交互，但用户基本的诉求却难以很好的满足。

　　作者：可飞。公众号：@可飞(ID：abckefei)。互联网产品经理，目前专注互联网金融领域，记录自己作为产品经理的点滴，用文字记录的方式进行反思提升。

三 : 求配色卡实例分析？

求配色卡实例分析？的参考回复

色彩，一直是设计讨论中永恒的话题。在一个设计作品的第一印象中，占70%的视觉冲击力。

。www.61k.com。

讲色彩构成和基本原理的出版物很多，都讲得很详细。所以关于色彩构成的基础我这边就不赘述了，大家自己去看书。

正好前不久有人问我那个DA的配色卡资源如何使用，所以，今天就来讲下配色色卡的制作，和举些实例大家参考下。

本文多有疏漏，还望谅解。

一、向自然学习色彩搭配，制作自己的配色卡。

我们很多朋友在做设计的时候，经常为自己的用色烦恼，画面不是做得又花又艳又俗，就是谨慎的用同一个色相不同明度来做搞得很单调又死气沉沉。

不敢用色，或者乱用色成为一个通病，其实我们可以向真实的世界中的配色去学习，然后提炼出一套自己的配色色卡来为我们所用。

当然，很多人知道，黑白灰3个无彩色是一贴杀手锏，可以调和各种无彩色。我也同意这个观点。但是我们这次再学一些可以现学现卖的技巧。

大自然的美在于其千变万化，我们设计师应该有一颗捕捉美和变化纤细的心。比如大海，如果有人问你大海是什么颜色，你可以回答蓝色，但是你仔细观察，大海的细节，大海是色彩斑斓的。艺术是来源于生活的高于生活的，设计师要经常总结。设计是一个“理解-分解-再构成”的技术。

朝阳下大海和深山里的岩石

其实不单单是自然界，很多人造物在自然光线下也会呈现出很和谐的色彩搭配。现在流行跨界学习，下面再给两张例子。

古典室内陈列和诱人的食物

还有明快的配色，如北冰洋的积雪，绿色的瓷器，黄色的花朵，他们在自然光下都呈现出丰富的色彩细节。

动手题，去年开始国内兴起了很多以视觉图片收集为主题的网站，如堆糖、花瓣等，大家可以去收集图片。来做做看自己的配色卡。

色彩会说话，每张配色卡都会有自己的故事，比如上面的嫩绿色配色卡。让你感到清新，自然，绿茶等情感。你如果正在做一个，以环保家装或者园艺为主题的网站，可以考虑选用。

二、配色卡的运用，如何把配色用到设计中。

大家知道，一个网页一般由主色调 辅色调 点睛色 背景色等几部分构成。所以一个网站的主色调是非常重要的。色卡有时候可以很方便的帮你找到那个网站需要的主色调。但是我们要活学活用。自己增加和减少色块比重来调和整个画面。甚至可以用2张相似的色卡来达到增加颜色细节的目的。在你的实验中说不定可以升华出更华丽新颖的配色。

下面是一些配色卡和网站实例的运用例子。

蓝色+白色调和，一种看起来很权威和官方的配色（请注意这个蓝色和科技蓝的区别）

彩虹糖果色+黑色调和，一种梦幻活泼的妖艳的配色

（一般比较亮的彩虹色都会显得很粉很飘，加入大面积黑色调和后，画面稳定很多）

橙蓝对比色的和谐统一，一种有活力，并且造成时间感的色彩运用

（大家知道，橙色和蓝色是补色，用的不好就会俗气，这个作品，很好的在橙色里加了米色（白），蓝色里加重了深蓝（黑），来拉开色相上的冲突）

绿色+白调和，一种自然的优雅的清新配色

（注意本作品运用白色和绿色大面积渐变来制造柔和轻松的气氛，并且那些水晶感觉的按钮，以及小提琴元素，金色丝带风格线上的亮点都让本作品如雨后森林一样美丽）

棕色+白+黑调和，一种高雅的如史诗般的配色

（棕色一般被运用在怀旧复古的作品中，本作品在棕色里很好的加入了金色点缀及羊皮卷和油画风格，非常好诠释了电影制作及奥斯卡金像奖相关的信息）

红色+黑色调和，一种金属冷色+热烈的红色的对比配色

（本作品运用黑白灰的金属色调来体现出科技感，又用热烈奔放的红色来表现出音乐手机的产品定义）

四 : 我国手机需求因素分析-以小米手机为例

MPAcc2012秋

讨 论
影响我国手机需求的因素 目前影响我国手机需求的因素主要来自 手机本身、制造商、销售商、潜在顾客、 周边环境等五个方面。

手机本身因素
? 手机的价格仍然是影响消费者对手机需求的主要因素，手机 的需求量与其价格呈反方向变化。 ? 预期价格也是对当前手机需求的一个比较重要的影响因素。 随着生产技术水平的不断提高，未来手机的价格将会有较大 幅度下降的趋势，一定程度上造成不少消费者呈待价而沽的 态势，减少了当前对手机的需求。 ? 手机的品种、颜色、外观、品牌是影响消费者对手机需求的 几个因素。随着我国国民收入的持续增加，人民生活水平的 不断提高，人们对手机产生了差别化需求，特别是青年人越 来越追求个性化，对手机需求的层次会越来越高。 ? 手机的性价比是影响其需求的另外一个重要因素。性价比高 的手机容易被市场所接受，容易受到消费者的欢迎。

来自制造商的影响因素
? 制造商的生产规模大，手机的产量高，意味着社会上拥有该种 品牌手机的用户比较多。 ? 制造商的营销能力强，其产品的需求量就大已是不争的事实。 ? 制造商过去的业绩及其在公众中的形象也影响到其产品的需求 。 ? 公众对制造商的发展预期也是影响制造商产品需求的一个因素 。 公众认为某个手机制造商有着良好的发展前景，消费者购买其 产品就比较放心，相信其有能力提供比较完善的售后服务。 ? 制造商产品出厂后的服务质量是影响制造商产品需求的一个重 要因素。如果制造商有完善的出厂后服务，发生问题后就比较 容易得到解决。这样，消费者就愿意购买服务质量比较高的制 造商的产品，因而其产品的需求量就大。

来自销售商的影响因素
? 与制造商类似，销售商的经营规模、营销 能力、营销策略、过去的销售业绩、在公 众心目中的形象及其售后服务质量是影响 其所经营的手机需求的主要因素，这个问 题比较容易理解，在此不再详细讨论。

来自潜在顾客的影响因素
? 潜在顾客将来的收入和消费预期是目前影 响我国手机需求的一个非常重要的因素。 ? 潜在顾客的消费偏好和消费观念也是影响 手机需求的一些因素。

来自周边环境的影响因素
? 潜在顾客的家庭其他成员、亲戚、邻居、 朋友及同事等周边人群对购买手机的看法 和态度会促进或动摇潜在顾客购置家用手 机的决心。

M1的简介
? 小米手机[1]是小米公司（全称北京小米科技 有限责任公司）研发的高性能发烧级智能手 机。 ? 小米手机坚持 “为发烧而生”的设计理念， 将全球最顶尖的移动终端技术与元

器件运用 到每款新品。同时小米手机超高的性价比也 使其成为近年来最值得期待的智能手机。

小米M1的需求分析
? 需求函数： ? 小米的需求量=f(小米的价格、相关替代品 的价格、消费偏好、消费者的收入水平、 广告费用等）

? Q=f(Px、Py、T、I、A）

小米M1的价格对需求的分析
2500

2000
1500 1000

价格P

系列1

500
0 0 1000 2000 3000 4000 5000

销量Q

得出的函数关系
Q = 11810.962061 - 5.9434073175*P 由此，企业可以根据价格P预测出 未来的销售量，以便做出预算。

END 谢谢！

本文标题：uml需求分析实例-实例化需求的优点
本文地址： http://www.61k.com/1203342.html