Define what a user requirement is. Why they are important. How they will be used. How you will use them later on for testing.
User Requirements are a list of specific key details a product must include based on the instructions or scenario. In terms of creating a product, it is usually used as a checklist to ensure a product contains a certain list of features or functions. It is usually contained in a document form and outlines what a projected system must be capable of doing to solve the problems of a defined set of users
A good user requirement is:
• Verifiable- meaning it is confirmable, meaning it can be demonstrated.
• Complete- it should be comprehensive and full.
• Clear and Concise- It should be straight and to the point, and rather succinct
• Consistent, meaning it should be reliable and dependable
• Viable- the User Requirement should be both feasible and practicable.
• Traceable- it should perceptible
• Necessary- there should be a purpose to have the User Requirement in the first place
• Implementation free- meaning that the User Requirements don’t need to be applied or changed as the project continues.
A User Requirement is tested often by
• Inspection, which is a review of the product as a whole and in particular areas.
• Analysis which is an investigation or breakdown
• Demonstration, which is a testing session, to try the product.
A user requirement is verifiable by methods that will not alter the product or negotiate the data’s integrity. The purpose of this is to make it possible to evaluate whether the user requirement is met, and is used like a checklist when creating the application.
A clear and concise requirement must:
• consist of a single task or requirement
• It should be concise and no more than 30-50 words in length. Any more than that is covering more than a single point and would be un-needed and this level of detail is not required at this stage of the project.
• The User Requirement must be easily read and comprehended by non-technical people so therefore needs top include language which is exact but not overly technical
• It must be explicitly clear and not prone to multiple interpretations or understandings.
• It must not contain meanings, descriptions of its use, or reasons for its need as it is only meant to state what the requirement is and any other details may be changed along the development process.
• It must avoid subjective or open-ended terms so that it can mean the same thing to whoever interprets it.