IEC 62304要求在5.2节中说明软件需求。你不仅可以符合标准，而且可以用很少的精力，以精确和简洁的方式完整地记录你的软件需求。这有助于你更快、更有成本效益地开发更好的产品，并避免审核中的麻烦。

 

软件需求规范（SRS）：典型的错误和他们的后果

 

许多软件需求规格（SRS）的典型错误有以下几点：

 

-软件需求是不完整的，因此没有进一步的需求时，不允许开发人员继续开发产品。

 

-SRS文件是不正确的，甚至是矛盾的，因为作者并没有像软件需求应该记录的那样写出一个思维模型。

 

-软件需求是目的、客户要求、项目要求（即不仅是产品）、使用要求、系统要求和具体解决方案的规范（例如与架构有关）的粗略混合。这个问题特别适用于那些使用规格表概念的公司。

 

错误的软件需求

 

-导致昂贵的返工和项目延误；

 

-使得测试变得困难，因为对于验证来说，没有具体的规格可言；

 

-使得验证和确认无法分开，并且；

 

-导致审核过程中的问题，因为不符合法规要求。

 

一些公司试图避免这些后果，其中他们“过度记录”并产生了危险的质量管理开销。

 

建议：从黑盒的角度来指定软件需求（software requirements，SRS）

 

SRS应该将软件的需求描述为一个黑盒。系统应该如何向外表现？它如何通过接口做出反应，无论是对用户界面（GUI）还是其他系统？因此，SRS应该描述：

 

-用户界面(s)；

 

-GUI：元素的定位，风格指南，... ；

 

 

-系统在正常情况和故障情况下对用户操作的行为：从显示的系统信息、计算、图形、信息、警告、“ScreenFlow”等；

 

-这些反应发生的速度；

 

-软件（黑盒）可以安装到哪些环境（操作系统预设的数据库和其他服务器硬件，包括RAM），以及这种安装应该如何进行。

 

-系统应该如何对用户的错误和过载作出反应。

 

-技术接口（与其他系统）：

 

结构、句法和语义上的互操作性，因此技术协议、数据类型、分类系统（在审计保证人中有更多介绍）；

 

导入和导出数据也包括在内；

 

时间安排；

 

预期的数量，交易的数量；

 

预期的观点和反应。

 

为什么这个概念有助于满足IEC 62304第5.2节的要求？

 

这个列表听起来很熟悉吗？那么请查看ISO 9126或其后续标准ISO 25010，在这里你会发现一个精彩的分类法。在这里，IEC 62304采取了很多5.2章的软件要求。你可以通过上述程序满足本章所述的所有要求。建议你不要对软件要求进行分类，就像IEC 62304中要求的分类方式。

 

什么是不属于SRS的？

 

-使用要求；

 

-对要使用的技术的要求；

 

-解决方案的要求，如对架构、数据库的“想法”，等。

 

自己评估软件需求

 

你了解软件需求文件必须包含什么？不包含什么吗？你知道以下内容的哪一部分属于软件需求规范吗？

 

-该软件必须能够在摩托罗拉处理器A383B上运行。

 

-该软件必须以每分钟50次的脉冲来控制电极。

 

-该软件必须在屏幕上显示数据，使正常视力的人可以在2米外阅读。

 

-该软件必须是可维护的。

 

-该软件必须在4个月内提供测试版。

 

-5000台设备应在24个月内售出。

 

软件需求（Software Requirements）与软件规范（Software Specification）

 

英语术语是软件需求规范。这个术语包含了需求和规范。严格说来，两者并不完全相同。建议你把软件指定为一个黑盒。这实际上就是一个软件规范。由于IEC 62304只谈到了软件要求，我们也使用这个术语，大部分甚至是同义的。

 

如果你把这两个术语分开，软件需求将比软件规范更普遍地制定需求。例如：

软件需求（Software   Requirements）	软件规范（Software   Specification）
系统必须显示病人姓名	系统显示病人的名字，字体为Arial，大小为18，距离屏幕的右边缘20像素（根据模拟屏幕X）。
系统需要通过HL7连接的相邻系统发送数据	当检测到一个新病人时，系统通过接口X发送HL7 V2.6 ADT A01消息，据此，系统在MSH段注册为 "KIS "作为发送系统。
系统必须在内部存储1024位的加密信息

 

推荐黑盒式的规范，因为只有这些可以在相应的软件系统测试中被测试。此外，几乎所有的软件需求都可以更精确、更完整、更清楚地指定（并且可以用更简单的方式测试）为黑盒的属性。

 

 

来源：MDR小能手

关键词： 软件