User Requirement Specification is a document, which can be either supplemental information regarding business process requirements to the software professionals, as in specifying assertions about various modules of the software, or can be the complete specification of the software. Also, URS is a key document from the prospects of Computer System Validation(CSV) / Computer Software Assurance(CSA).
During the interaction for GxP system implementation with various life science clients, we have noticed that users expect, IT professionals to provide User Requirement Specification (URS), this approach will mislead the project and end up with the situation, where, either user has to compromise on their requirement or project cost and timeline is increased. The core reason for this approach is mainly atelophobia in users for drafting a new type of specification.
To refer pre-drafted URS, shared from IT company, is not the wrong approach, but players in the Life Science niche must consider this pre-drafted URS as a frame only and have to modify the document, on the basis of their requirements as per their organizational practices with the support of in-house SME or Business Process Consultant.
To overcome the atelophobia in users for preparing URS, we are coming with a 7 Point guideline, that helps GxP application implementer/ Functional Owner to prepare smart and error-free URS-
1. Title of the Document:
Firstly, the Title of the document should be generic (and not the name of the marketed product) and must denote the process name for which software will be developed. E.g. Instead of “Trackwise Management System for QMS”, the title should be “Implementation of Software-based Quality Management System”.
2. Unique Document No. and Sequential Version No.:
Document No. should be uniquely defined in a way that from the number itself, a system can be identified. Version for each revision should be maintained, which is helpful to organize the document history.
3. Introduction of Requirement:
In this phase, give a brief introduction of the system, which defines the purpose of the document and scope of the system.
4. Abbreviation:
It is an abbreviated form of a word, that helpful when the client needs to squeeze lots of writing into a small space.
5. Elements of Reference Document:
It is good to list out the references of the current Procedure, Quality/ Business Policies, Regulatory Guidelines, and other resources from where we took the reference to draft URS.
6. Requirement Category and Numbering:
The various requirement should be categorized and ID of each requirement must contain an abbreviation of category. Below listed are a few examples of the category along with their abbreviation.
Security Requirements-[SC]
Reporting Requirements-[AT]
Electronic Record and Electronic Signature Requirements-[ERES]
Interface Requirement Including the Data Requirements-[IRID]
Migration Requirements-[MR]
Database Backup/ Restore and Archive/ Retrieval Requirements-[DB]
Network and Hardware-[N-HW]
Business Requirement-[BR]
7. Writing Method of User Requirement Specification:
Know the document’s purpose.
If your company has CSVMP guidelines and formats, use it.
Write in a clear, conversational style.
Be direct, concise, specific, and consistent and must be SMART (Specific, Measurable, Achievable, Realistic and Testable).
Use jargon sparingly.
Make your writing cohesive and easy to follow.
Prefer the active voice over the passive.
Use stacked lists and visuals if appropriate.
Break the writing up into short, readable sections.
Try to mention as much as possible workflow and business process diagrams.
Give a reference for various Business Process Scenario.
Also, Please DM or mail on info@srutatechnologies.com for free URS format and more detailed to improve your URS to have the best software implementation experience.
During the interaction for GxP system implementation with various life science clients, we have noticed that users expect, IT professionals to provide User Requirement Specification (URS), this approach will mislead the project and end up with the situation, where, either user has to compromise on their requirement or project cost and timeline is increased. The core reason for this approach is mainly atelophobia in users for drafting a new type of specification.
To refer pre-drafted URS, shared from IT company, is not the wrong approach, but players in the Life Science niche must consider this pre-drafted URS as a frame only and have to modify the document, on the basis of their requirements as per their organizational practices with the support of in-house SME or Business Process Consultant.
To overcome the atelophobia in users for preparing URS, we are coming with a 7 Point guideline, that helps GxP application implementer/ Functional Owner to prepare smart and error-free URS-
1. Title of the Document:
Firstly, the Title of the document should be generic (and not the name of the marketed product) and must denote the process name for which software will be developed. E.g. Instead of “Trackwise Management System for QMS”, the title should be “Implementation of Software-based Quality Management System”.
2. Unique Document No. and Sequential Version No.:
Document No. should be uniquely defined in a way that from the number itself, a system can be identified. Version for each revision should be maintained, which is helpful to organize the document history.
3. Introduction of Requirement:
In this phase, give a brief introduction of the system, which defines the purpose of the document and scope of the system.
4. Abbreviation:
It is an abbreviated form of a word, that helpful when the client needs to squeeze lots of writing into a small space.
5. Elements of Reference Document:
It is good to list out the references of the current Procedure, Quality/ Business Policies, Regulatory Guidelines, and other resources from where we took the reference to draft URS.
6. Requirement Category and Numbering:
The various requirement should be categorized and ID of each requirement must contain an abbreviation of category. Below listed are a few examples of the category along with their abbreviation.
Security Requirements-[SC]
Reporting Requirements-[AT]
Electronic Record and Electronic Signature Requirements-[ERES]
Interface Requirement Including the Data Requirements-[IRID]
Migration Requirements-[MR]
Database Backup/ Restore and Archive/ Retrieval Requirements-[DB]
Network and Hardware-[N-HW]
Business Requirement-[BR]
7. Writing Method of User Requirement Specification:
Know the document’s purpose.
If your company has CSVMP guidelines and formats, use it.
Write in a clear, conversational style.
Be direct, concise, specific, and consistent and must be SMART (Specific, Measurable, Achievable, Realistic and Testable).
Use jargon sparingly.
Make your writing cohesive and easy to follow.
Prefer the active voice over the passive.
Use stacked lists and visuals if appropriate.
Break the writing up into short, readable sections.
Try to mention as much as possible workflow and business process diagrams.
Give a reference for various Business Process Scenario.
Also, Please DM or mail on info@srutatechnologies.com for free URS format and more detailed to improve your URS to have the best software implementation experience.
Comments
Post a Comment