《软件需求分析》博文读后感

这学期我们开设了软件需求与分析这门课，在阅读了博客《我们应当怎样做软件需求分析》。    

     文中有一句话，幸福的软件项目都是一样的，不幸的软件项目却各有各的不幸；或者说，成功的软件项目都是一样的，失败的项目却各有各的问题。在我看来，需求分析是一门艺术，它需要你的能力与你的判断力，最后展现出独特的成果。成功的项目在我们看来 更是给人一种赏心悦目的感觉。因此，我认为做好软件需求分析，就必须做到以下几点：

     需求调研：初识。

      对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。在与客户接触的过程中，过程的开始尤为重要，这就要求我们对自己要有足够的自信，也要有循循善诱的表达能力。如果我们做到了这些，就会客户心目中形成一种威信，使项目向着一种良性的方向前进。不要跟着顾客的思维去走，这是一个恶性条件，尽量做到低风险，高效率。做好本职。

    需求调研：拜访客户。

    在开端树立好了以后，与客户一起为项目制订了短期与长期目标。最后一个成果，也是最重要的成果，就是与各种角色、各个类型的客户建立了联系。需求调研不是一蹴而就的事情，关系的相处极为重要，寻找自己的战略伙伴，进行合作。在交往中结交人，也许是朋友能给与你巨大帮助，也许是阻碍你前行，但是随着你交际的结果，都会向着好的方向发展，在以后的业务领域中也能有所突破和进步。

    需求调研：研讨会

    需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。在面对多个方案时，采用这种集中式的研讨，可以使问题的处理变得高效而及时。选择最合理的方案，或者方案合并，使得差异最小化，最终在软件维护中体现出来，让客户自己去选择自己的管理模式。进入一个良性循环。合理地与客户组织研讨会，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。

    需求调研：需求研讨

    在需求分析过程中，客户存在的最大问题就是提不出正确的需求：

    1 由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。

    2  能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。这类客户，他们能熟练使用电脑，对信息化管理是清楚的。

    3 能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。   

    在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。在最后我们才能说出，是客户让我们这样做的。眼界决定你的成败。

    需求调研：迭代

     需求分析是一个反复迭代的过程，需求捕获->需求整理->需求验证->再需求捕获••••••这是一个迭代循环。需求整理，就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。在一个系统中，用例需要细化几次，是由这个用例的业务复杂程度决定的。通过不断的迭代，最后得到客户满意的结果。

    需求调研：需求捕获

    需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。需求捕获最重要的是态度。在需求分析的整个过程，不断进行业务领域知识的学习。做需求访谈的初期，不是跟客户谈需求，而是先跟客户谈业务。我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。

    需求分析：功能角色分析与用例图

     一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。

功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。

    需求分析：业务流程分析

   我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。清除低效环节，简化业务瓶颈，整合可用资源，最后是自动化繁重操作。

    需求分析：用例说明

    编写用例说明应当是最主要的工作，之后在一些关键部分辅之以行动图、状态图。将需求列表附在用例后面，便于日后的需求评审与确认。做到最方便。

    需求分析：查询报表分析

    报表作用：就是描述参与者使用这个报表做什么。如果有多个参与者，每一个都应当描述。

    报表内容：用简短的话描述一下。

    查询报表的需求分析与一般的业务操作的需求分析存在着巨大的差异。查询报表一定要分析到位。

    需求分析：子用例与扩展用例

    用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。

    需求分析：行动图与状态图

    正如任何事物都有两面性，用例图也不例外。在需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。活动图表明了各种活动之间的流转顺序。

    需求分析：业务领域分析

    软件系统就是对现实世界的真实模拟。在软件世界中就拥有什么函数；在现实世界中与哪些事物存在怎样的关系，在软件世界中就应当与它们发生怎样的关联。这正是面向对象编程的核心思想。业务领域，就是客户所在的知识领域，譬如财务人员所在的是财务领域，税务人员所在的是税务领域，营销人员所在的是销售领域。进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。

    需求分析：原文分析法

    过去我们拿到需求不知道该怎样去业务领域分析。有了原文分析方法，给了我们一个简单可行、易于操作的方法，让我们准确而高效地完成业务领域分析。

     非功能需求可以简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。而这5部分我们可以进一步细化。

    需求确认：需求列表

    通过需求列表的形式可以更加直观的看出系统有哪些需求。

    需求确认：快速原型法

用实物与用户确认需求，这就是快速原型法的基本思想。快速原型法，简称原型法（Prototyping），它摒弃了那种一步步周密细致地调查分析，然后逐步整理出文字档案，设计开发，最后才能让用户看到软件结果的繁琐作法。当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。

    需求确认：需求规格说明书

    需求规格说明书（Requirement Specification）分为用户需求规格说明书和产品需求规格说明书。

    需求确认：评审与确认签字会：

    确认需求，内部评审会与外部评审会，签字确认，成功完成！