论系统需求分析方法.pdfVIP

论系统需求分析方法 一 需求分析概括 需求分析应该先了解宏观的问题，再了解细节的问题。 一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记 为D）分类，每个问题域对应于一个软件子系统。 S＝ ｛D1， D2， D， …Dn｝ 问题域Di 由若干问题（记为P）组成，每个问题对应于子系统中的一个软构 件。 Di＝｛P1，P2， P3， …Pn｝ 问题Pi 有若干个行为（或功能，记为F），每个行为对应于软构件中的实现 接口。 Pj＝｛F1， F2， F3， …Fk｝ 需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员 都合适。在写需求说明书时，应该注意两个问题： 1. 最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质， 以便选用最合适的技术来实现此需求 2. 需求说明不能有”二义性”，更不能前后矛盾。如果有二义性或前后矛 盾，即要重新分析此需求。 二 需求分析方法论 第一阶段：“访谈式” 第一阶段是和具体用户方的领导层、业务层人员的访谈沟通， 主要目的是从 宏观上把握用户的具体需求方向和趋势， 了解现有的组织架构、业务流程、硬件 环境、软件环境、现有的运行系统等等具体情况、客观的信息。 建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局， 最好能 指定本次项目的接口人。 实现手段：访谈、调查表格 输出成果：调查报告、业务流程报告 第二阶段：“诱导式” 结合第一阶段的基本信息，做出简单的用户流程页面，同时结合以往的项目 经验对用户采用诱导式，启发式的调研方法和手段，和用户一起探讨业务流程设计 的合理性、准确性、习惯性。用户可以操作简单演示的DEMO，感受整个业务流程 的设计合理性、准确性等等问题，以及提出改进意见和方法。 实现手段：诱导（拜访）、原型演示 输出成果：调研分析报告、原型反馈报告、业务流程报告 第三阶段：“确认式” 此阶段在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认 阶段。这个阶段 承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向 用户描述系统的业务流设计目标。通过审查，提出反馈意见，并对已经可接受的报 告、文档签字确认。 实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示 系统 输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后 三者可以统一归到需求分析报告中） 后续的需求改进中， 工作则基本集中在后两个阶段中。 三 需求工程 的问题域的研究，获得对该领域特性及存在其中的问题特性的透彻理解并用文档说明。 在“业务需求”充分理解下，并且收集了本质的“用户需求”之后就可以开始进行需求分析 明确项，更多待捕获的信息，这时就可以生成第二次的需求调研计划、问题和素材 档化过程 ，否则很容易造成与开发脱离 很重要的工作 时，客户发现不是这样的，导致不期望的需求变更 评审、需求确认和原型验证《需求方法之－原型开发》 它就包括了用特性说明的功能需求，质量属性以及其他非功能需求，还有设计约束 unix操作系统之下（硬、软件的约 将项目大的目标整理提炼，划分为项目子目标，将其作为“项目的行动纲 领”，还应该得到“项目发起人”的认可，并且在此基础上编写“项目的目标和范 围文档”。 需求分析迭代过程 需求捕获 用例模型 验证需求分析 将需求分析的结果还原为用户场景，然后向用户描述该场景的目的、任务、 实现的方法，以此验证是否正确。 推荐的需求文档格式 1) 业务名称解释 2) 需求背景及目标介绍 3) 用户操作场景说明 4) 功能总览：用列表的方式，逐项叙述对系统所提出的功能要求，说明输入 什么量、经怎么样的处理、得到什么输出 5) 系统交互 6) 界面原型（对该系统的输入、输出数据类型、格式、数值范围、精度的描 述） 7) 业务规则说明 8) 业务正常流流程：功能模块，主要操作 9) 业务异常流处理：异常场景，错误提示；异常流转