大家都知道医疗设备的管控上，是非常严格的，那么在医疗设备制造企业做需求管理是一种什么样的体验，我也说不清，但我可以从我工作的经历来聊一聊。
需求工程师的职责
当然，聊工作前需要聊聊我的组织，我们需要干一些什么事情？
* 临床场景分析
* 竞争对手的知识产权分析，专利撰写、商标申请
* 法规符合性的分析
* 临床调研
* 竞争对手分析
* 产品策划和产品策划方案输出
* 用户需求输出
* 产品需求输出
* 产品需求分解（子系统分解需求说明书）审核
* 软件需求输出
* 术语表（数据字典输出）
* 中文字符串组织评审
* 中文说明书审核
* 说明书评审
* 需求跟踪
* 软件需求功能确认，软件方案设计评审
* 与产品线和市场部排定需求优先级
* 产品资料发布（长期）
* 临床反馈收集和走访
不负责什么呢？
* 项目进度跟踪
* 字符串表输出，只负责术语表的定义和中文字符串审核
* 英文字符串输出和英文说明书审核，资料和项目经理负责
* 硬件需求输出
* 模块需求输出
* 结构需求输出
* 附件需求输
我们很多职能其实并不是需求工程师的基本职能，从负责的工作上将，多数已经跨越了产品经理方面的工作。但实际上，需求工程师要做的核心工作还是需求的输入管理和转化，而周边相关工作应该淡化。我们这一系列的文章来谈谈我们怎么来做好需求管理或我们采取了什么措施做好需求管理。
需求分层
复杂的事情简单化的两种基本思路：一是划分模块，也就是分割，化整为零；二是分层，割裂到各自的应用领域来解决，下图是《软件需求（第三版）》中关于软件需求分层的方法。

上图的层次很清楚也很理想，第一层次的业务需求描述组织目标，第二层描述用户期望，第三层描述满足用户期望的方法。
组织目标也就是商业目标，往往，在研发层面的需求工程师是较少接触的，这往往是产品经理、产品线经理（或其他类似职能经理）跟老板一起来做出的决策，也就是这是一个策划活动，与组织战略和企业目标相关。
医疗系统需求层次
对于软件需求的分层的方法，我这里不继续展开叙述，但对于需求工程师来说，第二、三层才是重点。与我们的工作实际相关，实际上我接下来就是要谈我们的需求的分层，实际上，我们讲软件需求中提到的二、三两层的需求又划分了三个层次，如下图：

接下来我们看看每一个层次的需求是用来定义生么的。
用户需求
用户需求定义什么呢？用户需求是用来定义产品预期用途及用户主要的预期功能。
预期用途：描述产品主要的应用目的和场景和使用的预期效果。
举个例子，什么样的描述是预期用途，假设我们要做一个监护仪，它的预期用途可以这么描述：该产品在医疗单位中供有资质的医师操作，对成人、小儿和新生儿进行心电(ST 段测量和心律失常分析)、呼吸、体温、脉搏氧饱和度、脉率、无创血压、呼吸 二氧化 碳、成人和 3 岁以上小儿有创血压的监护。
用户主要的预期功能怎么说呢，还是举例来说明：
| XX-CRD-001 | 需求名称 | 支持心电监测 |
|---|---|---|
| 父需求编号 | 需求描述 | 能够进行人体的心电监测 |
这里描述的是非常高层的用户需要的需求，以用户的语言来描述，也许有人会质疑这种高层抽象的需求存在的必要性。那么从FDA 820 QSR来看，用户需求存在的理由还是很充分的，另外从流程V&V的角度来讲，用户需求的存在也简化了Validation的复杂度，后边我会专门讲到流程。

产品需求
子系统需求
来源：http://www.cnblogs.com/peapon/p/xu-qiu-zai-yi-liao-she-bei-qi-ye.html