Agility - Requirements
Management
Christopher de Kok
IBM Rational IT Specialist
References:
The premiere software and product delivery event.
June 6–10 Orlando, Florida
Yan Zhuo - RDM-1196
Bill Shaw & George DeCandio - RDM-2302
Mia McCroskey - RDM-1206A
Objectives
 Requirements in the context of an Agility@Scale approach
 Requirements Definition and Management Roadmap
 Requirements Agility Case Study Video - Mia McCroskey - Emerging
Health Information Technology
2
2
Agile Process Maturity Model
3
Disciplined
Agile Delivery
2
1
Core Agile
Development
Focus is on construction
Goal is to develop a
high-quality system in
an evolutionary,
collaborative, and selforganizing manner
Value-driven lifecycle
with regular production
of working software
Agility at Scale
Addresses one or more
scaling factors:
Team size
Extends agile
development to
address full system
lifecycle
Geographical
distribution
Risk and value-driven
lifecycle
Regulatory compliance
Self organization
within an appropriate
governance
framework
3
Organizational
distribution
Environmental
complexity
Enterprise discipline
4
What is Agility at Scale?
3
Compliance requirement
Team size
100’s of
developers
Under 10
developers
Geographical distribution
Co-located
Global
Disciplined
Agile Delivery
Critical,
Audited
Organization distribution
(outsourcing, partnerships)
Third party
In-house
Enterprise discipline
Application complexity
Simple,
single platform
Low risk
Complex,
multi-platform
Project
focus
4
Enterprise
focus
From use case to user story
A use case is…
A user story is…
the specification of a set of actions
 a simple, clear, brief description
performed by a system,
 expressing a user’s goal for
using the system under
development
which yields an observable result that
is, typically,
of value for one or more actors or other
stakeholders of the system. (Unified
Modeling Language - UML 2.0)
 to deliver business value
Both methods are focusing on users and values to the users
Each has its own challenges
Choose use cases for green-field development and user
stories for incremental releases
5
User story: Ron Jeffrey’s 3 Cs
Card
What is the goal of a
user
As a (user role), I want to (goal) so I can (reason)
Example:
As a registered student, I want to view course details so I can create
my schedule
Conversation
How to achieve the
goal using the
system?
Discuss the card with a stakeholder. Just in time analysis (JIT)
through conversations.
Example:
What information is needed to search for a course?
What information is displayed?
Confirmation
How to verify if the
story is done and
complete, and the
goal is achieved
Record what you learn in an acceptance test.
Example:
Student can access course catalog 24 x 7 hours
Student cannot choose more than three courses
6
6
INVEST in good stories
 Independent
 Negotiable
 Valuable
7
Right-size user stories
 Estimateable
 Small
Capture constraints as part of
user stories
 Testable
Write closed stories
Include user roles in the stories
7
User stories and iterative planning
Write initial stories, estimate high-priority stories, and develop high-level
release plan at beginning of project
Each iteration, pull one iteration’s worth of work off the stack based on
your velocity
Source: www.ambysoft.com/essays/agileLifecycle.html
8
Agile requirements project template
 The agile requirements project template includes a set of folders and
a document template to elaborate a user story
 Project Folder:
Stakeholder Needs
Features
Glossary
9
Non-functional Requirements
User Story Elaboration
Document Template: User Story Elaboration
 Use the template to create a new Requirements Composer project
 Customize the template based on your project needs
9
Potentials artifacts for the Stakeholder Needs folder
Potential artifacts at the
product and program
level:
Business goals
Product vision
Product roadmap and
strategy
Business processes (asis vs. to-be)
10
10
Potential artifacts for the Features folder
Potential artifacts:
 Market analysis and
release themes
 Features and benefits for a
product release
11
11
Potential artifacts for the Glossary folder
Potential artifacts:
 Glossary and Terms
12
12
Potential artifacts for the Non-functional Requirements folder
Potential artifacts:
 System-wide nonfunctional requirements
13
13
Potential artifacts for the User Story Elaborations folder
Potential artifacts:

Flow diagrams for scenarios

14
A scenario can involve
multiple user stories

Roles and personas

User story elaboration

UI sketches

