140 likes | 209 Views
The Requirements Balance. Test Managers Forum - April ‘08 Stevan Zivanovic stevan@probatur.com. Outline. Requirements and Techniques Agile Waterfall Iterative What is a good requirement? Debate. Requirement Techniques. Good requirements gathering is NOT easy
E N D
The Requirements Balance Test Managers Forum - April ‘08 Stevan Zivanovic stevan@probatur.com
Outline • Requirements and Techniques • Agile • Waterfall • Iterative • What is a good requirement? • Debate
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
Requirement Types • Reference: Software Requirements Styles and Techniques – Soren Lauesen, Addison Wesley 2002 • IEEE 830 – 1998 – Recommended Practice for Software Requirements Specification
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
Agile - Process • High level features defined • Refined during a “sprint” • Document only what is needed • Depend on good interaction with business during development
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
Waterfall - Process • High level requirement defined, reviewed and agreed • Low level requirements defined, reviewed and agreed • Specification defined, reviewed and agreed • Develop and test
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
Iterative (Unified Process) • Define Use Cases up front and gain formal agreement • Refine and modify requirements as project progresses
Iterative (UP) Advantages: • As Agile • Some of Waterfall Disadvantages: • Some of Agile • Less of Waterfall
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
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
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 3rd party development / testing • Are some Quality/Non Functional requirements implicit?