multiple projects, organizations are able to get a more detailed picture of the requirements' activities and where they can be improved. This can indicate opportunities for training among the Business Analysis team, a need for more resources, or more executive support, but can also indicate if the problem is with the development or testing teams. It can also provide enough evidence to support changing the overall life cycle processes. Business Rules Business rules are typically separated out into a separate document with references made within the requirements themselves. The naming and numbering conventions are the same as for the requirements but are indicated as rules with a 'B' preceding the number. For example, if the business rule B36 for the same shopping cart, states that taxes shall be calculated on the total purchase amount according to a 12% British Columbia tax rate, then the business rule would be written as: B36.1 British Columbia tax rate 12% If requirement 1.1 references this business rule, it would be written as: 1.1 Customer must be able to select their state AND/OR province from a selector. Applicable Business Rules: B36 Use Cases Use Cases can be started at any point during the requirements process and polished as the requirements are completed. Their value is in adding a layer of validation for the requirements to support a review for completeness. These may be presented to the users in a walkthrough to help validate the step-by-step process through which the user and system will go in performing specific transactions. Both literary (descriptive) and diagram (such as UML, Activity or Swim Lane) use cases are appropriate for this due to the value each of these can provide to the end users. References External links Access to official CRRSP Information (including certification & downloads) on Requirements Networking Group Bender RBT website Software project management