技术文件-软件项目技术需求(模板).docxVIP

技术文件-软件项目技术需求(模板)??摘要：技术需求1. Objectives 目标阐明需求说明书的标准格式，做为合同和需求分析的结果。2. Scope 范围2.1 适用于指导需求说明书的编写。2.2 本模板力图覆盖所有可能在需求说明书中出现的主题。这样做的目的是并不是要求每一个需求说明书都要包括这里定义的全部章节，而是提供一个所有需求说明书都应当遵循的框架。一些特殊的章节应当提供但不要求有详细的说明，只需在说明书中包含下面有适当文字说明的标题即可，例如，不适用。3. References 参考4. Outstanding Issues 尚存主要问题5. Approvals 批准销售主管6. Responsibilities 职责客户经理有责任确认本模板被切实执行。7. Template 模板7.1 Lead-in sections 引导部分7.1.1 以下是需求说明书的起始部分。在文档格式规范中有关于它们的更详细的描述。1）Objectives目标2）Scope范围3）References参考4）Assumptions前题条件5）Outstanding Issues尚存主要问题6）Document Control文档控制 7）Approvals批准8）Distribution分发9）Amendment Record更改记录 10）Traceability可追溯7.2 Component or System Description 部件或系统描述7.2.1 本说明书所覆盖的部件或系统的简要介绍。本部分可以很简要，因为它仅包含帮助读者快速了解所说明内容的信息。7.2.2 应当提供一个上下文相关图来帮助确定被描述的部件或系统的定位。使用USER-CASE图来描述。7.2.3 参考应当做成关联文档（例如建议，合同，项目编号）。7.3 Purchaser Requirements 客户需求7.3.1 Summary 概要7.3.1.1 本部分应当包括那些直接影响到客户使用本部件或系统的需求。它分为两个部分，功能和特性。l 部件或系统的功能描述了什么可以做，例如，打印一个报表。l 部件或系统的特性提供了那些可以描述和评价系统质量的属性。7.3.1.2 每个段落（或段落组）应当包含一个参考来跟踪需求的出处。每个句子或段落应当编号；无论何种情况每个编号的项目仅应当定义一个需求。7.3.1.3 每个段落（或段落组）应当指出它的重要程度，按以下方式分类：1）强制的：最基本的特征；没有它产品将不可用。2）必需的：单独的非基本的特征，但是它们加在一起会影响产品的能力。3）期待的：最好能有的特征；一个或多个这些特征被忽略也不会影响产品的能力。7.3.2 Purchaser-Related Functionality 客户要求的功能7.3.2.1 Application Functionality 应用程序的功能7.3.2.1.1 在系统或子系统一级，这一部分应当包含可用的应用程序所提供的功能的描述。7.3.2.1.2 在应用程序一级，这一部分细化应用程序必须做到的功能。7.3.2.1.3 功能应当用结构化的英语或适当的形式化的方法学来描述。7.3.2.2 Human Interface 人机界面7.3.2.2.1 这一部分应当定义所需的菜单结构，屏幕/窗口设计，报表设计和其它操作/或管理界面。在这一过程中，需求可能广泛地涉及已有的标准或产品。7.3.2.2.2 参考应当指向其它的说明书和标准。7.3.2.3 Data Types 数据类型这一部分应当包括对系统或应用程序中对用户有用的所有数据类型的描述，包括应用程序开发工具用到的或表单，显示，报表和输出用到的。7.3.2.4 Control Structures 控制结构这一部分应当描述系统或应用程序的控制结构。7.3.2.5 Application Development Environment 应用开发环境这部分应当指定可供用户用来开发应用程序的系统部件。它应当至少包含数据类型和语言或者可用的应用程序生成器。7.3.2.6 Hardware 硬件这部分应当详细说明根据用户需要提出的硬件需求。7.3.2.7 Software 软件本节将详细说明因为用户需要所产生的软件需求。如果用户已经提供了面向系统或部件或与系统或部件合为一体的产品，那么这些应当在需求和所有设想以及需求文档中清晰的定义出来。这些需求可能包括下列各项：1） Operating System 操作系统2） Database 数据库3） Communications 通信4） Interfaces 接口7.3.3 Purchaser-Related Characteristics 客户相关的特征在多数情况下，用户会指定一些如下的特性。如果