Presentation on theme: "April '081 The Requirements Balance Test Managers Forum - April ‘08 Stevan Zivanovic"— Presentation transcript:
April '081 The Requirements Balance Test Managers Forum - April ‘08 Stevan Zivanovic email@example.com
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?
Your consent to our cookies if you continue to use this website.