During the Agile Austria Conference 2017, Graz, Austria Speaker: Fariz Saracevic This session will examine how requirements management can bring significant value to agile development teams.

1. Agile Development
Why Requirements Matter
Fariz Saracevic (fariz@us.ibm.com)
Senior Offering Manager
IBM
@FarizSaracevic

2. 2
AGENDA
Why are requirements needed?
Right-Sized Agile Requirements Management
• Understanding your requirements management needs
• Choices, choices…
What’s Next?

3. 3
What Agile Development is NOT?
Agile is NOT
• prescribed software development process (like RUP)
• strict set of rules you must exactly follow
• excuse to avoid design, documentation or difficult tasks you can benefit from
• guidance against requirements management, documentation, and doing what is
right for you
It is OK to incorporate traditional Requirements Definition and Management
(RDM) practices into agile development
• Requirements can (and will) change
• Change can come from any source: retrospectives, customers or architectural
re-iterations
• Change can come any time: before, during and after you
elaborated/implemented your story
Requirements Definition and Management
(RDM)

4. 4
You know that:
• Requirements can (and will) change
• Change can come from any source: retrospectives, customers or
architectural re-iterations
• Change can come any time: before, during and after you
elaborated/implemented your story
To embrace to change you need structure and organization
Stating the facts…

5. 5
Agile manifesto requires structure and organization
* Individuals and interactions over
process and tools
* Work product over comprehensive
documentation
* Customer collaborating over contract
negotiation
* Responding to change over following a
plan
Communicate but use
tools to support you
Document as needed
and at the right time
But don’t forget about all
your stakeholders and
complex relationships
Still plan, but focus on getting
started vs. long-term plan

6. 6
No perceived value
• Requirements should not be just a checkbox in a checklist
No real use for the requirements
• Requirements used to take a lot of time to develop
• After development, they sat on the shelf for too long
• Design, tests and code should follow requirements. If not, they are useless.
They change
• All the time, any time
• Unmanaged change is very frustrating
Why are requirements a burden?

7. 7
Why are requirements needed?
Increased Compliance and Regulatory
Requirements
10 million lines of
code in GM Volt
Mars Rover Curiosity had
16000+ requirements
Multiple vendors and
supply chain contractors
Smarter Products & Systems
Complex
Requirements
Increased number
of stakeholders
Collaboration Across the Value Chain
Effective Requirements Management

8. 8
Why are requirements needed?
Marine One Helicopters Fiasco
Costs mushroomed to $11.2B from $6.1B
Gaudi’s Unfinished Cathedral
100+ year old project still not complete
The Defense Science Board issued a new study blaming “poor communication” about
aircraft requirements between the government and contractors.
The only existing copy of Gaudí’s last recorded blue prints were destroyed by the
anarchists in 1938 during the Spanish Civil War. La Sagrada Família is now being
completed, but differences between his work and the new additions can be seen.

9. 9
Where human safety is a factor, even simple devices and
systems require careful engineering to reduce risk

10. 10
Why requirements matter?
If you ask for the wrong thing, you’ll get it…
If you don’t know what was asked for,
you’ll deliver the wrong thing…
You need to
understand what
problem you’re trying
to solve, get feedback
early and often and
then adjust…
This is all about Agile
way of working…

11. 11
Poor Requirements Management has a Significant Impact
on your Business
Requirements Rework
 Errors, late detected in the Maintenance phase can cost up to 200
times more than detected early in Requirement Analysis phase
 More than 40% of development budget
can be consumed by poor requirements
Project Impacts
 41% of projects fail to deliver the expected business value and
ROI
 49% of projects overrun original estimates
 28% of projects on time and on budget
Project Delays
 Being late to market by 6 months or more will cost organizations
33% of the 5-year ROI
“Our research indicates 80-plus percent of development failures result directly from poor
requirements gathering, management, and analysis.”
IDC, November 2007

12. 12
How do we know what we have built?
The development team won’t be there for ever.
Someone has to maintain and extend the system. A list
of user stories does not give a sufficient picture.
Team’s memory
Team members can find information
about work done in previous Sprints
without having to dig through stacks of
“done” user stories
Product owner/business analysts memory
To inform the creation of new user stories
User documentation and training
material development
Why Requirements Management is (still) important in an agile way of working?
Requirements can be viewed as:

