Requirements Engineering @ Agile
- 1. Requirements Engineering @ Agile Opportunities for getting requirements right in Agile
- 2. Take Aways From This Session Quick Refresher < 5 minutes • Agile Basics • Fundamentals of Requirements Engineering (RE) RE Practices in the Agile World (Scrum) Comparison of RE Practices – Classic vs. Agile Assessment of RE @ Agile Version 5.1 | 2
- 3. Why Agile? Version 5.1 | 3 Flexibility New and changed requirements are welcome Time to Market Turn requirements fast into functional software and deliver it Feedback Make sure that requirements and deliverables meet the needs of the customer Productivity Concentrate on action, that will … • Create value • Facilitate team work and efficiency Agile Basics
- 4. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: What is agile ? – Values of the “Agile Manifesto” That is, while there is value in the items on the right, we value the items on the left more. 4Version 5.1 | Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Agile Basics
- 5. Principles behind the “Agile Manifesto” Source: http://agileManifesto.org/ 5Version 5.1 | • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome change, even late in development. Agile processes harness change for the customer's competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile Basics
- 6. Big Bang = Big Risk 6Version 5.1 | Just one delivery to the customer First shot has to meet the aim No feedback about the Usability for a long time Risk: Customer is in the end Source: Agile Basics
- 7. Agile Approach: Continued Integration/Delivery and Feedback 7Version 5.1 | Customer feedback about usability Product- increments Source: Agile Basics
- 8. What is a requirement? Version 5.1 | 8 IEEE Standard Glossary of Software Engineering Terminology. IEEE Std 610.12-1990 Fundamentals of Requirements Engineering A requirement is ... • (1) ... a condition or capability, needed by a user (person or system) to solve a problem or to achieve an objective. • (2) ... a condition or capability, that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents. • (3) ... a documented representation of a condition or capability as in (1) or (2).
- 9. Three Requirement Types Version 5.1 | 9 • Functional Requirements define functions to be provided by the system • Quality Requirements define quality characteristics, which the system or its functions shall possess. • Constraints are organizational or technical guidelines to be followed during design and implementation of the system. Non-Functional Requirements Fundamentals of Requirements Engineering
- 10. Requirements Engineering consists of four activities Version 5.1 | 10 Elicitation Documentation Management Validation and Negotiation Requirements Engineering • Elicitation: Requirements from stakeholders and other sources are identified, detailed and refined. • Documentation: The compiled requirements are described adequately. • Validation and Negotiation: Documented requirements are validated and negotiated at an early stage in order to comply with the required quality criteria. • Management: Requirements management includes all measures to structure requirements, to prepare them for different roles and to change and implement requirements in a consistent way. Fundamentals of Requirements Engineering
- 11. 11Version 5.1 | RE Practices in the Agile World (Scrum)
- 12. Take Aways From This Session Quick Refresher RE Practices in the Agile World (Scrum) • Scrum Process • User Stories • Product Backlog • Sprint Planning • Definition of Done Comparison of RE Practices – Classic vs. Agile Assessment of RE @ Agile Version 5.1 | 12
- 13. Scrum Process Version 5.1 | 13 Source: https://commons.wikimedia.org/wiki/File:Scrum_process-de.svg#filelinks/ RE Practices in the Agile World (Scrum)
- 14. Development team • Discusses and improves Stories with the Product Owner • Delivers for each Iteration ( Sprint) Increments, that implement the planned User-Stories Scrum Master • Coach for the Scrum Team • Establishes Scrum Rules • Removes Obstacles and disturbances for the Team Product Owner • Is held responsible for the Value of the Product • Manages Sources of Requirements and Stakeholders • Monitors the Product Backlog: Which Requirements ( Stories) have to be done first ? Roles in Scrum Processes Version 5.1 | 14 RE Practices in the Agile World (Scrum)
- 15. Maturing of Requirements with Scrum Version 5.1 | 15 Product Discovery • General objectives of the product in connection with business value • Target groups and their needs e.g. as fictitional person ( Personas) Epics • High-Level Requirements for overall product features User Stories • Represent Requirements • Sound Stories comply with the INVEST- Principles: I ndependent N egotiable V aluable E stimatable S mall T estable RE Practices in the Agile World (Scrum)
- 16. Why Stories? Version 5.1 | 16 Small and focused contains easy to plan and realize Will improve communications and interaction with the customer more precise Will focus on business value and costs of the requirements (Stories) Stories will reduce waste. • They’ll be written when needed • The way they are compiled they’ll stay useful and relevant. • They’ll delay decisions to the last possible moment. • They are placeholders, to keep the detailed descriptions till later Stories (and their acceptance criteria, tests) describe the relevant requirements. They can be split and joined with little effort. RE Practices in the Agile World (Scrum)
- 17. 3 C’s of a User Story Version 5.1 | 17 Card: A sentence representing the story: As a <role> I want <wish>, so that <purpose> Conversation: Team and Product Owner agree on a common understanding of the Story Confirmation: Acceptance criteria … … define, when a Story is done (Definition of Done) … should be SMART : Specific Measurable Acceptable Realistic Timed Acceptance Test Driven Development Test cases are part of the requirements: • Realistic examples / Scenarios ( Specification by Example) • Expected results ( Given <context>, when <event>, then <result>) RE Practices in the Agile World (Scrum)
- 18. Agile Requirements Management Version 5.1 | 18 Product Backlog • Sorted sist of stories, to develop the product • Contains epics and user stories • Stories clustered by technically related subjects • Sorted according to value, risk, priority and necessity • Keeps continuously evolving and changing over time Task of RE: The Product Backlog has to be “DEEP“ : D etailed appropriately E stimated E mergent P rioritized Detailed Stories ready for the next Sprint Stories with less detail, to be improved for future Sprints Rough Stories e.g. Epics or Ideas RE Practices in the Agile World (Scrum)
- 19. Working the Product Backlog Version 5.1 | 19 Backlog Refinement (Grooming) • Development Team and Product Owner discuss Stories in order to get a better understanding of the stories • Details (e.g. Acceptance criteria) are added and effort (Story Points) estimated • The Team splits big Stories ( Epics) into smaller ones • The Product Owner prioritizes the Stories Definition of Ready When is a Story ready for a Sprint? Example: • Story has been estimated for Functionality / Complexity / Testability • Functional and nonfunctional Requirements are defined • Test cases for each Story are defined (are often added while planning the Sprint) • Constraints and Dependencies for each Story have been defined • Acceptance criteria for each Story are known and defined • Functionality is drafted (Mockup, Prototype, Design Briefing...) • Tasks for Implementing und Testing the Story have been identified and estimated RE Practices in the Agile World (Scrum)
- 20. What is “done”? – Definition of Done (DoD) Version 5.1 | 20 Definition of Done Criteria of what it means that a Product has been completely implemented Examples: • All Acceptance Criteria are met • Code has been delivered and checked into the Versioning Tool • Documentation / Update was done • Release Documentation has been updated • Code Review has been performed or the coding was done by Pair Programming • Coding Guidelines and Standards have been observed • Unit Tests executed and "Green" • No critical Bugs unsolved • "Functional Tests" have been successful on all levels The criteria for “done” are applied to each single User Story (Story Level), that means, they have to be met, so that the stories can be regarded as delivered and approved RE Practices in the Agile World (Scrum)
- 21. Other Levels of the Definition of Done Version 5.1 | 21 Sprint Level Criteria … … have to be met, so that the artifacts (systems or components) of a sprint could be released (which doesn’t necessarily mean that they will be released for production) … should ensure, that all artefacts together with other systems and components will run properly in the operational environment Examples: • Separate deployment on the integrations-(test)-system. • Stories are tested together with other external systems and components. Integrations- and Interface tests have been defined and successfully executed • Performance is as defined • Tests on business case level have been successful • No release preventing errors open • Technical documentation of the system has been done or is updated • All changes of the system have been documented RE Practices in the Agile World (Scrum)
- 22. Other Levels of the Definition of Done Version 5.1 | 22 Release- and Product level criteria Successful run on the PreLive environment is a precondition for releasing the software into production Examples: • Artefacts are ready for release ( DoD at Sprint Level) and cleared for Deployment • Binaries are in the Repository with their respective Release numbers • All Business Case Tests have been defined and the results have been documented • Release-Notes contain all information regarding configuration • Known defects and possible effect on operation are documented • Results of the PreLive Tests are available • Depending on the release more tests have been performed e.g. Security, Performance • Tolerated-Online-Time for open defects has been calculated • Adequate Performance has been proved for performance critical changes • On Release Level the operation of the system has been tested successfully : start; stop; restart (functional/ technical), Monitoring RE Practices in the Agile World (Scrum)
- 23. 23Version 5.1 | Comparison of RE Practices - Classic v/s Agile
- 24. Take Aways From This Session Quick Refresher RE Practices in the Agile World (Scrum) Comparison of RE Practices – Classic vs. Agile • Order of Activities • Roles in the Organization • Stakeholder Involvement • Requirements Elicitation • Requirements Documentation • Feedback and Rework of Requirements Assessment of RE @ Agile Version 5.1 | 24
- 25. Order of Activities Version 5.1 | 25 Classic: RE-Activities are located in an closed first Phase of the Project Requirements Engineering happens as a first closed phase in a project. At the end of the phase the requirements are complete and in full detail. Later Changes (Change Requests) are treated as exceptions. Agile: RE-Activities will be iterative and parallel to Design, Implementation and Test RE-Activities go along side the complete software life cycle. Stakeholders will give their feedback for early delivered product-Increments. Requirements will be changed and refined following that feedback. Comparison of RE Practices – Classic vs. Agile
- 26. Roles in the Organization Version 5.1 | 26 Classic: RE- Activities will be performed by predefined Roles The RE-Role is often personally and organizational separated from other roles. Team members often occupy just one role: • Product Manager • Business Analyst • Software engineer or • Tester and belong to their respective organizational unit. Agile: RE-Activities are performed by interdisciplinary teams Each single team member will have multiple roles: • Requirements Engineer • Software engineer and • Tester And has to develop the necessary skills Comparison of RE Practices – Classic vs. Agile
- 27. Stakeholder Involvement Version 5.1 | 27 Classic: Including of the Stakeholders happens in specific phases Requirements engineering Proof of Concept A-Sample (e.g. Prototype) Test of B-Sample (Functions operational, Components not completely approved) Field test with C-Sample (All Components of a serial production) Pre-production with D-Sample (pre-production sample) Agile: Continuous Collaboration with Stakeholders and Customers Identify the functional requirements at business case level Improve / split the requirements so that they be “Ready” according to definition Discover and consider non-functional requirements Confirm that requirements are fulfilled Comparison of RE Practices – Classic vs. Agile
- 28. Requirements Elicitation Version 5.1 | 28 Classic: Experts predict what the Customer wants Marketing Experts … • analyze the market, • Create Customer segments, • define and advertise the product-features. Till the product is delivered, customer segments and needs will change. Agile: Customer feedback will determine the Evolution of the Products Fast delivery of a minimalistic, useful product Gather real feedback from real customers Define customer segments with more detail ( Personas) Understand the needs of the customer segments Develop intuition for innovations, that will meet the customer segments needs Deliver product improvements fast and get feedback etc. Comparison of RE Practices – Classic vs. Agile
- 29. Requirements Documentation Version 5.1 | 29 Classic: “Complete and detailed” – “as early as possible” • Lots of assumptions, that will only be validated much later • Long project duration will make changes of the environments more probable • Documentation will be outdated and produce a lot of maintenance effort Agile: “Just Enough” – “Just in Time” • Documents only, what will produce lasting value for the stakeholders or the team • … and only up to the necessary depth of detail (that can be rather high) • Up to date, accurate, useful • Example: Test cases enhance and detail the requirement documentation Comparison of RE Practices – Classic vs. Agile
- 30. Feedback and Rework of Requirements Version 5.1 | 30 Classic: Tedious and long-lasting rework “First shot has to hit the goal” More effort and more defects in the process of adapting of the requirements to… • Feedback from stakeholders • New findings from implementation and test • Changes in the product context High Risk, to develop software that won’t meet the stakeholders expectations for a long time before it can be discovered Agile: Fast follow up of small, incremental changes and development of the product Knowledge gained in one sprint will be considered in the next one Continuous, direct feedback will allow a fast adjustment of the requirements Comparison of RE Practices – Classic vs. Agile
- 31. 31Version 5.1 | Assessment of RE @ Agile
- 32. Take Aways From This Session Quick Refresher RE Practices in the Agile World (Scrum) Comparison of RE Practices – Classic vs. Agile Assessment of RE @ Agile • Advantages • Disadvantages • Recommendations Version 5.1 | 32
- 33. Advantages Version 5.1 | 33 Flexibility: • Fast and flexible handling of requirement changes Feedback: • Stakeholder are actively and continuously involved in the validation of requirements Productivity: • Implementation of requirements will timely be demonstrated to the stakeholders Continuous Improvement of product and cooperation • Small user stories will be quickly implemented and the value confirmed through regular feedback • Lessons Learned is often performed within each Sprint there is a retrospective • Concentration on few improvements for each spring will increase the chance to succeed Assessment of RE @ Agile
- 34. Disadvantages Version 5.1 | 34 Fuzzy planning for product releases • No definite commitment, which requirement will be delivered when and at what cost More Management Resources needed: • Business analysts and product owner need to invest more time to participate in the RE Not used to: • Stakeholders need to change their mindset to adopt agile principles and practices Challenging • Small Teams need a larger range of skills and knowledge including RE No one size fits all • Big projects and safety critical systems need an appropriate approach e.g. Traceability and change control of the requirements have to be guaranteed Assessment of RE @ Agile
- 35. Recommendations – Improve classic RE Skills in Agile Teams Version 5.1 | 35 Product Owner (PO) needs classic RE Practices • Stakeholder Management • Source of Requirements • Elicitation Techniques • Use of the Kano Model • Methods for prioritizing (Kano, Cost/Benefit Analysis) Project teams need classic RE Practices (together with many other skills) • Elicitation Techniques (PO can delegate elicitation, but will remain accountable) • Improve and split the requirements (in Dialog with PO) • Validation of requirements (through Feedback) Assessment of RE @ Agile
- 36. Recommendations – Structure RE Version 5.1 | 36 Control the abstraction level of the requirements • Long-term Planning (3 to 12 months in advance) Goals describe the product vision from a business point of view • Medium-term Planning (1,5 to 6 months in advance) Epics describe rough features in the product backlog Backlog Refinement: Stories have to be split into easy to handle User Stories • Short-term Planning (1 to 3 sprints in advance) User Stories detailed to a level appropriate to facilitate their implementation Stories fulfill the definition of Ready and can be implemented in the next sprint Story Mapping • High-Level Use Case Model gives an overall picture of the product • Each User Story will incrementally increase the functionality of one Use Cases • Mapping: Refer the stories to the extended Use Cases Assessment of RE @ Agile
- 37. Recommendations – Consider Constraints for RE Version 5.1 | 37 Industrial norms and process reference models formulate expectations for • The quality of the requirements documentation • The quality of the requirements engineering process Examples: • IEC 61508 (interbranch) • ISO 26262 (automotive) Agile Teams have to know and implement the standards of their respective domain • How they achieve this remains in their own sovereignty Approved Practices • Split User Stories into functional groups ( Story Mapping) • Add acceptance criteria to the User Stories • Map Traceability with a tool Assessment of RE @ Agile
- 38. Thank you for your attention. Girish Khemani https://www.linkedin.com/in/girishkhemani
Editor's Notes
- #5: Source: http://agilemanifesto.org/iso/en/manifesto.html