Define and Manage Requirements with IBM Rational Requirements Composer

Define and Manage Requirements with IBM Rational Requirements Composer Alan Kan Technical Manager Rational Software, IBM New Zealand

Housekeeping Restrooms Emergency exit No smoking building Morning tea

Lawyers made me do this IBM's statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM's sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

Agenda Requirements Quality Issues Key Principles of RRC Requirement Elicitation Techniques Agile Requirements Rational Requirements Composer Overview Hands-on Lab Overview Hands-on Labs

Symptoms of Requirements Quality Issues User or business needs not met Poor quality or end user experience No coordinated team effort Difficult to find information Difficult to incorporate change Cost overrun and project delays

Key Principles for Using Requirements Composer Getting “requirements right” is more important then ever These six principles articulate best practices for effective Requirements Management and are supported by IBM Rational Requirements Composer: F E D C B A Adapt to Change & Incorporate Balance Competing Stakeholder Priorities Create in Context Information About Requirements Develop Solution to Solve Business Problem Evolve and Incorporate Visual Techniques Foster a Team Based Approach Through Collaboration

Eliciting and Defining: Which Techniques to Use? High Adapted from Alan Davis Which of these techniques might you use for your projects? Developer Experience Customer/User Experience Low High Low “ Fuzzy problem” “ Catch Up” “ Mature” “ Selling/Teaching” Technique Tools Domain Technology Quadrant affected by techniques, technology, tools, and domain. Documentation Process Sketching Brainstorming Use Cases Interviews Questionnaires Role Playing Storyboarding Interface Sketch

What about Agile Requirements? Business Case Business Requirements High Level Requirements Business Process Sketches Use Case (possibly) Non-functional Requirements User Story UI Sketch Storyboard Elaboration documents Product Backlog

IBM Rational Requirements Composer Capture, connect, organize and collaborate with the Entire Team Storyboard Use Case Business Process Document Tracing UI Sketch Screen Flow Review & Approve Dashboard Quality Manager Team Concert Requirements Composer Guide teams to execution Requirements, Plans, Tests and Work Items

About Money that Matters Hi, I’m Bob. I was recently hired as a lead analyst for JKE enterprise, a worldwide financial and banking enterprise. Our team focus is to analyze business issues and work cross organizationally, with Business and IT to identify improvements that will increase profit. Although these areas are our traditional focus this project is driving a key initiative where we are trying to set ourselves apart from our competition by leading the way for social responsibility. The project name is “Money that Matters.” In the “Money that Matters” project analysts will collaborate with peers, and customers to elicit requirements for money that matters. This program is critical as it is the first of its kind at JKE where we will actively involve a focus group of customers. Additionally it is the first project where team members from the parent company and newly acquired brands will work together. JKE has adopted IBM Rational Requirements Composer and additional tools to support Requirements Management. Our team will use these tools to help capture requirement information visually, collaborate and gain concurrence on the requirement information so that it can be later managed and leveraged across the lifecycle.

Lab Scenario Accelerate the economic recovery of disaster-stricken areas by linking investors/donors with impacted business owners Dividend Deposit Option automatically deposits a portion of a customer’s dividends into a pooled assistance fund New technical requirements on mobile devices and operating systems support Requirement has changed from allowing donors to donate to one organisation, to allowing donors to donate to multiple organisations

The intent of this slide is to briefly capture the modules for the RRC hands on lab. page 7 to 59 page 60 to 75 (skip optional lab) Lab Overview Module Brief Description Goals 1: Tour of RRC & JKE Banking Instructor led demo to provide tour of RRC interface and provide an overview of the JKE Banking Project Quickly highlight key functional components of RRC and provide attendees exposure to the benefits. Overview of what JKE Banking is and the basic project structure 2: Respond to Change Request Requirement content has already been defined for the release and allocated for Sprint 2. It is realized that new requirements must be added. We will demonstrate various mechanisms for adding new requirements. Demonstrate the ability to quickly create requirements via one click and copy. Demonstrate the ability to leverage external content from RRC and import (upload csv file) Conduct an instructor led demonstration of Word document import and create requirements.

Lab Overview page 82 to 104 page 105 to 123 (skip optional lab) Module Brief Description Goals 3: Impacts to Business Process Change existing business process to reflect changes to support new requirements for sprint 2. (Donor may donate to more than one organization) Quickly demonstrate the functions in a business process diagram. Ease of refining existing content. Collaborate with team-mates to inform them of change via comments. 4: Refine the Use Case Model Refine use case model to reflect ability to donate to more than one organization. Identify how a specification may be tied to either a use case or a user story. Demonstrate how the use case model can be used as collaboration and planning vehicle to call out scenarios and actors. Demonstrate can be used for agile and or use case driven approaches and show user story card and use case specification. Discuss the ability to use templates. Capture terms. Demonstrate linking to other artifacts.

Lab Overview page 135 to 156 page 157 to 172 (skip optional lab) Module Brief Description Goals 5: Change the User Interface It is important to show reuse in the UI. We can quickly show this change by changing a part and demonstrating the impact on sketches. We will also demonstrate the affects of donors choosing multiple organizations in the storyboard for sprint 2. The finance rate for auto loans has changed. Make a change to the part in the landing page to reflect this change and demonstrate the impacts. Send a comment to AL to let him know that you have made this change. Make a change to the Dividend Allocation Storyboard for sprint 2. 6: Conduct a Review Demonstrate how you can involve multiple stakeholders in a review and different types of review roles. Add Curtis, Deb and Tanuj to the Review. Describe different types of reviews. Approve artifacts in review as Curtis. Demonstrate the ability to quickly change the status of the requirements after review in project home page.

