《技术文件软件项目技术需求.docx》由会员分享，可在线阅读，更多相关《技术文件软件项目技术需求.docx（7页珍藏版）》请在三一办公上搜索。
1、技术文件软件项目技术需求技术文件-软件项目技术需求(模板) 摘要： 技术需求 1. Objectives 目标 阐明需求说明书的标准格式，做为合同和需求分析的结果。 2. Scope 范围 2.1 适用于指导需求说明书的编写。 2.2 本模板力图覆盖所有可能在需求说明书中出现的主题。 这样做的目的是并不是要求每一个需求说明书都要包括这里定义的全部章节，而是提供一个所有需求说明书都应当遵循的框架。一些 特殊的章节应当提供但不要求有详细的说明，只需在说明书中包含下面有适当文字说明的标题即可，例如，不适用。 3. References 参考 4. Outstanding Issues 尚存主要问题
2、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 Rec
3、ord更改记录 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 本部分应当包括那些直接影响到客户使用本部件或系统的需求。它分为两个部分，功能和特性。
4、l 部件或系统的功能描述了什么可以做，例如，打印一个报表。 l 部件或系统的特性提供了那些可以描述和评价系统质量的属性。 7.3.1.2 每个段落应当包含一个参考来跟踪需求的出处。每个句子或段落应当编号；无论何种情况每个编号的项目仅应 当定义一个需求。 7.3.1.3 每个段落应当指出它的重要程度，按以下方式分类： 1）强制的：最基本的特征；没有它产品将不可用。 2）必需的：单独的非基本的特征，但是它们加在一起会影响产品的能力。 3）期待的：最好能有的特征；一个或多个这些特征被忽略也不会影响产品的能力。 7.3.2 Purchaser-Related Functionality 客户要求的功能
5、 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.
6、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 Softwa
7、re 软件 本节将详细说明因为用户需要所产生的软件需求。如果用户已经提供了面向系统或部件或与系统或部件合为一体的产品，那么这些应 当在需求和所有设想以及需求文档中清晰的定义出来。这些需求可能包括下列各项： 1） Operating System 操作系统 2） Database 数据库 3） Communications 通信 4） Interfaces 接口 7.3.3 Purchaser-Related Characteristics 客户相关的特征 在多数情况下，用户会指定一些如下的特性。如果它们能够增强系统的能力则应当被包含进来，另一种选择是在最开始的时候就对某 些特性进行限定以避免验
8、收测试时无休止的争论。如果一些特性没有在本部分被指定，它们应当在公司需求部分被指定，举例来说很 多特性关系到系统投入使用后公司的技术支持成本。 7.3.3.1 Pre-operational 运行之前 7.3.3.1.1 Packaging 包装 7.3.3.1.2 Installation 安装 7.3.3.1.3 Configuration 配置 7.3.3.2 Functionality 功能 7.3.3.2.1 Suitability 适用性 7.3.3.2.2 Accuracy 精确性 7.3.3.2.3 Interoperability 协同工作能力 7.3.3.2.4 Compl
9、iance standards 遵循标准 7.3.3.2.5 Security 安全性 7.3.3.3 Reliability 可靠性 7.3.3.3.1 Maturity 完备性 7.3.3.3.2 Fault tolerance 容错能力 7.3.3.3.3 Recoverability 可恢复能力 7.3.3.4 Usability 可用性 7.3.3.4.1 Understandability 易懂 7.3.3.4.2 Learnability 易学 7.3.3.4.3 Operability 可操作能力 7.3.3.5 Efficiency 效率 7.3.3.5.1 Time beh
10、aviour 时间特性 7.3.3.5.2 Resource behaviour 资源特性 7.3.3.6 Maintainability 可维护性 7.3.3.6.1 Analyzability 易于分析 7.3.3.6.2 Changeabilty 可变性 7.3.3.6.3 Stability 稳定性 7.3.3.6.4 Testability 易测性 7.3.3.7 Portability 轻便 7.3.3.7.1 Adaptability 适应性 7.3.3.7.2 Installability 易安装 7.3.3.7.3 Conformance 一致性 7.3.3.7.4 Repl
11、aceability 可替换 7.3.3.8 Documentation 文件 本部分应当详细说明系统或部件必须为用户提供的文档。 7.4 Company Requirements 公司需求 1） 本部分定义那些必须确认的与用户需要有冲突的系统或部件需求。所有的冲突都必须被解决，或者得到用户的让步或者满足前述 的用户需要。 2） 说明书中哪些是分布在公司以外的，这部分可以省略或放在一个单独的文档中。 7.4.1 Business Requirements 商业需求 7.4.1.1 Cost 开销 7.4.1.1.1 这部分应当论述与指定系统相关的开销。它可以通过参考项目详细计划来得出一个合计值
12、放在这里。 7.4.1.1.2 这些开销应当包括所有开发费用和可能的项目支持费用。如果可能这部分还应当论述弹性的开销，以及所有削减的开销， 离开这些开发将会因为没有有效的费用来完成系统而停止。 7.4.1.2 Make/Buy 制作/购买 本部分应当讨论确定是否这个系统或部件比起开发更适于买入或再开发的标准。例如日常应用程序，缺乏经验， 缺乏资源等等。 7.4.1.3 Relationship to future products 与将来产品的关系 本部分应当覆盖基于系统或部件所涉及的与尚未开发的其它产品的关系的需求。例如确认与将来产品和系统的兼容性。 7.4.1.4 Scheduled sh
13、ip date 预定出货日期 本部分应当讨论项目出货日期，包括任何按计划进行的临时发布或阶段出货。本部分还应当描述与这些出货日期相关的约束和依赖关 系。 7.4.1.5 Support considerations 支持考虑 本部分应当讨论系统或部件可能需要的任何特殊的或不常用的支持考虑，例如首先应当安装一个UNIX系统。 7.4.2 Company Hardware Requirements 公司硬件需求 7.4.2.1 Hardware Functionality 硬件功能 本部分应当覆盖公司明显需要的，但对用户来说是不可见的或无关的硬件功能。例如支持多操作系统所需的硬件功能，或必须支持以
14、 太网等。 7.4.2.2 Hardware Characteristics 硬件特性 本部分应当覆盖公司明显需要的，但对用户来说是不可见的或无关的硬件特性。至少应当包括硬件诊断所需要的。 7.4.3 Company Software Requirements公司软件需求 7.4.3.1 Software Functionality 软件功能 本部分应当覆盖公司所需的，但对用户来说是无关的或不需要的软件性能。例如，数据库，操作系统，通讯，诊断。 7.4.3.2 Software Characteristics 软件特性 本部分应当覆盖公司明显需要的，但是对用户来说是不可见或无关的软件特性例如代码的可复用性，包装等。 7.5 Architecture Overview 结构概述 高层设计或结构的概述。仅在用户需要一个特殊的系统结构例如客户-服务器，或者用户把定义部分或全部的系统结构作为合同的一 部分时才应包括进来。 7.6 Acceptance Criteria 验收标准 7.6.1 本部分应当详述验收标准的要点以做为需求确定后进行确认验收计划的基础。 7.6.2 需求与一些具体的合同有关的部分，可以直接写相应合同中验收标准的一个引用。 7.7 Glossary 术语表
