You may probably recognize the situation when a requirements professional is assigned to a new, challenging, agile project. As Scrum does not know the role of a Requirements Engineer (RE) or Business Analyst (BA), the requirements professional will either become the Product Owner or be part of the Scrum Team (which consists of members with cross-functional know-how). Either way, the activities of requirements engineering will be executed in some way in an agile environment: that is handling requirements, often associated with user stories, eliciting needs from various stakeholders, documenting them accordingly, negotiating them and achieving acceptance and finally dealing with changes. There is definitely a lot that goes on with requirements in Agile projects. Sometimes, you may not recognize that a practice used is nothing other than the basic method such as prioritisation; it becomes even more important and may be performed in a very similar way to traditional approaches (e.g. single-criterion classification or the Kano model), even if the result is represented as a sorted Product Backlog. In this slideshare, the presenter will make some propositions about practices of the four major activities of requirements engineering (elicitation, documentation, validation, management) that may be implemented in a Scrum environment. This will be done by virtue of eliciting differences between the classic way of requirements engineering versus requirements engineering done in the Agile way published in the presenter's article at: https://www.scrumalliance.org/community/articles/2017/august/requirements-engineering.aspx

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