Trufun
规范软件开发过程 优化软件开发流程
保证软件开发质量 提高软件开发效率
西安楚凡科技有限公司(Trufun)是全球领先的软件开发行业应用生命周期管理(ALM)和CASE工具解决方案提供商,倡导”实用、简洁“的产品理念,为企业实现产品开发与服务支持间的规范化应用平台,在管理软件研发全过程的同时,支持当前各种规范标准,实现企业的战略目标。
word文档模板下载地址:
http://trufun.net/UML/2016/0629/163.html
1. 范围
1.1. 标识
1.2. 系统概述
1.3. 文档概述
2. 引用文档
3. 需求
3.1. 要求的状态和方式
如果要求CSCI在多种状态或方式下运行,并且不同的状态或方式具有不同的需求,则应标识和定义每一状态和方式。状态和方式的例子包括:空闲、就绪、活动、事后分析、训练、降级、紧急情况、后备、战时、平时等。可以仅用状态描述CSCI,也可以仅用方式、用方式中的状态、状态中的方式、或其他有效的方式描述CSCI。如果不需要多种状态和方式,应如实陈述,而不需要进行人为的区分;如果需要多种状态和/或方式,应使本规格说明中的每个需求或每组需求与这些状态和方式相对应,对应关系可以在本条或本条引用的附录中,通过表格或其他方式加以指明,也可以在该需求出现的章条中加以说明。
3.2. CSCI能力需求
为详细说明与CSCI各个能力相关的需求,本条可以分为若干字条。“CSCI能力需求”中的“能力”为一组相关需求,可用“功能”、“主题”、“对象”、或其他适合表示需求的词替代。
3.2.1. X(CSCI能力)
本条应标识必需的每一CSCI能力,并详细说明与该能力有关的需求。如果该能力可以更清晰地分解为若干子能力,则应分条对自能力进行说明。需求应详细说明所需的CSCI行为,包括适用的参数,如响应时间、吞吐时间、其他时限约束、时序、精度、容量、优先级别、连续运行需求和基本运行条件下允许的偏差;适当时,需求还应包括在异常条件、非许可条件或超限条件下所需的行为,错误处理需求和任何为保证在紧急时刻运行的连续性而引入到CSCI中的规定。在确定与CSCI所接收的输入和CSCI所产生的输出有关的需求时,应考虑在3.3.x给出的要考虑的主题列表。
3.3. CSCI外部接口需求
本条可分为若干个小条来规定关于CSCI的外部接口的需求(若有)。本条可引用一个或多个接口需求规格说明(IRS)或包含这些需求的其它文档。
3.3.1. 接口标识和接口图
本条应标识所需要的CSCI外部接口(即,与涉及共享、提供或交换数据的其他实体的关系)。每一个接口的标识应包括项目唯一的标识符,(若适用)应通过名称、编 、版本、应用文档来指明接口实体(系统、配置项、用户等)。该标识应声明哪些实体具有固定的接口特性(要给出这些接口实体的接口需求);说明那些实体正在开发或修改之中(这些实体已有各自的接口需求)。应该通过一张或多张接口图来描述这些接口。
3.3.2. X(接口的项目唯一的标识符)
3.4. CSCI内部接口需求
3.5. CSCI内部数据需求
3.6. 适应性需求
本条应描述关于CSCI将提供的与安装有关的数据(如场地的经纬度或场地所在地的赋税代码)的需求(若有),应指定对要求CSCI使用的运行参数(如指明与运动有关的目标常数或数据记录的参数)的需求,这些运行参数可以根据运行需要而改变。
3.7. 安全性需求
本条应描述关于防止或尽可能降低对人员、财产和物理环境产生意外危险的CSCI需求(若有)。例子包括:CSCI必须提供的安全错误,以便防止意外动作(例如意外地发出一个“自动关闭导航”命令)和无动作(例如发出“自动导航关闭”命令失败)。本条还应包括关于系统的核部件的CSCI需求(若有),若适用应包括预防意外爆炸以及与核安全规则保持一致等方面的需求。
3.8. 保密性需求
本条应描述与维护保密性有关的CSCI需求(若有)。(若适用)这些需求应包括:CSCI必须在其中运行的保密性环境、所提供的表迷行的类型和级别、CSCI必须经受的保密性风险、减少此类风险所需的安全措施、必须遵循的保密性政策、CSCI必须具备的保密性责任、保密性认证/认可必须满足的准则等。
3.9. CSCI环境需求
本条应描述CSCI的运行环境需求(若有)。如在其上运行CSCI的计算机硬件和操作系统。(对计算机资源的其他需求见3.10)。
3.10. 计算机资源需求
3.10.1. 计算机硬件需求
本条应描述针对本CSCI必须使用的计算机硬件的需求(若有)。(若适合)这些需求应包括:各类设备的数量;处理剂、存储器、输入/输出设备、辅助存储器、通信/ 络设备及所需其他设备的类型、大小、容量和其他所需的特征。
3.10.2. 计算机硬件资源使用需求
本条应描述本CSCI的计算机硬件资源使用需求(若有),例如:最大允许利用的处理机能力、存储容量、输入/输出设备的能力、辅助存储设备容量和通信/ 络设备的能力。这些需求(例如陈述为每一个计算机硬件资源能力的百分比)应包括测量资源使用时所处的条件(若有)。
3.10.3. 计算机软件需求
本条应描述本CSCI必须使用或必须被并入本CSCI的计算机软件的需求(若有)。例子包括:操作系统、数据库管理系统、通信/ 络软件、实用软件、输入和设备仿真软件、测试软件、制造软件。要列出每一个这样的软件项的正确名称、版本和参考文档。
3.10.4. 计算机通信需求
本条应描述本CSCI必须使用的计算机通信方面的需求(若有)。例子包括:要连接的地理位置;配置和 络拓扑;传输技术;数据传送速率; 关;要求的系统使用时间;被传送/接收的数据的类型和容量;传送/接收/响应的时间限制;数据量的峰值;以及诊断特性。
3.11. 软件质量因素
本条应描述合同(或软件研制任务书)规定的或由较高一级规格说明派生出的软件质量因素方面的CSCI需求(若有)。例子包括有关CSCI功能性、可靠性、易用性、效率、维护性、可移植性和其他属性的定量要求。
3.12. 设计和实现约束
本条应描述约束CSCI的设计和实现的那些需求(若有)。这些需求可引用相应的商用或军用标准来规范和指定。例子包括关于以下各方面的需求:
a. 使用一个特定的CSCI体系结构,或针对体系结构的要求,例如所要求的数据库或其他软件单元;使用标准的或现有的部件;或使用由政府/需方提供的资源(设备、信息或软件);
b. 使用特定的设计或实现标准;使用特定的数据标准;使用特定的编程语言;
c. 为支持在技术、威胁或实名方面预期的增长或变化,必须提供的灵活性和可扩展性。
3.13. 人员需求
本条应描述与其使用或者支持本CSCI的人员有关的CSCI需求(若有),包括人员的数量、技术水平、责任期限、培训要求或其他信息、例子包括要求允许多少用户同时工作,以及嵌入的帮助和培训等方面的需求;还应包括施加于CSCI的人素工程需求(若有)。(适用时)这些需求应包括对人的能力和局限性的考虑,在正常和极端条件下可预见的人为错误,以及人为错误影响特别严重的那些特定场合。例子包括对出错消息的颜色和持续时间的要求、对关键指示器或按钮的物理位置的要求、以及对听觉信 的使用要求。
3.14. 培训需求
本条应描述与培训有关的CSCI需求(若有)。
3.15. 软件保障需求
本条应描述与软件保障考虑有关的CSCI需求(若有)。这些考虑可以包括:对系统维护、软件保障、系统运输方式、补给系统的要求、对现有设施的影响和对现有设备的影响。
3.16. 其他需求
本条应描述上述各条未能覆盖的其他CSCI需求(若有)。
3.17. 验收、交付和包装(修改有关内容)
本条应描述为了交付而对CSCI进行波安装、加标记和处理(例如用8道磁带提交,该磁带以确定的方式加以包装并贴上标签)的需求(若有)。(若适用)可引用适当的标准。
3.18. 需求的优先顺序和关键程度
4. 合格性规定
本条应描述所定义的合格性方法,并为第3章中的每个需求指定为确保需求得到满足所要使用的方法。可用表格形式表述该信息,或为第3章中的每个需求注明所使用的方法。合格性方法可以包括:
a. 演示:不需要使用仪器、专用测试设备或进行事后分析,而是依靠可见的功能操作,直接运行本CSCI或本CSCI的一部分。
b. 测试:使用仪器或其他专用测试设备,运行本CSCI或本CSCI的一部分,采集数据供事后分析使用。
c. 分析:处理从其他合格性方法获得的累积数据。例如,对测试结果进行约简、解释或推断。
d. 审查:对CSCI代码、文档进行目视检查。
e. 特殊的合格性方法:任何针对CSCI的特殊合格性方法,例如专用工具、技术、规程、设施、验收限制。
5. 需求可追踪性
本章应描述:
a. 从本规格说明中的每一个CSCI需求,到所涉及的系统(或子系统,若合适)需求的可追踪性(也可以通过对第3章中的每一个需求进行注释来提供可追踪性)。
注:每一个曾粗的系统细化都可能导致需求不能直接被追踪到较高层次。例如:一个系统体系结构设计建立了多个CSCI,可能导出关于这些CSCI如何接口的需求,而这些接口需求在系统需求中并没有被涵盖。这样的需求可以被追踪到类似于“系统实现”这样的一般需求,或被追踪到导致它们产生的系统设计决策。
b. 从已分配给本CSCI的每一个系统需求(或子系统需求,若合适),到所涉及的CSCI需求的可追踪性。分配给本CSCI的全部系统/子系统需求都应加以说明。追踪到包含在IRS的CSCI需求时,可引用那些IRS。
6. 注释
本章应包括有助于了解文档的所有信息(例如:背景、术语、缩略语或公式)。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!
a. 使用一个特定的CSCI体系结构,或针对体系结构的要求,例如所要求的数据库或其他软件单元;使用标准的或现有的部件;或使用由政府/需方提供的资源(设备、信息或软件);
b. 使用特定的设计或实现标准;使用特定的数据标准;使用特定的编程语言;
c. 为支持在技术、威胁或实名方面预期的增长或变化,必须提供的灵活性和可扩展性。
a. 演示:不需要使用仪器、专用测试设备或进行事后分析,而是依靠可见的功能操作,直接运行本CSCI或本CSCI的一部分。
b. 测试:使用仪器或其他专用测试设备,运行本CSCI或本CSCI的一部分,采集数据供事后分析使用。
c. 分析:处理从其他合格性方法获得的累积数据。例如,对测试结果进行约简、解释或推断。
d. 审查:对CSCI代码、文档进行目视检查。
e. 特殊的合格性方法:任何针对CSCI的特殊合格性方法,例如专用工具、技术、规程、设施、验收限制。
a. 从本规格说明中的每一个CSCI需求,到所涉及的系统(或子系统,若合适)需求的可追踪性(也可以通过对第3章中的每一个需求进行注释来提供可追踪性)。
注:每一个曾粗的系统细化都可能导致需求不能直接被追踪到较高层次。例如:一个系统体系结构设计建立了多个CSCI,可能导出关于这些CSCI如何接口的需求,而这些接口需求在系统需求中并没有被涵盖。这样的需求可以被追踪到类似于“系统实现”这样的一般需求,或被追踪到导致它们产生的系统设计决策。
b. 从已分配给本CSCI的每一个系统需求(或子系统需求,若合适),到所涉及的CSCI需求的可追踪性。分配给本CSCI的全部系统/子系统需求都应加以说明。追踪到包含在IRS的CSCI需求时,可引用那些IRS。
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!