软件需求调研方案设计.docx

软件需求调研方案设计.docx

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

软件需求调研方案设计

软件需求调研方案设计

软件需求作为软件项目工作的重要依据对软件项目的成败起着至关重要的作用以下是小编整理的软件需求调研方案设计欢迎阅读

软件需求分析是一个项目的开端也是项目实施最重要的关键点据有关的机构分析结果表明我们设计的软件产品存在不完整性、不正确性等问题80％以上是需求分析错误所导致的而且由于需求分析错误造成根本性的功能问题尤为突出因此一个项目的成功软件需求分析是关键的一步

A.软件需求分析人员组织

软件需求分析其根本性问题是理解用户功能需求由此软件需求分析实际上是与客户间交流过程完成的目标要求我们组织适当的参与人员进行交流活动

需求分析是一个综合团队的工作是在需求分析理论的指导下对用户需要进行渐进方式逐步深化；通过不断变化方式形成具体约束；努力实现需求功能目标形成特色效果的商业化产品需求分析是一个商业行为完全是一个商业化操作要求有商业、技术等结合的团队共同合作解决需求和设计的同步设计符合需求

项目涉及内容项目大小都需要我们考虑参加软件需求分析工作团退的人数配置合理的参与人员一般我们必须有商务活动人员项目管理人员设计技术人员等参加而且要求组织人员必须明确负责范围以及明确工作目标保证实施的有效性

B.具体开展需求分析工作建议采用以下步骤形成软件需求：

确定项目目标及范围→获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求

第一步：

明确需要分析的工作目标同时确定调研对象最好能指定本次项目的接口人

明确软件需求分析的主要实现目标包括如下内容：

1）对实现软件的功能做全面的描述帮助用户判断实现功能的正确性、一致性和完整性促使用户在软件设计启动之前周密地、全面地思考软件需求；

2）了解和描述软件实现所需的全部信息为软件设计、确认和验证提供一个基准；

3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据；

第二步：

获取用户需求这是该阶段的一个最重要的任务对用户进行访谈和调研交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式具体说来可分为三个阶段：

1.“访谈”阶段

这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通主要目的是从宏观上把握用户的具体需求方向和趋势了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息建立起良好的沟通渠道和方式针对具体的职能部门以及成员单位

实现手段：

访谈、调查表格

输出成果：

调查报告、业务流程报告

2.“诱导”阶段

这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上结合现有的硬件、软件实现方案做出简单的用户流程页面同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性用户可以操作简单演示的DEMO来感受一下整个业务流程的设计合理性、准确性等等问题及时地提出改进意见和方法

实现手段：

拜访（诱导）、原型演示

输出成果：

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

3.“确认”阶段

这一阶段是在上述两个阶段成果的基础上进行具体的流程细化、数据项的确认阶段这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表并能清晰地向用户描述系统的业务流设计目标用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统来提出反馈意见并对已经可接受的报告、文档签字确认

实现手段：

拜访（回顾、确认）提交业务流程报告、数据项表；原型演示系统

输出成果：

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

整体来讲需求分析的三个阶段是需求调研中不可忽视一个重要的部分三个阶段或者说三步法的实施和采用对用户和承建方都同样提供了项目成功的保证当然在系统建设的过程中特别在采用迭代法的开发模式时需求分析的工作需一直进行下去而在后期的需求改进中工作则基本集中在后两个阶段中

第三步：

分析用户需求

需求分析人员对收集到的用户需求做进一步的分析和整理下面是几条常见的准则：

1.对于用户提出的每个需求都要知道“为什么”并判断用户提出的需求是否有充足的理由;

2.将那种以“如何实现”的表述方式转换为“实现什么”的方式因为需求分析阶段关注的目标是“做什么”而不是“做”;

3.分析由用户需求衍生出的隐含需求并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件）这一点往往容易忽略掉经常因为对隐含需求考虑得不够充分而引起需求变更

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

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

软件需求分析应尽量提供软件实现功能需求的全部信息使得软件设计人员和软件测试人员不再需要需求方的接触这就要求软件需求分析内容应正确、完整、一致和可验证此外为保证软件设计质量便于软件功能的休整和验证软件需求表达无岔意性具有可追踪性和可修改性

1.软件的功能需求

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

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

对功能的描述应包含与功能相关的信息并应具有内在的一致性（即各种描述之间不矛盾、不冲突）应注意以下几点：

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

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

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

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

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

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

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

（5）尽可能不使用“待定”这样的词所有含有待定内容的需求都不是完整的文件如果出现待定的部分必须进行待定部分内容说明落实负责人员、落实实施日期

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

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

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

（2）可以用语言、方程式、决策表、矩阵或图等对功能的描述如果选用语言描述必须使用结构化的语言描述前必须说明该步骤（或子功能）的执行是顺序选择重复还是并发然后说明步骤逻辑整个描述必须单入单出

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

（4）功能描述应注意需求说明和程序设计的区别需求设计仅仅是软件的功能设计它给出软件运行的的外部功能描述以及为了实现这一外部功能必须做些事情（采用和种数据结构定义多个模块接口间的接口等）是设计阶段的事情功能描述不应涉及到那些细节问题以避免给软件设计带来不必要的约束

2.软件与硬件或其他外部系统接口

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

（1）人机接口：

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

（2）硬件接口：

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

（3）软件接口：

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

（4）通讯接口：

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

