软件需求分析方案设计Word文件下载.docx

软件需求分析方案设计Word文件下载.docx

《软件需求分析方案设计Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件需求分析方案设计Word文件下载.docx（7页珍藏版）》请在冰豆网上搜索。

　　需求分析的详细内容可以归纳为六个方面：

软件的功能需求，软件与硬件或其他外部系统接口，软件的非功能性需求，软件的反向需求，软件设计和实现上的限制，阅读支持信息。

　　软件需求分析应尽量提供软件实现功能需求的全部信息，使得软件设计人员和软件测试人员不再需要需求方的接触。

这就要求软件需求分析内容应正确、完整、一致和可验证。

此外，为保证软件设计质量，便于软件功能的休整和验证，软件需求表达无岔意性，具有可追踪性和可修改性。

　　2.1、软件功能需求

　　软件的功能需求是整个需求分析最主要、最关键和最复杂的部分，它描述软件的各种可能的条件下，对所有可能输入的数据信息，应完成那些详细功能，产生什么样的输出。

描述软件功能需求是应注意下面几点：

　　1）功能需求的完整性和一致性

　　对功能的描述应包含与功能相关的信息，并应具有内在的一致性（即各种描述之间不矛盾、不冲突）。

应注意以下几点：

（1）给出触发功能的各种条件（如：

控制流、运行状态、运行模式等）;

（2）定义各种可能性条件下的所有可能的输入（包括合法的输入空间和非法的输入空间）;

　　（3）给出各种功能间可能的相互关系（如各个功能间的控制流、数据流、信息流，功能运行关系：

顺序、重复、选择、并发、同步）;

　　（4）给出功能性的主要级别（如：

根本功能、可由设计者选择逐步实现的功能、可由设计者改变实现的功能等）;

　　（5）尽可能不使用“待定”这样的词。

所有含有待定内容的需求都不是完整的文件，如果出现待定的部分，必须进展待定部分内容说明，落实负责人员、落实实施日期。

　　2）功能描述的无岔意性和可追踪性

　　需求功能描述的无岔意性、可追踪性和标准化：

（1）功能描述必须清晰地描述出怎样输入到怎样输出，并且输入、输出描述应对应有数据流描述、控制流描述图，这些描述必须与其它地方描述一致;

（2）可以用语言、方程式、决策表、矩阵或图等对功能的描述。

如果选用语言描述必须使用构造化的语言，描述前必须说明该步骤（或子功能）的执行是顺序，选择，重复，还是并发，然后说明步骤逻辑。

整个描述必须单入单出。

　　（3）描述时，每一个功能名称和参照编号必须唯一，且不要将多个功能混在一起进展描述，这样便于功能的追踪和修改。

　　（4）功能描述应注意需求说明和程序设计的区别。

需求设计仅仅是软件的功能设计，它给出软件运行的的外部功能描述，以及为了实现这一外部功能必须做哪些事情（采用和种数据构造，定义多个模块，接口间的接口等）是设计阶段的事情，功能描述不应涉及到那些细节问题，以防止给软件设计带来不必要的约束。

　　2.2、软件与硬件或其他外部系统接口

　　软件与硬件或其它外部系统接口包括下述内容：

（1）人机接口：

说明输入、输出的内容、屏幕安排、格式等要求;

（2）硬件接口：

说明端口号，指令集，输入输出信号的内容与数据类型，初始化信号源，传输通道号和信号处理方式。

　　（3）软件接口：

说明软件的名称、助记符、规格说明、版本号和;

　　（4）通讯接口：

指定通讯接口和通讯协议等描述。

　　2.3、软件的非功能性需求

　　软件非功能性需求是指软件性能指标，容限等功能以外的需求。

一般指下述内容：

（1）时间需求：

输入、输出频率，输入、输出响应时间，各种功能恢复时间等;

（2）处理容限、精度、采样参数的分辨率，误差处理等;

　　（3）可靠性的MTBF要求，可维护性、平安性要求等。

（对可能的不正常的输入给以正常响应是可靠性的重要内容，这属于功能性需求。

）

　　2.4、软件反向需求

　　软件的反向需求描述软件在那些情况下不能做什么。

这一条是随软件实际要求而定。

有两类情形需要采用反向需求的形式。

第一种情况：

某些用户需求适宜采用反向形式说明，如数据平安性要求属于这类形式。

第二种情况：

对一些可靠性和平安性要求较高的软件，有些必须描述软件不能做些什么。

