登录

软件需求说明书

百科 > 软件项目管理 > 软件需求说明书

1.什么是软件需求说明书[1]

软件需求说明书是需求分析阶段的最后成果,是软件开发中的重要文档之一。软件需求说明书是作为需求分析的一部分而制定的可交付文档,该说明把在软件计划中确定的软件范围加以展开,制定出完整的信息描述、详细的功能说明、恰当的检验标准以及其他与要求有关的数据。

2.软件需求说明书内容和书写参考格式[1]

软件需求说明书所包括的内容和书写参考格式如下:

一、概述

二、数据描述

口数据流图

口数据字典

口系统接口说明

口内部接口

三、功能描述

口功能

口处理说明

口设计的限制

四、性能描述

口性能参数

口测试种类

口预期的软件响应

口应考虑的特殊问题

五、参考文献目录

六、附录

概述是从系统的角度描述软件的目标和任务。

数据描述是对软件系统所必须解决的问题做出的详细说明。

功能描述中描述了为解决用户问题所需要的每一项功能的过程细节。对每一项功能要给出功能的说明、处理的说明以及设计时要考虑到的限制。

在性能描述中说明系统应达到的性能和应该满足的限制条件、检测的方法和标准、预期的软件响应和可能需要考虑的特殊问题。

参考文献目录中应包括与该软件有关的全部参考文献,其中包括前期的其他文档、技术参考资料、产品目录手册以及标准等。

附录部分包括一些补充资料,如列表数据、算法的详细说明、框图、图表和其他材料。

软件需求规格说明是分析任务的最终产物,通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准,给出对目标软件的各种需求。

3.软件需求说明书的作用[1]

软件需求说明书主要有以下三个作用:

口作为用户和软件人员之间的共同文件,为双方相互了解提供基础。

口反映出用户问题的结构,可以作为软件人员进行设计和编码的基础。

口作为验收的依据,即作为选取测试用例和进行形式验证的依据。

软件需求说明书是一份在软件生命周期中至关重要的文件,它在开发早期就为尚未诞生的软件系统建立了一个可见的逻辑模型,它是确保系统质量的有力措施,可以保证开发工作的/顷利进行。因而应及时地建立并保证它的质量

作为设计基础和验收依据,需求说明书应该是精确而无二义性的。需求说明书越精确,以后出现错误、混淆、反复的可能性越小。用户能看懂需求说明书,并且发现和指出其中的错误是保证软件系统质量的关键,因而需求说明书必须简明易懂,尽量不包含计算机的概念和术语,以便用户和软件人员双方都能接受它。

由于在一个企业组织中各部门的用户可能提出相互冲突的要求,在分析阶段必须协调和解决这些冲突,因而在需求说明书中的表达应该是一致的、无矛盾的用户要求。

软件生命周期中,软件错误发现得越早,纠正的代价就越小。所以需求说明书编写完成后,应该组织用户和一些专家反复对其作检验和复查,争取尽早发现错误并及时纠正,以免到系统后期改正错误时付出巨大代价。

4.软件需求说明书范文[2]

某软件的需求说明书

一.引言

软硬件系统基本支持:系统的运行平台是PC机。本系统拟采用××[[技术开发]],一期开发实现单机模式,选择CJHJ为开发语言。

二、主要目标

所开发的软件要能实现以下要求。

1.日期和时间:实现多种日历表,如农历表。

2.日程事务提醒。办公日程提醒:如会议、出差、上课、课间休息;生活琐事提醒:如就餐时间、体育锻炼。

3.提醒方案:实现多种提醒设定选项,比如每日、每周循环提醒。

4.提醒方式:以[[娱乐]]提醒方式为主(可以是音频或视频片断),比如学习工作中休息时刻到时就播放范晓萱的《健康歌》。

三、对现有系统的分析

现有系统是指当前实际使用的系统,这个系统可能是计算机系统,也可能是个机械系统甚至是一个人工系统。对现有系统进行分析的目的是进一步阐明建议中的
开发新系统或修改现有系统必要性。

现有系统主要功能过于简单,主要包括通讯录、日程表、[[文档管理]]、闹钟等,不能满足对于各种提醒方案和各种提醒方式的要求。

四、所建议的系统

(一)闹钟,用于提醒各种事务,包括用餐、休息等

日期和时间:实现多种日历表,如农历表;根据已经成熟的日期换算算法直接得到结果。

(二)日程事务提醒

根据用户设定的某个时间的具体事务,当时间到达时,将用闹钟或是语音的方式提醒用户。

提供日程安排提醒功能。使用了一个比较有效的事务处理模型,即紧急、重要事务处理模型。事务按照紧急性和重要性排在二维坐标上,那么通知的时候会按照图示
的模型提醒,保证用户的工作最高效。

五、[[投资]]及[[效益分析]]

(一)[[支出]]

一次性支出:系统开发阶段所需经费主要为书籍资料费,由开发团队自行准备,总额不超过XX元。

非一次性支出:开发团队日常生活费用自理。

(二)[[收益]]

本系统属于非营利性的系统,不存在收益评估问题,但建议开发团队确实能充分利用现有资源,适当减少[[投资]]。

六、[[可行性分析]]

1.法律方面的可行性。该软件没有侵犯任何的个人或是团体,也不违反任何的相关法律。

2.技术的可行性。在技术上不存在困难,完全可以达到。

3.时间的可行性。预定期限为四个月,可以完成。

4.用户使用方面的可行性。本系统的主要用户为办公人员,对于基本的电脑使用和操作不会陌生。因此不会在系统的使用上遇到太大问题。同时系统将提供《操作手册》
和《用户手册》指导用户操作和使用,因此,系统在使用方面是完全可行的。
软件需求说明书注意要点:

需求说明书要符合以下原则。

1.明确性:需求叙述的读者应只能从其得到唯一的解释说明,同样,一个需求的多个读者也应达成共识。每写一个需求都应简洁、简单、直观地采用用户熟知的语言,每个需求必须精确描述要交付的功能。

2.可行性:在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性,在需求分析阶段应该有一个开发人员参与,在抽象阶段应该有市场人员参与。

3.必要性:每个需求应载明什么是客户确实需要的,每个需求都有原始出处。

4.完整性:不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。

5.一致性:一致性需求就是不要与其他系统发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎,如果只审定修改的部分,没有审定于修改相关的部分,就可能导致不一致性。

评论  |   0条评论