Agile and requirements management aren't exactly a match made in heaven. But, in many industries, there is a practical reality that mandates some successful marriage between true requirements management and Agile. If you are writing surveillances for regulating Wall Street or building the software for a pacemaker or the automated brake system for cars that have to meet standards in different countries, you have to make them work together. In these cases, you will want to examine three areas to ensure that you can successfully implement requirements management and still operate in a “SAFe” way. First, what is your motivation for deciding to do more sophisticated requirements management? Is it purely for compliance or auditability reasons? Or is reusability a big driver? Second, what other, non-requirements management tools will be involved in the extended flow necessary to accomplish your final goal? And what role will these tools play? Finally, what specific information will be needed by the tools and for what reason? This webinar examines these three areas and provide guidance to aid in your implementation of SAFe with requirements management.

1. © Tasktop 2016© Tasktop 2016
Requirements Management and SAFe:
Oxymoron or Practical Reality?
June 15, 2016

2. © Tasktop 2016

3. © Tasktop 2016
Feature
Epic
Capability
Initiative
Portfolio Backlog
Program Backlog
Iteration Backlog
SAFe Terms

4. © Tasktop 2016
Have you ever seen any of those terms in an Agile tool?
Yes!

5. © Tasktop 2016
Have you ever seen any of those terms in a Requirements Mgmt tool?
No!

6. © Tasktop 2016
Bingo. So what do you do?

7. © Tasktop 2016
Why is this the case?
Why should I care?
How do I overcome this fundamental disconnect?
Well, that’s what today’s webinar is all about ….

8. © Tasktop 2016
But wait …
Aren’t we talking about SAFe …. As in ”Scaled Agile” …
Why are you bringing up Requirements Management?
Requirements Management / Agile = Oxymoron?

9. © Tasktop 2016
Scaled = Big
Big (often =) Regulated / mission critical
I’d love to watch you describe to an auditor that the user story that was implemented for
the automatic break system for the car is just gone now because that sprint is over ;)
I’d love to watch the team recreate all the user stories necessary to implement
accessibility every time a new application for a pharmaceuticals company is being built.
I’d love to watch all of your systems engineers when you tell them “just
use JIRA stories for the specs for the propulsion engine”

10. © Tasktop 2016
For many organizations, your SAFe implementation will
simply have to include requirements management tools.
Requirements
Management
Tool
Agile
Management
Tool
Test Management
Tool

11. © Tasktop 2016
CA Clarity
DNG
JIRA
HP QC
RTC
Tosca
Rally ServiceNowVersionOne
Blueprint
iRise
Reproduced and adapted with permission from © 2011-2016 Scaled Agile, Inc. All rights reserved.

12. © Tasktop 2016
So now let’s explore a bit more about why
requirements management tools don’t have all the
common SAFe concepts – like backlogs and sprints
(remember our pop quiz at the beginning?)
So now you know why you should care … it is highly likely if
you are doing SAFe, you will need *both* Agile
management tools and requirements management tools.

13. © Tasktop 2016
Requirements Management is a much older discipline than Agile
(But don’t be deceived … that is not the most important reason)
Fundamentally requirements management is about DEFINING
and agile management is primarily about DOING

14. © Tasktop 2016
But how then do I overcome this fundamental disconnect?
Ah. Ok. So now I know why I need to care (cuz you’ll likely
need requirements management if you are “scaling”) and I
also know why requirements management tools just don’t
have the same concepts as Agile (DEFINING is
fundamentally different and needs different concepts than
DOING.)

15. © Tasktop 2016
It’s just like a marriage.
• You need to stay true to the basics of what each
person brings into the relationship
• There will be some struggles that will take a lot of
solid communicating to overcome
• It won’t be perfect
• It gets better over time

16. © Tasktop 2016
• Work Items: Primary goal of a work
item is to hold information about
work to be done
• Containers: Primary goal is to group
for some purpose

17. © Tasktop 2016
And it is really about understanding the
container’s underlying purpose that will
form the basis for a successful marriage
(We have a tendency to only focus on the artifacts… which is
not good – containers are equally important)

18. © Tasktop 2016
First, a little bit more about containers…
Scheduling Organizing Aggregating

