《软件需求分析方法》.docVIP

需求分析方法 一 需求分析概括 需求分析应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S＝ ｛D1， D2， D， …Dn｝ 问题域Di由若干问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di＝｛P1，P2， P3， …Pn｝ 问题Pi有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj＝｛F1， F2， F3， …Fk｝ 需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时，应该注意两个问题： 最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质， 以便选用最合适的技术来实现此需求 需求说明不能有”二义性”，更不能前后矛盾。如果有二义性或前后矛盾，即要重新分析此需求。 二 需求分析方法论 第一阶段：“访谈式” 第一阶段是和具体用户方的领导层、业务层人员的访谈沟通， 主要目的是从宏观上把握用户的具体需求方向和趋势， 了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。 建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局， 最好能指定本次项目的接口人。 实现手段：访谈、调查表格 输出成果：调查报告、业务流程报告 第二阶段：“诱导式” 结合第一阶段的基本信息，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式，启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO，感受整个业务流程的设计合理性、准确性等等问题，以及提出改进意见和方法。 实现手段：诱导（拜访）、原型演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：“确认式” 此阶段在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段。这个阶段 承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。通过审查，提出反馈意见，并对已经可接受的报告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归到需求分析报告中） 后续的需求改进中， 工作则基本集中在后两个阶段中。 三 需求工程 需求开发： 确定产品所期望的用户分类。 获取每类用户的需求。 了解实际用户任务和目标以及这些任务所支持的业务需求。 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 了解相关质量属性的重要性。 商讨实施优先级的划分。 将所收集的用户需求编写成规格说明和模型。 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。 需求分析 需求分析是指通过对需求获取中获得的问题域的研究，获得对该领域特性及存在其中的问题特性的透彻理解并用文档说明。 不需要等到需求完全捕获后开始，在“业务需求”充分理解下，并且收集了本质的“用户需求”之后就可以开始进行需求分析 交替进行，先把握“用户需求”主要部分，然后在分析的基础上引入系统级的需求（系统的涉及与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台 分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研计划、问题和素材 编写规约 规格说明书是对需求分析结果的文档化过程 需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离 为需求规约定义统一的格式是一个很重要的工作 规约内容必须严谨、正确、无歧义 需求验证 不重视需求验证工作会在系统交付时，客户发现不是这样的，导致不期望的需求变更 提高需求质量的重要手段有：需求评审、需求确认和原型验证《需求方法之－原型开发》 需求分析层次 需求层次 内容 业务需求 反应组织机构或客户对系统、产品高层次的目标要求。通常问题定义就是业务需求 用户需求 描述用户使用产品必须要完成什么任务、怎样完成，通过是在问题定义的基础上进行访谈、调查、对用户使用的场景进行整理，从而建立从用户角度的需求 系统需求 从系统的角度来说明软件的需求， 它就包括了用特性说明的功能需求，质量属性以及其他非功能需求，还有设计约束 1.功能需求：系统必须完成的任务，以及怎样完成这些任务。即为了向用户提供有用的功能，必须完成的动作。 2.非功能需求：指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性和扩展性。 3.设计约束：即限制条件或补充规约，通常是对