如控制点火时序，我们必须交代清楚在那些情况下不能点火，否那么会造成故障。

　　2.5、软件设计和实现上的限制

　　软件设计和实现上的限制主要指对软件设计者的限制。

如软件运行环境的限制（选择计算机类型，使用配置，操作系统的限制等）、设计工具的限制（使用语言、执行的标准）和保密要求等。

　　2.6、阅读支持信息

　　这部分内容是为了更好的帮助我们理解用户需求，也是为了使需求便于修改和追踪。

其本身并不是对需求的描述，但它影响到需求分析的可读性，也属于需求分析的一个重要部分。

一般目录、需求背景信息、内容索引、穿插引用表、注释等均属于这个部分的内容。

　　软件需求分析其根本性问题是理解用户功能需求，由此软件需求分析实际上是与客户间交流过程完成的目标。

要求我们组织适当的参与人员进展交流活动。

　　需求分析是一个综合团队的工作，是在需求分析理论的指导下，对用户需要进展渐进方式逐步深化;

通过不断变化方式形成详细约束;

努力实现需求功能目标形成特色效果的商业化产品。

需求分析是一个商业行为，完全是一个商业化操作，要求有商业、技术等结合的团队共同合作，解决需求和设计的同步，设计符合需求。

　　工程涉及内容，工程大小都需要我们考虑参加软件需求分析工作团退的人数，配置合理的参与人员。

一般我们必须有商务活动人员，工程管理人员，设计技术人员等参加，而且要求组织人员必须明确负责范围，以及明确工作目标，保证实施的有效性。

　　为了保证工程的正常实施，并且能够顺利的完成，我们必须加强工程管理和重视工程分析工作。

我们只有从实际出发，切切实实地把握用户需求，把握用户需求目标，把握用户将来功能界定，保证我们开发工作正确性方向。

　　4.1、重点监控软件需求分析方法

　　由于软件工程的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又确实实确难做。

其原因根本是由于以下情况造成的。

　　4.1.1、客户说不清楚需求

　　有些客户对需求只有朦胧的感觉，当然说不清楚详细的需求。

例如全国各地的很多部门、机构、单位在进展应用系统以及网络建立时，客户方的办公人员大多不清楚计算机网络有什么用，更缺乏IT系统建立方面的专家和知识。

此时，用户就会要求软件系统分析人员替他们设想需求。

工程的需求存在一定的主观性，为工程未来建立埋下了潜在的风险。

　　4.1.2、需求自身经常变动

　　根据以往的历史经历，随着客户方对信息化建立的认识和自己业务水平的提高，他们会在不同的阶段和时期对工程的需求提出新的要求和需求变更。

事实上，历史上没有一个软件的需求改动少于三次的!

所以必须承受“需求会变动”这个事实，在进展需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在进展系统设计时，将软件的核心建筑在稳定的需求上，同时留出变更空间。

咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助客户方和承建方来界定“做什么”、“不做什么”的系统功能界限。

　　4.1.3、分析人员或客户理解有误

　　软件系统分析人员不可能都是全才，更不可能是行业方面的专家。

客户表达的需求，不同的分析人员可能有不同的理解。

如果分析人员理解错了，可能会导致以后的开发工作劳而无功。

记得一那么笑话，有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：

“主宰地球的是汽车。

它们喝汽油，靠四个轮子滚动前进，嗓门极大，双眼在夜里能射出强光……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。

”所以分析人员知识的专一性也会造成需求分析的误解和失败。

这时，咨询监理公司就必须根据实际的工程需求调研方案，提醒承建方加强业务了解程度和注重沟通技巧。

　　4.2、有效性软件需求分析三步法

　　根据以往的工程经历，需求分析工作方法，应该定位在“三个阶段”（也称“三步法”）。

　　4.2.1、“访谈式Visitation”阶段

　　这一阶段是和详细用户方的领导层、业务层人员的访谈式沟通，主要目的是从宏观上把握用户的详细需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等详细情况、客观的信息。

建立起良好的沟通渠道和方式。

针对详细的职能部门以及各委办局，最好能指定本次工程的接口人。

　　实现手段：

访谈、调查表格

　　输出成果：

调查报告、业务流程报告

　　4.2.2、“诱导式Inducement”阶段

　　这一阶段是在承建方已经了解了详细用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等详细实际、客观的信息根底上，结合现有的硬件、软件实现方案，做出简单的用户流程页面，同时结合以往的工程经历对用户采用诱导式、启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。

