软件需求分析方案设计

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

1、软件需求分析方案设计软件需求分析是研究用户需求得到的东西，完全理解用户对软件需求 的完整功能，确认用户软件功能需求，建立可确认的、可验证的一个基本 依据。今天小编为大家准备了软件需求分析方案设计，欢迎阅读！软件需求分析方案设计如果我们用数学方法来描述软件需求分析，可以将一个应用软件定义为S，可能应用软件涉及功能性问题非常广, 我们用抽象化理论分析，可以划分为各个功能域，可以用DI、D2、Dn 表示，那么，我们可以用一个表达式描述为S=D1，D2，D3，Dn但是，功能域Di依然存在着有若干个问题Pl、P2、P3、Pm组成, 并且每个功能对应于子系统中的一个软构件，我们可以表示为Di=P1，P2，

2、P3，Pm同样，功能Pj有若干个行为Fl、F2、F3、Fk，每个行为对应于软 构件中的实现方法Pj=F1，F2，F3，Fk一个软件包含了所有功能的集合，同时包含了实现所有功能的所有方 法和算法描述。需求分析是依据于用户需求，经过需求问题识别，进行分 析、消化与综合，制订规格说明，评审，分为四个阶段，形成用户需求与 设计同步，设计满足用户需求目标。需求分析方法始终贯穿着吸收、同化、贯彻方法和手段，用商业化行 为解决需求与实现中存在的矛盾，解决用户需求与商业化产品融通，解决 规范与个性化追求。软件需求分析的主要实现目标：1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确 性、一致性和完整

3、 性，促使用户在软件设计启动之前周密地、全面地思 考软件需求；2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提 供一个基准；3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依 据；需求分析的具体内容可以归纳为六个方面：软件的功能需求，软件与 硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件 设计和实现上的限制，阅读支持信息。软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设 计人员和软件测试人员不再需要需求方的接触。这就要求软件需求分析内 容应正确、完整、一致和可验证。此外，为保证软件设计质量，便于软件 功能的休整和验证，软件需求表达无岔意性，

4、具有可追踪性和可修改性。、软件功能需求软件的功能需求是整个需求分析最主要、最关键和最复杂的部分，它 描述软件的各种可能的条件下，对所有可能输入的数据信息，应完成那些 具体功能，产生什么样的输出。描述软件功能需求是应注意下面几点：1）功能需求的完整性和一致性对功能的描述应包含与功能相关的信息，并应具有内在的一致性(即 各种描述之间不矛盾、不冲突)。应注意以下几点：(1) 给出触发功能的各种条件(如：控制流、运行状态、运行模式等)；(2) 定义各种可能性条件下的所有可能的输入(包括合法的输入空间 和非法的输入空间)；(3) 给出各种功能间可能的相互关系(如各个功能间的控制流、数据 流、信息流，功能

5、运行关系：顺序、重复、选择、并发、同步);(4) 给出功能性的主要级别(如：基本功能、可由设计者选择逐步实 现的功能、可由设计者改变实现的功能等)；(5) 尽可能不使用“待定”这样的词。所有含有待定内容的需求都不 是完整的文件，如果出现待定的部分，必须进行待定部分内容说明，落实 负责人员、落实实施日期。2)功能描述的无岔意性和可追踪性需求功能描述的无岔意性、可追踪性和规范化：(1) 功能描述必须清晰地描述出怎样输入到怎样输出，并且输入、输 出描述应对应有数据流描述、控制流描述图，这些描述必须与其它地方描 述一致；(2) 可以用语言、方程式、决策表、矩阵或图等对功能的描述。如果 选用语言描述必须

6、使用结构化的语言，描述前必须说明该步骤(或子功能) 的执行是顺序，选择，重复，还是并发，然后说明步骤逻辑。整个描述必 须单入单出。(3) 描述时，每一个功能名称和参照编号必须唯一，且不要将多个功 能混在一起进行描述，这样便于功能的追踪和修改。(4) 功能描述应注意需求说明和程序设计的区别。需求设计仅仅是软 件的功能设计，它给出软件运行的的外部功能描述，以及为了实现这一外 部功能必须做哪些事情(采用和种数据结构，定义多个模块，接口间的接 口等)是设计阶段的事情，功能描述不应涉及到那些细节问题，以避免给 软件设计带来不必要的约束。、软件与硬件或其他外部系统接口软件与硬件或其它外部系统接口包括下述内

7、容：(1) 人机接口：说明输入、输出的内容、屏幕安排、格式等要求；(2) 硬件接口：说明端口号，指令集，输入输出信号的内容与数据类 型，初始化信号源，传输通道号和信号处理方式。(3) 软件接口：说明软件的名称、助记符、规格说明、版本号和来源;(4) 通讯接口：指定通讯接口和通讯协议等描述。、软件的非功能性需求软件非功能性需求是指软件性能指标，容限等功能以外的需求。一般 指下述内容：(1) 时间需求：输入、输出频率，输入、输出响应时间，各种功能恢 复时间等；(2) 处理容限、精度、采样参数的分辨率，误差处理等；（3）可靠性的MTBF要求，可维护性、安全性要求等。（对可能的不正 常的输入给以正常响

