软件需求分析方案设计文档格式.docx
- 文档编号:15019838
- 上传时间:2022-10-26
- 格式:DOCX
- 页数:5
- 大小:20.90KB
软件需求分析方案设计文档格式.docx
《软件需求分析方案设计文档格式.docx》由会员分享,可在线阅读,更多相关《软件需求分析方案设计文档格式.docx(5页珍藏版)》请在冰豆网上搜索。
1)对实现软件的功能做全面的描述,帮助用户判断实现功能的正确性、一致性和完整性,促使用户在软件设计启动之前周密地、全面地思考软件需求;
2)了解和描述软件实现所需的全部信息,为软件设计、确认和验证提供一个基准;
3)为软件管理人员进行软件成本计价和编制软件开发计划书提供依据;
需求分析的具体内容可以归纳为六个方面:
软件的功能需求,软件与硬件或其他外部系统接口,软件的非功能性需求,软件的反向需求,软件设计和实现上的限制,阅读支持信息。
软件需求分析应尽量提供软件实现功能需求的全部信息,使得软件设计人员和软件测试人员不再需要需求方的接触。
这就要求软件需求分析内容应正确、完整、一致和可验证。
此外,为保证软件设计质量,便于软件功能的休整和验证,软件需求表达无岔意性,具有可追踪性和可修改性.
、软件功能需求
软件的功能需求是整个需求分析最主要、最关键和最复杂的部分,它描述软件的各种可能的条件下,对所有可能输入的数据信息,应完成那些具体功能,产生什么样的输出。
描述软件功能需求是应注意下面几点:
1)功能需求的完整性和一致性
对功能的描述应包含与功能相关的信息,并应具有内在的一致性(即各种描述之间不矛盾、不冲突)。
应注意以下几点:
(1)给出触发功能的各种条件(如:
控制流、运行状态、运行模式等);
(2)定义各种可能性条件下的所有可能的输入(包括合法的输入空间和非法的输入空间);
(3)给出各种功能间可能的相互关系(如各个功能间的控制流、数据流、信息流,功能运行关系:
顺序、重复、选择、并发、同步);
(4)给出功能性的主要级别(如:
基本功能、可由设计者选择逐步实现的功能、可由设计者改变实现的功能等);
(5)尽可能不使用“待定”这样的词.所有含有待定内容的需求都不是完整的文件,如果出现待定的部分,必须进行待定部分内容说明,落实负责人员、落实实施日期.
2)功能描述的无岔意性和可追踪性
需求功能描述的无岔意性、可追踪性和规范化:
(1)功能描述必须清晰地描述出怎样输入到怎样输出,并且输入、输出描述应对应有数据流描述、控制流描述图,这些描述必须与其它地方描述一致;
(2)可以用语言、方程式、决策表、矩阵或图等对功能的描述。
如果选用语言描述必须使用结构化的语言,描述前必须说明该步骤(或子功能)的执行是顺序,选择,重复,还是并发,然后说明步骤逻辑。
整个描述必须单入单出.
(3)描述时,每一个功能名称和参照编号必须唯一,且不要将多个功能混在一起进行描述,这样便于功能的追踪和修改。
(4)功能描述应注意需求说明和程序设计的区别.需求设计仅仅是软件的功能设计,它给出软件运行的的外部功能描述,以及为了实现这一外部功能必须做哪些事情(采用和种数据结构,定义多个模块,接口间的接口等)是设计阶段的事情,功能描述不应涉及到那些细节问题,以避免给软件设计带来不必要的约束。
、软件与硬件或其他外部系统接口
软件与硬件或其它外部系统接口包括下述内容:
(1)人机接口:
说明输入、输出的内容、屏幕安排、格式等要求;
(2)硬件接口:
说明端口号,指令集,输入输出信号的内容与数据类型,初始化信号源,传输通道号和信号处理方式。
(3)软件接口:
说明软件的名称、助记符、规格说明、版本号和来源;
(4)通讯接口:
指定通讯接口和通讯协议等描述.
、软件的非功能性需求
软件非功能性需求是指软件性能指标,容限等功能以外的需求。
一般指下述内容:
(1)时间需求:
输入、输出频率,输入、输出响应时间,各种功能恢复时间等;
(2)处理容限、精度、采样参数的分辨率,误差处理等;
(3)可靠性的MTBF要求,可维护性、安全性要求等。
(对可能的不正常的输入给以正常响应是可靠性的重要内容,这属于功能性需求。
)
、软件反向需求
软件的反向需求描述软件在那些情况下不能做什么。
这一条是随软件实际要求而定。
有两类情形需要采用反向需求的形式。
第一种情况:
某些用户需求适宜采用反向形式说明,如数据安全性要求属于这类形式。
第二种情况:
对一些可靠性和安全性要求较高的软件,有些必须描述软件不能做些什么。
如控制点火时序,我们必须交代清楚在那些情况下不能点火,否则会造成故障.
、软件设计和实现上的限制
软件设计和实现上的限制主要指对软件设计者的限制。
如软件运行环境的限制(选择计算机类型,使用配置,操作系统的限制等)、设计工具的限制(使用语言、执行的标准)和保密要求等.
、阅读支持信息
这部分内容是为了更好的帮助我们理解用户需求,也是为了使需求便于修改和追踪。
其本身并不是对需求的描述,但它影响到需求分析的可读性,也属于需求分析的一个重要部分.一般目录、需求背景信息、内容索引、交叉引用表、注释等均属于这个部分的内容。
软件需求分析其根本性问题是理解用户功能需求,由此软件需求分析实际上是与客户间交流过程完成的目标。
要求我们组织适当的参与人员进行交流活动。
需求分析是一个综合团队的工作,是在需求分析理论的指导下,对用户需要进行渐进方式逐步深化;
通过不断变化方式形成具体约束;
努力实现需求功能目标形成特色效果的商业化产品.需求分析是一个商业行为,完全是一个商业化操作,要求有商业、技术等结合的团队共同合作,解决需求和设计的同步,设计符合需求。
项目涉及内容,项目大小都需要我们考虑参加软件需求分析工作团退的人数,配置合理的参与人员。
一般我们必须有商务活动人员,项目管理人员,设计技术人员等参加,而且要求组织人员必须明确负责范围,以及明确工作目标,保证实施的有效性。
为了保证项目的正常实施,并且能够顺利的完成,我们必须加强项目管理和重视项目分析工作.我们只有从实际出发,切切实实地把握用户需求,把握用户需求目标,把握用户将来功能界定,保证我们开发工作正确性方向。
、重点监控软件需求分析办法
由于软件项目的特殊性和行业覆盖的广阔性,以及需求分析的高风险性,软件需求分析的重要性是不言而喻的,同时需求分析又的的确确难做.其原因基本是由于以下情况造成的.
、客户说不清楚需求
有些客户对需求只有朦胧的感觉,当然说不清楚具体的需求.例如全国各地的很多部门、机构、单位在进行应用系统以及网络建设时,客户方的办公人员大多不清楚计算机网络有什么用,更缺乏IT系统建设方面的专家和知识。
此时,用户就会要求软件系统分析人员替他们设想需求.工程的需求存在一定的主观性,为项目未来建设埋下了潜在的风险。
、需求自身经常变动
根据以往的历史经验,随着客户方对信息化建设的认识和自己业务水平的提高,他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。
事实上,历史上没有一个软件的需求改动少于三次的!
所以必须接受“需求会变动”这个事实,在进行需求分析时要懂得防患于未然,尽可能地分析清楚哪些是稳定的需求,哪些是易变的需求,以便在进行系统设计时,将软件的核心建筑在稳定的需求上,同时留出变更空间。
咨询监理方在需求分析的功能界定上担任一个中间、公平、公正的角色,所以也必须积极参与到需求分析的准备中来,以便协助客户方和承建方来界定“做什么"
、“不做什么”的系统功能界限.
、分析人员或客户理解有误
软件系统分析人员不可能都是全才,更不可能是行业方面的专家.客户表达的需求,不同的分析人员可能有不同的理解.如果分析人员理解错了,可能会导致以后的开发工作劳而无功。
记得一则笑话,有个外星人间谍潜伏到地球刺探情报,它给上司写了一份报告:
“主宰地球的是汽车.它们喝汽油,靠四个轮子滚动前进,嗓门极大,双眼在夜里能射出强光……有趣的是,车里住着一种叫作‘人’的寄生虫,这些寄生虫完全控制了车。
”所以分析人员知识的专一性也会造成需求分析的误解和失败.这时,咨询监理公司就必须根据实际的项目需求调研计划,提醒承建方加强业务了解程度和注重沟通技巧。
、有效性软件需求分析三步法
根据以往的工程经验,需求分析工作方法,应该定位在“三个阶段”(也称“三步法”)。
、“访谈式Visitation”阶段
这一阶段是和具体用户方的领导层、业务层人员的访谈式沟通,主要目的是从宏观上把握用户的具体需求方向和趋势,了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。
建立起良好的沟通渠道和方式。
针对具体的职能部门以及各委办局,最好能指定本次项目的接口人.
实现手段:
访谈、调查表格
输出成果:
调查报告、业务流程报告
、“诱导式Inducement”阶段
这一阶段是在承建方已经了解了具体用户方的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体实际、客观的信息基础上,结合现有的硬件、软件实现方案,做出简单的用户流程页面,同时结合以往的项目经验对用户采用诱导式、启发式的调研方法和手段,和用户一起探讨业务流程设计的合理性、准确性、便易性、习惯性。
用户可以操作简单演示的DEMO,来感受一下整个业务流程的设计合理性、准确性等等问题,及时地提出改进意见和方法。
实现手段:
拜访(诱导)、原型演示
输出成果:
调研分析报告、原型反馈报告、业务流程报告
、“确认式Afirm”阶段
这一阶段是在上述两个阶段成果的基础上,进行具体的流程细化、数据项的确认阶段,这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表,并能清晰地向用户描述系统的业务流设计目标。
用户方可以通过审查业务流程报告、数据项表以及操作承建方提供的DEMO系统,来提出反馈意见,并对已经可接受的报告、文档签字确认。
拜访(回顾、确认),提交业务流程报告、数据项表;
原型演示系统
需求分析报告、数据项、业务流程报告、原型系统反馈意见(后三者可以统一归入需求分析报告中,提交用户方、监理方进行确认和存档)
整体来讲,需求分析的三个阶段是需求调研中不可忽视一个重要的部分,三个阶段或者说三步法的实施和采用,对用户和承建方都同样提供了项目成功的保证。
当然在系统建设的过程中,特别在采用迭代法的开发模式时,需求分析的工作需一直进行下去,而在后期的需求改进中,工作则基本集中在后两个阶段中.
我们根据用户需求,通过反复讨论、分析,最终明确一个唯一性的用户需求,这个结果其实就是我们的软件需
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 需求 分析 方案设计
![提示](https://static.bdocx.com/images/bang_tan.gif)