The User Requirements Specification (URS) is raised by the end user at URS Level One stage, and specifies what the end user requires the equipment to do. Additionally, any regulatory guidance, mandatory instructions or conditions of use, must be included into the URS. The URS must be the subject of one or more peer reviews where the user, the maintainer and QA, review and ensure that the document is clear and concise in all the requirements detailed. The guidelines below are used by our own authors.
- Each requirement must be uniquely referenced, although not mandatory, attempts at this stage should be made to keep each requirement to less than 200 words.
- Requirement statements should not be duplicated or contradicted.
- The URS should express requirements and not design solutions.
- Each requirement should be testable.
- The user requirement specifications must be understood by both the customer and supplier; ambiguity and jargon must be avoided.
- Whenever possible, the user requirement specifications must distinguish between regulatory requirements and desirable features, by using should to represent a nice to have function, and must to indicate a mandatory function.
- There should be a formal review of the URS between the customer and supplier to ensure that requirements are understood.
Using the
URS produced above, along with
Validation Plan (VP),
GAMP 4 any other relevant regulatory or guidance documents, the supplier should prepare a Function Specification (FS). Traceability from the basic requirement as detailed in 1 above, to the functionality in the FS required to produce functionality 1, is maintained. This traceability is used to produce URS Level Two.
When software is required then the same must recur, lines (and or groups) of code must be traceable back to each functionality as given in level 2. This traceability is used to raise URS Level Three.
Note:The preparation of the Software User Requirement Specification Level three, forces the various concerned groups in the customer’s organization to consider rigorously all of the requirements before design begins and reduces later redesign, recoding, and retesting. Careful review of the requirements in the Software Requirement Specification can reveal omissions, misunderstandings, and inconsistencies early in the development cycle (Full Life Cycle) when these problems are easier to correct. This procedure is mandatory if the software use can have an impact on product quality, or is used to store or manipulate predicate rule derived data.
URS RELATIONSHIP TO VALIDATION.
USER REQUIREMENT SPECIFICATION.
