1 / 11

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. Martin Dodd martinpdodd @aol.com. Terminology in the Functional Specification. Requirements

keira
Download Presentation

Martin Dodd martinpdodd @aol.com

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 Martin Dodd martinpdodd @aol.com

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

  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. Boundaries the solution MUST stay within: the constraints Solution space Requirement space Cost Time Standards Laws Constraints

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

  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. Different tests = different solution: e.g. Easy to use 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. 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. Cost of quality v cost of failure 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. When do you define acceptance? Define and agree the tests Requirements When it should be done Specification Design Build When it is often done Test

  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

More Related