19. © Tasktop 2016
Tool Type Scheduling Organizing Aggregating
JIRA Agile • Release
• Backlog
• Sprint
• Project
Rally Agile • Release
• Backlog
• Sprint
• Workspace
• Project
• Portfolio Item
HP ALM Agile (ish) • Release
• Iteration
• Projects
• Folders
IBM DNG Requirements • Project Area
• Folders
• Collections
• Modules
• Streams
Jama Requirements • Projects
• Sets
• Folders
• Components
• Baselines
Blueprint Requirements • Projects
• Folders
• Baselines
• Reviews
Let’s See More!

20. © Tasktop 2016
But we already know why this is the case … remember?
Agile Mgmt Tools = DOING (Scheduling)
Requirements Mgmt Tools = DEFINING (Organizing)

21. © Tasktop 2016
Tool Type Organizing
JIRA Agile • Project
Rally Agile • Workspace
• Project
HP ALM Agile (ish) • Projects
• Folders
IBM DNG Requirements • Project Area
• Folders
• Collections
• Modules
Jama Requirements • Projects
• Sets
• Folders
• Components
Blueprint Requirements • Projects
• Folders
Purpose
Reuse?
Compliance & Audit?
Storyboards, Diagrams?
All of the Above?

22. © Tasktop 2016
Compliance and Audit
I want one grouping for all requirements for my propulsion engine, another grouping for the
radar system requirements. And I want both of these groupings to be contained within a higher
level grouping indicating these are all “Functional Requirements” vs. “Non Functional”. I need to
be able to prove traceability based on these groupings – traceability between requirements and
traceability to tests and any implementations
Reusability
I want to have all of my accessibility requirements defined in one place and then “apply” them
to a whole bunch of different products. These need to be able to have variants as well.
So that is step 1 … think through your core needs/purpose
for using a requirements management tool

23. © Tasktop 2016
Tool Type Organizing
JIRA Agile • Project
Rally Agile • Workspace
• Project
HP ALM Agile (ish) • Projects
• Folders
Organizing Type Tool
• Project Area
• Folders
• Collections
• Modules
Requirements IBM DNG
• Projects
• Sets
• Folders
• Components
Requirements Jama
• Projects
• Folders
Requirements Blueprint

24. © Tasktop 2016
Every requirement exists in one and only one folder
You can have a hierarchy of folders
Collections are essentially a “view” into requirements
One requirement can exist in multiple collections
Modules are essentially structured views
One requirement can exist in multiple modules (but it is not recommended to do that)
Let’s Talk about IBM DOORS NextGen
So let’s walk through a quick example ….

25. © Tasktop 2016
Our organization needs to ensure that any new web application that we build to support
the business, adheres to all of the Accessibility Requirements that the federal
government mandates. (Core Goal: Reuse)
Business Goal

26. © Tasktop 2016
Collection For App 2
Req 1 Req 2 Req 3
Collection For App 1
Req 1 Req 2 Req 3
Req 1
Req 2
Req 3
Will This Work?
Project 1
Req 1 Req 2 Req 3
Project 2
Req 1 Req 2 Req 3
IBM DNG

27. © Tasktop 2016
Containment Sync Point
Folder
Collections
Purpose: Functional Grouping
Purpose: “Instance of” for
reusability; 1 per App Project
Purpose: Execution
Structure
Project
Area
Purpose: Top level initiative
IBM DNG

28. © Tasktop 2016
Collection For Product 2
Req 1 Req 2 Req 3
Collection For Product 1
Req 1 Req 2 Req 3
Req 1
Req 2
Req 3
Problem 1: Changing Requirements
Project 1
Req 1 Req 2 Req 3
Project 2
Req 1 Req 2 Req 3
IBM DNG

29. © Tasktop 2016
Collection For Product 2
Req 1 Req 2 Req 3
Collection For Product 1
Req 1 Req 2 Req 3
Req 1
Req 2
Req 3
Problem 1: Changing Requirements
Project 1
Req 1 Req 2 Req 3
Project 2
Req 1 Req 2 Req 3
IBM DNG

30. © Tasktop 2016
Collection For Product 2
Req 1 Req 2 Req 3
Collection For Product 1
Req 1 Req 2 Req 3
Req 1
Req 2
Req 3
Problem 2: Traceability
Project 1
Req 1 Req 2 Req 3
Project 2
Req 1 Req 2 Req 3
Test 1
Test 2
Test 3
Test 4
IBM DNG
Test 1
Test 2
Test 3
Test 4