Storyboards
14
User story elaboration - example
A user story may start as a short
statement, explaining the intent of
the user
It can be elaborated through
conversations and confirmation,
leveraging techniques such as
user interface sketches, and
storyboarding
15
15
Strategy of describing and managing epics
 Process sketch or storyboard can visually describe an epic
 Break down an epic into user stories to elaborate the details
 Use a collection to manage a group of related user stories
16
16
Analyzing elaborated stories using attributes, tags, and filters
 Display all elaborated user stories with their attribute values
 Filter and display elaborated story based on attribute values
By Business Priority
By Origin
By Product Owner
By Role
 Organize elaborated stories by themes
 Display elaborated stories in a collection
17
17
Objectives
 Requirements in the context of an Agility@Scale approach
 Requirements Definition and Management Roadmap
 Requirements Agility Case Study Video - Mia McCroskey - Emerging
Health Information Technology
1
8
18
DISCLAIMER
 Plans are based on best information available and may change in future
© Copyright IBM Corporation 2010. All rights reserved. These materials are
intended solely to outline our general product direction and should not be relied on
in making a purchasing decision. Information pertaining to new product is for
informational purposes only, is not a commitment, promise, or legal obligation to
deliver any material, code or functionality, and may not be incorporated into any
contract. The development, release, and timing of any features or functionality
described for our products remains at our sole discretion. Nothing contained in
these materials is intended to, nor shall have the effect of, creating any warranties
or representations from IBM or its suppliers or licensors, or altering the terms and
conditions of the applicable license agreement governing the use of IBM products.
IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and
other IBM products and services are trademarks of the International Business
Machines Corporation, in the United States, other countries or both. Other
company, product, or service names may be trademarks or service marks of others.
Rational RM portfolio today
Addressing different cultures and different needs
Group
Associated Offerings
Engineering & Compliance cultures
DOORS & DOORS
Web Access
Good outcomes are the result of good,
controlled processes. “Have we
missed anything?”
RequisitePro
Market-driven culture
Balance process and expedience.
“How can we get this out faster with
good quality?”
Requirements
Composer
ALM minimalist culture
Team Concert and
Quality Manager
“We use our main tools for
requirements too”
Ad-hoc culture
“We don’t do RM”
“What is RM?”
50% of project failure
can be tracked to poor
requirements practices
The Rational RM Strategy
Deliver market-leading
RM tools and practices
 Relevant for all types of
RM cultures, including
engineering / compliance
and market-driven
Foster an
RM ecosystem
 Enable partners and
customers to provide
value-add capabilities on
the requirements platform
Do all this using
Innovate while protecting
customer investments
 Deliver next-gen capabilities
in a common product family
 Enable adoption by
supporting backward
compatibility and providing
smooth migration paths
services and philosophy
 Jazz is a platform for transforming software and systems delivery
 Service-oriented tools with loosely-coupled integrations making mashups
