1. The premiere software and product delivery event. June 6–10 Orlando, Florida Agility - Requirements Management Christopher de Kok IBM Rational IT Specialist References: Yan Zhuo - RDM-1196 Bill Shaw & George DeCandio - RDM-2302 Mia McCroskey - RDM-1206A

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

3. 3 Agile Process Maturity Model 1 Core Agile Development Focus is on construction Goal is to develop a high-quality system in an evolutionary, collaborative, and self- organizing manner Value-driven lifecycle with regular production of working software Disciplined Agile Delivery Extends agile development to address full system lifecycle Risk and value-driven lifecycle Self organization within an appropriate governance framework Agility at Scale Addresses one or more scaling factors:  Team size  Geographical distribution  Organizational distribution  Regulatory compliance  Environmental complexity  Enterprise discipline 32

4. 44 Co-located Geographical distribution Global Team size Under 10 developers 100’s of developers Enterprise discipline Project focus Enterprise focus Compliance requirement Low risk Critical, Audited Application complexity Simple, single platform Complex, multi-platform Organization distribution (outsourcing, partnerships) In-house Third party What is Agility at Scale? 3 Disciplined Agile Delivery 4

5. 55 A user story is…  a simple, clear, brief description  expressing a user’s goal for using the system under development  to deliver business value A use case is…  the specification of a set of actions  performed by a system,  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)  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 From use case to user story

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

7. 7 INVEST in good stories  Right-size user stories  Capture constraints as part of user stories  Write closed stories  Include user roles in the stories  Independent  Negotiable  Valuable  Estimateable  Small  Testable 7

8. 8 Source: www.ambysoft.com/essays/agileLifecycle.html 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

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

10. 10 Potentials artifacts for the Stakeholder Needs folder 10 Potential artifacts at the product and program level:  Business goals  Product vision  Product roadmap and strategy  Business processes (as- is vs. to-be)

11. 11 Potential artifacts for the Features folder 11 Potential artifacts:  Market analysis and release themes  Features and benefits for a product release

12. 12 Potential artifacts for the Glossary folder 12 Potential artifacts:  Glossary and Terms

13. 13 Potential artifacts for the Non-functional Requirements folder 13 Potential artifacts:  System-wide non- functional requirements

14. 14 Potential artifacts for the User Story Elaborations folder 14 Potential artifacts:  Flow diagrams for scenarios  A scenario can involve multiple user stories  Roles and personas  User story elaboration  UI sketches  Storyboards

15. 15 User story elaboration - example 15  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

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

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

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

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

20. GroupAssociated Offerings Engineering & Compliance cultures Good outcomes are the result of good, controlled processes. “Have we missed anything?” Market-driven culture Balance process and expedience. “How can we get this out faster with good quality?” ALM minimalist culture “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 Rational RM portfolio today Addressing different cultures and different needs Team Concert and Quality Manager Requirements Composer RequisitePro DOORS & DOORS Web Access

21. 21 Jazz provides a foundation for the development Lifecycle 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 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 Do all this using 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

22. Recent Steps to Implement our RM Strategy 200820092010 Requirements Composer 1.0  Collaborative req. definition  Visual and textual notations  Foundation for future offerings Requirements Composer 2.0  Collections, snapshots, reviews  Performance, Usability  Common reporting components  Reviewer Web client  Collaborative ALM with RTC/RQM RequisitePro 7.1.1  Package level security  ReqWeb improvements RequisitePro “getting info out”  Rational Publishing Engine for docs  Rational Insight for dashboards Acquired Telelogic and DOORS  Market leader in RM DOORS 9.2 / DWA 1.3  Requirements Interchange Format (RIF)  DOORS Web Access Edit  Rational Quality Manager integration  IBM-ized DOORS, Chinese/Japanese NLS

23. 23 Recent Improvements in RM Integrations 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) 200920102011+

24. 24 Today’s High-level Architecture Three separate products Six requirement clients Three separate repositories Significant overlap 24 COTS database ReqWeb Server ReqPro Web ReqPro Rich RequisitePro JFS RRS (Requirements Server) COTS database RRC Web RRC Rich RRC DOORS Rich DWA DOORS-D Interop server DOORS

25. DOORS Requirements Professional Vision: Proposed Long Term Architecture Single product line Single Web client Single server Interoperability Group Engineering & Compliance cultures Good outcomes are the result of good, controlled processes. “Have we missed anything?” Market-driven culture Balance process and expedience. “How can we get this out faster with good quality?” ALM minimalist culture “We use our main tools for requirements too” Team Concert Quality Manager OSLC RM Resources COTS database Web Client Rich Client Jazz Foundation Server DOORS Enterprise Requirements Professional Composer DOORS Enterprise Web Access DOORS Requirements Composer Extensions

26. OSLC Integration Strategy – Producing generic integrations Requirements Management Services Change Management Services Quality Management Services Architecture Management Services DOORS 9.x DOORS Enterprise DOORS Requirements Professional Publishing Services ClearQuest, RTC, Change RQM Publish Consume Publish ClearQuest, RTC, Change RQM, Insight, RPE Open Services for Lifecycle Collaboration

27. 27 2010 Enhancements: DOORS and DOORS Web Access 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 200920102011+ “Integrated with Jazz” “Built on Jazz”

28. 28 2011 Enhancements: DOORS Requirements Professional and Requirements Composer 200920102011+ First direct migration target for RequisitePro users 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 Requirements Composer (RRC)  Improved performance and usability

29. 29 2011 Enhancements: DOORS Enterprise DOORS Enterprise  Hosting DOORS server on 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 200920102011+ “Built on Jazz”

30. 30 2011 Enhancements: DOORS Requirements Professional, Requirements Composer, and DOORS Web Access 200920102011+ 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

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

32. Customer Video Place Holder

33. 33

34. 34 © 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. www.ibm/software/rational