7第四章_1软件需求说明书的编写.pptVIP

四、 软件需求说明书示例 从第四章的《科技进步先进个人申报管理系统可行性研究报告》出发，编写《科技进步先进个人申报管理系统需求说明书》如下： 科技进步先进个人申报管理系统需求说明书 本说明书是系统客户和开发者对将要开发的软件系统的共同理解，是后续设计和实现工作 的基础。 本说明书由以下表格组成： 作业（小组完成、电子版） 教材P145 三选一： 撰写需求规格说明书 在需求说明书中是否使用形式化方法要依据下列因素： ①程序规模和复杂性。 ②客户合同中是否要求使用。 ③需求说明书是否是一个合同工具或仅仅是一个内部文件。 ④需求说明书文件是否成为设计文件的根据。 ⑤具有支持这种方法的计算机设备。 1．形式化说明方法 软件产品生产中有多种生产工具。比如，计算机的字处理器就是非常有用的生产辅助工具。一个需求说明书通常有若干作者，可能经历若干版本，并且要进行多次重新组织子文档名称，因此使用生产工具是必要的。 2．生产工具 在需求说明书中有许多词汇，特别是许多名词和动词，专门涉及到系统的实体和许多活动，所以需求说明书需要若干表达工具。 此外，可以使用若干种形式化方法，以便允许自动处理需求说明书子文档名称；可以用一些表格或图示法来显示需求。 用详细分层体系自动检查需求说明书的需求，这里每一个分层自身是完全的，但是也可以扩展为下一层或是上一层的一个组成成分。 3．表达工具 需求说明书的基本点是它必须说明由软件获得的结果，而不是获得这些结果的手段。编写需求说明书必须描述的基本问题是： ①功能——所设计的软件要做什么。 ②性能——是指软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等。 ③强加于实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、操作环境等方面所要求的标准。 ④属性——可移植性、正确性、可维护性及安全性等方面的考虑因素。 ⑤外部接口——与人、硬件、其他软件和其他硬件的相互关系。编写需求说明书应当避免把设计或项目需求写入需求说明书之中，应当对说明需求设计约束与规划设计两者有清晰的区别。 2.5 在表达需求时应注意的问题 1．避免在需求说明书中嵌入设计 2．避免在需求说明书中嵌入一些项目要求 在表达需求时应注意的问题 在需求说明书中嵌入设计说明，会过多地约束软件设计，并且人为地把具有潜在危险的需 求放人需求说明书中。 需求说明书必须描述在什么数据上、为谁完成什么功能，在什么地方产生什么结果。需求说明书应把注意力集中在要完成的服务目标上。通常不指定如下的设计项目： ①把软件划分成若干模块。 ②给每一个模块分配功能。 ③描述模块间的信息流程或者控制流程。 ④选择数据结构。 1．避免在需求说明书中嵌入设计 把设计完全同需求说明书隔离开来始终是不现实的。安全和保密方面的周密考虑可能增加一些直接反映设计约束的需求。例如： ①在一些分散的模块中保持某些功能。 ②允许在程序的某些区域之间进行有限的通信。 ③计算临界值的检查和。 通常应考虑到，若要为软件选择高层次的设计，就可能需要大量的资源(可能占整个产品 开发成本的10％~20％以上)。有两种选择： ①在需求说明书中描述了设计。这意味着，或者将一个潜在不适当的设计作为一个需求进行描述或者在需求阶段花费了过多的时间。②用模型设计描述需求，这种模型设计只用于辅助描述需求，而不使之成为实际的设计。 cont. 避免在需求说明书中嵌入设计 需求说明书应当是描写一个软件产品，而不是描述生产软件产品的过程。项目要求表达客户和开发者之间对于软件生产方面合同性事宜的理解(因此不应当包括在需求说明书中)，例如，成本、交货进度、报表处理、软件开发方法、质量保证、确认和验证 的标准、验收过程。 项目需求在另外的文件中描述。在需求说明书中提供的只是关于软件产品本身的需求。 2．避免在需求说明书中嵌入项目要求 软件产品的开发过程中，在项目的开始阶段不可能详细说明某些细节，在开发过程中可能发现需求说明书的缺陷、缺点和错误等，所以可能要对需求说明书进行改进。 在需求说明书的改进中，应注意如下事项： ①尽管可以预见校正版本的开发以后不可避免，但对需求还必须尽可能完全、清楚地描述。 ②一旦最初识别出项目的变化，应引入一个正式的改变规程来标识、控制、追踪和报告项目的改变。 3．需求说明书的改进问题 软件开发的过程是从开发者和客户双方同意开发什么样的软件协议开始的。这种协议要使用需求说明书的形式，应该由双方联合起草。这是因为： 其一，客户通常对软