软件文档的评审和签署规范
一、目的
在软件开发的每个阶段，对该阶段所形成的文档进行评审，尽早发现问题，并及时采取措施予以解决，确保文档的内容准确，为软件产品的质量提供保障。文档的签署是为了体现文档的合法性、有效性、法规性。
二、规定
1．文档评审的重点是需求说明和设计说明的评审，见附录一。
2．需求评审需要进一步确认用户要求什么，及用户从开发者一方了解某些限制和约束。用户代表必须参与此项评审活动，以得到双方认可的需求文档。3．设计评审主要进行概要设计评审和详细设计评审。概要设计评审主要详细评审每个系统组成部分的基本设计方法和测试计划；详细设计评审主要评审程序和程序单元测试计划。
4．所有评审会议必须形成会议记录（备忘录）和评审报告。
5．涉及到文档的更改按文档的更改要求执行。
6．评审的内容还可以包括：编排方式、技术准确度、完整性、对读者的适合性、表达上的正确性、格式的规范性等。
7．评审一般采用评审会的方式进行。
8．软件文档都应进行签署，签署的一般顺序为编制→审核→会签→标准化→批准的顺序进行。其中会签仅在必要时进行。
9．签署不允许代签，且修改单的签署与被修改的文档签署要一致。
10．编制、审核、会签、标准化、批准等人员见附录二。
三、程序
评审
1．由主管领导、用户代表（必要时）、开发小组成员、项目管理人员、标准化人员等组成评审小组，必要时邀请外单位专家参加。
2．开会前，由主管领导确定评审的具体内容，并将材料发给评审小组成员。3．评审小组成员准备。
4．主管领导主持会议，根据评审条目由评审小组成员评议、评审。
5．评审小组得出评审结论，形成评审报告，评审小组成员应在评审报告上签字。
签署
（无）
四、相关记录
评审报告
会议纪要（记录）
五、相关文档
（无）
附录一各评审点评审内容
附录二软件文档签署者一览表
编制：审核：批准：附录一各评审点评审内容
.
受理号：0010600120190386 境内第二类医疗器械注册 技术审评报告 产品名称：全自动多重免疫分析仪 产品管理类别：第二类 申请人：珠海丽珠试剂股份有限公司 广东省药品监督管理局审评认证中心
目录 基本信息 (3) 一、申请人名称 (3) 二、申请人住所 (3) 三、生产地址 (3) 产品审评摘要 (4) 一、产品概述 (4) 二、临床前研究摘要 (5) 三、临床评价摘要 (10) 四、风险分析及说明书提示 (11) 综合评价意见 (14)
基本信息一、申请人名称 珠海丽珠试剂股份有限公司 二、申请人住所 珠海市香洲区同昌路266号 三、生产地址 珠海市香洲区同昌路266号
产品审评摘要 一、产品概述 （一）产品结构及组成 全自动多重免疫分析仪主要由判读模块、孵育模块、洗涤模块、机械臂模块、稀释制冷液与洗针模块、标本架模块、反应孔运送模块、试剂管理模块、移卡模块、旋转臂模块、平铺振荡模块、称重模块、软件组成。 （二）型号规格 MCLIA-800 （三）适用范围 MCLIA-800全自动多重免疫分析仪与本公司生产的磁条码免疫荧光试剂配套使用，用于磁条码免疫荧光试剂的定量和定性分析。 （四）工作原理 MCLIA-800全自动多重免疫分析仪是通过检测患者血清或其他样本从而对人体进行免疫分析的医学检验仪器。将样本加入到包被有多种不同免疫项目抗原、抗体的反应管中，包被抗原、抗体的载体为磁条码（即单个反应管中会有多种包被着用于检测不同免疫项目的抗原、抗体）。样本中的待测分子与载体上的抗原、抗体特异性结合。分离洗涤未反应的游离成分。接着，加入荧光标记物，分离洗涤多余的荧光
[项目名称] 软件需求说明书 编制 审核 批准 发布日期
文件更改控制记录
目录 1 前言 (5) 1.1 目的和范围 (5) 1.2 术语及缩略语 (5) 1.3 参考资料 (5) 2 系统概述 (6) 2.1 项目介绍 (6) 2.1.1 项目背景 (6) 2.1.2 项目目标 (6) 2.2 客户顾客及其他利益相关者 (6) 2.2.1 客户 (6) 2.2.2 操作者 (6) 2.3 软件安全性级别 (6) 2.4 上层输入 (6) 2.5 运行环境 (7) 3 需求条款 (7) 3.1 用户需求 (7) 3.2 界面需求 (7) 3.3 软件功能需求 (7) 3.4 性能需求 (8) 3.4.1 速度和响应时间需求 (8) 3.4.2 精度和准确性需求 (8) 3.4.3 可靠性和有效性需求 (8) 3.4.4 容量需求 (9) 3.4.5 可扩展性需求 (9) 3.5 数据需求 (9) 3.6 接口 (9) 3.7 运行和环境需求 (10) 3.8 网络安全需求 (10) 3.9 信息安全需求 (10) 3.10 产品化需求 (10) 3.11 警告与故障消除 (10) 3.12 法规与标准要求 (10) 3.13 安全和保密 (10) 3.14 维护与支持 (11) 3.15 风险控制措施 (11) 4 现成软件使用评估 (11) 5 软件确认创建要求 (11) 6 可追溯性分析 (11) 7 评审 (12) 8 附录 (12) 8.1 需求项编号规则 (12)
1前言 1.1 目的和范围 <阐明编写需求分析的目的，指明用户对象。（系统分析员、开发人员、测试人员）> 1.2 术语及缩略语 <该软件系统的相关术语及缩略语。> 1.3 参考资料 <列举出相关参考资料。>
2性能指标 2.1质量要求：软件应符合GB/T25000.51-2016中第5章的要求。 2.2外观 2.2.1软件包装应端正、表面光洁，存储介质可正常读操作。 2.2.2光盘盒表面一般应当包括以下内容： a)制造单位名称、商标； b)产品名称； c)制造日期或编号； d)软件发布版本号。 2.3性能 2.3.1安装和卸载 软件应能顺利安装和卸载。软件按使用说明书规定安装后，应能正常工作，图文应清晰，各模块应能正确进行各功能的运行。 2.3.2预约叫号候诊 a)应能按特定时间进行预约登记病历； b)应能在预约队列中选择患者、检查室，呼叫患者检查； c)应能即时反馈病人候诊情况； d)应能对预约总量、不同时间段检查量进行管理。 2.3.3病历管理 a)应能打开病历，查看患者有关信息； b)应能修改病历，更改患者有关信息； c)应能删除病历，删除患者有关信息； d)应能打印病历，打印机输出报告内容包含患者信息，图像、检查日期等信息； e)应能采用不同颜色标识病历的不同状态； f)应能对病历进行特殊标记； g)应能导出病历； h)应能恢复未彻底删除的病历，恢复患者有关信息。 2.3.4病历资料查找、统计
a)应能根据病历资料中的单个项目或组合项目为条件进行查找，如病人姓名、年龄、登 记日期等； b)应能按项目、工作量等进行统计。 2.3.5条码扫描 软件应能支持扫描条码的方式提取病人资料。 2.3.6采图、录像 a)应能对影像设备产生的图像进行动、静态采集保存； b)应能对影像设备产生的图像在显示器同步显示； c)应能对已采集图片进行复制、删除、图像说明和打印标记； d)应能对影像设备产生的图像进行录像保存； e)应能支持各种分辨率的图像的采集和录像。 2.3.7病历信息追踪 应能标识计划追踪、正在追踪、追踪完成的病历、并能输入追踪信息。 2.3.8图像查看与编辑 a)应能对图像标识部位及说明，对图像进行标注，可专门根据部位及说明来查找、浏览 相应图像； b)内置多种体位图供选择，可根据所选部位自动在体位图上定位； c)图像可选择性导出导入。 2.3.9检查报告单打印 a)应能创建各种不同的报告类型及格式，可设置为无图及多图的报告格式； b)编辑检查报告时自动提示同名病历，可以查看和复制病历检查信息； c)应能将当前图像与历史图像同屏显示对比； d)应能病理申请。 2.3.10用户权限 a)以管理员账号登录时应能添加、删除用户或修改用户的权限； b)不同的用户登录软件后应只具有相应的权限。 2.3.11系统安全性 软件应具有用户及密码验证功能，防止非法用户进入软件。
◇可行性分析报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 ◇项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 ◇软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 ◇概要设计说明书：该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。 ◇详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 ◇用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。 ◇测试计划：为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 ◇测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。 ◇开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 ◇项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。 ◇软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。 ◇软件问题报告：指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。 ◇软件修改报告：软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。
口腔图像处理软件 组成： 由软件安装光盘（内含软件安装包和电子说明书）、加密锁组成，逻辑结构组成模块包括：患者数据管理模块、二维图像处理模块、三维图像处理模块、全景图像处理模块、报告模块。 适用范围：适用于符合DICOM3.0标准的口腔CT图像，以及STL/OBJ标准头面部图像和JPEG标准的面像、口内照，用于图像显示和处理、存储与传输、数据管理及诊断报告编写。不适用于耳鼻喉部位的检查和诊断。 1.1 软件型号规格 口腔图像处理软件，型号：CephPro3D。功能配置如下表所示： 1.2 软件发布版本 V1 1.3版本命名规则 软件版本用X.Y.Z.B表示，其中X为主版本号（即软件发布版本号），表示重大增强类软件更新，Y为副版本号，表示轻微增强类软件更新，Z为修订版本号，表示纠正类软件更新，B代码编译版本号，表示构建。 重大增强类软件更新是指影响到医疗器械安全性或有效性的增强类更新，如更改预期用途，软件运行平台跨越互不兼容的计算机平台（包括软件和硬件），核心功能变化影响到用户临床决策或者影响到人员安全，软件的安全性级别、体系结构、用户界面关系或物理拓扑发生改变。轻微增强类软件更新是指不影响医疗器械安全性与有效性的增强类更新。纠正类软件更新是指为修正软件缺陷而进行的软件更新。构建是指软件编译生成一个工作版本。 软件的主版本号从1开始编号。当软件涉及架构或功能的重大修改时，主版本号加1，同时副版本号、修订版本号和代码编译版本号复位为0。
软件的副版本号从0开始编号，当软件在原有基础上增加或修改局部功能 时，主版本号不变，副版本号加1。 软件的修订版本号从0开始编号，当软件修复缺陷时，主版本号和副版本 号不变，修订版本号加1。 软件的代码编译版本号，从0开始增加。 2.1 通用要求 2.1.1处理对象 适用于符合DICOM3.0标准的口腔CT图像，以及STL/OBJ标准头面部图像和JPEG 标准的面像、口内照，用于图像显示和处理、存储与传输、数据管理及诊断报告编写。 2.1.2 最大并发数 100 2.1.3 数据接口 DICOM3.0标准，STL/OBJ标准，JPEG标准。 2.1.4 特定软硬件 不需要特定的软硬件。 2.1.5 临床功能 1. 患者数据管理 a) 患者管理：新建患者，修改患者信息，删除患者信息，查询患者信息； b) 病历管理：新建病历，修改病历，删除病历，查询病历，导入病历和导出病历； c) 病历图像管理：导入本地图像数据，导入网络图像数据； d) 图像编辑 e) 患者数据的上传和下载； 2. 三维图像处理 a) 三维图像处理；阈值调节，保存不同方位图片，保存显示部位图片，保存图片，打开2D测量页面； b) 姿态调整：切换视图方向，平移视图，旋转视图，移动参考线，视图复原，保存矩阵，鼠标交互，同步三视图头位，预设三视图显示效果，头位复原； c) 3D测量； d) 重叠；
需求开发规程 文件状态： [V ]草稿 [] [] 正式发布 正在修改 普华讯光（北京）科技有限公司
版本历史 审批人员
1目的 ........................................................................................ 2范围..................................... 3术语定义................................. 4职责..................................... 5裁剪指南................................. 6过程..................................... 6.1概要图.................................. 6.2启动条件................................. 6.3输入..................................... 6.4活动..................................... 6.4.1需求调研................................ ............................... 错误! 未定义书签。 6.4.2分析需求................................ ............................... 错误! 未定义书签。 6.4.3需求确认................................. ............................... 错误！未定义书签。 6.4.4细化需求................................. ............................... 错误! 未定义书签。 6.4.5需求确认................................. ............................... 错误! 未定义书签。 6.5输出..................................... 6.6关闭标准................................. 7审核.................................... 8度量..................................... 9技能要求................................. 10参照文件................................. 1 1 1 1 2 2 2 4 4 4 6 6 6 6 7 7 I
第三部分技术规范 1、系统实施的总体要求全面预算管理软件系统实施后，应使企业全面预算管理的编制、审批、滚动、分析、数据集成等功能得到全面提升，尤其实现各事业部可独立完成预算编制的整体运算。 投标人应根据以下要求提供详细的技术方案。 1.1稳定性和可靠性 ⑴ 系统应符合企业全面预算管理工作要求。 ⑵ 系统应经过完善的设计和充分的测试运行，具备在较长时间内连续无故障的运行能力。 ⑶ 系统应提供全面、有效的系统安全机制。 ⑷ 系统应具备开放的标准化体系结构，可方便地与其它业务系统衔接，实现与其它业务系统间的无缝集成。 1.2兼容性和易用性 ⑴ 全面预算管理软件在安装、配置、升级、维护等管理方面应该简单快捷。 ⑵ 系统应具备易操作的特点，好记易学、实用高效。 ⑶ 系统应具备强大的容错、数据恢复与稳定运行的能力。 ⑷ 系统应易于扩展和升级，能够根据用户的具体需求快速、方便地定制、扩展原系统的功能。 2、系统实施要求 2.1 系统架构 ⑴ XXHyperion 全面预算管理系统最新版本 11 的软件实施。 ⑵ 系统支持集中式部署方式。 ⑶ 服务端支持 32位和 64位 Windows Server 2003及以上版本操作系统 ⑷ 客户端支持32位和64位WindowsXP及以上版本操作系统。 ⑸优化与Oracle ERP等系统数据对接及数据分析。 ⑹ 可使用 IE6.0 及以上版本浏览器进行预算系统操作。 2.2权限管理 ⑴ 要求系统可以按照预算管理人员的职责不同进行权限的分配，可以支持
功能权限和数据权限的赋权管理 ⑵ 要求提供用户角色定义、访问权限定义，可对用户进行角色分配，实现不同资源控制的组合式访问控制与授权管理。 2.3系统实施后达到的效果 主要功能效果如下：
软件需求分析说明书审查规范
文件修改控制
目录 软件需求分析说明书审查规范 (1) 目录 (3) 1.引言 (3) 1.1.目的 (3) 1.2.适用范围 (3) 1.3.使用说明 (4) 2.参考资料 (4) 3.术语定义 (4) 4.质量要求 (6) 4.1.完整性 (6) 4.1.1.整体内容完整性 (6) 4.1.2.需求项信息完整性 (8) 4.2.正确性 (9) 4.3.一致性 (10) 4.4.可验证性 (10) 4.5.划分优先级 (10) 4.6.可用性 (11) 5.附件 (11) 5.1.一些编写建议 (11) 5.2.部分参考实例 (12) 5.2.1.需求项表格 (12) 5.2.2.表格需求项实例 (13) 5.2.3.优先级划分方法实例 (14) 5.2.4.软件需求分析说明书模板 (15) 1.引言 1.1.目的 软件需求分析说明书在软件开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。为了保证软件说明书对质量，本文档具体描述了《软件需求分析说明书》所要包含的内容及其编制所要达到的质量要求。 1.2.适用范围 作为《软件需求分析说明书》是否可以进入正式评审的审查标准，符合该规范的可以提交正式需求评审； 作为测试人员编制《软件需求分析说明书审查列表》的依据；
作为开发人员编制《软件需求分析说明书》的指导原则； 1.3.使用说明 本文重点对需求分析说明书的内容进行要求，对表示方式、方法未明确提出要求对视为不作要求； 本文中的“应”、“必须”含义等同； 本文中的“现有的技术水平”指与该需求相关的行业中，可获得的、已知的、可实际运用于生产的、可信的、经过验证的所有技术； 本文中的需求可行性以通过审核发布的《项目可行性研究报告》为依据； 2.参考资料 GB 8566 计算机软件开发规范受控编号？ GB 8567 计算机软件产品开发文件编制指南受控编号？ GB/T 11457 软件工程术语受控编号？ Systematic Software Testing Rick D.Craig, Stefan P.Jaskiel Artech House Publishers 2002-05-1 统一软件开发过程RUP2000手册IBM公司2000年 3.术语定义 GB/T 11457所列术语和下列定义适用于本文 需求 系统必须符合的条件或具备的功能 软件需求分析 软件需求分析的基本任务是准确地定义未来系统的目标，确定为了满足用户的需求，系统必须做什么。需求分析包括需求获取和需求规约：需求获取是系统分析员通过学习以及同用户的交往，熟悉用户领域的知识，并获得对未来系统的需求；需求规约是系统分析员在获得了用户的初步需求后，必须进行一致性分析和检查，通过和用户协商解决其中存在的二义性和不一致性，并以一种规范的形式准确地表达用户的需求，形成软件需求分析说明书。 软件需求分析说明书（Software Requirements Specifications，简称SRS）：软件需求分析说明书（也称软件需求规格说明书、软件需求分析报告）是软件需求分析阶段得到的最终文档，它以形式化的术语和表示对软件的功能和性能进行详细而具体的描述。它是用户和开发者之间的技术合同，是软件设计、编码阶段的基础,也是软件测试和验收的依据。
软件需求规范
版本记录 版本号日期修改章节修改内容及说明编制者XXXXXXXX
编制：审核：批准：
目录 1.简介 (5) 1.1.系统简介 (5) 1.2.文档目的 (5) 1.3.文档范围 (5) 1.4.与其它开发任务/文档的关系 (5) 1.5.文档结构 (5) 1.6.术语和缩写词 (5) 1.7.项目背景 (5) 2.参考文档 (6) 3.系统及软件概述 (7) 3.1.软件目标功能 (7) 3.2.运行环境 (7) 3.3.限制条件 (7) 4.需求假设 (8) 5.需求分析 (9) 6.软件范围 (10) 7.功能需求 (11) 8.质量属性需求 (12) 9.接口需求 (13) 9.1.用户界面 (13) 9.2.硬件接口 (13) 9.3.软件接口 (13) 9.4.通信接口 (13) 10.安全需求 (14) 11.系统限制 (15) 12.需求追踪 (16)
1.简介 1.1.系统简介 错误!未找到引用源。 错误!未找到引用源。 1.2.文档目的 错误!未找到引用源。错误!未找到引用源。 1.3.文档范围 1.4.与其它开发任务/文档的关系 错误!未找到引用源。如软件结构和界面设计文档的关系1.5.文档结构 1.6.术语和缩写词 错误!未找到引用源。 1.7.项目背景 错误!未找到引用源。 错误!未找到引用源。
2.参考文档 错误!未找到引用源。 错误!未找到引用源。 错误!未找到引用源。 错误!未找到引用源。文档 错误!未找到引用源。 软件开发计划 软件界面定义文档 软件结构设计文档 软件应用数据文档 软件配置文档 相关硬件设计文档等
软件技术规范
第三部分技术规范 1、系统实施的总体要求 全面预算管理软件系统实施后，应使企业全面预算管理的编制、审批、滚动、分析、数据集成等功能得到全面提升，尤其实现各事业部可独立完成预算编制的整体运算。 投标人应根据以下要求提供详细的技术方案。 1.1 稳定性和可靠性 ⑴系统应符合企业全面预算管理工作要求。 ⑵系统应经过完善的设计和充分的测试运行，具备在较长时间内连续无故障的运行能力。 ⑶系统应提供全面、有效的系统安全机制。 ⑷系统应具备开放的标准化体系结构，可方便地与其它业务系统衔接，实现与其它业务系统间的无缝集成。 1.2 兼容性和易用性 ⑴全面预算管理软件在安装、配置、升级、维护等管理方面应该简单快捷。 ⑵系统应具备易操作的特点，好记易学、实用高效。 ⑶系统应具备强大的容错、数据恢复与稳定运行的能力。 ⑷系统应易于扩展和升级，能够根据用户的具体需求快速、方便地定制、扩展原系统的功能。 2、系统实施要求 2.1 系统架构 ⑴XXHyperion全面预算管理系统最新版本11的软件实施。 ⑵系统支持集中式部署方式。 ⑶服务端支持32位和64位Windows Server 2003及以上版本操作系统。 ⑷客户端支持32位和64位Windows XP及以上版本操作系统。 ⑸优化与Oracle ERP等系统数据对接及数据分析。 ⑹可使用IE6.0及以上版本浏览器进行预算系统操作。 2.2 权限管理 ⑴要求系统可以按照预算管理人员的职责不同进行权限的分配，可以支持功能权限和数据权限的赋权管理。
⑵要求提供用户角色定义、访问权限定义，可对用户进行角色分配，实现不同资源控制的组合式访问控制与授权管理。 2.3 系统实施后达到的效果 主要功能效果如下： 序号功能软件实施描述 1 实现系统基本功 能及最新功能包括对企业全面预算管理的编制、审批、滚动、分析等功能。 实现25个实体（事业部、总部）的全面预算的编制、审批、滚动、分析 1.1全面预算的编制实现实体按月份、季度、年度进行全面预算的编制， 完成所有预算表单及预算报表的编制 1.2 流程与任务管理使用规划单元跟踪预算，审核状态﹑流程问题以及规 划单元所有权实现各层级预算的审批。通过系统及网 络进行信息反馈。实现数据驱动型的图形化审批流 程，满足按部门、表单的流程审批需求 1.3 实现滚动预算的 编制1、实现企业按月份、季度、半年度滚动预算的编制； 2、实现实际数据的数据集成及部分数据的手工录 入，达到滚动预算的编制。 1.4 优化预算计算模 型满足不低于25个实体用户同时自行整体计算的功能。各实体可以独立完成预算编制的整体计算（包括通过层次聚合计算的数据），各实体（事业部、总部）在填报完数据后，可即时自行计算，得到各实体层级的报表 1.4.1 优化计算脚本增加事业部层级的计算脚本，在事业部填报完数据 后，可在WEB界面的规则运行平台直接运行事业部计 算、聚合等规则，即时或者事业部层级的管理报表 1.4.2 调整用户权限调整事业部级用户的权限，事业部层级的用户除了原 有的写入权限外，增加特定脚本的执行权限 1.5 优化预算分析系 统优化全面预算分析模板，通过使用预算分析系统实现预算分析。完成所有预算分析表单的编制 1.6 与ERP的数据集 成 实现11版本预算系统与Oracle ERP的数据集成 1.7 预算插件通过Smartview,essbase等Hyperion插件的使用，实 现与Office Excel、Outlook的无缝集成 1.8 新增其它功能组合表单 文本输入 日期输入 日历选择
软件文档的评审和签署规范 一、目的 在软件开发的每个阶段，对该阶段所形成的文档进行评审，尽早发现问题，并及时采取措施予以解决，确保文档的内容准确，为软件产品的质量提供保障。文档的签署是为了体现文档的合法性、有效性、法规性。 二、规定 1．文档评审的重点是需求说明和设计说明的评审，见附录一。 2．需求评审需要进一步确认用户要求什么，及用户从开发者一方了解某些限制和约束。用户代表必须参与此项评审活动，以得到双方认可的需求文档。3．设计评审主要进行概要设计评审和详细设计评审。概要设计评审主要详细评审每个系统组成部分的基本设计方法和测试计划；详细设计评审主要评审程序和程序单元测试计划。 4．所有评审会议必须形成会议记录（备忘录）和评审报告。 5．涉及到文档的更改按文档的更改要求执行。 6．评审的内容还可以包括：编排方式、技术准确度、完整性、对读者的适合性、表达上的正确性、格式的规范性等。 7．评审一般采用评审会的方式进行。 8．软件文档都应进行签署，签署的一般顺序为编制→审核→会签→标准化→批准的顺序进行。其中会签仅在必要时进行。 9．签署不允许代签，且修改单的签署与被修改的文档签署要一致。 10．编制、审核、会签、标准化、批准等人员见附录二。 三、程序 评审 1．由主管领导、用户代表（必要时）、开发小组成员、项目管理人员、标准化人员等组成评审小组，必要时邀请外单位专家参加。 2．开会前，由主管领导确定评审的具体内容，并将材料发给评审小组成员。3．评审小组成员准备。 4．主管领导主持会议，根据评审条目由评审小组成员评议、评审。 5．评审小组得出评审结论，形成评审报告，评审小组成员应在评审报告上签字。 签署 （无） 四、相关记录 评审报告 会议纪要（记录） 五、相关文档
{产品名称} 软件需求规格说明书 编写人： 编写日期：年月日
目录 1.产品描述 (3) 1.1.编写目的 (3) 1.2.产品名称 (3) 1.3.名词定义（可选） (3) 2.产品需求概述 (3) 2.1.功能简介 (3) 2.2.运行环境 (3) 2.3.条件与限制（可选） (3) 3.功能需求 (3) 3.1.功能划分（可选） (3) 3.2.功能1 (4) 3.3.功能N (4) 3.4.不支持的功能 (4) 4.数据描述 (4) 5.性能需求（可选） (4) 6.运行需求（可选） (4) 6.1.用户界面 (4) 6.2.硬件接口 (4) 6.3.软件接口 (5) 6.4.通信接口 (5) 7.其它需求（可选） (5) 8.特殊需求（可选） (5) 9.不确定的问题（可选） (5) 10.编写人员及编写日期 (5) 11.附录 (5) 11.1.引用文件 (5) 11.2.参考资料 (5)
1.产品描述 1.1.编写目的 【说明编写本软件需求规格说明书的目的，指出预期的读者。】 1.2.产品名称 【本项目的名称，包括项目的全名、简称、代号、版本号。】 1.3.名词定义（可选） 【对重要的或是具有特殊意义的名词（包括词头和缩写）进行定义，以便读者可以正确地解释软件需求说明。】 2.产品需求概述 2.1.功能简介 【对产品的基本功能做一个简介，包括： 1.本产品的开发意图、应用目标及作用范围。 2．概略介绍了产品所具有的主要功能。可以用列表的方法给出，也可以用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图等。 3．说明本产品与其他相关产品的关系，是独立产品还是一个较大产品的组成部分。 可以用表示外部接口和数据流的系统高层次图，或者方框图说明。】 2.2.运行环境 1.硬件环境： 【详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其它特殊设备。】 2.软件环境： 【如操作系统、网络软件、数据库系统以及其它特殊软件要求。】 2.3.条件与限制（可选） 【说明本软件在实现时所必须满足的条件和所受的限制，并给出相应的原因。 必须满足的条件包括输入数据的范围以及格式。 所受的限制包括软件环境、硬件环境等方面的内容。例如：必须使用或者避免的特定技术、工具、编程语言和数据库；企业策略、政府法规或工业标准；硬件限制，例如定时需求或存储器限制；经费限制、开发期限；项目对外部因素存在的依赖。例如其它项目开发的组件。等等】 3.功能需求 【功能需求描述系统特性，即产品所提供的主要服务。可以通过使用实例、运行模式、用户类、对象类或功能等级等不同方法来描述，还可以把它们组合起来使用。 功能需求的表述形式可以参见《需求分析和管理指南》第8.2节。】 3.1.功能划分（可选） 【此部分从用户的角度描述将软件划分成不同的部分，并给出总体功能结构。对于复杂
系统中涉及的所有规范、标准或材料规格（包括一切有效的补充或附录）均采用最新版本，即以招标方与投标方签订供货合同之日作为采用最新版本的截止日期。若发现本规范书与参照的文献之间有不一致之处，我方向贵方书面指明，并由贵方确定采用哪一个规范。 我方所有设备的设计，制造，检查，试验及特性除木规范中规定的特别标准外，都遵照适用的最新版中国国家标准（GB）以及国际单位制（SI） O 我方提出的等同标准应不低于贵方要求的标准并征得贵方的认可，我方应遵循的标准至少包括： 《中华人民共和国计算机信息系统安全保护条例》 GB2887-89 计算站场地技术条件 GB/T 9361-1988 计算机场地安全要求 GB4943 —90 信息技术设备（包扌舌电气事务设备）的安全 GB/T -1995 中华人民共和国计算机信息安全保护条例 GB18030-2000 信息交换用汉字编码字符集基本集的扩充 GB1526-89信息处理一数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文字编制符及约定
GB8566计算机软件开发规范 GB9385计算机软件需求说明编制指南 GB9386计算机软件测试文件编制规范 GB/T13502信息处理、程序构造及其表示法的约定 GB/T14085信息处理系统计算机系统配置图符号及约定GB10112确立术语的一般原则与方法 GB/T13725确立术语数据库的一般原则与方法 SJ/T11293企业信息化技术规范 GB/T12504-90计算机软件配置管理计划规范 GB/T13702-92计算机软件分类与代码 GB/T14079-93软件工程术语 GB/T15532-1995计算机软件单元测试 GB/T 14394-1993《计算机软件可靠性和可维护性规范》GB/T 2887-1989《计算机软件质量保证规范》 GB/T 8566-2000《信息技术软件生成期过程》
软件工程文档模板 目录 1. 范围 (1) 2. 总体要求 (1) 2.1总体功能要求 (1) 2.2软件开发平台要求 (1) 2.3软件项目的开发实施过程管理要求 (2) 2.3.1 软件项目实施过程总体要求 (2) 2.3.2 软件项目实施变更要求 (3) 2.3.3 软件项目实施里程碑控制 (4) 3. 软件开发 (4) 3.1软件的需求分析 (5) 3.1.1 需求分析 (5) 3.1.2 需求分析报告的编制者 (6) 3.1.3 需求报告评审 (6) 3.1.4 需求报告格式 (6) 3.2软件的概要设计 (7) 3.2.1 概要设计 (7) 3.2.2 编写概要设计的要求 (7) 3.2.3 概要设计报告的编写者 (7)
3.2.4 概要设计和需求分析、详细设计之间的关系和区别 (7) 3.2.5 概要设计的评审 (8) 3.2.6 概要设计格式 (8) 3.3软件的详细设计 (8) 3.3.1 详细设计 (8) 3.3.2 特例 (8) 3.3.3 详细设计的要求 (8) 3.3.4 数据库设计 (9) 3.3.5 详细设计的评审 (9) 3.3.6 详细设计格式 (9) 3.4软件的编码 (9) 3.4.1 软件编码 (9) 3.4.2 软件编码的要求 (10) 3.4.3 编码的评审 (10) 3.4.4 编程规范及要求 (10) 3.5软件的测试 (10) 3.5.1 软件测试 (10) 3.5.2 测试计划 (11) 3.6软件的交付准备 (11) 3.6.1 交付清单 (11) 3.7软件的鉴定验收 (12) 3.7.1 软件的鉴定验收 (12)
附件5 医疗软件产品技术审评规范（2017版） 本规范旨在指导企业提交医疗器械软件注册申报资料，同时规范医疗器械软件的技术审评要求。 本规范是对医疗器械软件的一般性要求，企业应根据医疗器械软件的特性提交注册申报资料，判断指导原则中的具体内容是否适用，不适用内容详述理由。企业也可采用其他满足法规要求的替代方法，但应提供详尽的研究资料和验证资料。 本规范是在现行法规和标准体系以及当前认知水平下、并参考了国外法规与指南、国际标准与技术报告制定的。随着法规和标准的不断完善，以及认知水平和技术能力的不断提高，相关内容也将适时进行修订。 本规范是对企业和审查人员的指导性文件，不包括审评审批所涉及的行政事项，亦不作为法规强制执行，应在遵循相关法规的前提下使用本规范。 本规范针对软件的特殊性，在现行法规要求下进一步明确了对医疗器械软件的要求，特别是对软件更新、软件版本的要求。本规范是医疗器械软件的通用规范，其他涉及软件医疗器械产品的规范可在本规范基础上进行有针对性的调整、修改和完善。 一、适用范围 本规范适用于第二类医疗器械软件的注册申报，适用的软件开发方式包括自主开发、部分采用现成软件和全部采用现成
软件。 医疗器械软件包括独立软件和软件组件。独立软件：作为医疗器械或其附件的软件；软件组件：作为医疗器械或其部件、附件组成的软件。 独立软件应同时具备以下三个特征：具有一个或多个医疗用途，无需医疗器械硬件即可完成预期用途，运行于通用计算平台。独立软件包括通用型软件和专用型软件，其中通用型软件基于通用数据接口与多个医疗器械产品联合使用，如PACS、中央监护软件等；而专用型软件基于通用、专用的数据接口与特定医疗器械产品联合使用，如Holter数据分析软件、眼科显微镜图像处理软件等。 软件组件应同时具备以下两个特征：具有一个或多个医疗用途，控制（驱动）医疗器械硬件或运行于专用（医用）计算平台。软件组件包括嵌入式软件和控制型软件，其中嵌入式软件（即固件）运行于专用（医用）计算平台，控制（驱动）医疗器械硬件，如心电图机所含软件、脑电图机所含软件等；而控制型软件运行于通用计算平台，控制（驱动）医疗器械硬件。 软件组件也可兼具处理功能。专用型独立软件可单独注册，也可随医疗器械产品注册，此时视为软件组件。 二、技术审查要点 （一）产品名称和结构组成的要求 1.独立软件 产品名称应为通用名称，并符合相关法规、规范性文件的要求，可以结合人体部位（如胸部、心脏等）、临床科室（如骨科、神经外科等）、处理对象（如CT图像、MRI图像、心电数
软件需求分析文档编写规范 A、三种编写方法 1、用好的结构化和自然语言编写文本型文档； 2、建立图形化模型，这些模型可以描绘转换过程、系统状态、和它们之间的变化、数据关系、逻辑流或对象类和他们的关系； 3、编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。 多种编写方法可在同一个文档使用，根据需要选择，或互为补充，以能够把需求说明白为目的。 B、应有成果 1、各业务手工办理流程文字说明； 2、各业务手工办理流程图； 3、各业务手工办理各环节输入输出表单、数据来源； 4、目标软件系统功能划分（示意图及文字说明）； 5、目标软件系统中各业务办理流程文字说明； 6、目标软件系统中各业务办理流程图（模型）； 7、目标软件系统中各业务办理各环节数据、数据采集方式、数据间的内在联系分析。 8、目标软件系统用户界面图、各式系统逻辑模型图及说明 C、文档工具推荐 1、调研结果《需求分析说明书》格式参照开发文档模板； 2、单位组织结构图、功能模块分解图用VISIO绘制，或直接用WORD中的画图工具； 3、业务流程图用VISIO中的FLOWCHART模板绘制； 4、系统逻辑模型使用ROSE绘制活用VISIO中的UML模板绘制； 5、软件用户界面用VISIO中的WIN95 USER INTERFACE模板绘制； 6、数据物理模型用POWERDESINER绘制；
D、需求文档编写原则 1、句子简短完整，具有正确的语法、拼写和标点； 2、使用的术语与词汇表中所定义的一致； 3、需求陈述应该有一致的样式，例如“系统必须..”或者“用户必须..”，并紧跟一个行为动作和可观察的结果。； 4、避免使用模糊、主观的术语，减少不确定性，如“界面友好、操作方便”； 5、避免使用比较性词语，如“提高”，应定量说明提高程度
软件エ程文档模板 目录 1. 范围 (1) 2. 总体要求 (1) 2.1总体功能要求 (1) 2.2软件开发平台要求 (1) 2.3软件项目地开发实施过程管理要求 (2) 2.3.1 软件项目实施过程总体要求 (2) 2.3.2 软件项目实施变更要求 (2) 2.3.3 软件项目实施里程碑控制 (2) 3. 软件开发 (3) 3.1软件地需求分析 (3) 3.1.1 需求分析 (3) 3.1.2 需求分析报吿地编制者 (4) 3.1.3 需求报吿评审 (4) 3.1.4 需求报吿格式 (4) 3.2软件地概要设计 (4) 3.2.1 概要设计 (4) 3.2.2 编写概要设计地要求 (4) 3.2.3 概要设计报吿地编写者 (4) 3.2.4 概要设计合需求分析、详细设计之间地关系合区别 (4) 3.2.5 概要设计地评审 (4) 3.2.6 概要设计格式 (4) 3.3软件地详细设计 (5) 3.3.1 详细设计 (5) 3.3.2 特例 (5) 3.3.3 详细设计地要求 (5) 3.3.4 数据库设计 (5) 3.3.5 详细设计地评审 (5) 3.3.6 详细设计格式 (5) 3.4软件地编码 (5) 3.4.1 软件编码 (5) 3.4.2 软件编码地要求 (5) 3.4.3 编码地评审 (6) 3.4.4 编程规范及要求 (6) 3.5软件地测试 (6) 3.5.1 软件测试 (6) 3.5.2 测试计划 (6) 3.6软件地交付准备 (6)
3.6.1 交付清单 (6) 3.7软件地鉴定验收 (7) 3.7.1 软件地鉴定验收 (7) 3.7.2 验收亼员 (7) 3.7.3 验收具体内容 (7) 3.7.4 软件验收测试大纲 (7) 3.8培训 (7) 3.8.1 系统应用培训 (7) 3.8.2 系统管理地培训（可选） (8) 附录А软件需求分析报吿文档模板 (9) 附录Ь软件概要设计报吿文档模板 (21) 附录С软件详细设计报吿文档模板 (33) 附录D 软件数据库设计报吿文档模板 (43) 附录Е软件测试(验收)大纲 ...................................................................... 错误!未定义书签。5
软件需求文档格式的标准写法 1．引言 1．1 编写目的 ·阐明开发本软件的目的； 1．2 项目背景 ·标识待开发软件产品的名称、代码； ·列出本项目的任务提出者、项目负责人、系统分析员、系统设计员、程序设计员、程序员、资料员以及与本项目开展工作直接有关的人员和用户； ·说明该软件产品与其他有关软件产品的相互关系。 1．3 术语说明 列出本文档中所用到的专门术语的定义和英文缩写词的原文。 1．4 参考资料（可有可无）
列举编写软件需求规格说明时所参考的资料，包括项目经核准的计划任务书、合同、引用的标准和规范、项目开发计划、需求规格说明、使用实例文档，以及相关产品的软件需求规格说明。 在这里应该给出详细的信息，包括标题、作者、版本号、发表日期、出版单位或资料来源。 2．项目概述 2．1 待开发软件的一般描述 描述待开发软件的背景，所应达到的目标，以及市场前景等。 2．2 待开发软件的功能 简述待开发软件所具有的主要功能。为了帮助每个读者易于理解，可以使用列表或图形的方法进行描述。使用图形表示，可以采用： ·顶层数据流图； ·用例UseCase图；
·系统流程图； ·层次方框图。 2．3 用户特征和水平（是哪类人使用） 描述最终用户应具有的受教育水平、工作经验及技术专长。 2．4 运行环境 描述软件的运行环境，包括硬件平台、硬件要求、操作系统和版本，以及其他的软件或与其共存的应用程序等。 2．5 条件与限制 给出影响开发人员在设计软件时的约束条款，例如： ·必须使用或避免使用的特定技术、工具、编程语言和数据库； ·硬件限制； ·所要求的开发规范或标准。 3．功能需求 3．1 功能划分
第三部分技术规范 1、系统实施的总体要求 全面预算管理软件系统实施后，应使企业全面预算管理的编制、审批、滚动、分析、数据集成等功能得到全面提升，尤其实现各事业部可独立完成预算编制的整体运算。 投标人应根据以下要求提供详细的技术方案。 1.1 稳定性和可靠性 ⑴系统应符合企业全面预算管理工作要求。 ⑵系统应经过完善的设计和充分的测试运行，具备在较长时间内连续无故障的运行能力。 ⑶系统应提供全面、有效的系统安全机制。 ⑷系统应具备开放的标准化体系结构，可方便地与其它业务系统衔接，实现与其它业务系统间的无缝集成。 1.2 兼容性和易用性 ⑴全面预算管理软件在安装、配置、升级、维护等管理方面应该简单快捷。 ⑵系统应具备易操作的特点，好记易学、实用高效。 ⑶系统应具备强大的容错、数据恢复与稳定运行的能力。 ⑷系统应易于扩展和升级，能够根据用户的具体需求快速、方便地定制、扩展原系统的功能。 2、系统实施要求 2.1 系统架构 ⑴XXHyperion全面预算管理系统最新版本11的软件实施。 ⑵系统支持集中式部署方式。 ⑶服务端支持32位和64位Windows Server 2003及以上版本操作系统。 ⑷客户端支持32位和64位Windows XP及以上版本操作系统。 ⑸优化与Oracle ERP等系统数据对接及数据分析。 ⑹可使用IE6.0及以上版本浏览器进行预算系统操作。 2.2 权限管理 ⑴要求系统可以按照预算管理人员的职责不同进行权限的分配，可以支持功能权限和数据权限的赋权管理。
⑵要求提供用户角色定义、访问权限定义，可对用户进行角色分配，实现不同资源控制的组合式访问控制与授权管理。 2.3 系统实施后达到的效果 主要功能效果如下：