需求分析

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目 的其中一项不变真理：人是会死的， 需求 是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 2.5 小结与练习 小结 本章最主要的目的其实就是帮你“洗脑”！ 需求分析 的工作其实很复杂，可以足够写一本书的内容。而我希望只通过一个章节能向你讲清楚 需求 分析工作的基本道理，让你认清需求分析工作的根本，并且明白到要做好需求分析工作并没有捷径，只有切实提高自身水平。下面我们一起来回顾一下本章的主要内容： 认识清楚需求分析工作中客户方和 软件 公司一方各种角色的特点，能帮助我们需求分析工作更有针对性。总体来说，客户方的倾向是花小钱办大事，而软件公司一方的倾向是多拿钱少办事。 “双赢”是我们应该追求的目标，软件只有对客户的工作真正有帮助，客户才算“赢”，而在客户能“赢”的基础上，我们软件公司才可能实现自己的“赢”。 不要抱怨客户变来变去，客户对需求的理解总是趋向上升的，而 项目 组也是一样。如果项目组对需求的认识落后于客户，就会陷于“被动”的局面，项目组应该努力提升水平，想办法让自己对需求的认识领先于客户。 需求分析工作是很复杂难度很高的工作，如果看不清楚客户的真正

阅读笔记1 读了这篇关于软件需求分析的博客之后，令我大有感触。我觉得这篇文章写得实在是太好了，完全可以绘制成一本关于软件需求分析的书。 此书主要从客户的一些需求分析作为出发点，对用户的需求作大量的研究，从不同的角度做分析。一个需求分析的是否彻底决定了项目的成功与否。但是从现实中来说，很难做到不停的调研，对用户的需求能够彻底的了解，直至到达用户需要的场景。对于一些基层人员，像这种专门做软件开发设计的，在开展一个项目之前，必须要了解用户的需求，用户在什么样的工作环境下的需求，对于最基层工作人员的工作情况了解，不能让此系统软件给工作人员造成了负担。要做到好的需求结果，我认为需要，大胆和用户沟通不要怕说错、有不懂业务问题一定要问用户不要怕打扰别人了、多写各类软件文档不要怕麻烦、多百度一下很多 问题能解决、多推敲在用户需求上能否在扩展更有用的东西、系统界面一定要美观，很多开发人员都不太重视界面，只注重一些功能的实现，每次先完成一些项目的功能之后，可以先让用户看看，是否按着他的一些思路，对于一些对此专业一窍不通的用户，可能会有一些天马行空的想法，在这个时候你不能拒绝用户的想法，这样会让用户感到反感。对于这种情况分析人员只能调查为什么用户会有这样的想法，这种想法对于用户的利益，然后分析人员 可以通过其他的解决方法进行解决。 我们应当怎样做需求分析：子用例与扩展用例 这部分里用例图中

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目的其中一项不变真理：人是会死的，需求是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 （本书已经发售） 作者： 张传波 网名：Fireball（火球） www.umlonline.org 2.1 需求分析面面观 客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子……很多角色参与项目工作，每种角色会从自身角色出发来理解需求，以致各种角色对需求的理解会不太一样。下表对各种角色的特点进行了分析： 表 2.1 各种角色的特点 另外要说明的是： 客户一方的总倾向是：自己少花钱，让软件公司多做事情。 而软件公司一方的总倾向是：多拿客户的钱，尽量少做事情。 影响各人对需求理解的主要因素有两方面：一方面是角色的思考倾向，上表反应了这点；另外一方面是人的需求分析能力，能力越强的人越能把握需求，本书重点讲解的内容就是如何 活用UML 来提升需求分析能力。 而更“离谱”的是：每个人嘴巴上说的需求和心目中的需求总是有差异的，所谓的“词不达意”，受表达能力所限，不是每个人都能完整准确地表达自己的想法；有时候客户今天想要这个

摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目的其中一项不变真理：人是会死的，需求是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 作者： 张传波 www.umlonline.org www.umlonline.org/school/ 本文来自新书《活用UML——需求分析高手》的第二章。 第一章已经在博客园发布，文章名字叫：UML一篇文章就学通 文章链接： http://www.cnblogs.com/umlonline/archive/2011/07/12/2104626.html 以下是正文： 2.1 需求分析面面观 客户需要的是一把梯子，系统分析员了解到的是一张凳子，开发人员做出来的是一张桌子，测试人员以为是一张椅子……很多角色参与项目工作，每种角色会从自身角色出发来理解需求，以致各种角色对需求的理解会不太一样。下表对各种角色的特点进行了分析： 表 2.1 各种角色的特点 另外要说明的是： 客户一方的总倾向是：自己少花钱，让软件公司多做事情。 而软件公司一方的总倾向是：多拿客户的钱，尽量少做事情。 影响各人对需求理解的主要因素有两方面：一方面是角色的思考倾向，上表反应了这点

　　作为一个软件开发人员，如何做好软件需求分析对我们的这个工作非常重要，可以说这是我们这个行业工作的基础和核心。如果一个软件工程师连做起码的客户的需求都搞不清楚，那还谈什么开发软件。 通过阅读者篇文章，我了解到： 当客户提出业务变更的时候，我们不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。 我们不能非要按照可客户的方式去设计软件，毕竟客户没有学过软件开发这个专业，不了解软件开发过程中的技术实现，但对于我们技术人员，需求分析必须要实事求是，基于技术可以实现的角度去考虑。 一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。而且不能一蹴而就，必须与专家建立联系，反复沟通后完成。 在软件开发的整个过程中，需求分析不是一蹴而就的，我们需要不停地将开发成果给客户看，与客户交流，及时的获取反馈，将需求分析贯穿于整个开发周期，这样才能保证项目的成功。 我们应该怎样做需要求调研：初识 　　在我们第一次与客户的接触过程中，我们保持适当的谦卑是必要的，但是不能过于谦卑，起初的唯唯诺诺，这会为日后项目的进行带来风险，让客户不在关注你的意见，让客户提出许多不现实的需求，让我们做的很累。我们应该对客户的需求进行深入地分析

这 学期我们开始学《软件需求与分析》这 门课，这门课程算是软件工程专业比较重要的课程 了，因为软件的需求是一个软件项目的开始，没有需求将会没有软件，但是有了需求之后，我们要做好充分地分析后才能着手开始开发项目，那么如何做好软件的需求与分析就显得尤为重要了 通过阅读《我们应该怎样做需求分析》这一博文，我总结出来做好软件需求分析一共分三步。 需求调研 - 需求分析 - 需求确认三大部分，对每一个部分又有更具体的的划分，要想做好软件需求分析，就要把握好这三步！ 首先是做需求调研，就是采集需求这个阶段，在这个阶段其实是一个反复循环的过程：需求捕获 ——需求整理——需求验证——再需求捕获.，文中提到的方式有拜访等，与 直接接触到相关人员和相关的利益群体 面对面交谈 ，通过他们最直接的表达来进行的调研方式 ， 面对直接的利益体，不可能泛泛而谈，这需要提前做好准备，因为我们可能会遇到不同的群体和领导层。他们对软件的认识和理解对不在同一层面上。交谈的内容自然也不尽相同。研讨会作为需求调研的一个重要方式之一，把同一人群或同一业务的相关人员组织到一起，以商议和探讨的方式总结出统一的要求和看法，效率会有所提升，但容易出现混乱的情况，这需要很好的组织和策划。随着时间的改变，需求不会一直不变的 需求捕获 (requirement elicitation)是需求工程的主体。对于所建议的软件产品

一、什么是软件测试需求（定义） 1、测试需求主要解决“测什么”的问题，一般来自需求规格说明书的原始需求（客户直接给出） 2、测试需求应该全部覆盖已定义的业务流程，以及功能和非功能方面的需求。（eg：假设我们要设计一个购物网站，我们从原始需求中就可以知道需要包括：注册、登录、浏览商品、购买商品、支付等功能，如果没有注册直接就可以登录那么这个测试就没有全部覆盖已经定义的流程。） 二、为什么需要软件测试需求 1、软件测试需求是设计测试用例的依据。 2、有助于保证测试的质量和进度。 3、软件测试需求是衡量测试覆盖率的重要指标。 三、如何进行软件测试需求分析 软件测试需求分析的一般步骤： 1、列出需求文档中具有可测性（原始需求中提到的可以验证的功能）的原始需求。 2、对每一条测试点进行细化，形成可测试的分层描述的测试点。 3、对形成的测试点从软件产品质量需求来分析，确定测试执行需要实施的测试类型。 4、建立测试需求跟踪矩阵，对测试需求进行管理。 测试需求分析的主要目的 ：找出测试点 测试点的分析 ： --通过描述需求分析中的输入、输出、处理、限制约束等，给出对应的验证内容：（功能性测试） --通过分析各个模块之间的业务顺序，和各个模块传递的业务信息和数据对存在功能交互的功能项，给出对应的验证内容。（功能交互测试） --考虑需求的完整性，要充分覆盖软件需求的各个特征，包含隐形需求验证

