软件需求规范

软件需求规范（SRS）

[编辑]

软件需求规范是需求分析阶段的最终结果，并且是软件开发中的重要文档之一. 软件需求规范是作为需求分析的一部分而开发的可交付文档. 该描述扩展了软件计划中确定的软件范围，以开发完整的信息描述，详细的功能描述，适当的检查标准和其他要求. 相关数据.

[编辑]

软件要求手册中包含的内容和写作参考格式如下:

I. 概述

第二，数据描述

端口数据流程图

嘴巴数据字典

端口系统接口说明

内部界面

三，功能说明

端口功能

端口处理说明

口型设计上的限制

四，性能说明

端口性能参数

口试的类型

预期的软件响应

应考虑的特殊问题

五，参考名单

VI. 附录

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

数据描述是软件系统必须解决的问题的详细描述.

功能描述描述了解决用户问题所需的每个功能的过程细节. 对于每个功能，应给出功能说明，处理说明以及设计中要考虑的限制.

在性能描述中，说明系统应达到的性能以及应满足的约束条件，检测方法和标准，预期的软件响应以及可能需要考虑的特殊问题.

参考目录应包括与该软件相关的所有参考，包括以前的其他文档，技术参考，产品目录手册和标准.

附录中包含一些补充材料，例如列表数据，算法的详细说明，框图，图表和其他材料.

软件需求规范是分析任务的最终产品. 通过建立完整的信息描述，详细的功能和行为描述，性能要求和设计约束以及适当的接受标准，可以给出目标软件的各种要求.

[编辑]

软件需求手册主要具有以下三个功能:

作为用户和软件人员之间的通用文件，为双方之间的相互理解提供了基础.

The

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

端口是接受的基础，即选择测试用例和进行正式验证的基础.

软件需求规范是软件生命周期中的重要文件. 它为尚未在开发初期诞生的软件系统建立了可见的逻辑模型. 这是确保系统质量并且可以保证的有力措施. 进行开发工作. 因此，应建立并保证其质量.

作为设计依据和接受依据，需求规范应准确无误. 需求规格说明越精确，将来发生错误，混乱和重复的可能性就越小. 用户可以理解需求规范，发现并指出错误是确保软件系统质量的关键. 因此，需求规范必须简明易懂，并且不要包含计算机概念和术语，以便用户和软件人员都可以接受.

由于企业组织中各个部门的用户可能提出冲突的要求，因此在分析阶段必须协调并解决这些冲突. 因此，需求规范中的表达应保持一致，并且不会出现冲突的用户需求.

在软件生命周期中，发现的软件错误越早，纠正的成本越低. 因此，在编写需求规范后，应组织用户和一些专家对其进行反复检查和审查，并尽早发现错误并及时进行纠正，以免在系统使用时付出高昂的代价. 稍后更正错误.

[编辑]

　　某软件的需求说明书
　　一.引言
　　软硬件系统基本支持：系统的运行平台是PC机。本系统拟采用××[[技术开发]]，一期开发实现单机模式，选择CJHJ为开发语言。
　　二、主要目标
　　所开发的软件要能实现以下要求。
　　1．日期和时间：实现多种日历表，如农历表。
　　2．日程事务提醒。办公日程提醒：如会议、出差、上课、课间休息；生活琐事提醒：如就餐时间、体育锻炼。
　　3．提醒方案：实现多种提醒设定选项，比如每日、每周循环提醒。
　　4．提醒方式：以[[娱乐]]提醒方式为主(可以是音频或视频片断)，比如学习工作中休息时刻到时就播放范晓萱的《健康歌》。
　　三、对现有系统的分析
　　现有系统是指当前实际使用的系统，这个系统可能是计算机系统，也可能是个[[机械系统]]甚至是一个人工系统。对现有系统进行分析的目的是进一步阐明建议中的
开发新系统或修改现有系统必要性。
　　现有系统主要功能过于简单，主要包括、日程表、[[文档管理]]、闹钟等，不能满足对于各种提醒方案和各种提醒方式的要求。
　　四、所建议的系统
　　(一)闹钟，用于提醒各种事务，包括用餐、休息等
　　日期和时间：实现多种日历表，如农历表；根据已经成熟的日期换算算法直接得到结果。
　　(二)日程事务提醒
　　根据用户设定的某个时间的具体事务，当时间到达时，将用闹钟或是语音的方式提醒用户。
　　提供日程安排提醒功能。使用了一个比较有效的事务处理模型，即紧急、重要事务处理模型。事务按照紧急性和重要性排在二维坐标上，那么通知的时候会按照图示
的模型提醒，保证用户的工作最高效。
　　五、[[投资]]及[[效益分析]]
　　(一)[[支出]]
　　一次性支出：系统开发阶段所需经费主要为书籍资料费，由开发团队自行准备，总额不超过XX元。
　　非一次性支出：开发团队日常生活费用自理。
　　(二)[[收益]]
　　本系统属于非营利性的系统，不存在收益评估问题，但建议开发团队确实能充分利用现有资源，适当减少[[投资]]。
　　六、[[可行性分析]]
　　1．法律方面的可行性。该软件没有侵犯任何的个人或是团体，也不违反任何的相关法律。
　　2．技术的可行性。在技术上不存在困难，完全可以达到。
　　3．时间的可行性。预定期限为四个月，可以完成。
　　4．用户使用方面的可行性。本系统的主要用户为办公人员，对于基本的电脑使用和操作不会陌生。因此不会在系统的使用上遇到太大问题。同时系统将提供《操作手册》
和《用户手册》指导用户操作和使用，因此，系统在使用方面是完全可行的。

软件要求手册中的注意事项:

需求规范应满足以下原则.

1. 清晰度: 需求叙述的读者只能从中得到一个解释. 同样，需求的多个读者也应达成共识. 每个要求都应以用户熟悉的语言简洁明了，简单明了. 每个要求都必须准确描述要交付的功能.

2. 可行性: 必须以已知的能力，有限的系统及其环境实现所有要求. 为了避免需求的不可行，应该在需求分析阶段介入开发人员，而在抽象阶段介入市场人员.

3. 必要性: 每个需求都应指定客户的真正需求需求规格说明书的作用，并且每个需求都有原始来源.

4. 完整性: 不应忽略要求和必要信息. 诚信也是一项要求.

5. 一致性: 一致性要求不得与其他系统冲突. 在开始开发之前，必须解决需求差异. 只有经过调查，我们才能确定哪些是正确的. 修订要求时必须小心. 如果仅批准了修订部分需求规格说明书的作用，而未批准相关部分，则可能导致不一致.

[编辑]

↑朱爱民，柯建勋. PowerBuilder 9.0和系统开发. 清华大学出版社，第一版，2003年11月. 陈建中，吕波. 营销营销文案写作指南. 中国经济出版社，2011.03. <

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-279567-1.html