April '081 The Requirements Balance Test Managers Forum - April ‘08 Stevan Zivanovic

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

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

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

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

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

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

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

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

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

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

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

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

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?