The clear benefits of agile development is a better collaboration, incremental delivery, early error detection and the elimination of unnecessary work—have made it the default approach for many teams. Some developers have questioned whether requirements fall into the category of unnecessary work, and can be cut down or even completely eliminated. Meanwhile, teams developing complex products, systems and regulated IT continue to have requirements-driven legacy processes. So how does requirements management fit in an agile world? This meetup will take a look at requirements management and how it can bring significant value to agile development in regulated IT and complex product development projects, and sets out the characteristics of an effective requirements management approach in an agile environment.

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

2. SPONSORS & PARTNERS

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

4. 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

5. Stating the facts…
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

6. 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

7. Why are requirements perceived a burden?
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

8. 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

9. 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.

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

11. 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…

12. 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

13. 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:

14. Do as much as you need, but not more!
• 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
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!

15. Make requirements elaboration a core
feature team activity
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
Feature Team 1
Architect
Dev Team
Scrum Master
Product Owner
Feature Team 2
Architect
Dev Team
Scrum Master
Product Owner

16. Use and link traditional requirements and agile artifacts
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

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

18. Informal terminology notes
• 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

19. Document relevant information
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

20. But traceability is too much work
• 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!

21. Provide structure and examples
• 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

22. Three Key Challenges
Products are becoming much more complex
Products are becoming part of larger solutions /
ecosystems
Disrupt or be disrupted: innovating faster than
competitors
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

23. 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…

24. 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

25. 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.

26. 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.

27. 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…

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

29. 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

30. 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

31. 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

33. “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

34. We’re Agile now.
Do we really need Requirements Management?
• 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