and cross-product workflows more productive and flexible than ever
Jazz provides a foundation for the development Lifecycle
21
Recent Steps to Implement our RM Strategy
2008
2009
Acquired Telelogic and DOORS
Market leader in RM
2010
DOORS 9.2 / DWA 1.3
Requirements Interchange Format (RIF)
DOORS Web Access Edit
Rational Quality Manager integration
IBM-ized DOORS, Chinese/Japanese NLS
Requirements Composer 1.0
Collaborative req. definition
Visual and textual notations
Foundation for future offerings
RequisitePro 7.1.1
Package level security
ReqWeb improvements
Requirements Composer 2.0
Collections, snapshots, reviews
Performance, Usability
Common reporting components
Reviewer Web client
Collaborative ALM with RTC/RQM
RequisitePro “getting info out”
Rational Publishing Engine for docs
Rational Insight for dashboards
Recent Improvements in RM Integrations
2009
2010
2011+
DOORS 9.2
Rational Quality Manager v2.0
RRC v2.0
Rational Insight using RIF exports
HP QualityCenter v10
RRC 2.0
DOORS 9.2
RequisitePro
Rational Software Modeller
Rational Software Architect
CALM 2009 (with RTC/RQM)
23
Today’s High-level Architecture
RRC
RequisitePro
ReqPro
Rich
ReqPro
DOORS
RRC
Web
RRC
Rich
DOORS
Rich
DWA
Web
RRS
(Requirements
Server)
ReqWeb
Server
COTS database
JFS
COTS database
Interop
server
DOORS-D
Three separate products
Three separate repositories
Six requirement clients
Significant overlap
24
Vision: Proposed Long Term Architecture
Group
Enterprise
Engineering & Compliance cultures
Requirements Composer Extensions
DOORS Requirements
Professional
DOORS Web Access
Good outcomes are the result of good,
controlled processes. “Have we missed
anything?”
DOORS
Enterprise
Market-driven culture
Requirements
Professional
Balance process and expedience. “How can
we get this out faster with good quality?”
DOORS
Composer
ALM minimalist culture
Web Client
“We use our main tools for requirements
too”
Rich Client
Team Concert
Quality Manager
RM
Resources
Jazz
Foundation
Server
Future
IBM
Capabilities
Your
existing
capabilities
Business
Planning &
Alignment
Product
& Project
Management
Collaborative
Lifecycle
Management
Compliance
& Security
Engineering
& Software
Tools
3rd-Party
Jazz
Capabilities
Best Practice Processes
Collaboration
Presentation:
Mashups
Discovery
Query
COTS database
Single product line
Single server
Single Web client
Interoperability
Storage
Administration:
Users, projects,
process
OSLC Integration Strategy – Producing generic integrations
DOORS 9.x
ClearQuest, RTC, Change
RQM
Consume
Consume
Publish
Open Services for Lifecycle Collaboration
Architecture
Management
Services
Publishing
Services
Publish
Quality
Management
Services
Consume
Publish
Change
Management
Services
Consume
Requirements
Management
Services
ClearQuest, RTC, Change
RQM, Insight, RPE
DOORS Enterprise
DOORS Requirements Professional
2010 Enhancements: DOORS and DOORS Web Access
2009
2010
2011+
“Integrated with Jazz”
DOORS 9.x
RTC, ClearQuest, Change integrations using OSLC-RM and OSLC-CM
Embedded document generation with common reporting components
Additional translations: German, French, and Russian
SSL communication with certificate based authentication (CAC/PKI)
DOORS Web Access 1.x
Enhanced filtering for improved analysis/review
OSLC integration point for server side integration
UI harmonization with IBM Rational Jazz clients
“DOORS on Jazz” Tech Preview
Common Jazz based requirement server
COTS database
“Built on Jazz”
27
2011 Enhancements: DOORS Requirements Professional and
Requirements Composer
2009
2010
DOORS Requirements Professional
 Web based/Zero footprint
 Next-generation RequisitePro
 RM and Business Analyst solution for market
driven cultures
 Requirements, traceability, schema,
and analysis
 Common Jazz based requirement server
2011+
First direct migration target
for RequisitePro users
Requirements Composer (RRC)
 Improved performance and usability
28
2011 Enhancements: DOORS Enterprise
2009
2010
2011+
DOORS Enterprise
“Built on
Hosting DOORS server on Jazz
Jazz”
 Commercial database support
 Performance, resilience, and availability focus
Requirements interoperability with other Jazz products
 Requirements sharing with RTC, RQM, RSA, etc.
Shared components between RM products
 Project level attribute/types management
 Dashboard viewlets
 Jazz collaboration
 Requirements workflow
 Common reporting components
29
2011 Enhancements: DOORS Requirements Professional,
Requirements Composer, and DOORS Web Access
2009
2010
2011+
DOORS Requirements Professional
Security model and Administration
Marquee capabilities (e.g. graphical traceability)
Requirements Workflow
Requirements Composer (RRC)
Provide RRC capabilities on DOORS RP
Web based/Plug-ins
DOORS Web Access
Provided through DOORS RP
Common Web technology for
requirements access
30
Objectives
 Requirements in the context of an Agility@Scale approach
 Requirements Definition and Management Roadmap
 Requirements Agility Case Study Video - Mia McCroskey - Emerging
Health Information Technology
3
1
Customer Video Place Holder
33
www.ibm/software/rational
© Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind,
express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have
the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM
software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities
referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future
product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services
are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product,
or service names may be trademarks or service marks of others.
34