Agile Requirements Gathering Techniques
•Descargar como PPTX, PDF•
5 recomendaciones•6,797 vistas
Agile requirement gathering and elicitation techniques will be explained on this presentation. It is useful for Business Analysts and Agile practioners.
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Agile Requirements Gathering Techniques
Similar a Agile Requirements Gathering Techniques (20)
Último
Último (20)
Agile Requirements Gathering Techniques
- 2. Who am I? • Onur Demir, PMP, PSM • Beykent Uni Maths Computer Sc & MIS Double Degree • ITU Business & Technology Management Master • 7 years of Business Analyst Experience • 1 year as SAP Consultant at Novigo
- 3. Agenda • What is Requirement Gathering and why is it important? • Background for successful requirements gathering • Agile Modeling Techniques • Interface prototype • CRC • UML • User Stories • CASE Tools • Agile Documentation
- 4. It's difficult to build a solution if you don't know the requirements 3 types of requirement: • Business • Functional • Technical What is REQUIREMENTS GATHERING
- 6. What is a good REQUIREMENT ? • «We must be able to change an employee’s profile information» • «System should be easy to use» • «We should be able to enter the employee eye colour» • «The system should automatically be updated when the government changes the law»
- 7. TIPs • Ask Questions • Listen • Feedback • Agreement
- 8. Agile MANIFEST Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
- 9. • Management Support • Techniques • Terminologies • Keep it fun Stakeholder MANAGEMENT
- 12. User Stories
- 13. Interface PROTOTYPE • Collaborative approach for designing interfaces • Just use post-its/slicky notes
- 14. CRC Cards
- 15. UML Modeling • Basic UML modeling that customer understands • User roles and scenarios can be modeled
- 16. CASE Tools
- 17. MoSCoW • Must have • Should have • Could have • Would have
- 19. Scope VALIDATION
- 21. • “The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labour to build. Over the years we have learned to build bridges more efficiently, using fewer materials and less labor to perform the same task.” Tom Clancy – Sum of All Fears
Notas del editor
- Concious Non concious Undreamed
- Doğru soruları sormak önemlidir. Açık uçlu sorular sorun Paraphrasing yapın kopyalamayın Hemfikir olun
- Explain techniques Adopt to terminology Obtain Management Support Keep it fun
- Many organizations prefer a "big modeling up front (BMUF)" approach to modeling where you invest significant time gathering and documenting requirements early in the project, review the requirements, accept and then baseline them before implementation commences. This sounds like a great idea, in theory, but the reality is that this approach is spectacularly ineffective. A 2001 study performed by M. Thomas in the U.K. of 1,027 projects showed that scope management related to attempting waterfall practices, including detailed, up-front requirements, was cited by 82 percent of failed projects as the number one cause of failure. This is backed up by other research - according to Jim Johnson of the Standish Group when requirements are specified early in the lifecycle that 80% of the functionality is relatively unwanted by the users. He reports that 45% of features are never used, 19% are rarely used, and 16% are sometimes used. Why does this happen? Two reasons: When project stakeholders are told that they need to get all of their requirements down on paper early in the project, they desperately try to define as many potential requirements (things they might need but really aren't sure about right now) as they can. They know if they don't do it now then it will be too hard to get them added later because of the change management/prevention process which will be put in place once the requirements document is baselined. Things change between the time the requirements are defined and when the software is actually delivered. The point is that you can do a little bit of initial, high-level requirements envisioning up front early in the project to understand the overall scope of your system without having to invest in mounds of documentation.
- Update documentation only when it hurts.