我们应当怎样做需求分析？ 成功的软件项目都是一样的，失败的项目却各有各的问题。不过归根到底还是需求的问题。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。 只有深入地去理解客户的业务，最后做出来的东西必然是客户满意的。当客户提出业务变更的时候，一定不能被客户牵着走。要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。 客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的。但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。所以我们必须要基于技术实现去引导客户的需求。 软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。 在敏捷开发过程中，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。 我们应当怎样做需求调研？ 首先是双方初步认识，这个时候需要树立良好的职业威信，在交谈中进行详细角色分析，将与会各方代表对号入座，最后从宏观上制订目标与方案。 做好初步认识之后，接下来就要一一去拜访这些对应角色了。需求不是一蹴而就，在这漫长的时间里

在一开始，作者讲述了自己曾经接的一个项目的上一个团队的搁浅并解散的过程和原因。关于客户对需求改来改去的原因 从这段我们可以看到，作者认为，不能只被客户的要求牵着走，要深入的思考，为什么客户会有这样的需求，怎样更改能解决这个问题，从用户的角度出发，切实的看到问题的根源，才能满足客户的需求。 在第二个故事中，作者提到了自己曾经失败的项目。 从这一段，我们可以看到，客户的手工报表给作者带来了很大的困难，最终导致项目无法完成，作者从这次经历中得到的教训是：客户的要求往往是站在自己的理想角度来提的，他们根本不知道技术问题是否可以解决，也不知道不系统的管理会带来的困难，因此我们在做需求时，就应该去有意识的引导他们系统化的管理，将管理模式转化为易操作、可实现的。 剩下两个故事都遭遇了各种各样的问题，我不一一举例，仅仅讲讲作者的看法以及我从中想到的一些感悟。 第三个故事中，作者因为在需求分析中没有详细得分析所有角色的需求，导致最后的作品状况百出，我认为在需求分析时，应该切实地去对每个用户角色进行调研，然后在进行分析，才能做出客户满意的作品。 第四个故事中，作者十分顺利的完成了项目，可是提交时，却发现许多地方不符合客户需求要重新修改。因此，在开发过程中，一定要不断地跟客户进行交流，才能在最后阶段完成跟客户想象中接近的作品。 我们应当怎样做需求调研：初识 我们对客户提出的需求进行深入理解以后

本文简述产品经理的工作方法及应用之商业需求分析。 一、需求采集 1、需求来源渠道 ①公司内部（老板、其他部门或同事） ②产品经理自己（策划、挖掘） ③公司外部（用户、客户、伙伴） 2、需求获取方式 ①业务发展的要求 ②用户调查结论 ③用户反馈分析 ④产品数据分析 ⑤竞品分析 3、需求管理表（要素） ①来源渠道 ②需求描述 ③需求性质：优化、新增、bugfix、idea ④需求评述 ⑤备注：提出人、提出时间 ⑥后续计划：排期、留存、暂缓、合并、搁置 4、产品需求池 汇总管理（部门级别） 二、需求分析（价值、成本） 1、需求分类 ①功能类（加法、减法） ②数据类 ③运营类 ④体验类 ⑤设计类 2、四象限定位法 ①重要并急需 ②重要不急需 ③不重要但急需 ④不重要也不急需 三、需求筛选（团队评审、汇报） 1、需求决策 战略定位 产品定位 用户需求 2、战略方向 起步阶段--关注产品最核心的功能 发展阶段--优化、扩展、完善 迭代阶段--设计、体验、运营 3、产品定位 战略方向更偏向于市场 产品定位更注重功能定义 4、用户需求 不把需要当成需求 不把产品形态当成本质 四、需求处理 需求处理、转向开发 五、文档（产品管理分析文档） 分类 分析（四象限） 分级（包括优先级、时间、人员） 原因（搁置、是否启动、何时启动） 周期（更新） 来源： https://www.cnblogs.com