13. 13
Requirements are only written when needed and detailed enough to
know how to implement the system
Requirements are written just in time, to help understand and decompose
items on the backlog
Capture decisions as they are made
Do as much as you need, but not more!
Documenting your system as it is
being built enables you to better
reuse work when developing the
next feature/component/system,
saving both time and money
If you are fundamentally
opposed to calling such
decisions “requirements”
then don’t.
But still capture them!

14. 14
Product Owner
• Product Vision
• Product backlog prioritization
• Represents the client often high level
Architect
• Technical consistency and quality
• Often interfaces with Product Owner
Development Team
• Get further information on what to implement
• Recall details of how finished parts of the system work
Make requirements elaboration a core feature team activity
Feature Team 1
Architect
Dev Team
Scrum Master
Product Owner
Feature Team 2
Architect
Dev Team
Scrum Master
Product Owner

15. 15
Defect
Story
Task
Project
Collection
Module
Backlog
Ranked
Backlog
Release
Plan
Project
Plan
Item
Affects
Implements
Friend
CCM RM
Artifact
UX Design
Requirement
Diagram
Implements
Use and link traditional requirements and agile artifacts

16. 16
Documentation over memorization
16
Complexity
Sprint 1 Sprint 2 Sprint 3 Next Sprint

17. 17
The term “Requirement” is loosely used to including all requirements-related information
• Textual requirement
• Use Case
• Usage Scenario
• Feature Descriptions
• Diagrams and Sketches
• User Story
• Story Elaborations
• Etc
These are not all strictly
requirements, the same points apply to all
Many of these are not found
on the backlog
Informal terminology notes

18. 18
Capture the work you are doing
Document your decisions
Connect the related information
All these things count as requirements
• Diagrams and Sketches
• User Story
• Story Elaborations
• Textual requirement
• Use Case
• Usage Scenario
• Feature Descriptions
• Retrospective
Document relevant information

19. 19
Common perception when you create traceability separately
• That is making life hard for yourself
• When you enter information you have the source available
• So create trace information at the same time
Do the right thing at the right time is the essence of agile
It is insane to do it any other time!
But traceability is too much work

20. 20
Providing good examples (and counter examples) of requirements
• enhance the quality, consistency and completeness of their requirements
• teach through “culture and practices” instead of documentation
Structure
• Artifact data model (requirement types)
• Link Types
• Workflow
Templates
• Folder structure & tags
• Pre-defined views
• Document templates
• Project templates
Provide structure and examples

21. 21
Products are becoming much more complex
Products are becoming part of larger solutions / ecosystems
Disrupt or be disrupted: innovating faster than competitors
Three Key Challenges
More software
Hardware – Electronics – Software
More suppliers More teams More specialists
More subsystems
Learning fast Deciding fast Acting fast Delivering fast
From “predictable world” to “unpredictable world”
Safety and security … and new failure modes
Teams on-prem and on cloud
Teams on different cadences

22. 22
Requirements in IBM DevOps
Customer /
Stakeholder
Product
Manager /
Product Owner
Dev Lead
Requirement
Feature
Dev Work
Item
Continuous
Customer Feedback
& Optimization
Collaborative
Development
Continuous Release
and Deployment
Continuous
Monitoring
Continuous
Business Planning
Continuous
Testing
Operate Develop/
Test
Deploy
Steer
DevOps
Continuous
Feedback
Requirements are the key
artifact representing feedback…
Requirements drive
articulation of application
features…
Development delivers
function for features…

23. 23
Rational Team Concert (RTC)
Development
Change Control
Board
(CCB)
Design and
develop software
(SCM)
Triage
Enhancements /
defects
Backlog
(Work items)
Customer /
Stakeholder
Product
owner /
manager
Dev Lead
Software Engineer
Analyse
Specific work items can be
put into the product backlog
and delivered against directly
Requirements

