Prospective Validation - Requirements Phase
Business requirements are further developed to produce what is commonly called a user requirements specification (URS). The URS should focus on what the system should do and not to detail how to achieve this, i.e. design statements should not be incorporated. For large and complex systems, a number of URSs may be required. For small and simple systems the
business requirements and URS may be combined. The URS provides a statement of process/functional requirements of the proposed system. Each requirement should be categorised in order to define the level of importance, e.g. must, should, and could. All URS requirements should be successfully validated before system use unless otherwise justified
Each URS requirement should be:
• Referenced to facilitate requirements tracking (Requirements Traceability Matrix [RTM]).
• Unambiguous, clear and concise.
• Be approved by the end-user.
The URS provides the basis for system acceptance testing and should be approved before a design review is conducted.
An RTM or other equivalent mechanism should be established in order to provide a means of demonstrating how a particular function of a system/application has been validated through design (including any DQ), programming (including source code review), and testing (pre-qualification, IQ, OQ, PQ).