掌握需求过程2

掌握需求过程

中篇

第六章 场景

场景就是情景梗概或一系列假设的步骤。将工作分解为一系列的步骤或情景，通过解释这些步骤，就解释了工作。即场景讲述了业务用例的故事。

在编写场景时，将业务用例的功能分解成一系列的步骤，每个步骤都是某种有意义的、可识别的活动，构成BUC的一部分。UML（统一建模语言）、BPMN（业务过程建模表示法）等可以用于描述场景。

假设场景让你探索一些可能性，对业务规则提出质疑。假设场景的目的是激发创造性，引导利益相关者得到更创新的产品。同时检查正常用例中的每一步，询问是否有人反对或错误执行这个动作。在收集需求时，尝试产生一些假设场景来研究不可预见的事情，这样做的意图是将不可预见转变为可以预见：在构造产品之前对可能发生的事情了解得更多，产品就会更健壮、更耐用。

第七章 理解真正的问题

如何通过“抽象”来找到真正的问题，即关注想法而不是解决方案，换言之，抽象就是思考问题的本质，护理技术或物理的部分。从所有提出的解决方案中分离出问题的本质，无论技术如何实现，本质总是存在的。如果需求包含了实现的方法，那它就是解决方案而不是需求。对于任何技术，都必须从技术中抽象出来，看到它背后的本质目的。

系统思考

系统思考很适合需求阶段，系统思考的基本思想是将业务看出一个系统，得到的结果是任何部分都不能独自得到。所以我们要看这些部分的聚合以及它们交互的方式。不要只看解决方案，后退一步，看看想改进的整个工作。系统思考的思路是考虑整个业务，它的组成部分如何相互交互，最重要的是它们相互之间如何“影响”。不是查看简单的过程流图，也不是遵守某人对过程的文本描述，而是考虑系统的不同部分如何相互“影响”。

假想用户

如果真正的用户不能出席或者人数太多，无法逐个进行访谈，假想用户就有用了。假想用户是一个虚拟的角色，替代真人用户。在无法接触真正的用户或客户时，采用假想用户。不管怎样，大部分团队会编写一两页描述，确定假想用户的行为模式、目标、技能、态度和环境。一个产品可以有多个假想用户，但应该有一个假想用户是该产品的主要目标。

挑战限制条件

限制条件是强加在问题或可选解决方案上的限制，它可能是一条业务规则，也可能是一条指令，说明解决方案必须采取的方式。限制条件的问题在于，每个人都假定限制条件是真实不变的。挑战限制条件尝尝导致一些令人吃惊的创新。

创新

创新研讨会是产生想法的一种方式，如果有大量的利益相关者参与创新过程，可使用这种方法。如果希望利益相关者理解新的、更好的工作方式带来的好处，而不只是重新构建同样的老系统，也可以采用创新研讨会。

头脑风暴也是一种创新的方法，针对问题的范围，它会产生许多想法，这种策略并不是要推动不受约束的范围蔓延，相反，头脑风暴产生的想法会导致更好产品而没有增加费用。

思考Brown Cow模型中的Future-How部分，结果是得到一些未来工作的模型，我们通常使用简单的场景和草图引起利益相关者的合作，因为Future-What代表了新业务策略或要做的新工作，所以需要利益相关者的全面合作，对工作的范围达成一致意见之后，确定Future-What视图，更新工作上下文范围图，根据需要添加或修改事件列表。

每个人都想要激动人心的未来，所以要确保我们未来的工作不令人失望。

第八章 开始解决方案

Brown Cow模型要从第三象限Future-What到第四象限Future-How，从抽象的世界转向物理世界，从策略转向技术，从问题转向解决方案，从目标转向设计。

业务分析师要考虑许多因素，决定要构建的最佳产品

迭代式开发

确定产品的范围

考虑用户

设计用户体验

创新

接口草图

业务事件的起源

相邻系统和外部技术

成本、收益和风险

产品用例场景

第九章 业务分析策略

需求策略作为指导，决定从哪里开始，是否有足够的细节，需要哪些迭代循环，记录知识时采用哪种方式，何时复查，何时让哪些利益相关者参与，何时构建原型，何时及如何做大量的事情，让工作更接近业务产生最优价值。沟通需求知识、发现和传播知识的活动、参与的人，这些是影响需求策略的所有变量。

需求活动是一个活动的框架，需要根据给定的项目轮廓，执行这些活动，发现合适层面的知识，与合适的人沟通这些知识。所有负责的项目都有一个共同点：期望在有关限制条件下，尽可能快地得到最佳结果。需求工作中的每项活动都会积累知识，积累足够的知识后就达到了突破条件。每个活动的突破条件是不同的，要为每种项目轮廓（外部轮廓、迭代轮廓和顺序轮廓）定义不同的突破条件。

外部轮廓项目是指采用了外部解决方案提供商。

迭代轮廓项目是指以迭代的方式发现需求并交付部分解决方案，知道产品完成。

顺序轮廓项目对具体的活动和交付设有很多的限制，需求完全确定，才能提交给设计者和开发者，让他们开发解决方案。

需求策略如下：

概念到范围确定

范围去的到工作调研

工作调研到产品确定

工作调研到原子需求定义

工作调研到构建

产品确定到原子需求定义

产品确定到构建

原子需求定义到构建

大多数组织机构发现，每个新项目都是在开发类似的产品。服用需求可能节省大量的时间和工作量。寻找业务规则，业务规则是组织机构设定的一些方向，知道操作、人员和系统要做什么，从顶层管理到最底层的流程，作为业务分析师，要揭示以前未知的规则，或创建新的规则。有一种开发方法学叫“业务规则方法”，它用自然语言记录业务规则，然后翻译成业务过程，有时候会翻译成软件。业务用例场景足够成为有用的规则存储处。在业务分析师研究一个系统时，一定不能只看到组件，而是要看到它们协作的方式。