• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Define and Manage Requirements with IBM Rational Requirements Composer
 

Define and Manage Requirements with IBM Rational Requirements Composer

on

  • 4,449 views

 

Statistics

Views

Total Views
4,449
Views on SlideShare
4,449
Embed Views
0

Actions

Likes
0
Downloads
111
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Essentials of Requirements Definition Using RRC v7.1 Module 1 - Requirements Definition and Management 1.) Failing to define requirements effectively impacts the software development team and decreases the probability of meeting the project objectives. Unfortunately, all of the students can identify with one or more of symptoms. They are in class to learn our requirements definition tool. What are your key pains? Review these bullets and get consensus that students can relate to one or more of them.
  • Essentials of Requirements Definition Using RRC v7.1 Module 1 - Requirements Definition and Management 1.) Adapt to Change : As the development team obtains a better understanding of the requirements the solution will evolve. As part of this evolution, how they will address a customer’s problem may be very different from the original “Vision.” Just as long as there is concurrence and agreement from stakeholders, the change is acceptable. 2.) Balance Competing Stakeholder Priorities: There are many stakeholders that provide feedback on what the solution should contain. An effective team will manage the expectations and prioritize effectively. Collaborate early and often with stakeholders to obtain feedback and concurrence with stakeholders for the solution to be built. 3.) In Context Information: Requirements definition will follow a phased and or iterative process whereby an understanding of the solution will grow as the project proceeds. Providing a mechanism to define relationships between artifacts as part of the decomposition process is helpful. 4.) Develop Solution to Solve Business Problems : A solution where scope has been defined appropriately will meet the customers goals and or business problems, no more and no less. 5.) Evolve and Incorporate Visual Techniques: Leveraging visual techniques to supplement text can help drive an understanding of requirements. For example creating a business process diagram can help a development team to better understand the business and its domain. A user interface can help flush out visual details for a screen. 6.) Foster a Team Based Approach: Collaborative techniques will help an organization to keep on the same page or drive an understanding of requirements. Talk to at a high level potential areas where IBM Rational Requirements Composer can help teams be more effective in these key principles: Adapt to change: Requirements Composer can be used to help quickly define and elaborate requirements for a potential solution. If a change is defined a solution team can quickly create mockups for example of a UI before moving too far into design. They can share with the stakeholder and reach concurrence regarding the proposed solution. Balance Competing Stakeholder Priorities: Leverage the attribute groups to help capture priorities of the different stakeholders and define the stakeholders. Create in Context Information About Requirements: Requirements Composer provides “just in time” information about requirement artifacts as they are decomposed. Stakeholders and the team can see and understand the context through the linking functions. Develop Solution to Solve Business Problem: Capture the business problem of a stakeholder in for example a Vision document or perhaps a User Story. Then identify the requirements that solve the business problem or goal. Evolve and Incorporate Visual Techniques: Business Process Diagram for Business Domain, UI Sketches and Storyboards to combine UI work with a scenario. Foster a Team Based Approach: Leverage commenting functions to tie to requirement artifacts to pose question, aid in review, etc…
  • Which of these tools might you use for each quadrant of the graph? The experience level of the customer or user and the experience level of the development team can often be critical factors in determining which techniques you apply in your project. For example, if the customer has a lot of experience in a particular domain but the developer has little experience, then the developer must “Catch Up” with the customer. What techniques would be particularly good to help an inexperienced developer to catch up with the very knowledgeable customer? The selection of elicitation techniques can also be related to experience in different dimensions: The problem domain The development methodology, such as object oriented The tools being used and so on You may, for example, start off in “Fuzzy Problem” and make use of techniques 1, 2, and 7. After you have performed these elicitation techniques, you may move into another quadrant and then additional techniques that are more appropriate. Use this slide to reinforce that there are many elicitation techniques available. The more familiar you are with the techniques, the more weapons you can draw from your arsenal to elicit stakeholder requests as different situations present themselves to you. The selection of elicitation techniques can also be related to experience in different dimensions: The problem domain The development methodology, such as object oriented The tools being used, and so on There is not one right answer here; the important thing is to get students reasoning about when they might apply these techniques. For example, use cases may be helpful in any of the quadrants, but in “Catch Up,” the customer sketches the use cases for the developer and in “Selling/Teaching,” the developer might sketch the use cases for the customer. That said, there are some possible candidates for each quadrant. Catch Up:1, 3, 4, 7, 8, 9. Fuzzy: 1, 2, 7. Mature: 1, 3, 4, 5, 6, 7, 8, 9. Selling/teaching: 1, 2, 3, 4, 5, 6, 7, 8.
  • What about Agile Requirements? User Stories are the focus of Agile Requirements. But they don’t come out of a vaccum. There are a number of high level requirement documents that Agile teams usually create before the User Story. Starting from business case document, business requirements or high level requirements, down to business process, use case, etc. These contribute to the creation of a User Story. Then the User Stories accumulate to a product backlog Some of the User Stories will need to be elaborated and illustrated to customer using screen design, storyboard, etc. If you use document, spreadsheet and drawing applications, you will have separate files everywhere with no traceability and no context to any content. When user requirement changes, where do you find the right files to change? If there is a new person joining the team, can he find the right file in 5 minutes? Or will he spend 30 minutes hunting for the right files and possibly missing a couple?
  • Speaker Notes
  • An IBM Proof of Technology Session Summary
  • Mandatory IBM Rational standard closing slide to be included in all external presentations. Learn more links: IBM Rational software: www.ibm.com/software/rational Rational launch announcements: www.ibm.com/software/rational/announce/ Rational Software Delivery Platform: www.ibm.com/software/info/developer Accelerate change and delivery: www.ibm.com/software/rational/offerings/scm.html Deliver enduring quality: www.ibm.com/software/rational/offerings/testing.html Enable enterprise modernization: www.ibm.com/software/info/developer/solutions/em/index.jsp Ensure Web site security and compliance: www.ibm.com/software/rational/offerings/websecurity/ Improve project success: www.ibm.com/software/rational/offerings/lifecycle.html Manage architecture: www.ibm.com/software/rational/offerings/design.html Manage evolving requirements: www.ibm.com/software/rational/offerings/irm/ Small and midsized business: www.ibm.com/software/rational/smb/ Targeted solutions: www.ibm.com/software/info/developer/solutions/index.jsp Rational trial downloads: www.ibm.com/developerworks/rational/downloads Leading Innovation Web site: www.ibm.com/software/rational/leadership developerWorks Rational: www.ibm.com/developerworks/rational IBM Rational TV: www.ibm.com/software/info/television/index.jsp?cat=rational&media=video&item=en_us/rational/xml/M259765N40519Z80.xml IBM Rational Business Partners: www.ibm.com/partnerworld/pwhome.nsf/weblook/index.html IBM Rational Case Studies: www.ibm.com/software/success/cssdb.nsf/topstoriesFM?OpenForm&Site=rational

Define and Manage Requirements with IBM Rational Requirements Composer Define and Manage Requirements with IBM Rational Requirements Composer Presentation Transcript

  • 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
  • Collaborative Team Roles
    • 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.
  • 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/