需求分析
《掌握需求过程》笔记十二：需求工作之迭代环境下的需求工作
摘要: 高速发展的世界，需要我们迭代地开发和改进业务问题的解决方案，我们需要一些方法来持续探索业务及其问题，将这些要求告诉技术专家，他们为业务提供技术解决方案。
许多组织机构不是等待需求的所有细节都得到定义，而是更喜欢迭代完成这些业务活动，定义一些需求，开发一部分解决方案，定义更多的需求，这样增量式交付发行版本，直到解决方案被判定完成。这种迭代的方式意味着，业务环境和开发环境中的关注点、想法和变化更加同步。使开发者更了解今天的业务问题，工作的产品适合今天的业务环境。
这种持续的工作探索意味着，业务分析师持续地将新故事或需求加入分析列表，这个列表又持续地按价值进行分析，最重要的是按业务价值来分析。列表根据价值和紧急性来排列优先级，最高优先级的需求交给开发者开发。
阅读全文
posted @
2014-06-02 23:59 cheng 阅读(1929) |
评论 (1) 编辑
《掌握需求过程》笔记十一：需求工作之业务分析策略
摘要: 今天的大多数软件都不是拥有它的组织机构开发的，而是购买的。考虑到这些开发和解决方案选项，今天的业务分析师有一项额外任务：即决定最佳的策略来发现和沟通需求，不论组织机构决定采用哪种方式实现自动化。
以需求策略作为指导，决定从哪里开始，是否有足够的细节，你需要哪个迭代循环，记录知识时采用哪种形式，何时复查，何时让哪些利益相关者参与，何时构建原型，何时以及如何做大量的事情，让你的工作更接近为业务产生最优价值，每个项目的情况不同，有必要采用不同的做事顺序、做事细节、沟通形式。
阅读全文
posted @
2014-06-02 23:58 cheng 阅读(1202) |
评论 (1) 编辑
《掌握需求过程》笔记十：需求工作之需求规格说明书审查
摘要: 需求评审环节检查了单项需求，确保它表述正确、无二义性、在范围内、可测试、可追踪、不是镀金需求，从而确定制有正确的原子需求才包含在需求规格说明中。
接下来，必须考虑需求规格说明是否完整，这意味着将规格说明作为一个整体来复查，确保应该有的部分都有。
这种复查可以在任何时候进行，而不只是在发布之前，它可以是一项持续的活动。
阅读全文
posted @
2014-05-16 22:16 cheng 阅读(1466) |
评论 (0) 编辑
《掌握需求过程》笔记九：需求工作之需求评审
摘要: 需求来自于人，人们并非总能确定他们需要什么，并非总能解释他们想要什么，需求也并非总是编写地很小心，完整无二义。
需求工作的要点是要确保交给开发者的东西是准确的、完整的、无二义的，陈述了真正的需求。任何不足都有违需求工作的初衷。开发者可以构建任何东西，但他们首先必须知道他们必须构建什么。
阅读全文
posted @
2014-05-16 22:10 cheng 阅读(1207) |
评论 (0) 编辑
《掌握需求过程》笔记八：需求工作之测量标准和理由
摘要: 如果产品有一项需求，要执行某个功能或具备某种属性，那么测试活动必须展示产品确实执行了该项功能，或具备了该项期望的属性。为了进行这样的测试，需求必须有一个测试基准，这样测试者才能比较提交的产品和最初的需求。要注意的是，这里的验收标准既不是测试，也不是对测试的设计，而是测试提交的产品必须采用的测试基准，是构建测试用例的输入信息。
阅读全文
posted @
2014-05-10 11:54 cheng 阅读(1141) |
评论 (1) 编辑
《掌握需求过程》笔记七：需求工作之非功能需求
摘要: 为什么所谓的‘非功能需求’也很重要？请考虑一个真实发生的故事：客户拒绝了交付的服务台软件。功能是正确的，但客户不想要它。为什么？因为客户拒绝使用它，更愿意采用原来的人工过程。这就是需求团队几乎没有注意非功能性需求。
只所以需要这些非功能需求，不是因为它们是产品的功能活动（诸如计算、操作数据活动），而是因为用户希望这些活动以特定的方式执行，并达到特定的品质。
例如，亚马逊网站很容易导航，这让客户容易找到对象，它也很友好，让你觉得自己是尊贵的顾客，你可以写评论，通过购物伙伴和亚马逊推荐得到指引，很容易查看和安排送货，等等。
阅读全文
posted @
2014-05-10 11:25 cheng 阅读(992) |
评论 (0) 编辑
《掌握需求过程》笔记六：需求工作之功能需求
摘要: 通过产品用例（PUC）场景展示和确定了解决方案后，下面就需要PUC场景转换到功能需求。
功能需求指明了产品必须做的事情，即产品为了满足它存在的根本理由而必须执行的一些动作。需求分析师理解了产品必需的功能后，他要用功能需求告诉开发者要构建什么。
阅读全文
posted @
2014-05-10 11:06 cheng 阅读(1170) |
评论 (0) 编辑
《掌握需求过程》笔记五：需求工作之解决方案
摘要: 当需求人员和客户之间针对需求沟通中的业务本质问题达成一致时，接下来就是沟通和确定多少业务将通过产品来实现自动化。作为需求分析人员，需要在业务需求、包含的功能、用户体验、非功能需求、开发成本、技术可行性、限制条件这些因素之间取得平衡和折中来完成解决方案的确定和发布。
没有公式化的方法能得到最佳的解决方案，需要实际过程中考虑和权衡。
阅读全文
posted @
2014-05-06 22:26 cheng 阅读(1057) |
评论 (0) 编辑
《掌握需求过程》笔记四：需求工作之理解真正的问题
摘要: "我知道这是我提出的,但这不是我想要的。”你不必在IT这行待很长时间就能听到这句话，看着期待的笑容从开发者脸上消失，因为这事经常发生。开发者交付了客户提出的需求，但结果却不能解决他们的业务问题。为什么？因为真正的问题从未阐明，所以从未正确理解。
在做需求调研和收集时如果听到的都是客户关于解决方案的想法，而不是描述背后要解决的问题，这可能是个好的解决方案，但更有可能的是，它受限于客户的经验和想象力。而且，你不清楚它是否解决了正确的问题。所以，作为需求分析人员，你的任务就是解释客户所说的内容，揭示它的本质。
阅读全文
posted @
2014-05-06 22:05 cheng 阅读(1254) |
评论 (0) 编辑
《掌握需求过程》笔记三：需求工作之需求调研
摘要: 不论哪种工作，试图改变之前先对它有充分的理解，如果一头冲进去，对你要改变的东西几乎没有理解，就进行‘改进’，那么结果不如意也不奇怪。当你开始理解原有的工作时，肯定会产生一些想法，知道如何改进它。
这里探讨的比较常用的Brow Cow模型和一些用于发现业务过程的调研方法，而实际过程中不可避免地需要多种调研技巧组合使用，具体情况需要具体应对。
阅读全文
posted @
2014-05-05 22:05 cheng 阅读(2062) |
评论 (1) 编辑
《掌握需求过程》笔记二：需求对象定义及关系
摘要: 项目启动过程建立了工作的范围，即要研究的业务领域，业务领域其中的一部分将通过预期的产品实现自动化。而实际上，这个工作范围可能太大，难以作为一个单元进行研究，正如吃东西之前先要将它切成小块一样，需要将工作范围分解为一些可管理的部分，然后再来研究它以发现产品的需求。这里将需求过程中涉及到主要对象以及它们的分工界面通过一张关系图来展示：
阅读全文
posted @
2014-05-05 21:03 cheng 阅读(1075) |
评论 (0) 编辑
《掌握需求过程》笔记一：一些事实及概念
摘要: 从通信行业的产品工作到政府行业的项目工作，一直在和‘需求’打交道，不同的行业特点和项目环境需要针对性的需求发现和实现方法，但围绕需求调研、分析、编写、评审、验证到需求交付这几个过程基本是相通的。经历从瀑布型项目需求策略到迭代型需求策略的转变和实践过程，回过头来看《软件开发方法学-掌握需求过程》，进行摘录和梳理的同时，也加深和沉淀一些对需求的理解和认识。以此片文章开始，分享一些读书笔记：
阅读全文
posted @
2014-05-05 20:49 cheng 阅读(1286) |
评论 (0) 编辑