1. April '081 The Requirements Balance Test Managers Forum - April ‘08 Stevan Zivanovic stevan@probatur.com

2. April '082 Outline Requirements and Techniques Agile Waterfall Iterative What is a good requirement? Debate

3. April '083 Requirement Techniques Good requirements gathering is NOT easy Analysts need to be able to: –Familiar with multiple analysis techniques –Accurately interpret the customers needs –Translate the customers language into something for technical people –Determine how much to document

4. April '084 Requirement Types Reference: Software Requirements Styles and Techniques – Soren Lauesen, Addison Wesley 2002 IEEE 830 – 1998 – Recommended Practice for Software Requirements Specification

5. April '085 Why Bother? Requirements are used to: –Gain agreement from the Business –Act as a legal document –Define the contents of a project –Defined what to build –AND define what to test

6. April '086 Agile - Process High level features defined Refined during a “sprint” Document only what is needed Depend on good interaction with business during development

7. April '087 Agile Advantages: Keeps the business informed and can rapidly respond to business changes Very effective if the business do not have a clear view on the end solution No need for long requirements capture phase Disadvantages: A lot of refactoring as a result of not having the system in place to fully reconcile changes Not enough time spent on challenging the business model

8. April '088 Waterfall - Process High level requirement defined, reviewed and agreed Low level requirements defined, reviewed and agreed Specification defined, reviewed and agreed Develop and test

9. April '089 Waterfall Advantages: Process modelled and all aspects analysed Full agreement by all stakeholders before development Disadvantages: Requirements fixed possibly years before delivery – but the business changes Large requirements management overhead Users do not truly understand what they need

10. April '0810 Iterative (Unified Process) Define Use Cases up front and gain formal agreement Refine and modify requirements as project progresses

11. April '0811 Iterative (UP) Advantages: As Agile Some of Waterfall Disadvantages: Some of Agile Less of Waterfall

12. April '0812 What is a good requirement? SMART Have a suitable diagram Be supported by all stakeholders (business/user, analysts, project managers, developers, testers, support) Provide sufficient information Be clearly related to other requirements and goals

13. April '0813 The Requirements Balance Which is the “best” dev methodology Too many requirements vs too few Requirement techniques – too many or not enough Level of detail How relevant/believable are the requirements

14. April '0814 For Discussion Does Iterative development offer an optimal requirements approach? Do we need written requirements? What can we as tester do to optimise requirements? Can we blend Agile practices with Iterative requirement development? The challenge of 3 rd party development / testing Are some Quality/Non Functional requirements implicit?