Learn, Share and Keep Learning
| Requirement Verification |
| Templates - Checklist Guidelines |
|
It is a well established fact that early involvement of testers during the software development life cycle brings immense value to the project. Participation of the testers during the requirement phase helps in identifying and correcting defects in the requirements. As a tester if you are involved in the requirement phase you need to know , what attributes you should be looking for in the requirements? How can you ensure quality of the requirements? Following checklist gives you information about the attributes which should be tested for every requirement. These are just a subset of attributes that as a tester you will be interested in.
a. Complete: Every requirement should be complete and give complete information on what is expected. For example, provide a shopping cart to the website is not a complete requirement. Complete requirement could be stated as "Provide shopping cart to the registered user who can pay using credit card and are within the EU region" b. Correct: This is self explanatory, it is expected that every requirement specified in the requirements document will be correct. This can be ensured by having stake holders/client representatives in the team. c. Precise, Unambiguous and clear: Each item in the requirement should be clear and have single interpretation, for every member in the team; the meaning of each item should be understood and specifications should be easy to read. For example, response time of the application should be good. Now good can have different meaning for different people. Requirement should be stated as "With an anticipated load of 1000 simultaneous users, system should respond with in 4 seconds." d. Consistent: Requirement should not conflict with each other. For example if one requirement states that "Additional 2% charges should be applied for the people shopping out side US" and another says "Options to buy/sell should be disabled for the people who are not in US", these two requirements are conflicting. Either one of them is wrong or not clear, and you should seek clarification from the stake holders or clients representatives. e. Relevant: Each item is pertinent to the problem and its solution. For example, if we are dealing with the problem of providing web interface to the existing retail operation, information related to staffing may or may not be pertinent to the problem we are solving. You should hunt for clarification on why this item is present in the requirements documents. f. Testable: Every requirement should be testable, it should be possible to determine whether the stated requirement has been satisfied or not. For example, requirements like application navigation should be very good is very difficult to test. Testable requirement should be that "The user should be able to navigate from one page to any other page on the site with maximum three clicks". g. Feasible: It should be possible to implement requirement with the available techniques, tools and resources within the specified cost and schedule constraints. h. Free of Unwarranted Design Detail: The requirements specifications are a statement of the requirements that must be satisfied by the problem solution. Requirements document, ideally should not implementation and design details. i. Manageable: The requirements should be expressed in such a way that each item can be changed without excessive impact on other items. Even if there is any impact, it should be minimum and and it should be possible to identify dependencies in the requirements for impact analysis. |
| Last Updated on Wednesday, 28 January 2009 15:18 |