软件需求分析的方法

《软件需求分析的方法》由会员分享，可在线阅读，更多相关《软件需求分析的方法（10页珍藏版）》请在金锄头文库上搜索。

1、软件需求分析的方法软件需求分析(Software Requirement Analysis)是研究 用户需求得到的东西，完全理解用户对软件需求的完整功 能，确认用户软件功能需求，建立可确认的、可验证的一个 基本依据.软件需求分析是一个项目的开端，也是项目实施最 重要的关键点。据有关的机构分析结果表明，我们设计的软件 产品存在不完整性、不正确性等问题80%以上是需求分析错 误所导致的，而且由于需求分析错误造成根本性的功能问题 尤为突出。因此，一个项目的成功软件需求分析是关键的一 步。一、软件需求分析理论如果我们用数学方法来描述软件 需求分析,可以将一个应用软件定义为S,可能应用软件涉及 功能性问

2、题非常广，我们用抽象化理论分析，可以划分为各个 功能域，可以用D1、D2、Dn表示，那么，我们可以用一个 表达式描述为S=(D1, D2,D3,Dn但是，功能域Di依然存在着有若干个问题P1、P2、P3、Pm 组成，并且每个功能对应于子系统中的一个软构件，我们可 以表示为Di= P1, P2,P3,-Pm同样，功能Pj有若干个行为F1、F2、F3、Fk,每个行为对 应于软构件中的实现方法Pj= F1,F2,F3,Fk一个软件包 含了所有功能的集合，同时包含了实现所有功能的所有方法和算法描述。需求分析是依据于用户需求，经过需求问题识 别，进行分析、消化与综合，制订规格说明，评审，分为四个 阶段，

3、形成用户需求与设计同步，设计满足用户需求目标。 需求分析方法始终贯穿着吸收、同化、贯彻方法和手段，用 商业化行为解决需求与实现中存在的矛盾，解决用户需求与 商业化产品融通，解决规范与个性化追求。二、软件需求分 析目标软件需求分析的主要实现目标：1）对实现软件的功 能做全面的描述，帮助用户判断实现功能的正确性、一致性 和完整性，促使用户在软件设计启动之前周密地、全面地思 考软件需求；2）了解和描述软件实现所需的全部信息，为 软件设计、确认和验证提供一个基准；3）为软件管理人员 进行软件成本计价和编制软件开发计划书提供依据;需求分 析的具体内容可以归纳为六个方面：软件的功能需求,软件与 硬件或其他

4、外部系统接口，软件的非功能性需求，软件的反向 需求,软件设计和实现上的限制，阅读支持信息。软件需求分 析应尽量提供软件实现功能需求的全部信息，使得软件设计 人员和软件测试人员不再需要需求方的接触。这就要求软件 需求分析内容应正确、完整、一致和可验证。此外为保证软 件设计质量，便于软件功能的休整和验证，软件需求表达无 岔意性，具有可追踪性和可修改性。2。1、软件功能 需求软件的功能需求是整个需求分析最主要、最关键和最复 杂的部分它描述软件的各种可能的条件下对所有可能输入的数据信息，应完成那些具体功能，产生什么样的输出。描 述软件功能需求是应注意下面几点:1）功能需求的完整性和 一致性对功能的描述

5、应包含与功能相关的信息，并应具有内 在的一致性（即各种描述之间不矛盾、不冲突）。应注意以 下几点：（1）给出触发功能的各种条件（如：控制流、运行状态、运行模式等）；（2）定义各种可能性条件下的所有可能的输入（包括合法的输入空间和非法的输入空间）； 给出各种功能间可能的相互关系（如各个功能间的控制流、 数据流、信息流,功能运行关系：顺序、重复、选择、并发、 同步）；（4） 给出功能性的主要级别（如：基本功能、可由 设计者选择逐步实现的功能、可由设计者改变实现的功能 等）；（5） 尽可能不使用“待定”这样的词。所有含有待定内 容的需求都不是完整的文件，如果出现待定的部分，必须进 行待定部分内容说明

6、，落实负责人员、落实实施日期。2）功能 描述的无岔意性和可追踪性需求功能描述的无岔意性、可追 踪性和规范化：（1）功能描述必须清晰地描述出怎样输入到怎样输出，并且输入、输出描述应对应有数据流描述、 控制流描述图，这些描述必须与其它地方描述一致;（2）可以用语言、方程式、决策表、矩阵或图等对功能的描述。如 果选用语言描述必须使用结构化的语言，描述前必须说明该 步骤（或子功能）的执行是顺序，选择，重复还是并发，然 后说明步骤逻辑。整个描述必须单入单出.（3）描述时，每一个功能名称和参照编号必须唯一，且不要将多个功能混 在一起进行描述，这样便于功能的追踪和修改。（4）功能 描述应注意需求说明和程序设

7、计的区别。需求设计仅仅是软 件的功能设计，它给出软件运行的的外部功能描述，以及为 了实现这一外部功能必须做哪些事情（采用和种数据结构， 定义多个模块，接口间的接口等）是设计阶段的事情，功能描述 不应涉及到那些细节问题，以避免给软件设计带来不必要的 约束。2.2、 软件与硬件或其他外部系统接口软件与硬 件或其它外部系统接口包括下述内容:（1）人机接口：说明输入、输出的内容、屏幕安排、格式等要求；（2） 硬 件接口:说明端口号，指令集，输入输出信号的内容与数据类 型，初始化信号源，传输通道号和信号处理方式。（3）软件接口 ：说明软件的名称、助记符、规格说明、版本号和来 源；（4）通讯接口：指定通讯

8、接口和通讯协议等描述。2。3、软件的非功能性需求软件非功能性需求是指软件性能指标，容限等功能以外的需求。一般指下述内容：（1） 时 间需求:输入、输出频率，输入、输出响应时间,各种功能恢复 时间等；（2） 处理容限、精度、采样参数的分辨率，误差 处理等；（3） 可靠性的MTBF要求，可维护性、安全性要 求等。（对可能的不正常的输入给以正常响应是可靠性的重要 内容,这属于功能性需求。）2.4、软件反向需求软件的反向需求描述软件在那些情况下不能做什么。这一条是随软件实际要求而定。有两类情形需要采用反向需求的形式。第一 种情况:某些用户需求适宜采用反向形式说明，如数据安全性 要求属于这类形式.第二种

9、情况：对一些可靠性和安全性要求 较高的软件，有些必须描述软件不能做些什么。如控制点火 时序，我们必须交代清楚在那些情况下不能点火，否则会造成 故障。2.5、软件设计和实现上的限制软件设计和实现上的限制主要指对软件设计者的限制。如软件运行环境的限 制（选择计算机类型，使用配置，操作系统的限制等）、设计 工具的限制（使用语言、执行的标准）和保密要求等。2。6、 阅读支持信息这部分内容是为了更好的帮助我们理解用户 需求，也是为了使需求便于修改和追踪。其本身并不是对需 求的描述，但它影响到需求分析的可读性，也属于需求分析 的一个重要部分。一般目录、需求背景信息、内容索引、交 叉引用表、注释等均属于这个

10、部分的内容.三、软件需求分析 人员组织软件需求分析其根本性问题是理解用户功能需求， 由此软件需求分析实际上是与客户间交流过程完成的目标。 要求我们组织适当的参与人员进行交流活动。需求分析是一 个综合团队的工作，是在需求分析理论的指导下，对用户需 要进行渐进方式逐步深化;通过不断变化方式形成具体约束； 努力实现需求功能目标形成特色效果的商业化产品.需求分 析是一个商业行为，完全是一个商业化操作,要求有商业、技 术等结合的团队共同合作，解决需求和设计的同步，设计符 合需求。项目涉及内容，项目大小都需要我们考虑参加软件需 求分析工作团退的人数，配置合理的参与人员。一般我们必 须有商务活动人员，项目管

11、理人员，设计技术人员等参加，而 且要求组织人员必须明确负责范围，以及明确工作目标，保证 实施的有效性。四、软件需求分析方法为了保证项目的正常 实施，并且能够顺利的完成，我们必须加强项目管理和重视项 目分析工作。我们只有从实际出发，切切实实地把握用户需 求，把握用户需求目标，把握用户将来功能界定，保证我们 开发工作正确性方向。4.1、重点监控软件需求分析办法由于 软件项目的特殊性和行业覆盖的广阔性以及需求分析的高 风险性，软件需求分析的重要性是不言而喻的，同时需求分析 又的的确确难做。其原因基本是由于以下情况造成的.4。1.1、 客户说不清楚需求有些客户对需求只有朦胧的感觉，当然说 不清楚具体的

12、需求。例如全国各地的很多部门、机构、单位 在进行应用系统以及网络建设时，客户方的办公人员大多不 清楚计算机网络有什么用,更缺乏IT系统建设方面的专家和 知识。此时，用户就会要求软件系统分析人员替他们设想需 求.工程的需求存在一定的主观性，为项目未来建设埋下了潜 在的风险。4。1。2、需求自身经常变动根据以往的历史经 验，随着客户方对信息化建设的认识和自己业务水平的提 高，他们会在不同的阶段和时期对项目的需求提出新的要求 和需求变更。事实上，历史上没有一个软件的需求改动少于三 次的！所以必须接受“需求会变动”这个事实，在进行需求分析 时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需 求，哪些是

13、易变的需求，以便在进行系统设计时，将软件的核 心建筑在稳定的需求上，同时留出变更空间。咨询监理方在 需求分析的功能界定上担任一个中间、公平、公正的角色， 所以也必须积极参与到需求分析的准备中来，以便协助客户 方和承建方来界定“做什么、“不做什么的系统功能界 限.4 .1.3、分析人员或客户理解有误软件系统分析人员不 可能都是全才，更不可能是行业方面的专家。客户表达的需 求，不同的分析人员可能有不同的理解.如果分析人员理解错 了，可能会导致以后的开发工作劳而无功。记得一则笑话，有 个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告： “主宰地球的是汽车。它们喝汽油，靠四个轮子滚动前进，嗓 门极

14、大,双眼在夜里能射出强光有趣的是，车里住着一种叫 作人的寄生虫，这些寄生虫完全控制了车。”所以分析人员 知识的专一性也会造成需求分析的误解和失败。这时咨询监 理公司就必须根据实际的项目需求调研计划，提醒承建方加 强业务了解程度和注重沟通技巧。4。2、有效性软件需求分 析三步法根据以往的工程经验，需求分析工作方法，应该定位 在“三个阶段”（也称“三步法”）。4。2.1、访谈式Visitation 阶段这一阶段是和具体用户方的领导层、业务层人员的访谈 式沟通，主要目的是从宏观上把握用户的具体需求方向和趋 势,了解现有的组织架构、业务流程、硬件环境、软件环境、 现有的运行系统等等具体情况、客观的信息

15、。建立起良好的 沟通渠道和方式。针对具体的职能部门以及各委办局,最好能 指定本次项目的接口人。实现手段：访谈、调查表格输出成 果：调查报告、业务流程报告4.2。2、“诱导式I nducement” 阶段这一阶段是在承建方已经了解了具体用户方的组织架 构、业务流程、硬件环境、软件环境、现有的运行系统等等 具体实际、客观的信息基础上，结合现有的硬件、软件实现 方案，做出简单的用户流程页面，同时结合以往的项目经验 对用户采用诱导式、启发式的调研方法和手段,和用户一起探 讨业务流程设计的合理性、准确性、便易性、习惯性。用户 可以操作简单演示的DEMO,来感受一下整个业务流程的设 计合理性、准确性等等问

16、题，及时地提出改进意见和方法。 实现手段:拜访（诱导）、原型演示输出成果:调研分析报告、 原型反馈报告、业务流程报告4.2。3、“确认式Afirm”阶段这 一阶段是在上述两个阶段成果的基础上，进行具体的流程细 化、数据项的确认阶段，这个阶段承建方必须提供原型系统和 明确的业务流程报告、数据项表，并能清晰地向用户描述系 统的业务流设计目标。用户方可以通过审查业务流程报告、 数据项表以及操作承建方提供的DEMO系统，来提出反馈意 见，并对已经可接受的报告、文档签字确认。实现手段：拜 访（回顾、确认），提交业务流程报告、数据项表；原型演示系统输出成果：需求分析报告、数据项、业务流程报告、原 型系统反馈意见（后三者可以统一归入需求分析报告中，提 交用户方、监理方进行确认和存档）整体来讲,需求分析的三 个阶段是需求调研中不可忽视一个重要的部分，三个阶段或 者说三步法的实施和采用，对用户和承建方都同样提供了项 目成功的保证。当然在系统建设的过程中，特别在