the Data Flow Sales Order. Notice that the “form” hasn’t been documented. Salesperson, Current Date, Price, SKU, CAT, Vat Amount and Total Amount are NOT included because the customer does not provide this information. It is incorrect to document Stock Size at data primitive, because, if you “interview the data” on the form, you will notice that they use the Size column to document lots of different information which could be weight (grams and kilograms), package size (50 per pack), volume (litre) or a diameter (254mm). Payment Method is iterated, because if the customer wants to pay by cash, cheque, Visa and/or Master, BSS will accept it. The content of the Payment Method i.e. Cash, Cheque, Visa, Master will be documented in the Data Element Specification as a domain, so that if and when BSS alters their accepted payment methods i.e. Removing cheque and replacing with Maestro, the change is easily made to the specification.
test cases. You can define the data that you expect to pass AND fail. In the example above, the positive data, should pass the test and the negative cases should fail. You can take this concept a step further, by adding data that you expect to pass and data that you expect to fail. This will further confirm that you have documented the correct requirements