Scribd
Upload
192 views

How To Create A Bulletproof URS

The document provides tips for creating a bullet-proof User Requirements Specification (URS). It recommends that requirements be clearly defined, testable, and specific to avoid ambiguity. Requirements should describe what the system should do without duplication. The URS should also be updated over time and used to evaluate and select vendors based on their ability to meet the specified requirements.

Uploaded by

Userzbatavia
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
192 views

How To Create A Bulletproof URS

The document provides tips for creating a bullet-proof User Requirements Specification (URS). It recommends that requirements be clearly defined, testable, and specific to avoid ambiguity. Requirements should describe what the system should do without duplication. The URS should also be updated over time and used to evaluate and select vendors based on their ability to meet the specified requirements.

Uploaded by

Userzbatavia
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 5

How to Create a Bullet-Proof URS

Over the last number of months it has become quite apparent to us at Askaboutvalidation.com that many of you out there are finding it difficult to create URS documents (for the beginners out there User Requirement Specifications). 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 nightmare of developing a bullet-proof URS The answer is, it can be very difficult if you dont 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 follwoing tips helpful!

1. Requirements
Requirements 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 Manner


Requirements 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 doesnt.

3. One Requirement at a Time


Do 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 Requirements

Changes 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 Testable


Requirements should be written such that they can be tested. Individual requirements should be traceable through the life cycle.

6. Configured Products
For 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 / Assessment


Regulated companies should be 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. Specifications
For 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 Training


The 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 Knowledge


Business 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 Requirements


Do 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. Dont be Afraid to Audit Vendors


Audits 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. Dont be afraid to Compare Vendors


Use your URS to compare vendors. Document the pros and cons of each vendor. If you learn something new during the proposal phase dont 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 Traceability


Assure 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 Applications


Complex 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 Defined


Requirements 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 SMART


Requirements should be specific and appropriate for the desired system. Remember get SMART

Specific Measurable Achievable Realistic Testable

19. Prioritize Your Requirements

Prioritize with emphasis on identifying the mandatory requirements. Classify them as you see fit:

Mandatory (high) Beneficial (medium) Nice to have (low)

20. Clear Communication


Enable clear communication and management of the critical requirements throughout the life cycle rather than being just seen as a paper exercise.

21. Ownership
Ownership 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 fro 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 Pitfalls


Aspects 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.

You might also like