软件需求说明书(SRS,Software Requirements SPECIFication)
目录
- 1 什么是软件需求说明书
- 2 软件需求说明书内容和书写参考格式
- 3 软件需求说明书的作用
- 4 软件需求说明书范文
- 5 参考文献
什么是软件需求说明书
软件需求说明书是需求分析阶段的最后成果,是软件开发中的重要文档之一。软件需求说明书是作为需求分析的一部分而制定的可交付文档,该说明把在软件计划中确定的软件范围加以展开,制定出完整的信息描述、详细的功能说明、恰当的检验标准以及其他与要求有关的数据。
软件需求说明书内容和书写参考格式
软件需求说明书所包括的内容和书写参考格式如下:
一、概述
二、数据描述
口数据流图
口数据字典
口系统接口说明
口内部接口
三、功能描述
口功能
口处理说明
口设计的限制
四、性能描述
口性能参数
口测试种类
口预期的软件响应
口应考虑的特殊问题
五、参考文献目录
六、附录
概述是从系统的角度描述软件的目标和任务。
数据描述是对软件系统所必须解决的问题做出的详细说明。
功能描述中描述了为解决用户问题所需要的每一项功能的过程细节。对每一项功能要给出功能的说明、处理的说明以及设计时要考虑到的限制。
在性能描述中说明系统应达到的性能和应该满足的限制条件、检测的方法和标准、预期的软件响应和可能需要考虑的特殊问题。
参考文献目录中应包括与该软件有关的全部参考文献,其中包括前期的其他文档、技术参考资料、产品目录手册以及标准等。
附录部分包括一些补充资料,如列表数据、算法的详细说明、框图、图表和其他材料。
软件需求规格说明是分析任务的最终产物,通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准,给出对目标软件的各种需求。
软件需求说明书的作用
软件需求说明书主要有以下三个作用:
口作为用户和软件人员之间的共同文件,为双方相互了解提供基础。
口反映出用户问题的结构,可以作为软件人员进行设计和编码的基础。
口作为验收的依据,即作为选取测试用例和进行形式验证的依据。
软件需求说明书是一份在软件生命周期中至关重要的文件,它在开发早期就为尚未诞生的软件系统建立了一个可见的逻辑模型,它是确保系统质量的有力措施,可以保证开发工作的/顷利进行。因而应及时地建立并保证它的质量。
作为设计基础和验收依据,需求说明书应该是精确而无二义性的。需求说明书越精确,以后出现错误、混淆、反复的可能性越小。用户能看懂需求说明书,并且发现和指出其中的错误是保证软件系统质量的关键,因而需求说明书必须简明易懂,尽量不包含计算机的概念和术语,以便用户和软件人员双方都能接受它。
由于在一个企业组织中各部门的用户可能提出相互冲突的要求,在分析阶段必须协调和解决这些冲突,因而在需求说明书中的表达应该是一致的、无矛盾的用户要求。
在软件生命周期中,软件错误发现得越早,纠正的代价就越小。所以需求说明书编写完成后,应该组织用户和一些专家反复对其作检验和复查,争取尽早发现错误并及时纠正,以免到系统后期改正错误时付出巨大代价。
软件需求说明书范文
某软件的需求说明书一.引言软硬件系统基本支持:系统的运行平台是PC机。本系统拟采用××[[技术开发]],一期开发实现单机模式,选择CJHJ为开发语言。二、主要目标所开发的软件要能实现以下要求。1.日期和时间:实现多种日历表,如农历表。2.日程事务提醒。办公日程提醒:如会议、出差、上课、课间休息;生活琐事提醒:如就餐时间、体育锻炼。3.提醒方案:实现多种提醒设定选项,比如每日、每周循环提醒。4.提醒方式:以[[娱乐]]提醒方式为主(可以是音频或视频片断),比如学习工作中休息时刻到时就播放范晓萱的《健康歌》。三、对现有系统的分析现有系统是指当前实际使用的系统,这个系统可能是计算机系统,也可能是个[[机械系统]]甚至是一个人工系统。对现有系统进行分析的目的是进一步阐明建议中的开发新系统或修改现有系统必要性。现有系统主要功能过于简单,主要包括通讯录、日程表、[[文档管理]]、闹钟等,不能满足对于各种提醒方案和各种提醒方式的要求。四、所建议的系统(一)闹钟,用于提醒各种事务,包括用餐、休息等日期和时间:实现多种日历表,如农历表;根据已经成熟的日期换算算法直接得到结果。(二)日程事务提醒根据用户设定的某个时间的具体事务,当时间到达时,将用闹钟或是语音的方式提醒用户。提供日程安排提醒功能。使用了一个比较有效的事务处理模型,即紧急、重要事务处理模型。事务按照紧急性和重要性排在二维坐标上,那么通知的时候会按照图示的模型提醒,保证用户的工作最高效。五、[[投资]]及[[效益分析]](一)[[支出]]一次性支出:系统开发阶段所需经费主要为书籍资料费,由开发团队自行准备,总额不超过XX元。非一次性支出:开发团队日常生活费用自理。(二)[[收益]]本系统属于非营利性的系统,不存在收益评估问题,但建议开发团队确实能充分利用现有资源,适当减少[[投资]]。六、[[可行性分析]]1.法律方面的可行性。该软件没有侵犯任何的个人或是团体,也不违反任何的相关法律。2.技术的可行性。在技术上不存在困难,完全可以达到。3.时间的可行性。预定期限为四个月,可以完成。4.用户使用方面的可行性。本系统的主要用户为办公人员,对于基本的电脑使用和操作不会陌生。因此不会在系统的使用上遇到太大问题。同时系统将提供《操作手册》和《用户手册》指导用户操作和使用,因此,系统在使用方面是完全可行的。
- 软件需求说明书注意要点:
需求说明书要符合以下原则。
1.明确性:需求叙述的读者应只能从其得到唯一的解释说明,同样,一个需求的多个读者也应达成共识。每写一个需求都应简洁、简单、直观地采用用户熟知的语言,每个需求必须精确描述要交付的功能。
2.可行性:在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性,在需求分析阶段应该有一个开发人员参与,在抽象阶段应该有市场人员参与。
3.必要性:每个需求应载明什么是客户确实需要的,每个需求都有原始出处。
4.完整性:不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。
5.一致性:一致性需求就是不要与其他系统发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎,如果只审定修改的部分,没有审定于修改相关的部分,就可能导致不一致性。
发表评论