Define and Manage Requirements with IBM Rational Requirements Composer
•Download as PPT, PDF•
2 likes•5,929 views
The document provides an overview of a hands-on lab session on IBM Rational Requirements Composer (RRC). The lab aims to demonstrate how RRC can help teams collaborate to define, manage and trace requirements across the software development lifecycle. The lab covers topics like importing and linking requirements, modeling business processes and use cases, conducting reviews, and generating work items and test cases from requirements. Known issues encountered in the labs are also documented.
![Housekeeping ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Define and Manage Requirements with IBM Rational Requirements Composer
Similar to Define and Manage Requirements with IBM Rational Requirements Composer (20)
More from Alan Kan
More from Alan Kan (15)
Recently uploaded
Recently uploaded (20)
Define and Manage Requirements with IBM Rational Requirements Composer
- 1. Define and Manage Requirements with IBM Rational Requirements Composer Alan Kan Technical Manager Rational Software, IBM New Zealand
- 8. 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
- 9. 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
- 10. 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.
- 26. © 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/
Editor's Notes
- 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