1. 1 Martin Dodd martinpdodd @aol.com Transaction Log and Data Exchange Standards The requirements documents Requirements, constraints and acceptance criteria: An introduction for the non-technical reader 2 June 2003 Bonn, Germany

2. 2 Terminology in the Functional Specification Requirements –Functional requirements –Non-functional requirements Constraints Acceptance criteria

3. 3 Why and what…a crucial distinction Solution space Requirement space The functional specifications: - Allow flexibility for what has not yet been agreed (e.g. transaction sequences ) - Reflect decisions already made (e.g. use of ISO3166)

4. 4 Boundaries the solution MUST stay within: the constraints Solution space Requirement space Constraints Cost Time Standards Laws

5. 5 Defining target level quality: the acceptance criteria Solution space Requirement space Constraints Cost Time Standards Laws Acceptance criteria Speed Security Ease of use

6. 6 Different types of requirement need different quality tests Quality may be defined as: the totality of features and characteristics of a product or service that bear upon its ability to satisfy stated and implied needs ISO 8402 Where the quality test result is binary (e.g. yes/no or right/wrong) we refer to the relevant requirement as FUNCTIONAL Where the quality test result is a measure or a score (e.g. from 1-10 or high/medium/low) we refer to the requirement as NON-FUNCTIONAL

7. 7 Different tests = different solution: e.g. Easy to use SupplierClient 95% of a statistically valid, randomly selected panel of users found the site easy to use or very easy to use. After 10 minutes of trying, my 12 year old daughter gave up. Defining the tests and measures in collaboration with the vendor will ensure that everyone has the same understanding of what the non- functional requirements mean.

8. 8 Testing non-functional requirements: E.g. Efficiency Defining the tests and measures in collaboration with the vendor will allow you to make informed choices and understand the likelihood of success

9. 9 Cost of quality v cost of failure If cost of failure is HIGH High Integrity Production If cost of failure is LOW Development Scratch The cost of failure on discrepancy prevention is high, so the quality criterion should be high integrity. For other requirements, e.g. availability, cost of failure is lower (because loss of availability is easier to manage).

10. 10 When do you define acceptance? Requirements Specification Design Build Test Define and agree the tests When it should be done When it is often done

11. 11 Summary Requirements –Define needs: What the solution SHALL do, not what the solution may be –Can be functional or non-functional Constraints –Are the boundaries the solution MUST stay within –Cannot be broken without permission Acceptance criteria –Define the target level of quality –Provide the basis of choice between solutions that meet the requirements and constraints