Lab Overview page 178 to 206 (skip optional lab) page 207 to 229 Module Brief Description Goals 7: Leveraging the Requirements Across the Lifecycle Add new requirements to the Release Planning Collection. Demonstrate how to quickly create workitems from RRC requirements. (Time permitting show how they are added to plan and ranked in RTC). Demonstrate OOTB views to show trace link artifacts. Conduct similar steps to generate test case artifacts Demonstrate the automated functions to leverage requirements as inputs to ALM. Demonstrate traceability links. (Time permitting demonstrate requirement change an impacts to test). 8: Status of Project Demonstrate how a product owner can keep tabs on project via viewlets and generate PDF reports. See current status of requirements implemented and tested. Generate a report to use outside of RRC.

Define and Manage Requirements with IBM Rational Requirements Composer

Agenda Requirements Quality Issues Key Principles of RRC Agile Requirements RRC Overview A glance of modules Hands-on Labs

The intent of this slide is to briefly capture the modules for the RRC hands on lab. page 7 to 59 page 60 to 81 Lab Overview Module Brief Description Demonstrated Business Value 1: Tour of RRC & JKE Banking Instructor led demo to provide tour of RRC interface and provide an overview of the JKE Banking Project Dashboard provides event and progress awareness Quick web access to artifacts Collaborate with teams at any locations 2: Respond to Change Request Requirement content has already been defined for the release and allocated for Sprint 2. It is realized that new requirements must be added. We will demonstrate various mechanisms for adding new requirements. Quickly create requirements via one click and copy. Leverage external content from RRC and import (upload csv, Word file) Quickly create relationships between multiple requirements Tag artifacts enables quick searches

Known Issues Page 96 Issue: The menus above the dragged tasks will not go away even if you click on another part of the BP sketch Solution: Ignore Page 100 2 a Issue: It is not possible to write in the subject field of the new comment Workaround: add text to the Comment first and then go back to the Subject field and add text Page 113 c Issue: It is not possible to write anything in the search area Solution: Select “Link to web” and then select “Link to an artifact” again in order to be able to write in the search box

Lab Overview page 82 to 104 page 105 to 134 Module Brief Description Demonstrated Business Value 3: Impacts to Business Process Change existing business process to reflect changes to support new requirements for sprint 2. (Donor may donate to more than one organization) Business process sketches are supported. Ease of refining existing content. Collaborate with team-mates to inform them of change via comments. 4: Refine the Use Case Model Refine use case model to reflect ability to donate to more than one organization. Identify how a specification may be tied to either a use case or a user story. Use case model can be used as collaboration and planning vehicle to call out scenarios and actors. Can be used for agile and or use case driven approaches with user story card and use case specification. Ability to use templates to reduce effort. Build a glossary to clarify terminology. Linking to other artifacts to provide context. Embedded artifacts

Lab Overview page 135 to 156 page 157 to 177 Module Brief Description Demonstrated Business Value 5: Change the User Interface It is important to show reuse in the UI. We can quickly show this change by changing a part and demonstrating the impact on sketches. We will also demonstrate the affects of donors choosing multiple organizations in the storyboard for sprint 2. Inheritance improves efficiency of UI mockups User Interface sketch, story board and UI part sketch 6: Conduct a Review Demonstrate how you can involve multiple stakeholders in a review and different types of review roles. Perform online reviews and approval regardless of location of the teams

Lab Overview page 178 to 206 page 207 to 229 Module Brief Description Demonstrated Business Value 7: Leveraging the Requirements Across the Lifecycle Add new requirements to the Release Planning Collection. Demonstrate how to quickly create workitems from RRC requirements. (Time permitting show how they are added to plan and ranked in RTC). Demonstrate OOTB views to show trace link artifacts. Conduct similar steps to generate test case artifacts Requirement traceability across lifecycle (from requirement to dev to test) without keeping spreadsheets One version of truth - developers and testers will see the same info Baseline a collection of artifacts allows you to easily keep track of formally approved versions 8: Status of Project Demonstrate how a product owner can keep tabs on project via viewlets and generate PDF reports. Easily customised dashboards to keep track of progress. Generate reports to use outside of RRC when needed

Session summary We have described the Symptoms of Requirement quality issues, techniques, Agile Requirements, and how Requirement Composer caters for them We have explored how Requirements Composer can Enable business stakeholders, analysts, and delivery teams to collaborate in context by eliciting, elaborating and validating requirements that align with business objectives Enable analysts to capture stakeholders needs using multiple visual and textual requirements documentation techniques Unify the web of information by creating artifacts and capturing their inter-relationships to align stakeholders and empower lifecycle teams with context needed to deliver more value Provide traceability and guide execution across the lifecycle through integrations with other Rational Tools We have provided a hands on experience using Requirements Composer to enhance the software delivery process

Additional Resources Learn more about and download free trials of Rational Requirements Composer, Rational Team Concert and Rational Quality Manager https:// jazz.net /downloads Explore tutorials, demos and other developer learning resources http:// jazz.net Participate in the open commercial development of Jazz by joining the community http:// jazz.net Learn more about the Jazz technology and the future IBM Rational product roadmap http:// ibm.com /rational/jazz/roadmap

© Copyright IBM Corporation 2011. 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. Alan Kan Technical Manager, IBM Rational Software [email_address] www.linkedin.com/in/zenmaster/

Define and Manage Requirements with IBM Rational Requirements Composer

Recommended

More Related Content

What's hot (20)

Similar to Define and Manage Requirements with IBM Rational Requirements Composer (20)

More from Alan Kan (15)

Recently uploaded (20)

Define and Manage Requirements with IBM Rational Requirements Composer

Editor's Notes