如何实现HIS系统的需求描述？

sbf2000

HIS系统需求描述应该是一个很重要的问题。HIS系统的很多问题都源于需求描述不清楚。那么怎样的描述才能有效的沟通医院业务操作层和业务管理层与产商系统分析层和编码实现层之间的信息交流呢？

对于不同层次的人，所处的位置不一样，对需求的理解也就不会相同。规定一种标准的、有效的、有利于不同层次人员共享的需求描述规范是促进HIS产业发展的有效手段。

不知现在有没有这样的现成规范可以利用？希望大家读者讨论讨论！

l2004

能否开辟一栏目主要分析讨论医院的业务流程及优化，各位可以相互借鉴，尤其对新上系统的医院及准备升级系统的医院有很好的参考作用。

StoneBreaker

hl7有这些东西吧，可能。呵呵

扬帆

需求是HIS软件发展的原动力，如何清楚地描述HIS的需求，需要即精通计算机语义表达，又精通医学语义表达，还是熟知医院的流程管理。不同的人当然理解不同，但有一点就是医院到底要解决什么问题是可以讲清楚的，抓住这个主要矛盾，应该就可以写出较好的需求。
若的确要做一个需求规范，可分为医院的通俗需求描述和计算机语言描述。

小城医生

分析客户的需求又要高于需求。

扬帆

就是，若只是解决客户现有的某个特定问题，系统只会越做越复杂，若能化某个问题为某类问题，则是HIS开发人员的职责。而对于客户需求无理的，或对原数据结构产生破坏性的改动，则最好不去做。

sbf2000

现在软件工程有一种思想叫“面向服务，事件驱动”，我觉得未来的HIS系统确实应该是这样的。那么相应地，HIS系统需求描述也应该“面向服务，事件驱动”。

bluesea

可以使用UML来描述需求，使用 Rational Rose 的RUP

StoneBreaker

rup和Msf只是流程控制和管理，是工程学的一部分。而需求，只是工程学的一部分。
ibm的rose有需求表达的功能，但是我没有用过的ibm requestpro也许可能会更好。不过，对我们这些不是计算机专业的人，或者对于像his这样的小系统来说是不是要用到requestpro这样的东西就很难说了。我最近看了hl7v3的关于rose的表达，可以参考参考。偶认为中国弄HL7好像太早了些。

Founder

我对软件工程思想的理解是：它仅仅提供了一种方法，采用这种方法可以让设计人员能够更加全面、系统地将设计人员对业务的理解记录下来，作为分析业务及业务之间相互关系的依据，并最终过渡到系统的设计和实施。请注意，软件工程方法并不能解决设计人员对业务理解错误和不完整的问题。

软件工程实施的关键就在于你对业务理解的广度和深度，即有没有抓住业务的本质。业务模式提供了一个解决特定领域特定问题的比较好的方式，为我们理解特定业务的本质提供了一定的帮助。

在同一个行业里，不同企业的业务元素及业务元素之间的关系从根本上来说通常都是相同的，即业务结构是相同的（只有不同行业的业务结构才会存在非常大的差异），不同之处在于业务行为上会有差异，这主要是由于各企业领导层的管理方法和思路的不同而造成的。

我认为需求源于业务中存在的问题，正是由于这些问题的存在，才使得企业产生解决问题的需求。要解决业务中存在的问题，首先必须了解业务中存在哪些问题。由于问题具有复杂性和相关性的特点，甚至某些问题之间还存在着互斥性（例如，提高产品质量和降低成本），如何整理和分析这些问题，Hans-Erik Eriksson在《UML业务建模》一书中提供了业务目标建模方法，非常值得参考。