欢迎您注册蒲公英
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
培训的时候,或者各种书籍资料中,关于如何写URS,都会说URS的提出应遵循SMART原则(S=Specifiable具体的、M=Measurable可度量的、A=Achievable可实现的、R=Realistic可实现的、T=Traceability可追踪的)。大家是不是觉得这个说的太好了,URS提的这么清楚,与供应商的谈判,后续项目的测试都很好办,标准很明确啊。
当前国内的情况,大多数的项目,如果那个项目经理把URS写成这个样子,基本上这个项目离失败就不远了。很奇怪吧!理论与实践差别这么大?? 举个例子,假如企业要上LIMS系统,如果用户以前用过LIMS系统,现在准备上个新的系统,替换掉原先的,那用户会把自己的各种酸甜苦辣都总结出来,形成URS,这时候的URS可能会比较符合SMART原则。 如果用户以前没有用过,只是有这个需求,也就是听了几家供应商的介绍,综合了一下,形成的URS,这时候的URS也就是描述了想要的功能列表,离SMART还比较远。如果硬要按SMART做,等系统上线以后,各种问题就爆发了,大量的功能根本就不是自己想要的。
当前的国情是,大多数企业所上计算机系统,多数都是自己的第一套系统,没有以前的经验可以借鉴,也就别硬按SMART原则来了。 实践上,URS可以只粗略的描述想要的功能点,随与供应商的交流的深入,具体的实现可以在供应商的FS中反映出来。也就是把URS中的部分内容转移到FS中实现。 计算机化系统的常见问题之1-培训相关 计算机化系统的常见问题之2-哪些计算机系统需要验证? 计算机化系统的常见问题之3&4-谁可以做计算机系统验证 计算机化系统的常见问题之5-计算机系统如何分类? 计算机化系统的常见问题之8-历史遗留系统如何验证? 计算机化系统的常见问题之9-如何做供应商审计?审什么? 计算机化系统的常见问题之10-计算机源代码都需要确认? 计算机化系统的常见问题之11-风险评估如何在计算机系统验证中运用? https://www.ouryao.com/thread-282623-1-1.html |