用户可以操作简单演示的DEMO，来感受一下整个业务流程的设计合理性、准确性等等问题，及时地提出改进意见和方法。

拜访（诱导）、原型演示

调研分析报告、原型反响报告、业务流程报告

　　4.2.3、“确认式Afirm”阶段

　　这一阶段是在上述两个阶段成果的根底上，进展详细的流程细化、数据项确实认阶段，这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。

用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统，来提出反响意见，并对已经可承受的报告、文档签字确认。

拜访（回忆、确认），提交业务流程报告、数据项表;

原型演示系统

需求分析报告、数据项、业务流程报告、原型系统反响意见（后三者可以统一归入需求分析报告中，提交用户方、监理方进展确认和存档）

　　整体来讲，需求分析的三个阶段是需求调研中不可无视一个重要的部分，三个阶段或者说三步法的实施和采用，对用户和承建方都同样提供了工程成功的保证。

当然在系统建立的过程中，特别在采用迭代法的开发模式时，需求分析的工作需一直进展下去，而在后期的需求改进中，工作那么根本集中在后两个阶段中。

　　我们根据用户需求，通过反复讨论、分析，最终明确一个唯一性的用户需求，这个结果其实就是我们的软件需求分析报告。

一般我们采用Word、PowerPoint、Visio、ProntPage、Excel等Office工具，同时可能采用一些开发工具，如VC或BC等，同样也会使用一些图形工具，如Potoshop、调色板等画图工具。

　　使用各种工具表达软件需求分析，其详细表达手段可以分为：

　　l效果图描述。

主要是用户UI界面的描述反映用户需求功能;

　　l逻辑图描述。

根据用户需求功能，使用抽象化理论，以及需求分析理论，对用户需求功能进展全面的分析，建立功能性逻辑关系图，流程逻辑关系图等;

　　l关系图表描述。

主要是对信息关系、数据库表格、接口函数等描述;

　　l工程数学描述。

分析用户需求，分析用户需求信息，运用工程数学进展算法推导，进展合理化需求分析推导;

　　l甘地图描述。

主要是软件工程工作安排，开发周期预估;

　　l其它方法描述。

保证完整性合理性的有效描述。

　　软件需求分析评估是为了检查我们进展软件需求分析工作，保证软件需求分析工作正确性、完整性、有效性、合理性、可确认性、可实施性，完全保证用户所需求的功能。

　　6.1、组织构造与责任管理

　　我们对组织构造与责任管理的评估主要有：

参与人员任务和责任界面的明确;

安排方案按时完成状况;

相互间的协调能力状况。

　　6.2、满足用户需求的功能

　　我们进展需求分析的目的是完整、准确地描述用户的需求，跟踪用户需求的变化，将用户的需求准确地反映到系统的分析和设计中，并使系统的分析、设计和用户的需求保持一致。

　　需求分析的特点是需求的完整性、一致性和可追溯性。

完整性：

是准确、全面的描述用户的需求。

一致性：

是通过分析，剔除用户需求矛盾的方面，标准用户需求。

可追溯性：

有两个方面的含义，和标准的需求，其一，需要不断的和用户进一步交流，保持和用户最新的需求一致。

其二，和系统分析（设计）保持一致。

　　因此在需求分析之前我们必须建立需求分析技术层面的根本框架，从技术上保证需求分析的要求，在此根底上我们进展的需求分析才能满足工程对需求分析的要求。

　　6.3、保证可实施性

　　我们必须以用户软件需求为依据，以求实的态度详细的、准确的、完整的编写软件需求分析，防止空想世界，空中楼阁的想法;

防止无逻辑性、无核心的描述;

防止无量化思维，无实际空间概念。

　　6.4、需求分析评价指标

　　主要有这么几个指标：

功能性、完整性、正确性、逻辑性、表现性、合理性，可实施性等。

　　6.5、工作周期

　　评价人员投入，以及费用支出的合理性问题。

正确制定工作周期，保证软件工程的顺利完成。

　　6.6、需求不确定更改与可确认保证

　　可确认需求功能是实现用户需求的根本保证，如果不可确认的、不确定更改存在，将会阻碍软件实现，或者软件设计存在着不完整性缺陷，或者存在着不可实施性问题，我们必须区分是功能性障碍问题，还是未来性问题。

如果不能够明确是未来性问题，那么必须调整功能需求，化解不确定更改的问题。

因此，判断不确定性更改是一个非常重要的问题。