8、应是可靠性的重要内容，这属于功能性需求。）、软件反向需求软件的反向需求描述软件在那些情况下不能做什么。这一条是随软件 实际要求而定。有两类情形需要采用反向需求的形式。第一种情况：某些 用户需求适宜采用反向形式说明，如数据安全性要求属于这类形式。第二 种情况：对一些可靠性和安全性要求较高的软件，有些必须描述软件不能 做些什么。如控制点火时序，我们必须交代清楚在那些情况下不能点火， 否则会造成故障。、软件设计和实现上的限制软件设计和实现上的限制主要指对软件设计者的限制。如软件运行环 境的限制（选择计算机类型，使用配置，操作系统的限制等）、设计工具的 限制（使用语言、执行的标准）和保密要求等。、阅读

9、支持信息这部分内容是为了更好的帮助我们理解用户需求，也是为了使需求便 于修改和追踪。其本身并不是对需求的描述，但它影响到需求分析的可读 性，也属于需求分析的一个重要部分。一般目录、需求背景信息、内容索 引、交叉引用表、注释等均属于这个部分的内容。软件需求分析其根本性问题是理解用户功能需求，由此软件需求分析 实际上是与客户间交流过程完成的目标。要求我们组织适当的参与人员进 行交流活动。需求分析是一个综合团队的工作，是在需求分析理论的指导下，对用 户需要进行渐进方式逐步深化；通过不断变化方式形成具体约束；努力实 现需求功能目标形成特色效果的商业化产品。需求分析是一个商业行为， 完全是一个商业化操作

10、，要求有商业、技术等结合的团队共同合作，解决 需求和设计的同步，设计符合需求。项目涉及内容，项目大小都需要我们考虑参加软件需求分析工作团退 的人数，配置合理的参与人员。一般我们必须有商务活动人员，项目管理 人员，设计技术人员等参加，而且要求组织人员必须明确负责范围，以及 明确工作目标，保证实施的有效性。为了保证项目的正常实施，并且能够顺利的完成，我们必须加强项目 管理和重视项目分析工作。我们只有从实际出发，切切实实地把握用户需 求，把握用户需求目标，把握用户将来功能界定，保证我们开发工作正确 性方向。、重点监控软件需求分析办法由于软件项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险 性，软

11、件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。 其原因基本是由于以下情况造成的。、客户说不清楚需求有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如全 国各地的很多部门、机构、单位在进行应用系统以及网络建设时，客户方 的办公人员大多不清楚计算机网络有什么用，更缺乏IT系统建设方面的 专家和知识。此时，用户就会要求软件系统分析人员替他们设想需求。工 程的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。、需求自身经常变动根据以往的历史经验，随着客户方对信息化建设的认识和自己业务水 平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求 变更。事实上，历史上没有

12、一个软件的需求改动少于三次的！所以必须接 受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可 能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进行系统设 计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。咨询监理 方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必 须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做 什么”、“不做什么”的系统功能界限。、分析人员或客户理解有误软件系统分析人员不可能都是全才，更不可能是行业方面的专家。客 户表达的需求，不同的分析人员可能有不同的理解。如果分析人员理解错 了，可能会导致以后的开发工作劳而无功。记

13、得一则笑话，有个外星人间 谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是汽车。 它们喝汽油，靠四个轮子滚动前进，嗓门极大，双眼在夜里能射出强光 有趣的是，车里住着一种叫作人，的寄生虫，这些寄生虫完全控制了车。” 所以分析人员知识的专一性也会造成需求分析的误解和失败。这时，咨询 监理公司就必须根据实际的项目需求调研计划，提醒承建方加强业务了解 程度和注重沟通技巧。、有效性软件需求分析三步法根据以往的工程经验，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。、“访谈式Visitation”阶段这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通，主要 目的是从宏观上把握用

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

15、性、习惯性。用户可以操作简 单演示的DEMO,来感受一下整个业务流程的设计合理性、准确性等等问题, 及时地提出改进意见和方法。实现手段：拜访（诱导）、原型演示输出成果：调研分析报告、原型反馈报告、业务流程报告、“确认式Afirm”阶段这一阶段是在上述两个阶段成果的基础上，进行具体的流程细化、数 据项的确认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报 告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可 以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统， 来提出反馈意见，并对已经可接受的报告、文档签字确认。实现手段：拜访（回顾、确认），提交业务流程报告、数据

16、项表；原型 演示系统输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意 见（后三者可以统一归入需求分析报告中，提交用户方、监理方进行确认 和存档）整体来讲，需求分析的三个阶段是需求调研中不可忽视一个重要的部 分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了 项目成功的保证。当然在系统建设的过程中，特别在采用迭代法的开发模 式时，需求分析的工作需一直进行下去，而在后期的需求改进中，工作则 基本集中在后两个阶段中。我们根据用户需求，通过反复讨论、分析，最终明确一个唯一性的用 户需求，这个结果其实就是我们的软件需求分析报告。一般我们采用Word、 PowerPoint、Visio、ProntPage、Excel 等