软件需求说明书

软件需求说明书(SRS,Software Requirements Specification)

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

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

　　一、概述

　　二、数据描述

　　口数据流图

　　口数据字典

　　口系统接口说明

　　口内部接口

　　三、功能描述

　　口功能

　　口处理说明

　　口设计的限制

　　四、性能描述

　　口性能参数

　　口测试种类

　　口预期的软件响应

　　口应考虑的特殊问题

　　五、参考文献目录

　　六、附录

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　某软件的需求说明书

　　一.引言

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

　　二、主要目标

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

　　1．日期和时间：实现多种日历表，如农历表。

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

　　3．提醒方案：实现多种提醒设定选项，比如每日、每周循环提醒。

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

　　三、对现有系统的分析

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

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

　　四、所建议的系统

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

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

　　(二)日程事务提醒

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

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

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

　　(一)[[支出]]

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

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

　　(二)[[收益]]

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

　　六、[[可行性分析]]

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

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

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

　　4．用户使用方面的可行性。本系统的主要用户为办公人员，对于基本的电脑使用和操作不会陌生。因此不会在系统的使用上遇到太大问题。同时系统将提供《操作手册》
和《用户手册》指导用户操作和使用，因此，系统在使用方面是完全可行的。

　　软件需求说明书注意要点：

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

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

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

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

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

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