Downloaded 164 times
Uploaded byOnur Demir
Agile Requirements Gathering Techniques
The document discusses the importance of requirements gathering in agile project management, emphasizing the need for clear business, functional, and technical requirements. It outlines effective techniques, such as user stories and UML modeling, as well as the significance of stakeholder management and collaboration. The agile manifesto principles are highlighted to reinforce the value of adaptability and iterative development in meeting project goals.
More Related Content
Similar to Agile Requirements Gathering Techniques
![[Software Requirements] Chapter 20: Agile Projects](https://cdn.slidesharecdn.com/ss_thumbnails/agileprojects-160123143930-thumbnail.jpg?width=640&height=640&fit=bounds)
Agile Requirements Gathering Techniques
- 1.
- 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 isRequirement 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 tobuild a solution if you don't know the requirements 3 types of requirement: • Business • Functional • Technical What is REQUIREMENTS GATHERING
- 5.
- 6. What is agood 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 • AskQuestions • Listen • Feedback • Agreement
- 8. Agile MANIFEST Individuals and interactionsover 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
- 10.
- 11.
- 12.
- 13. Interface PROTOTYPE • Collaborative approachfor designing interfaces • Just use post-its/slicky notes
- 14.
- 15. UML Modeling • BasicUML modeling that customer understands • User roles and scenarios can be modeled
- 16.
- 17. MoSCoW • Must have •Should have • Could have • Would have
- 18.
- 19.
- 20.
- 21. • “The Romanbridges 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
Editor's Notes
- #5 Concious Non concious Undreamed
- #8 Doğru soruları sormak önemlidir. Açık uçlu sorular sorun Paraphrasing yapın kopyalamayın Hemfikir olun
- #10 Explain techniques Adopt to terminology Obtain Management Support Keep it fun
- #12 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.
- #21 Update documentation only when it hurts.