31. © Tasktop 2016
Collection For Product 2
Req 1 Req 2 Req 3
Collection For Product 1
Req 1 Req 2 Req 3
Req 1
Req 2
Req 3
Problem 2: Traceability
Project 1
Req 1 Req 2 Req 3
Project 2
Req 1 Req 2 Req 3
IBM DNG
Test 1
Test 2
Test 3
Test 4
Test 1
Test 2
Test 3
Test 4

32. © Tasktop 2016
Bummer. So let’s try a different approach.

33. © Tasktop 2016
Module For App 2
Req 1 Req 2 Req 3
Module For App 1
Req 1 Req 2 Req 3
Req 1
Req 2
Req 3
Will This Work?
Project 1
Req 1 Req 2 Req 3
Project 2
Req 1 Req 2 Req 3
IBM DNG

34. © Tasktop 2016
Containment Sync Point
Folder
Modules
Purpose: Functional Grouping
Purpose: “Instance of” for
reusability; 1 per App Project
Purpose: Execution
Structure
Project
Area
Purpose: Top level initiative
IBM DNG

35. © Tasktop 2016
Module For Product 2
Req 1 Req 2 Req 3
Module For Product 1
Req 1 Req 2 Req 3
Req 1
Req 2
Req 3
Problem 1: Changing Requirements
Project 1
Req 1 Req 2 Req 3
Project 2
Req 1 Req 2 Req 3
IBM DNG

36. © Tasktop 2016
Module For Product 2
Req 1 Req 2 Req 3
Module For Product 1
Req 1 Req 2 Req 3
Req 1
Req 2
Req 3
Problem 1: Changing Requirements
Project 1
Req 1 Req 2 Req 3
Project 2
Req 1 Req 2 Req 3
IBM DNG

37. © Tasktop 2016
Module For Product 2
Req 1 Req 2 Req 3
Module For Product 1
Req 1 Req 2 Req 3
Req 1
Req 2
Req 3
Problem 2: Traceability
Project 1
Req 1 Req 2 Req 3
Project 2
Req 1 Req 2 Req 3
Test 1
Test 2
Test 3
Test 4
IBM DNG
Test 1
Test 2
Test 3
Test 4

38. © Tasktop 2016
What would the equivalent look like if I was using Jama instead
of DNG? (And consider if it was HPE ALM instead of JIRA)
Their containers and purposes for those containers are different

39. © Tasktop 2016
Tool Type Scheduling
JIRA Agile • Release
• Backlog
• Sprint
Rally Agile • Release
• Backlog
• Sprint
HP ALM Agile (ish) • Release
• Iteration
IBM DNG Requirements
Jama Requirements
Blueprint Requirements
It’s not just about
organizing … what
about scheduling?

40. © Tasktop 2016
Use an organizing container to be a scheduling container
Issue 1: Maintenance
Issue 2: Dynamic movement
Issue 3: Now you’ve lost your organizing alignment
(If my collection is meant to allow for some amount of reuse then I’ve lost that ability)
Flow the sprint/release information as attributes of the actual requirement
Better choice!!!
Two Basic Choices

41. © Tasktop 2016
But wait … there are still more considerations ....
What about baselines? And reviews?
We don’t have time to talk about those today …
but know that they play a definite role in your
success

42. © Tasktop 2016
In Summary….
You will really need to think through your flow strategy to successfully
implement SAFe in an environment that requires requirements management
You must really understand containers to be successful at this
There is not a one size fits all solution – it is tool specific and organization
specific because each tool has different containers for different purposes
(and there are very tool specific nuances that are important to understand)

43. © Tasktop 2016
Understand what each container type is intended to be for
Understand if an artifact can be in more than one container
If an artifact can be in more than one container, understand whether a change made to
any instance of that artifact will change the rest of them
Very important to consider how relationships are handled (esp in a reuse scenario)
Represent the notion of release and sprint as attributes/fields – not as a organizing
container “masking” itself as a scheduling container
Tips and Tricks

44. © Tasktop 2016
Often using one way flow is the best choice for requirements - the requirements system
is often considered the “single source of the truth”
Recognize that the way you want to flow requirements to an agile test management tool
might be different than how you will want to flow requirements to a agile development
tool
Start small and experiment!
Talk to the business analysts and developers and really understand how they do their
work and *why* they have structured things they way they do.
Tips and Tricks

45. © Tasktop 2016
We Want to Hear From You!
• Survey will be sent out all about containment!
• Any other questions: http://go.tasktop.com/contact-us

46. © Tasktop 2016© Tasktop 2016
tasktop.com
@tasktop