蒲公英 - 制药技术的传播者 GMP理论的实践者

搜索
查看: 2757|回复: 11
收起左侧

[GMP相关] 如何创建严谨的URS

[复制链接]
药士
发表于 2016-12-12 22:31:25 | 显示全部楼层 |阅读模式

欢迎您注册蒲公英

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
本帖最后由 beiwei5du 于 2016-12-12 22:33 编辑

How to Create a Bullet-Proof User Requirement Specification (URS)

Graham O'Keeffe
Founder & CEO LearnaboutGMP

User requirements should be the starting point of any project you are working on. Time well-spent developing solid user requirements will help you enormously further down the line when you need to test your new equipment or software application.
Too many times people rush their requirements and as a result, the project suffers.
This article gives a clear outline of the best practices to follow when you create your user requirement specification.  







So where are people going wrong with this initial phase. How hard can it be to create a document detailing what exactly you want a system or piece of equipment to do?
The answer is, it can be very difficult if you don’t really know in the first place what exactly you want the system/application/equipment to do.
We have put together our top 22 tips for developing a bullet-proof URS. We hope you find the following tips helpful!
1. RequirementsRequirements may be developed internally by the supplier (in the case of product development). Requirements also may be provided by customers (for a configured product, custom application, or a service.
The requirements should define clearly and precisely what the system should do and state any constraints. Requirements should be reviewed and approved by the stakeholders and the subject matter experts.
2. Clear Concise MannerRequirements should be documented in a clear concise manner for the vendors/suppliers. Do not leave any room for ambiguous requirements allowing scope for the vendors to suggest their product meets the requirement when it doesn’t.
3. One Requirement at a TimeDo not double up on requirements; make it clear in your URS one requirement at a time. It will be easier for you to see how the requirement is handled and it will also make it easier for you to test one requirement at a time.
4. Control Changes to the RequirementsChanges to requirements should be controlled. Changes to subsequent specification documents that affect the requirements should lead to an update of the requirements.
5. Requirements Should be TestableRequirements should be written such that they can be tested. Individual requirements should be traceable through the life cycle.
6. Configured ProductsFor configured products and custom applications, the regulated company should describe the business processes to be automated. In the case of configured products, these processes should be aligned with the functionality of the product to be used.
7. Supplier Audit / AssessmentRegulated companies should formally assess their suppliers as part of the quality planning process. They also should be periodically re-assessed in accordance with the QMS (Quality Management System).
The decision whether to perform an audit of their sub-suppliers should be documented and based on risk assessment. The supplier may find it advantageous to use the GAMP process for categorization of the system components in assessing risk.
8. SpecificationsFor product development the supplier should document the functionality and design of the system to meet the defined requirements. This should cover software, hardware, and configuration.
Functional specifications should clearly and completely describe what the product can do. They should be produced such that objective testing can be subsequently performed.
9. User Documentation and TrainingThe supplier should provide adequate system management documentation, and provide training for both maintenance and operation in accordance with agreed contracts that should be in place before purchasing the system.
10. Business and Process KnowledgeBusiness knowledge is required in order to ensure that requirements are challenged against business needs and benefits can be realized. Process knowledge is required in order to identify key requirements of the system are related to the business or manufacturing process.
11. Avoid Duplication of RequirementsDo not over complicate the requirements of the system and do not duplicate the requirements to bulk up the document. Having duplicate requirements will lead to more testing, documentation, review time.
12. Don’t be Afraid to Audit VendorsAudits to supplier may include the following questions:
  • Company overview including any product-specific locations
  • Organisation, roles and responsibilities, staff training and experience
  • Key products and/or service history and development plans
  • QMS implementation at company level and for product-related processes
  • Development life cycle processes and deliverables
  • Development lifecycle support processes
  • Service delivery process
  • User training
  • Product support/maintenance
  • Security
  • Use of sub-contractors
13. Don’t be afraid to Compare VendorsUse your URS to compare vendors. Document the pros and cons of each vendor. If you learn something new during the proposal phase don’t hesitate to change your URS. Remember until the URS gets final approval it is fine to alter or tweak the requirements to suit your needs.
Look for the following
  • Knowledge
  • Experience
  • Documentation
14. Design Review and TraceabilityAssure that all of your requirements have been met by performing a design review and traceability. This will prove that the functionality is appropriate, consistent, and meets pre-defined standards and that the system is appropriately tested.
15. Custom ApplicationsComplex and custom applications may require several levels of requirement specifications. The requirements should define the intended use in the operating environment including limits of operation.
16. Requirements May Not be Fully DefinedRequirements may not initially be fully defined, example for some Category 5 systems. Requirements will be developed during subsequent phases of the project. The initial URS should recognise this and should be updated as information becomes available.
17. What Should the URS Contain?The contents of a URS typically include, but are not limited to the following:
  • Operational requirements
  • Functional requirements
  • Data requirements
  • Technical requirements
  • Interface requirements
  • Environmental requirements
  • Availability requirements
  • Security requirements
  • Maintenance requirements
  • Regulatory requirements
  • Migration of any electronic data
  • Constraints to be observed
  • Life cycle requirements
18. Get SMARTRequirements should be specific and appropriate for the desired system.
Remember get SMART
  • Specific
  • Measurable
  • Achievable
  • Realistic
  • Testable
19. Prioritize Your RequirementsPrioritize with emphasis on identifying the mandatory requirements.
Classify them as you see fit:
  • Mandatory (high)
  • Beneficial (medium)
  • Nice to have (low)
20. Clear CommunicationEnable clear communication and management of the critical requirements throughout the life cycle rather than being just seen as a paper exercise.
21. OwnershipOwnership of requirements lies with the regulated company. Without user ownership the business operational needs and any associated issues can never be fully understood and captured. Documented requirements from the basis for acceptance of the system by users.
Subject Matter Experts (SMEs), including those from third parties, may help both the user and technical communities analyse and understand the operational needs and develop and document appropriate requirements.
22. Requirement Planning PitfallsAspects of the requirements capture process require particular attention, including:
  • A common understanding of the requirements among team members should be established.
  • All required levels of the business should be involved during requirement capture.
  • Ambiguous requirements should be avoided and, where possible, requirements should be measurable.
  • Requirements should be classified to ensure that appropriate focus is given to critical requirements.
  • Functionality that will not be used should be avoided.
  • The original scope should be maintained, extending the scope should be possible only through a formal change control process.
  • An effective and efficient change management process should be implemented, incorporating impact assessment of changes based on risk, and formal version control.
  • Multiple requirements within a single requirement should be avoided.
                                       
               
            
               





回复

使用道具 举报

药生
发表于 2016-12-13 07:53:57 | 显示全部楼层
全英文,有压力。
回复

使用道具 举报

药生
发表于 2016-12-13 08:34:44 | 显示全部楼层
楼主这就是原文的全部吗?能否分享一下链接?
回复

使用道具 举报

药徒
发表于 2016-12-13 09:00:10 | 显示全部楼层
好难看懂啊。
回复

使用道具 举报

药士
 楼主| 发表于 2016-12-13 11:37:07 | 显示全部楼层
回复

使用道具 举报

药生
发表于 2016-12-13 12:18:08 | 显示全部楼层
beiwei5du 发表于 2016-12-13 11:37
http://learnaboutgmp.com/how-to-create-a-bullet-proof-urs/

多谢,多谢
回复

使用道具 举报

药徒
发表于 2016-12-15 13:39:10 | 显示全部楼层
有没有中文的,支持
回复

使用道具 举报

药徒
发表于 2016-12-15 16:37:38 | 显示全部楼层
有高手给翻译一下
回复

使用道具 举报

药徒
发表于 2016-12-16 10:24:52 | 显示全部楼层
学习了,谢谢分享!
回复

使用道具 举报

药徒
发表于 2016-12-16 10:24:56 | 显示全部楼层
学习了,谢谢分享!
回复

使用道具 举报

药徒
发表于 2016-12-16 10:25:02 | 显示全部楼层
学习了,谢谢分享!
回复

使用道具 举报

药神
发表于 2023-2-21 21:48:04 | 显示全部楼层
感谢分享。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

×发帖声明
1、本站为技术交流论坛,发帖的内容具有互动属性。您在本站发布的内容:
①在无人回复的情况下,可以通过自助删帖功能随时删除(自助删帖功能关闭期间,可以联系管理员微信:8542508 处理。)
②在有人回复和讨论的情况下,主题帖和回复内容已构成一个不可分割的整体,您将不能直接删除该帖。
2、禁止发布任何涉政、涉黄赌毒及其他违反国家相关法律、法规、及本站版规的内容,详情请参阅《蒲公英论坛总版规》。
3、您在本站发表、转载的任何作品仅代表您个人观点,不代表本站观点。不要盗用有版权要求的作品,转贴请注明来源,否则文责自负。
4、请认真阅读上述条款,您发帖即代表接受上述条款。

QQ|手机版|蒲公英|ouryao|蒲公英 ( 京ICP备14042168号-1 )  增值电信业务经营许可证编号:京B2-20243455  互联网药品信息服务资格证书编号:(京)-非经营性-2024-0033

GMT+8, 2024-11-24 18:32

Powered by Discuz! X3.4运维单位:苏州豚鼠科技有限公司

Copyright © 2001-2020, Tencent Cloud.

声明:蒲公英网站所涉及的原创文章、文字内容、视频图片及首发资料,版权归作者及蒲公英网站所有,转载要在显著位置标明来源“蒲公英”;禁止任何形式的商业用途。违反上述声明的,本站及作者将追究法律责任。
快速回复 返回顶部 返回列表