24. 24
Rational DOORS Next Generation (RDNG)
Change Control
Board
(CCB)
Triage
Enhancements /
defects
Backlog
(Work items)
Customer /
Stakeholder
Product
owner /
manager
Dev Lead
Analyse
Requirements
Requirements Analysis
Requirements
Analysis
System Requirements
User RequirementsSpecify
Requirements Analysis transforms many
disparate inputs from different stakeholders
into specific Requirements for the development
team to work against.

25. 25
Rational Team Concert (RTC)
Rational DOORS Next Generation (RDNG)
Change Control
Board
(CCB)
Triage
Enhancements /
defects
Backlog
(Work items)
Customer /
Stakeholder
Product
owner /
manager
Dev Lead
Analyse
Requirements
Requirements
Analysis
System Requirements
User RequirementsSpecify
Deployment
Design and
develop software
(SCM)
Software Engineer
These two activities can be executed in
the same organisation with Requirements
elaborating what business need the
development team is aiming to solve.

26. 26
Requirements in Scaled Agile Framework (SAFe)
Scaled Agile Framework (SAFe) with the Power of DevOps
Requirements
articulated in
Portfolio Planning
and refined
through analysis
into Features and
Stories…

27. 27
Rational DOORS Next Generation
Choices, choices…
Rational Team Concert
How do you choose?

28. 28
Understanding your requirements management needs
Regulated/System Enterprises
Need for regulatory
compliance and auditing
Separation of roles
(Business Analysts,
Development)
Requirement governance
Robust requirements
articulation needs
Rational DOORS
Next Generation
Small Agile Teams
Unregulated, little or no compliance or
audit requirements
Desire for single tool lightweight
requirements and change
management
Simple requirements articulation needs
Rational
Team Concert

29. 29
IBM Rational Team Concert
Requirements simplicity for Small Agile Teams
RTC Quick Planner
• Easy to learn
• Fast work item creation
• Manage a backlog and sprints in a single
window using drag and drop
• Manage Parent/Child tasks and their rank
relationships
• IBM Design driven task based UI
Reporting
• Jazz Reporting Service
• Fast data collection
• Query builder
• Lean reports
Collaboration
• Activity streams to track events
• Automated work item reply
• Social flow for comments
• Manage & preview attachments
Kanban/Taskboard
• States and State-groups
• Customize card display
• Customize display of states
• Display small, medium, large cards
Build & Deploy
• Post Build Deploy using UC Deploy
• Gated control of builds for
deployment
Compliance for SCM
• Improved large team usage with
pessimistic locking
• Improved auditing for work item
link changes
• Ability to see who and when code
changes were delivered
Integration
• Git
• Jenkins

30. 30
Better requirements… Less rework…
Better results!
IBM Rational DOORS Next Generation
Enhance your value and capability beyond RTC for requirements
Search, filter
on attributes
Business
Objectives
Business
Processes
Use
Cases
Storyboards
& Sketches
Reporting
Industry &
Domain Models
Impact &
Coverage
analysis
Rich text
Requirements
Traceability
between related
artifacts
Rational DOORS
Next Generation
Definition and Management
Lifecycle Traceability
Project Efficiency and Reuse
 Improves the developer’s ability to design UI
and software flow in the initial design phase
 Better define and manage rich text use
cases, visual diagrams or processes
 Strengthens stakeholder’s traceability across
all lifecycle artifacts to find missing
requirements or use cases
 Easily discover the impact from requirement
or use case changes
 Reuse requirements for multiple projects to
lower development costs and capitalize on
best practice
 Enables the development experience through
a specification structures

31. 31

32. 32
“Agile is quickly becoming the most popular way of developing
software because it ... more quickly deliver value to the end users.
That value will be driven to a large extent by the quality
and clarity of requirements that feed the software
development process. An agile, lean, and timely
approach to requirements as the starting point will
help to ensure that the process is optimized.”
Scrum Alliance
Agile Requirements Definition and Management
Feb 2012

33. 33
• Yes, if done correctly, at the right time, and to the right level!
• Yes, everything isn’t captured on the backlog!
• Yes, we need to know what you have built!
• Managing requirements does not need to be a burden
• Requirements management is possible and quite necessary in agile
development
• You need to understand the relationships between sets of
information and that is most of what RM is about
We’re Agile now.
Do we really need Requirements Management?