软件需求分析方法.doc

需求分析方法一 需求分析概括需求分析应该先了解宏观的问题，再了解细节的问题。一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。S D1， D2， D， Dn问题域Di由若干问题（记为P）组成，每个问题对应于子系统中的一个软构件。DiP1，P2， P3， Pn问题Pi有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。PjF1， F2， F3， Fk需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时，应该注意两个问题：1. 最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质， 以便选用最合适的技术来实现此需求2. 需求说明不能有”二义性”，更不能前后矛盾。如果有二义性或前后矛盾，即要重新分析此需求。二 需求分析方法论第一阶段：“访谈式”第一阶段是和具体用户方的领导层、业务层人员的访谈沟通， 主要目的是从宏观上把握用户的具体需求方向和趋势， 了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局， 最好能指定本次项目的接口人。实现手段：访谈、调查表格输出成果：调查报告、业务流程报告第二阶段：“诱导式”结合第一阶段的基本信息，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式，启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO，感受整个业务流程的设计合理性、准确性等等问题，以及提出改进意见和方法。实现手段：诱导（拜访）、原型演示输出成果：调研分析报告、原型反馈报告、业务流程报告第三阶段：“确认式”此阶段在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。通过审查，提出反馈意见，并对已经可接受的报告、文档签字确认。实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归到需求分析报告中）后续的需求改进中， 工作则基本集中在后两个阶段中。三 需求工程需求开发：1. 确定产品所期望的用户分类。 2. 获取每类用户的需求。 3. 了解实际用户任务和目标以及这些任务所支持的业务需求。 4. 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。 5. 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 6. 了解相关质量属性的重要性。 7. 商讨实施优先级的划分。 8. 将所收集的用户需求编写成规格说明和模型。 9. 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。 需求分析需求分析是指通过对需求获取中获得的问题域的研究，获得对该领域特性及存在其中的问题特性的透彻理解并用文档说明。 不需要等到需求完全捕获后开始，在“业务需求”充分理解下，并且收集了本质的“用户需求”之后就可以开始进行需求分析 交替进行，先把握“用户需求”主要部分，然后在分析的基础上引入系统级的需求（系统的涉及与实现角度），并且分析模型，成为开发人员之间、开发人员与客户之间达成共识的一个平台 分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研计划、问题和素材编写规约 规格说明书是对需求分析结果的文档化过程 需求规约必须与实际开发紧密结合，否则很容易造成与开发脱离 为需求规约定义统一的格式是一个很重要的工作 规约内容必须严谨、正确、无歧义需求验证 不重视需求验证工作会在系统交付时，客户发现不是这样的，导致不期望的需求变更 提高需求质量的重要手段有：需求评审、需求确认和原型验证需求方法之原型开发需求分析层次需求层次内容业务需求反应组织机构或客户对系统、产品高层次的目标要求。通常问题定义就是业务需求用户需求描述用户使用产品必须要完成什么任务、怎样完成，通过是在问题定义的基础上进行访谈、调查、对用户使用的场景进行整理，从而建立从用户角度的需求系统需求从系统的角度来说明软件的需求， 它就包括了用特性说明的功能需求，质量属性以及其他非功能需求，还有设计约束1.功能需求：系统必须完成的任务，以及怎样完成这些任务。即为了向用户提供有用的功能，必须完成的动作。 2.非功能需求：指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性和扩展性。3.设计约束：即限制条件或补充规约，通常是对解决方案的一些约束说明。例如必须运行在unix操作系统之下（硬、软件的约束）。将项目大的目标整理提炼，划分为项目子目标，将其作为“项目的行动纲领”，还应该得到“项目发起人”的认可，并且在此基础上编写“项目的目标和范围文档”。需求分析迭代过程需求捕获用例模型验证需求分析将需求分析的结果还原为用户场景，然后向用户描述该场景的目的、任务、实现的方法，以此验证是否正确。推荐的需求文档格式1) 业务名称解释2) 需求背景及目标介绍3) 用户操作场景说明4) 功能总览：用列表的方式，逐项叙述对系统所提出的功能要求，说明输入什么量、经怎么样的处理、得到什么输出5) 系统交互图6) 界面原型（对该系统的输入、输出数据类型、格式、数值范围、精度的描述）7) 业务规则说明8) 业务正常流流程：功能模块，主要操作9) 业务异常流处理：异常场景，错误提示；异常流转软件需求说明书1引言 11编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。 12背景 说明： a待开发的软件系统的名称； b本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C该软件系统同其他系统或其他机构的基本的相互来往关系。 13定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 14参考资料 列出用得着的参考资料，如：a本项目的经核准的计划任务书或合同、上级机关的批文； b属于本项目的其他已发表的文件； c本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 2任务概述 21目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。| 22用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束 23假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 3需求规定 31对功能的规定用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。 32对性能的规定321精度说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。 322时间特性要求 说明对于该软件的时间特性要求，如对： a响应时间； b更新处理时间； c数据的转换和传送时间； d解题时间； 等的要求。 323灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a操作方式上的变化； b运行环境的变化； c同其他软件的接口的变化； d精度和有效时限的变化； e计划的变化或改进。 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。 33输人输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。34数据管理能力要求 说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。 35故障处理要求 列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。 36其他专门要求 如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。 4运行环境规定 41设备 列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括： a处理器型号及内存容量；