3.软件的非功能性要求

软件非功能性需求是指软件性能指标容限等功能以外的需求一般指下述内容：

（1）时间需求：

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

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

（3）可靠性的MTBF要求可维护性、安全性要求等（对可能的不正常的输入给以正常响应是可靠性的重要内容这属于功能性需求）

4.软件反向需求

软件的反向需求描述软件在那些情况下不能做什么这一条是随软件实际要求而定有两类情形需要采用反向需求的形式第一种情况：

某些用户需求适宜采用反向形式说明如数据安全性要求属于这类形式第二种情况：

对一些可靠性和安全性要求较高的软件有些必须描述软件不能做些什么如控制点火时序我们必须交代清楚在那些情况下不能点火否则会造成故障

5.软件设计和实现上的限制

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

6.阅读支持信息

这部分内容是为了更好的帮助我们理解用户需求也是为了使需求便于修改和追踪其本身并不是对需求的描述但它影响到需求分析的可读性也属于需求分析的一个重要部分一般目录、需求背景信息、内容索引、交叉引用表、注释等均属于这个部分的内容

再看软件需求分析常用工具

我们根据用户需求通过反复讨论、分析最终明确一个唯一性的用户需求这个结果其实就是我们的软件需求分析报告一般我们采用Word、PowerPoint、Visio、ProntPage、Excel等Office工具同时可能采用一些开发工具如VC或BC等同样也会使用一些图形工具如Potoshop、调色板等画图工具

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

1.效果图描述主要是用户UI界面的描述反映用户需求功能；

2.逻辑图描述根据用户需求功能使用抽象化理论以及需求分析理论对用户需求功能进行全面的分析建立功能性逻辑关系图流程逻辑关系图等；

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

4.工程数学描述分析用户需求分析用户需求信息运用工程数学进行算法推导进行合理化需求分析推导；

5.甘地图描述主要是软件项目工作安排开发周期预估；

6.其它方法描述保证完整性合理性的有效描述

第四步：

编写需求文档

根据我们多年的经验总结针对特定项目我们的需求文档都有固定模板经过前面的需求调研、需求分析过程所得到的结果基本上按照用户组织结构、功能模块分布情况经过文档格式、内容的整合与优化即可形成我们需求调研分析的成果文件“需求规格说明书”其将做为我们下一步系统开发的主要输入文件之一

第五步：

评审需求文档

软件需求分析评审是为了检查我们进行软件需求分析工作保证软件需求分析工作正确性、完整性、有效性、合理性、可确认性、可实施性完全保证用户所需求的功能评审内容的主要载体就是“需求规格说明书”

1.组织结构与责任管理

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

参与人员任务和责任界面的明确；安排计划按时完成状况；相互间的协调能力状况

2.满足用户需求的功能

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

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

是准确、全面的描述用户的需求一致性：

是通过分析整理剔除用户需求矛盾的方面规范用户需求可追溯性：

有两个方面的含义整理和规范的需求其一需要不断的和用户进一步交流保持和用户最新的需求一致其二和系统分析（设计）保持一致

因此在需求分析之前我们必须建立需求分析技术层面的基本框架从技术上保证需求分析的要求在此基础上我们进行的需求分析才能满足项目对需求分析的要求

3.保证可实施性

我们必须以用户软件需求为依据以求实的态度详细的、准确的、完整的编写软件需求分析避免空想世界空中楼阁的想法；避免无逻辑性、无核心的描述；避免无量化思维无实际空间概念

4.需求分析评价指标

主要有这么几个指标：

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

5.工作周期

评价人员投入以及费用支出的合理性问题正确制定工作周期保证软件项目的顺利完成

6.需求不确定更改与可确认保证

可确认需求功能是实现用户需求的基本保证如果不可确认的、不确定更改存在将会阻碍软件实现或者软件设计存在着不完整性缺陷或者存在着不可实施性问题我们必须区分是功能性障碍问题还是未来性问题如果不能够明确是未来性问题则必须调整功能需求化解不确定更改的问题因此判断不确定性更改是一个非常重要的问题

第六步：

管理需求将存在于项目的整个生命周期内

需求管理就是IT项目中的范围管理需求管理是整个IT项目的源头IT项目的估算计划后续的跟踪控制验证和确认等各项工作都是跟需求密切相关的因此为了保证项目的进度质量和成本的目标的顺利实现保证项目计划的严肃性和可执行性；为了保证软件系统最终开发的产品正是客户期望的产品必须要做好需求管理工作

需求管理工作应该是需求全生命周期的管理从用户原始需求的提出到最终形成软件产品后用户对需求实现情况的验证以形成闭环流程因此我们需要跟踪和了解到需求状态的演变过程大型的项目软件生命周期模型较为复杂一个需求的实现会经过用户需求软件需求总体设计详细设计开发和单元测试集成测试系统测试和验收测试多个环节在这个过程中需要建立需求追踪以确认需求和中间阶段产生的工作产品的一致性另外变更管理是需求管理的另外一个重点需求在经过评审确认后需要基线并受到控制当出现需求变更的时候必须进行相应的需求影响分析以确认对需求变更的处理方式当变更工作量影响较大的时候还需要调整并重新基线项目计划

对于整个需求调研分析和需求开发评审确认的过程也需要进行管理在这个过程中的一个重点就是对需求输出的文档需要得到用户项目组设计开发人员的共同确认和承诺