and products in general. It follows similar rationale and logic behind naming hurricanes and tornadoes in that a requirement is assigned an exclusive number that remains its own even if the article becomes scrapped. This ensures accurate traceability across multiple versions of the documentation and scope changes. The numbers are assigned to a final draft before release to the design, development, and test teams for the ambiguity review process. This ensures that there is no confusion amongst the BA team when documenting the requirements. Numbers are only assigned to the high level requirements; sub-numbers are assigned to the mid- and low-level requirements since they are extensions of the high level requirements. For example, if the requirements for a web shopping cart state that the application must be able to calculate the tax for the specific state and/or province of the online customer, the requirement would be written as: 1.1 Customers must be able to select their state AND/OR province from a selector. However, the requirement is later reworded to state that the application must be able to calculate the tax for the specific state and/or province of the online customer, then the requirement would be rewritten as: 1.1 Requirement Removed. 1.2 The state or province from the customer's profile will be used to calculate the taxes on the purchase. Validation Validation uses a combination of ambiguity techniques derived from Requirements Based Testing and Logic Modeling. These techniques include an ambiguity log, an ambiguity review, and ambiguity walkthroughs involving the design, development, and testing teams to establish clarity and completeness of the requirements. The reviews and walkthroughs utilize a clear set of criteria for the reviewers to ensure that the information is complete, consistent, accurate, and written in language that clearly states and defines the intended functioning of the new software. Benchmarking Proponents of this methodology are able to apply a specialized formula to determine the effectiveness of requirements' activities by benchmarking and measuring against the established benchmark. By benchmarking requirements activities across a project, the BA team is able to better understand where time is being spent, how to improve, and to be able to increase task efficiency and effectiveness as a means of improving the project. This has proven to be the most effective technique for rapidly re-aligning a flagging project because of the insight it provides the team during the process. By benchmarking requirements activities in general across