IBM Rational DOORS family solutions offer best practices in requirements management and traceability, saving organizations time and money, through improved collaboration with stakeholders to eliminate inaccurate, incomplete, and omitted requirements.
Doors Next Generation is a requirements management application for optimizing requirements communication, collaboration and verification throughout your organization and supply chain. This scalable solution can help you meet business goals by managing project scope and cost. Rational DOORS lets you capture, trace, analyze and manage changes to information while maintaining compliance to regulations and standards.
Top three reasons your organization needs Doors Next Generation
- Reduce development costs by up to 57%
- Accelerate time to market by up to 20%
- Reduce cost of quality by up to 69%
Key Feature's :
Centralized location : Requirements management in a centralized location improves team collaboration, provides access to full editing, configuration, analysis and reporting capabilities through a desktop client. It also supports the Requirements Interchange Format, enabling suppliers and development partners to contribute requirements documents, sections or attributes that can be traced back to central requirements. Records and displays requirements text, graphics, tables, requirements attributes, change bars, traceablity links and more.
Link requirements : Traceability by linking requirements to design items, test plans, test cases and other requirements. Users can concurrently edit separate product and system requirement documents and link entries between documents. Requirement entries can also be linked to models, text specifications, code files, test procedures and documents created with other applications
Scalability : Address changing requirements management needs. Offers an explorer-like hierarchy with multiple levels of folders and projects for simple navigation no matter how large the database grows.
Change management : Integrations to help manage changes to requirements with either a simple, pre-defined change proposal system or a more thorough, customizable change control workflow. It integrates with Rational change management software for requirements change control and for requirements workflow management. It also integrates with other rational solutions, including IBM Rational Quality Manager, IBM Rational Rhapsody, IBM Rational Focal Point and others like HP Quality-Center for visibility of requirements to create test cases for traceability and for status report on coverage of requirements by test cases, and also with Microsoft Team Foundation Server (TFS) to enable Microsoft Visual Studio development teams to create and maintain traceability between requirements in Rational DOORS and TFS Work Items in Visual Studio.
If your organization wants to replace outdated and expensive legacy tools, and needs better control over multiple versions of documents, IBM appreciates the opportunity to discuss REQUIREMENTS with you. If you’d like to see a live demo please click dngdemo,
Would you like to start benefiting by using IBM Rational DOORS Next Generation? Start your free trial today Free Trial
Modified on by VijaySankar
We had a fantastic DOORS customer webcast panel on September 26 with experts from across the industries talking about their experience in using IBM Rational DOORS for requirements management. If we have to take one success metric for the webcast; it was that we overshoot by half an hour from the designated one hour for the discussion because we had some wonderful discussions going on. Our panelists have graciously agreed to respond to the questions on an offline basis, and we are publishing the answers here.
If you missed this golden opportunity and is wondering whether you can get another chance? YES! Or you would like to listen to it again; we have posted the replay here. You can listen to it anytime now. Register here
How to copy the objects with in-links and out-links from one module to another module?
< >Use DXL scripts that capture link information, which can be edited if necessary, and then copy the objects, and then run another dxl script to re-create the links.
Paul Lusardi has shared with us couple of samples. If you are interested, contact us
What factors determine using new database vs a new project in a database to differentiate/segregate work?
< >The biggest criteria for using the same database is Linking. If there are Projects in a database that you need to link to, the new Project should be in that same DB.The default should be to use the same database so that you only have to maintain one set of users, groups, standards, etc…. the possible exception is if you have 2 distinct sets of security measures (HIPAA, DoD or DoE cleared data) then you will want to segregate that out to a different server.
Does anyone on Panel publish documents directly from DOORS without Add-on applications?
< >[Patrick] I use DXL scripts which export the data out to RTF with some typical publishing formatting
[Mia] < >I do. Whether you can depends on the demand for documents (do you need to do them once a week? Daily? Quarterly?) and how critical their formatting is to your organization. We have configured views in most modules for output. A simple one has just the object number and the Object Heading/Object Text. For a full spec, we include trace columns for one or more linked modules, with object identifiers and even object headers or text in those columns. In the output you get the main object from the current module, followed by all the objects it’s linked to. I keep in a label that specifies “in link” or “out link.”I used to painstakingly populate the Paragraph Style attribute in order to map to MS Word, but because our need for documents is very low I have stopped enforcing this. We have a set of MS Word templates with the title page, toc, other front matter, and a standard set of styles. Plain Vanilla DOORS maps to basic Word styles fairly well.I pick the appropriate view and filters and select Export to Word. I select the appropriate Word template, and let it rip. I then do some minimal post processing, like getting rid of the object IDs on headings. Obviously if you’re doing very long documents this would be impractical.In my previous job we had interns create a DXL script that handled the post processing – you can get to something that’s usable without a huge investment.
How do you deal with sharing of your database with the government or other contractors? Do you share read-only partitions ?
[Paul] < >Previous to coming to NuScale, I co-developed the Unified RM Database where we allowed outside access, using access control and company VPN login credentials to enable multi-company development and reviewer teams to look at the data.The questions would be …..do you want them to see work in progress? Or just a snapshot of baselined work? Perhaps a separate server with a restored baseline set would be best in that case. I will defer to an expert on baseline sets though
How do you get rid of allowing DOORS Links?
[Patrick] We use a link schema with Pairings as necessary, and then create and delete but not purge the DOORS Links module with a copy in every sub-Project/Folder, and leave it as the default Link Module. That way, users cannot create a link that is not intended between any module pair.
Paul Lusardi has shared us a presentation. If you are interested, contact us
Is there a "Copy View" script available?
Paul Lusardi has shared us a presentation. If you are interested, contact us
Please ask about doing risk assessment in DOORS: Do any of the panelists document FMEA or risk analysis in DOORS? How do they do it?
< >[Paul] Yes and no. Textbook FMEA? No. using DOORS to analyze potential risks by means of looking at risk informed design? Yes, this is a “developing” activity[Patrick] We capture the risk status in DOORS, but not the actual assessment data
Do any of the panelists integrate DOORS with other tools like Rational Quality Manager?
< >[Patrick] We are looking into it, but have not actually started using in Production. Going to deploy DOORS/CQ by year end.[Paul] Only RPE integrations are used here
How has your work differed because you use SCRUM vs. when you did not?
Our pre-sprint requirements work is at a higher level – that is, not down in the functional weeds. We spend more time exploring new features from the user’s perspective, and more time on storyboarding and similar activities. The features we’ve built since going to agile are much more user-friendly and have much better workflows than the older stuff, where much of the workflow and usability decisions were left to the engineers.
Detailed functional analysis of requirements happens during the sprint, with the requirements analyst on the team working closely with the engineers and testers. For very complex features, this analysis process will begin before the sprint so that we have enough functional detail for the team to estimate the work. We have a small backlog grooming team that, members of the scrum teams, who help the requirements analyst with this.
For Mia, for your agile, how many full-time admins needed to maintain DOORS?
[Mia] We’re very small, so we don’t even have one full time admin. Our system engineer handles the environment, and I handle user administration. It’s a tiny part of each of our jobs. I don’t see that our approach represents a particularly different administrative need than any other. If we had a hundred users and multiple DOORS databases, then we’d dedicated administrative resources just like any other implementation.
@Mia - Are requirements for HW to SW interfaces traced through ICD(s) in DOORS?
We’re software only, so no HW/SW interfaces. However, I strongly support the use of interface specifications between software systems and have used an interface module to sit in between systems that need to interact. The trick is to stay on the requirements side of the requirements/design line. The cost of maintenance on such a model is high – probably too heavy for our agile process to maintain. However, should we need to support integration with an external application (one that our teams are not developing), our API requirements will undergo close scrutiny and possibly be carved out into a separate module so that we can use trace links to do impact analysis on external “clients.”
Do you DOORS lend itself to any specific Devops , ALM methodology liek Agile etc?
We adopted a continuous deployment model this year and it had no impact on our use of DOORS. That is, DOORS is still a critical part of our development tooling. We were already capturing release version information for requirements in DOORS, and this information remains very useful in understanding what feature set exists in a given version of our application.
Try IBM Rational DOORS in a Sandbox
Webcast - Achieving sustainable requirements across the supply chain with IBM Rational DOORS
Modified on by VijaySankar
Here is coverage of Requirements Management for Systems Engineering track keynote based on the presentation that Bill Shaw (Systems Program Director) and Richard Watson (Senior Product Manager for Requirements Management tools) delivered at Innovate 2013 today.
For those new to the space, IBM Rational DOORS is a widely recognized product in the requirements management area and here is how we see our products are meant for -
Rational DOORS the trusted, de-facto standard requirements management tool for employing Systematic Engineering methodologies to build complex and embedded systems.
Rational DOORS Web Access, an add-on for DOORS enables globally distributed stakeholders with visibility into requirements and traceability relationships (managed in Rational DOORS), with the ability to communicate via online requirements discussions. Using a Web browser, DOORS Web Access provides access to view and discuss requirements—with no additional software installed on your desktop.
And finally the latest addition to the family, Rational DOORS Next Generation is the next generation requirements management solution built on the IBM Rational Jazz platform.
With such a plethora of offerings, we believe we have the right requirements solution for you. As we mentioned earlier, introduction of DOORS Next Generation DOES NOT mean we are moving away from DOORS. We are continuing our investment in DOORS and we will continue to release better and improved versions of DOORS in future. We believe DOORS Next Generation takes the requirements management capabilities we offer to the next level especially with the foundation of an open collaborative platform. DOORS NG, designed from the ground up to accommodate an ever growing and complex ecosystem, greater need for collaboration and usability for a broader community of stakeholders plans to extend the capabilities for requirements change management & Product Line Engineering. Packaging DOORS NG within DOORS helps our customers to try both the products without purchasing two licenses.
New in Rational DOORS
We have now included four more pre-configured templates supplied from Systems and Software Engineering enabling our customers in kick-starting their projects.
Systems Engineering Template
A simple, pre-configured information schema for using DOORS to support systems engineering
Aerospace & Defense
Developing requirements against the DO-178B safety standard
Supporting the ISO26262 functional safety standard
FDA Design Control practices defined in 21 CFR Part 820
We are continuing our investments in replacing the requirement of installing Rational Publishing Engine (RPE) client for report generation. In DOORS 9.5.1, we have included the support for parameterized RPE templates. Advanced styling and configurations options are also now included.
We have been making some significant improvements in the Open Services for Lifecycle Collaboration (OSLC) front including an enhanced Rational DOORS-Design Manager integration. For this integration, we have used link discovery technique rather than back-linking, thus helping in a better integration - Links will only be stored within the creating application and discovery is done in the background on a real time basis. This investment also helps in improving our 3rd party integrations.
Starting this version of DOORS, we will be using ETL(Extract, Transform and Load) to integrate with Rational Insight. Since this is the method used for integrating RRC and DOORS NG with Insight, the metrics capabilities remain the same across the products. This enables specific metrics defined in DOOR being reused in DOORS Next Generation. Thus one can deploy insight over DOORS 9.x data and while piloting DOORS NG, all the metrics data would be made available in it automatically. Check this article for more details - Improve the value of your CLM reports by using metrics.
Based on feedback from customers, we have made good amount of usability enhancements in 9.5.1. Some of them include
Link preview with OSLC style rich hover on links to understand better traceability navigation
Better navigation into baselines and improvement in management of baselines
Improved support for DOORS table formatting
We have also made some significant improvements to DOORS Web Access. Some of them include
Simplified configuration and deployment
Improvements to Database Explorer
Support for DOORS project view in the Database Explorer now
New in Rational DOORS Next Generation
We have been continuing to make improvements in the product since its first release in November 2012. Our priorities are to focus on product quality and usability and from a long term perspective - on requirements configuration management. Some of the major updates to DOORS Next Generation are
Unobtrusive locking of data to avoid save conflicts
Improved graphical markup to help in change management
Improved multi-user and offline edits of non-native data
Improved data support for product evaluation
Note: Roadmap and strategies mentioned in this post are subject to change and request you to be in touch with IBM reps to understand the latest road maps
Modified on by VijaySankar
This year, Innovate - The IBM Technical Summit will be held from June 2 to 6 at Orlando, Florida. As in previous editions, we will be having two tracks dedicated to requirements management at the event. One track would be focusing on requirements definition and management for IT/Application development and the other track will be focusing on Requirements Engineering for Systems and Product development. Each track will have 16 sessions starting with the individual track kickoffs. This year the conference will witness personalities like Steve Wozniak, Eric Ries and many other.
The requirements management track will showcase more than 25 real life case studies and best practices from across the industries ranging from Banking to Insurance to Aerospace & Defense to Energy & Utilities. Some of the interesting sessions to watch out for are
Agile Requirements: Maintaining the Model Through Iterations (by Mia McCroskey, IBM Champion at Emerging Healthcare IT)
DOORS Next Generation: 1st Impressions and Key Comparisons (to IBM Rational DOORS) [by Alex Ivanov, IBM Champion at Raytheon]
Successful RRC adoption through a Community of Practice: Case Study from Blue Cross Blue Shield of North Carolina
Cerner Corporation: Migrating from Requisite Pro to RRC
Piloting Rational Requirements Composer for Enterprise-wide deployment: The Good, the Bad, and the Ugly (Fidelity)
Managing Parallel Streams of Requirements in DOORS at an Automotive OEM
A DOORS-based solution for semi-automated risk analysis within MedTech
We also have two instructor led workshops for Rational DOORS and Rational Requirements Composer. Learn more here. Demo booths, self paced tutorial labs for DOORS, DOORS Next Generation and RRC are also organized during the event.
Few other attractions for anyone interested in the field of requirements management are panel discussion, Meet the developer sessions, sessions from organizations like IAG Consulting, IIBA and INCHRON.
Every year Innovate attracts 4000+ professionals from across the world. Join us for one of the biggest technical conferences to learn, meet and network with like minded technical professionals. For more details about the conference visit Innovate 2013 - The IBM Technical Summit
Here is the detailed agenda of requirements management topics at Innovate -
ps: agenda subject to change
Modified on by VijaySankar
Jeremy Dick works as Principal Analyst for Integrate Systems Engineering Ltd in a consultancy, research and thought leadership capacity. He has extensive experience in implementing practical requirements processes in significant organizations, including tool customization, training and mentoring. At Integrate, he has been developing the concept of Evidence-based Development, an extension of his previous work on “rich traceability”. Prior to this appointment, he worked for 9 years in Telelogic (now part of IBM Rational) in the UK Professional Services group as both an international ambassador for Telelogic in the field of requirements management, and a high-level consultant for Telelogic customers wishing to implement requirements management processes. During this time, he developed considerable expertise in customizing DOORS using DXL to support advanced engineering processes. His roles in Telelogic included a position in the DOORS product division to assist in the transfer of field knowledge to the product team. Co-author of a book entitled “Requirements Engineering” that has recently reached its 3rd edition, he is recognized internationally for his work on traceability.Jeremy can be reached out at jeremy.dick[at]integrate.biz
It is a bit of a shock to find myself well into the fourth year on the same project! The nature of my work as a consultant means that it is rare for me to stick with a project beyond the initial phases of defining a requirements management process, establishing effective tool support and training the process enactors. But this time we have been able to stick with the requirements team supporting a large project long enough to see theory put into practice, and to see what it really means to apply the tools and techniques. We have gone well beyond just training, and find ourselves mentoring nearly 300 engineers in the application of DOORS for requirements capture, development and management. This has helped us keep our feet firmly on the ground – rubber on the road – and to walk with those who actually have to do the work.
So what have we learnt?
It is one thing to teach people how to write requirements statements that are clear, unambiguous, testable and traceable; it is quite another thing to help people understand how to take a requirement and develop it. None of the engineers we met on the project had previous experience of how to take a system requirement, for instance, and systematically decompose it through the design into sub-system and component requirements. We had to adapt our training and mentoring to address this skill.
Requirements decomposition establishes one of the essential requirements traceability relationships: how each layer of requirements contributes to the satisfaction of the layer above. This is often known as the satisfaction relationship, or as refinement in SysML. It is this relationship that connects the design to the development of requirements, and that lies at the heart of the ability to perform impact analysis.
Whatever layer you are engaged in – customer, system, sub-system or component – the same basic requirements development process can be applied. These are the process steps we teach for requirements development:
1. Collect and agree your requirements.
Here you actively seek out the requirements you are expected to fulfil. In an ideal world, development will be perfectly top-down, and you can wait for the layers above to allocate perfectly expressed requirements to you. In a practical world, you will have to be more proactive, and will have to cooperate with your requirement “customers” to obtain acceptably worded requirements.
2. Design against your requirements.
This stage is the creative bit that you perhaps most enjoy doing, and where the real engineering takes place. You will imagine how to design the system to meet the requirements, and what you need your requirement “suppliers” to do to contribute to your design. In other words, if you are at the system level, you design the system into sub-systems, and work out what each sub-system must do to meet the system requirements.
3. Decompose the requirements to reflect the design.
Now you enter the decomposed requirements and trace them back to the requirements they satisfy, thus making the requirements contents and traceability reflect your design. The wording of the decomposed requirements is important: if the original requirement read “The <system> shall ...”, then it is likely that the decomposed requirements will read “The <sub-system> shall ...” At this stage you can also capture rationale for the decomposition, including references to the design documentation or models, thus tracing also to design information.
4. Allocate the decomposed requirements.
Finally, you can pass on the decomposed requirements to those areas responsible for fulfilling them. These other areas engage in the same process, and together you systematically achieve alignment of requirements through all the layers.
The example below illustrates the end result of applying this process on a user requirement decomposed into system requirements. The rounded box contains the design rationale, and refers to a functional model of the product. (If you’ll forgive the shameless plug, such diagrams can be produced using a DOORS extension related to TraceLine. Ask me more if you are interested.)
The example just shown is a classic decomposition pattern. It is actually the decomposition of an overall performance into a combination of capacity and performance attributes of the product. We call this “decomposed”.
Other decomposition patterns are possible. Sometimes no decomposition is necessary, because the system requirement can be satisfied entirely by a single component or sub-system, as in the left-hand example below; or a constraint that will apply universally to all parts, as in the right-hand example. All that changes, perhaps, is the wording of the requirement to indicate the new target. We call this “direct flow”.
You will reach a point in the cascade of decomposed requirements when a requirement is satisfied entirely within the current area without the need to decompose further, as illustrated in the following. In this case, it is important to state the rationale for not flowing the requirement onwards, as otherwise it may be construed as a traceability gap. We call this “not developed further”.
I have seen a number of organisations that capture this flow-down type – Decomposed/Direct Flow/Not developed further – as an attribute of the requirement. We do this because it allows us to cross-check certain things: if you have marked a requirement as “Decomposed” but have not decomposed it, then that does indicate a design gap. However, if you mark the requirement as “Not developed further”, that gives you permission not to trace it further, i.e. not a design gap. (But you would do well to provide rationale!)
As requirements flow down through the layers, the complexity of the design becomes evident in the shape of the requirements graph. In general, satisfaction is a many-to-may relationship between requirements, and the figure below shows how this may be manifest. As the requirements are decomposed, they are refactored through the design.
Some patterns are questionable. Take these for instance:
Why decompose something into three requirements only to reduce them to a single one again? Or why collapse three requirements into one only to re-expand them in the next layer?
These patterns are not necessarily wrong, but they should be targeted for careful review.
So this is what we now teach those engaged in requirements decomposition, flow-down and traceability. It is wrong to assume that people will somehow automatically know how to do this kind of thing. By taking this approach, the flow-down of requirements reflects the design, and a clear satisfaction relationship is expressed in the traceability.
Read the second part here - The practical application of traceability Part 2: What’s really going on when you plan V&V against a requirement?
Modified on by VijaySankar
Just like the famous (mis)quote of Mark Twain, rumors of the demise of the requirements management tool IBM Rational DOORS are not only exaggerations but in fact untrue. I’d like to put straight here some of the myths and misunderstanding that I’ve heard and seen perpetuated:
Myth: IBM is discontinuing support and development for the DOORS 9.x series
Truth: IBM continues to develop the DOORS 9.x series with the same level of development resources. We have new functionality to announce in 2013 and plan further releases in the years ahead. In addition IBM has recently invested additional development resources in creating a new Requirements Management tool called IBM Rational DOORS Next Generation (DOORS NG).
Myth: IBM is replacing the DOORS 9.x series with DOORS Next Generation (DOORS NG) and expects customers to migrate now
Truth: DOORS 9.x will be developed in parallel with DOORS NG for many years to come. DOORS NG was released for the first time in November 2012. The tool has many functions DOORS 9.5 does not have, e.g. fully functional web client, type and data re-use (requirements & attributes), team collaboration, task management, but also does not have all of the capabilities relied on by DOORS 9.x users. We encourage users to evaluate the capabilities of DOORS NG and start projects or move projects to DOORS NG when practical and beneficial to the project.
Myth: To move to DOORS Next Generation, I’ll need to buy a whole new tool
Truth: Customers with active support & subscription on their DOORS 9.x licenses are entitled to use DOORS Next Generation - it is included as part of the DOORS 9.x package. Customers can choose to use either DOORS 9.x, DOORS Next Generation or a combination of both. There is no need for additional purchases or even for an exchange of licenses. All licenses are available to customers in the IBM license key center.
Myth: IBM offer no migration path from DOORS 9.x to DOORS NG
Truth: IBM do offer functions to transition into using DOORS NG for existing DOORS 9.x customers:
Work with DOORS 9.x and DOORS NG alongside each other - both tools support linking of information between both databases.
Work with suppliers by exchanging requirements through the standard exchange format of ReqIF. This works best between DOORS 9.x and DOORS NG but is also designed to work with other RM tools.
Where DOORS NG projects wish to be initialized with data from DOORS 9.x we offer re-factoring functions to harmonize the transition of data from DOORS 9.x to DOORS NG.
Myth: Everyone knows IBM’s strategy on requirements management and DOORS
Truth: IBM takes great care to regularly communicate our product strategy and roadmap at trade shows, IBM conferences and on webcasts. If in doubt, come and ask IBM! Please submit questions using the comment feature here or contact your IBM representative.
For information about the products, visit -
IBM Rational DOORS
IBM Rational DOORS Next Generation
Today we have with us Mia McCroskey at Emerging Health Montefiore Information Technology who was recognized as IBM Champion this year. She shares with us her thoughts about the requirements management domain.
Welcome to IBM family! It¹s a great pleasure to have you with us as an IBM Champion. Congratulations, How do you feel?
I am honored to be recognized in this way not just this year but for the past several years that I have been asked to present my team's stories at Innovate. It may seem like our little team's requirements management needs are nothing like those of customers with huge DOORS ecosystems. But really we are an R&D site for the evolution of requirements management techniques and strategies. If a member of my team has an interesting idea for how to capture, structure, track, or trace requirements, we can try it without getting high level approvals or disrupting the work of hundreds of people. I take tremendous satisfaction from sharing our successes in a way that may help others improve their best practices.
Can you tell us something about what you do at Emerging Health, Montefiore Information Technology?
Emerging Health is primarily an IT delivery organization supporting healthcare delivery in the Bronx. Montefiore Medical Center is our parent company. My team, Product Development, is a software development shop tucked away in a corner doing very different work from most everyone else. Our application, Clinical Looking Glass, is a browser-based clinical intelligence tool that gives clinicians access to the enormous wealth of patient data gathered by all the other systems. Our end users can get an answer to a question like "are my clinic's diabetic patients getting the level of follow-up care required by our funding sources?" in a few minutes. In most healthcare environments, getting the data that you need to answer this question takes weeks.
My title is Manager, Product Development Lifecycle because I have my fingers on just about every stage of that lifecycle. Specifically, I lead our Requirements Management, Quality Assurance, Education, Support, and Implementation teams. I also manage outsourced development work, manage client relationships, and do hands on end-user training and support. We are an extremely team-oriented organization, with two formal development scrum teams and two teams that are at various stages of adopting an agile process. I'm deeply involved in that right now: it's challenging to apply Scrum to a training and support team, and to a team of data analysts and engineers.
Having said all that, my roots are in requirements. On a team of "happy path" stakeholders who get very excited by ideas for new functionality, I love to dig in and find the challenges that nobody wants to think about -- before we start coding. Sometimes I feel like a real buzz kill!
What are your thoughts on managing requirements effectively?
Agile models have forced us to completely reorganize our requirements elicitation, analysis, and management processes. But one thing that has not changed is my belief in a comprehensive, functionally organized requirements model.
But when I say "comprehensive," I don't mean laboriously detailed. The art of requirements analysis and management is in knowing -- or guessing right -- what details are going to be important later. By later I don't mean to the coders and testers in this iteration, I mean when we want to revise or augment the feature in six months. The requirements analyst has to be deeply plugged in to the business goals and vision in order to predict the future and capture the least amount, but most important information about what the team is doing.
A few years ago I spent many months constructing an "as built" specification for a market data system at the New York Stock Exchange. I had the original ten-year-old spec and a few dozen incremental release documents. We were getting ready to refactor the system and nobody knew every business rule and function. I vowed that no system I worked on would ever lack a spec that described everything it currently did. Incremental requirements specs that aren't integrated into the overall system are defects waiting to be discovered once the coders get ahold of them.
Having argued that I must add that a requirements model in document form is pretty nearly impossible to maintain in the way I describe. You've got to employ a database tool that supports the granularity of each requirement and allows you to describe each one through attributes. Then you can use filters and queries and views to present an infinite number of customized specifications -- all of the requirements implemented in a specific release, or all of the requirements related to a specific functional area, or the completed requirements related to a specific business objective or corporate mandate.
What are your thoughts on the role of requirements management in agile projects?
I recently spoke with a software development professional who was very proud of his organization's highly structured and detailed requirements templates that captured every detail before any work began "to be sure we deliver what's wanted." I felt like I was talking to tyrannosaurus rex. We all know that the day after you baseline that 400-page spec it's already out of date.
Agile with its short increments and "only write down what you really need to" mentality can seem seductively freeing. When our organization adopted Scrum, I stuck to my requirements model guns, and sure enough a few months later we couldn't remember decisions that we'd made a few sprints back, nor even exactly which sprint we'd done the work in. Since we weren't supposed to be doing "heavy" requirements, we'd been coached to: use the system and see what happens; or sift through dozens of completed user stories and hope the detail we wanted was actually mentioned in the acceptance criteria (which it was not because it was an in-sprint decision); or try to find relevant test cases and check the expected results. Instead, I launched DOORS, went to the functional area related to the question, and checked our documented business rule. Done.
What are some of the challenges you see in Healthcare Informatics projects?
Deriving meaningful information from the electronic medical record is essential to justifying the cost of those systems. We're piloting the use of predictive analytics -- combining statistical methods with the mass of patient data collected every day at our parent medical center -- to predict outcomes at the population level. To do it you need a very wide range of data: blood pressure, height, and weight, smoking patterns, history of heart disease, current blood sugar level, and on and on. Just bringing all this data together is the first challenge. Next is the analytic tool -- that's CLG. Finally you need big iron to process it. Most local and regional healthcare providers don't have the funding for, say, Watson. My team spent last summer optimizing our hardware and software environment, and CLG itself, to handle analysis of larger data sets faster, but within a medical-center friendly infrastructure budget.
Another area of critical concern is patient information. The need to pool patient data for direct care as well as population research is supported by legislature and funding sources. But we are bound, both legally and ethically, to protect patient identity in every circumstance.
Clinical Looking Glass has the capacity to show patient contact information to users who have been granted permission to see it -- usually clinicians who are actively providing care and need to contact the patients. While this is a critical feature of CLG, we expect to have to develop more granular levels of access as new types of clients adopt the product. For example, our Regional Health Information Organization (RHIO) client has data from twenty-two healthcare institutions. Some patients have declined to have their identity shared across the organization. We have to build the capability to mask these patients' identity even to our users who have permission to see it.
On Thursday 14 March I presented on an IBM sponsored Dr Dobbs webcast on the topic of ‘3 Reasons to Throw Away Your Requirements Documents’. If you didn’t catch the webcast, you can view it on-demand and download the slides. If you did attend I hope you enjoyed it and in this blog post I want to answer some of the questions that I didn't get time to cover in the webcast, so scroll down to see if I've covered your question here. But first, for those of you who didn't make it, here's a quick recap of points I made during the webcast:
- What do I mean by ‘Throw Away Your Requirements Documents’? I’m not saying do away with your requirements or your requirements management process. What am I saying is invest in improving your requirements management process and support those process improvements with the right tooling. In the webcast audience poll, 60% said they are using documents and/or spreadsheets for requirements, so I set out to provide the case for why they should consider moving to a requirements management tool.
- Reason #1 – Collaboration. Using documents and spreadsheets, you can get into all sorts of problems like working from the wrong version of requirements. An integrated requirements management tool (one that has a collaborative repository that has open interfaces to share requirements data with design, test and development environments) helps you ensure that all engineering / development team members and their stakeholders are working from the right version and view of requirements for their role. I shared information from a case study on MBDA Missile Systems where collaboration was a major challenge.
- Reason #2 – Traceability. Traceability helps you get context and an audit trail for decisions made, perform coverage analysis, detect gold plating and perform impact analysis (See blog posts ‘What is Traceability?’ and ‘The uses and value of traceability’ for more explanation). But using documents and spreadsheets to create and manage traceability gives it a bad name – it becomes a tedious, error-prone overhead activity. With an integrated requirements management tool traceability links can be easily created and navigated. Traceability becomes part of the process rather than a bulk catch-up exercise, and through open interfaces it becomes easy to extend traceability from requirements to artifacts in other tools such as designs, work items and test cases. And most importantly there are automated views and reports that enable you to make active use of traceability for the purposes I mentioned above. I shared information from a case study on Invensys Rail Dimetronic where traceability is essential.
- Reason #3 – Agility. As many engineering and development organizations are looking to improve time to market and reduce costs, agile approaches are becoming increasingly popular (in the webcast audience poll 56% said they were using some sort of hybrid waterfall/iterative approach and 20% were agile), and with that comes changes to the way requirements might have been traditionally defined and most importantly to the way that changes to requirements are managed. Change is allowed and encouraged but you must have reviews and impact analysis to make informed decisions about whether to accept the change and implement in the current iteration or sprint, plan it into a future iteration or reject the change altogether. And to do that requires more than just a backlog managed in a spreadsheet or an agile planning tool. At IBM Rational we keep a prioritized backlog of user stories and epics as work items in plans managed in Rational Team Concert. User stories and epics are then decomposed and more fully described by requirements and supporting visual and textual artifacts created and managed in Rational DOORS Next Generation.
- And I started and concluded by looking at the most compelling reason for improving your requirements management process with the support of the right tooling: Return on Investment. I shared information from a case study on Emerging Health, Montefiore IT where they a achieved, among other benefits, a 69% reduction in the cost of quality (test preparation, testing and rework) within 6 months of deploying an improved requirements management process supported by IBM Rational DOORS. There’s also a follow-up video to this case study that was recorded after the client had adopted agile development practices.
Ok now onto some of the questions that were submitted but I didn’t time to answer during the webcast. I’ve divided them into sections based on the type of question so you can easily scan down to topics you’re interested in:
Alternative approaches to managing requirements
Q. What's the advantage of a requirements management tool if I could link my change management tickets to fine grained requirements (use cases, storyboards) that are maintained on a wiki or other collaboration tool (e.g. Sharepoint or IBM Connections)? It would seem that the work items would give you the needed traceability and metrics?
A. While you might be able to create the level of traceability you require, how would you report on it? Would you have to build bespoke views and reports? And would the use of a wiki for ‘fine grained requirements’ provide you with a view of requirements in context with one another as opposed to individual wiki pages? Where would you document additional properties of requirements? Could you easily reuse requirements across projects? A requirements management tool like IBM Rational DOORS Next Generation provides built-in traceability views and reports, enables to you to structure requirements in context with another in document-like views, provides user-defined properties for recording additional information and facilitates reuse of requirements.
Requirements Management and Agile Development
Q. We are mostly using water fall model, but looking into checking if Agile works for our customers. I am very interested in the role of a Requirements Analyst in the Agile world. In our world, the analyst is a facilitator of requirements gathering and not a SME on the business application we are gathering requirements for.
A. That facilitation role and the analysis skills of the Requirements or Business Analyst are still essential in Agile development. A common mistake when moving to moving to more agile approaches is appointing a ‘Product Owner’, who is a subject matter expert in the business domain you are building an application or product for, and expecting them to write the requirements or ‘user stories’. While they are experts in the business and you need that expertise on hand for Agile to work, they are not usually skilled in getting to the root goals or needs of the business problems you’re looking to address with the product or application. Without the skills of the Requirements or Business Analyst, it’s all too easy for the user stories to become about automating the way things are done today rather than addressing the real business issues in an optimal way. You can read more about the role of the analyst in Agile development in an interview with Mary Gorman of EBG Consulting.
Q. How does the IBM requirements toolset compare to more "agile" focused toolsets like Atlassian, Rally, etc.?
A. IBM is very committed to supporting agile development, particularly when agile is scaled to large, distributed development teams. At the heart of our agile development capabilities is Rational Team Concert which supports agile planning, task management and change management. As stated in the webcast though, we’ve found in our own continuous delivery process and heard from clients, that a place is needed to capture more details of requirements and their associated properties, in context with one another, together with supporting artifacts like storyboards, workflow scenarios and use cases. The integration of Rational Team Concert with Rational DOORS Next Generation provides those additional capabilities while preserving traceability to user stories and epics managed in the product backlog.
IBM Requirements Management solutions
Q. It seems this discussion is on Rational DOORS. Is Rational Requisite Pro still offered? If so then how do these two products compare?
A. IBM continues to support, maintain and respond to enhancement requests for Requisite Pro, but our future direction for requirements management for IT application development lies with Rational Requirements Composer and we provide migration support and a trade-up program. Please contact your IBM representative for more details. If you are using Requisite Pro for requirements management for complex products or embedded systems development, then you might also want to look at whether Rational DOORS or Rational DOORS Next Generation is the right move forward for your organization. But don’t worry we’re not forcing you to migrate today.
Q. You've mentioned DOORS Next Generation in your presentation, what is that? Does it replace DOORS?
A. IBM Rational DOORS Next Generation is a requirements management application on a collaborative lifecycle management platform for systems and software engineering that provides requirements collaboration, planning, reuse and lifecycle traceability. DOORS Next Generation (DOORS NG) was introduced in 2012 to take advantage of the common, collaborative ‘Jazz’ platform shared by Rational Team Concert, Rational Quality Manager, Rational Design Manager and Rational Requirements Composer; and to extend the requirements management capabilities in Requirements Composer to meet the needs of product & systems development organizations developing complex and/or embedded systems. DOORS NG will enable IBM to introduce new capabilities, faster, that would have been more difficult to deliver with existing DOORS product. However DOORS NG does not replace DOORS today. We have a very large install base of DOORS users working on programs that can last tens of years, and we will continue to support, maintain and enhance the DOORS 9.x series to meet the needs of those users. We encourage existing DOORS users to take a look at DOORS NG, to try it out on pilot projects and use the interoperability capabilities to exchange and/or link data with DOORS 9.x. Existing DOORS customers with active support & subscription are entitled to use DOORS NG without requiring an additional purchase – you can use your existing DOORS license entitlements to use with either DOORS or DOORS NG or a combination of the two. But we are not telling existing DOORS users to migrate live projects to DOORS NG today. DOORS NG in it’s early releases is attractive to organizations who don’t currently use a requirements management tool and are looking for a web based solution that also offers common platform integration with change management, agile planning, test management and design management capabilities. You can download a trial and follow development plans for DOORS NG on Jazz.net.
Q. How does Rational DOORS Next Generation compare to Rational Requirements Composer?
A. DOORS Next Generation is based on Rational Requirements Composer but extended to meet the requirements management needs of product & systems development organizations developing complex and/or embedded systems. In the first releases of DOORS NG, the web client is identical to Requirements Composer, but DOORS NG also features a rich client which is designed for usability of editing large requirements specifications. The strategy for the two products is that while Requirements Composer will be focused on the needs of business analysis and IT application development teams, DOORS NG will be focused on the needs of systems engineers and product & systems development teams.
I’d like to wrap up this post by thanking all of you who attended the webcast, participated in the polls, asked some great questions and completed the survey feedback. If you missed it, you can catch a replay or download the slides. I’d welcome any additional comments or questions here.
The importance of communication and collaboration in developing and managing good requirements were discussed in our earlier post on How to enable effective requirements communication and collaboration
. In this guest blog post, Melissa Robinson - a Senior Technical Specialist at IBM writes about how Rational DOORS addresses this aspects with Discussions. Melissa started her career at Telelogic enabling Product Management with technical support around requirements management. Melissa spent 3 years supporting clients getting started with Requirements management at Telelogic. After IBM acquired Telelogic in 2008, Melissa transitioned roles to support clients with Enteprise Architecture initiatives. She received the Carnegie Mellon certification in Enterprise Architecture in 2008 and is TOGAF certified. Melissa now supports clients getting started with evaluating and implementing both requirements management and enterprise architecture solutions.
Note: Please click on the screenshots for a better view
Why did we make this decision? Who made this decision? Who approved this requirement?
These are some of the questions we can help answer with effective collaboration messaging with DOORS. Collaboration messaging is now enabled in DOORS and DOORS Web Access (DWA) with the addition of DOORS Discussions. Discussions allow users to contribute and add comments to requirement objects or requirement modules, users can even add comments to base-lined requirements. Discussions offer a method of having a conversation on requirements. DOORS discussions really break the communication barrier by allowing users to easily make comments or start a discussion on any requirement, including read-only requirements. Discussions can be created in DOORS or DWA and viewed in both DOORS and DWA. Both DWA Editor and DWA Reviewer roles can contribute to Discussions. Discussions capture comments so that you can later review ancillary information about your requirements. Discussions allow everyone to contribute comments and provide a full understanding of requirements.
Here is a simple scenario for using DOORS Discussions. A DWA Reviewer user creates a Discussion on a requirement. A DOORS user then reviews this comment and contributes a comment on the requirement. The DWA user reviews the latest comment and closes the Discussion.
A DOORS user, Susan, reviews the current Discussion created by a DWA Reader user, Kavita. Susan can open the requirements module with a pre-created Discussion view to review the Discussions. Below Susan reviews the Discussion on Requirement AMR-STK-66.
Susan can contribute a comment to the open Discussion.
Kavita reviews the new Discussion comment in DWA. Notice that Kavita is a Reviewer in DWA. As a Reviewer, she can create and add comments to Discussions. Kavita can also close Discussions that she started. Later, Kavita can contribute another comment to the open Discussion.
As the person who first opened the Discussion, Kavita can close this Discussion.Later, in DOORS, Susan can review the latest status of the Discussion using the Discussion Thread view. As a Database Manager role, Susan can choose to re-open the closed Discussion at any time.
Discussions open up the communication thread between several different types of DOORS users. Discussions allow requirements reviewers to exchange views and comments about the content of a requirements module or the content of a requirement object in a module.
We believe the post gave you a sneak preview of how DOORS Discussions help in effectively collaborating and communicating between various stakeholders during requirements management. Feel free to contact melissarobinson[at]us.ibm.com if you have any queries about the topic. Melissa will be discussing the topic in detail in an upcoming webcast on October 5, 2012. Don't miss the opportunity to watch the action live.
Register now @ http://bit.ly/DOORS_Discussions
In this post Jim Hays
writes about the various options available in testing how the requirements are met in IBM Rational DOORS.
Jim works as a Senior Systems Engineer at IBM. Jim started his career in 1982 working for software providers. Jim’s career history is an interesting one; he hasn’t worked for many software companies over the course of his career. He worked for Applied Data Research (7 years) that eventually got bought by Computer Associates. He then moved to Goal Systems, that got bought by Legent (6 years). Legent, then got bought by Computer Associates. He then spent almost 10 years at Sterling Commerce that just got bought by IBM. After Sterling Commerce he joined Telelogic where he got into the ALM market that eventually got purchased by IBM Rational (7 years).
I’ve been involved with DOORS for over 7 years, and absolutely love the tool. My job at IBM is to technically support our sales team, and our customers, not only for DOORS but many other solutions we offer. I have had a lot of experience working with our DOORS customers understanding how they use DOORS, and even though DOORS is a requirements management solution there are other types of information being put into DOORS other than just requirements. An example of that is the fact that customers will put in test data into a DOORS module, and enable easy linking between the requirements and their related validation/verification results.
Note: Please click on the screenshots for a better view
Provided below is an example showing that. In this DOORS View we see traceability between 4 modules:
User Requirements>Functional Requirements>Functional Test Plan>Functional Test Cases
DOORS has had in it for years a capability called the Test Tracking Toolkit. This enables one to capture in a DOORS module test results by duplicating attributes based upon creating a new test run to store test run results for each run uniquely. This over time will create a lot of attributes in order to capture and store test run results per run. Both of these described usages of capturing tests and test results enable quite easy linking between the DOORS requirements and their related tests and test results. Below are the options available utilizing the Test Tracking toolkit.
(Read in clockwise from top left)
So what are the positives and negatives of both of these usages of DOORS modules to capture test, validation, and/or verification information. The positive is the ability to store and easily link requirements to testing results using standard DOORS linking. If requirements change that are linked to test-based modules, then standard DOORS “suspect links” would notify the folks maintaining the test-based DOORS modules of that requirement change to see if they need to update their test plan and or have to retest the test case. The other question is who is maintaining/updating the DOORS test-based modules? Are the actual testers going into DOORS to update the test results? Are the testers using a spreadsheet to capture test results and giving that to a DOORS user to update in DOORS? It is my opinion that either one of these scenarios discussed are fine for projects that only do manual testing, and don’t have a lot of testing (i.e. test runs) to perform. The other issue is that the actual testing can be occurring on different environments. For example if one built an application that is web-based and will run on different operating systems, then one would need to test all of those types of configurations . If one is building an embedded software device or a software application, then one might want to not just do manual
testing, but instead automate the execution and capturing results via automated
In my opinion I think a solution like DOORS for requirements management is great for that; whereas, I believe the folks that are in charge of Quality and/or performing the task of testing should have a solution that is suited for the role they play in a project-Test Management. So the final option for testing I will discuss is how DOORS (managing requirements) can integrate to IBM’s Test Management solution called Rational Quality Manager (RQM). RQM can provide a nice environment for the support of both manual and automated testing.
Provided below are an example “dashboard” that users can configure based upon what they would like to see and an example of a RQM Test Plan.
Provided below is an example of how one used a DOORS View that would be a view of requirements from DOORS that are known by this particular RQM project. Requirements driven testing enable requirements from DOORS to be used to automatically generate Test Cases and build specific links between the DOORS requirements to specific test cases.Screenshot provided in the right show the results of that link creation automation by showing traceability between test cases to DOORS requirements, and also could show development software assets.
The integration between DOORS and RQM is utilizing the OSLC (Open Services for Lifecycle Collaboration). Below is showing a “rich hover” ability to see details about linked items without actually having to navigate the link. One can also see the results of the test execution (pass or fail)
As the testers are doing their work then the requirements from DOORS can map data from RQM into DOORS-based attributes. Below is an example showing the traceability between DOORS requirements and the testing side of things in DOORS. I can see that the latest test case run passed.Provided below are screenshots showing coverage analysis relating the DOORS requirements to the Test Plan and associated test case.
Finally, provided below screenshot shows the test case execution results that were performed via RQM. These are mapped to DOORS attributes via the bi-directional integration and regular DOORS sorting and filtering can be used. For example if I wanted to see what Test Cases failed and or passed.
Hope the blog post was useful. Feel free to contact Jim @ haysji[at]us.ibm.com if you have any queries regarding the options for testing in DOORS.
Also, Jim will be hosting a webinar on the same topic in which he will go in depth the ideas presented in this post about the options related to testing in conjunction to using DOORS. Register for the session here - http://bit.ly/DOORS-Testing_Options
Date: September 7, 2012 (Friday)
Time: 1PM EDT
As we mentioned in an earlier blog post
, DOORS 9.4 and DOORS Web Access (DWA) 1.5 were released during Innovate 2012.This blog post provides insight into what’s changed in this release of DOORS and some of the significant new features. I have also provided a few resources where you can learn more about this release.
DOORS –RQM Integration based on OSLC
The most significant changes in DOORS 9.4 are the improvements to OSLC based integrations. A new integration based on OSLC has been provided for Rational Quality Manager
(RQM). Let's see how it is different from the existing (RQMI) integration based on a point-to-point solution. Provided below is a simplified representation of how RQMI works for the DOORS-RQM integration and contrasts it with the new OSLC based integration.
As you can clearly see, the integration has been made so simple in terms of software and storage, yet more powerful. The new integration provides a stable architecture for future enhancements and provides an automated migration. If we consider the installation and configuration aspects, the new integration no longer requires the server and java client components.
What does this mean to a typical DOORS user?
- This enables real-time lifecycle traceability to RQM test cases. This can be achieved through either the hover over menu from DOORS that display RQM artifacts or directly from RQMWhat does this mean to a typical RQM user?
- The real-time integration enables the RQM user to review and edit the automatically created draft test cases (with the new requirement reconciliation wizard) based on new requirements, and trace them back to DOORS. Full test coverage when requirements are changing is enabled with features like
- Automatic display of requirements not covered by test cases in current test plan
- Provision for linking existing test cases to new requirements
- Display of modified and removed requirements
- Enhanced suspect-ability analysis
Another important improvement in this release is the enhanced traceability to meet regulatory requirements. This enables
- Linking of one or more requirements to each test step of a manual test script
- Managing the association of requirements to related test cases
- Display of links during test execution and in test case results
Apart from this, integration to Design Manager RSA and Rhapsody beta
based on OSLC is also available in DOORS 9.4. However Design Manager is still in beta and this integration will be available only during later part of this year. For more details, visit jazz.net
. Also the data exchange mechanism has been upgraded to the latest version of OMG (Object Management Group) ReqIF (Requirements Interchange Format) from RIF. This helps in improved communication of requirements between organizations in a supply chain. Support for data exchange and linked data between DOORS 9.x and DOORS Next Generation is also included. Reporting across DOORS 9.x and DOORS Next Generation is also included.
There are going to be some changes in licensing when we consider using DOORS with Rational Publishing Engine (RPE). We have removed the requirement for a RPE license while using RPE custom templates from directly within DOORS. But you still need a license for creating new custom templates; however it is not required to drive the reports. Usability Enhancements
We will briefly look at the usability improvements that have gone into DOORS 9.4. Many of these usability improvements reduce the need of writing custom DXL scripts. In DOORS 9.4, we have provided a stronger support to define and manage how more than one user can work on a module simultaneously. It is controlled with a widget allowing you to set a sharing level for editing as shown below.
The Views now support color coding and the user is allowed to control the background color of attributes. The views have been also extended to 128 columns.
Another small, yet significant usability improvement is the possibility to remove multiple views in a single selection. And finally DOORS now supports rich text exporting to Microsoft Excel.
What do you think about the improvements? If you have questions or comments please leave them here. If you need more information about the product, trials or resources, visit IBM Rational Requirements Management Web Page.
We had a series of announcements
earlier this month during Innovate 2012. The major announcements pertaining to Requirements Management space were RRC 4.0, DOORS 9.4 and DOORS Next Generation Beta. This blog post aims to dive a little deeper into these and provide a few helpful links...so read on!
Introducing Rational Requirements Composer 4.0
Collaborative Lifecycle Management (CLM) 2012 was announced on June 12 at the jazz.net website and Rational Requirements Composer (RRC) 4.0 continues to be one of the major pillars. CLM 2012 aims to provide the best integration experience available today in the industry between requirements, source control and quality management. For a detailed post on CLM 12, see Robin Garside's post in jazz.net
In order to better the existing requirements management solution, RRC 4.0 comes up with a whole new set of improvements and features. The new and improved capability in this release will help project teams realize project change impact with downstream visibility using graphical and suspect traceability across requirements, test, and development items. Information access can now be controlled at a granular level - giving you the peace of mind knowing the exact requirements information that need to be modified. Project template upload and download as well as Requirements Interchange Format (ReqIF) are now available to give administrators and team leads easier control for multiple project environments. Additionally, project teams have greater cross project visibility through project dashboards. Some other significant highlights of RRC 4.0 are:
Enhanced enterprise deployment and scalability to support high availability and availability via clustering
- Extended and refined data access control and automatic requirements identification
- More solutions for analyzing traceability through graphical explorers and suspect link change identification
- Extended CLM lifecycle integration for Rational Design Manager (Beta) to trace and report requirements and models/elements
Watch out for another blog post detailing these improvements in RRC 4.0 soon…
Introducing Rational DOORS 9.4
Systems space was equally active this month with lots of announcements from IBM Rational. With the help Open Services for Lifecycle Collaboration (OSLC), continued efforts have been put in unifying lifecycle disciplines across systems and software engineering. DOORS 9.4 and DOORS Web Access 1.5 are the latest offerings in Requirements Management for Systems space. DOORS 9.4 boasts of significant enhancements in server side and new integrations with Rational Quality Manager, Rational Software Architect Design Manager beta and DOORS Next Generation beta using OSLC.
Significant usability enhancements have been made for both rich and web clients. Customer templates designed using Rational Document Studio are now supported by DOORS 9.4. An additional bonanza of producing documentation from DOORS without the need for an additional license of Rational Publishing Engine is now possible. For a detailed account on the improvements in DOORS 9.4; visit the announcement letter here
Download IBM Rational DOORS 9.4 here
. Learn more about Rational DOORS here
Stay tuned for a detailed post on What’s new in DOORS 9.4…..
DOORS Next Generation Beta
IBM DOORS Next Generation aims to be the next generation requirements management solution for complex software and systems engineering environments. Today, we are releasing latest version, Beta 3 of DOORS Next Generation and is available for download from jazz.net
. DOORS Next Generation is built on the learnings of DOORS and extends the technologies of Rational Requirements Composer and DOORS 9. If you are considering how different DOORS Next Generation is from DOORS
, read the article written by Richard Watson, Senior Product Manager for RM tools at IBM comparing the two products in jazz.net.
With this beta version, data import/export between DOORS Next Generation and DOORS 9.x projects are possible. Also bi-directional linking between the two products is supported. Development of DOORS Next Generation is kept transparent following the jazz vision and all developments can be tracked at Rational DOORS Next Generation
section in jazz.net.
Our intended direction for developing DOORS family is to allow a smooth transition between DOORS and DOORS Next Generation. For each DOORS license entitlement that has active Subscription and Support, a customer will be able to use either DOORS V9 or next-generation capabilities. A commercial version of DOORS Next Generation is expected in the last quarter of this year.
Any queries? Feel free to contact us!!
We have 16 sessions lined up in this track with focusing on software delivery that revolve around eliciting, defining, elaborating, understanding, organizing, reviewing, communicating and tracking business, user, and software requirements. We have multiple customer sessions; however I am sure you will find the below sessions interesting
- Case Study: Moving from Organized Chaos to Standard Process and Tooling – Disney’s Experience in deploying IBM Rational Tools
- DHL Aligning Business and IT with IBM Rational Requirements Composer
- Iterative Requirements Analysis: Implementing Lean and Agile Principles for Software Requirements Analysis
Like previous editions of Innovate, this year also we have keynotes where IBM shares its road map, strategies and vision for requirements definition and management tools. Also there will be immense number of opportunities to meet senior product management professionals and developers of IBM Rational's Requirements Management tools in sessions like 'Ask the Experts: IBM Rational Requirements Composer and IBM Rational RequisitePro', What's New with IBM® Rational® Requirements Composer? and other presentations.
Some of the other notable presentations focus on trending topics and best practices in the requirements management domain like conceptual frameworks for visual definition in requirements life cycle, Requirements Engineering Maturity Model (REMM) and many more. There are multiple workshops about defining and managing requirements with IBM Rational tools, IBM Collaborative Lifecycle Management, best practices in using Requirements Composer and Jazz primers. Don't forget to try out Open Labs and solutions peds at Innovate!
And finally we have a competition (Who Is the Best IBM Rational Composer User? ) in which Rational Requirements Composer experts put their skills to the test to compete in a variety of different tool challenges and prove who is the best requirements tool champion.In this special event, participants have a chance to compete with IBM experts and tool developers to prove their expertise by solving common and difficult requirements management problems!
Have you registered for Innovate 2012? Hurry Up!!! just 9 days left...http://www.ibm.com/innovate/
Don't miss this opportunity to meet 4000+ professionals, attend your preferred sessions from 27 tracks and 400+ presentations and try out next generation products.See you at Innovate!
At Innovate 2012 in Orlando, June 3-7 there
will be two requirements management (RM) tracks – one focused on RM for IT
application development, and product-wise primarily on RequisitePro and
Rational Requirements Composer; and another focused on RM for systems
engineering (SE), and product-wise on DOORS. This blog post is focused on the
RM for SE track but look out for another on the IT focused track.
I think you’ll find that the
RM for SE track has some really strong content this year. Out of 16 sessions,
10 will feature customer speakers, including:
- How IBM Rational DOORS Helps Jet Propulsion
Laboratory Get to Mars and Beyond: Best Practices in Metrics,
Verification, and Traceability
- Using IBM Rational DOORS to Support Systems
Engineering and Release Management across Multiple Programs at Trane, a
heating, ventilation & air conditioning systems manufacturer
- A CareFusion Case Study of Integrating IBM
Rational DOORS and HP Quality Center for Use in an FDA Environment
- Integrating IBM Rational DOORS with IBM Rational
Team Concert: Lessons Learned at
You’ll also be able to meet
product management and senior development staff and ask them questions in our ‘Ask
The Experts (for DOORS version 7.x, 8.x and 9.x users)’, and you’ll hear about
IBM’s strategy and roadmap in ‘What's Now and Next in Requirements Management
for Systems Engineering’, including the latest release and plans for the DOORS
If you’ve been following our
RM developments recently you’ll be aware of the DOORS Next Generation project
on Jazz.net and you’ll hear about that during the Now and Next session, and
if you want to dive deeper into what’s planned be sure to go to the session
‘Deep Dive Investigation and Feedback about IBM Rational DOORS Next-Generation
Beta’ and visit the DOORS Next Generation demo pedestal in the Innovation Lab
area of the Solution Center.
And if you’ve ever attended
before, you’ll know that a popular feature is the DOORS DXL Script Exchange
competition, where you can demonstrate your prowess in DXL and win a small
prize. For more details about this year’s competition (with a twist!) please
Scripts are due on or before May 25th.
On top of all this fantastic
content (and this is just for one track – there are over 400 sessions across
the whole conference!), Innovate is a great opportunity to network with other
systems engineers and software developers, share war stories, tips and tricks
and maybe a drink or two.
To find out more about
Innovate 2012 and to register go to ibm.com/innovate.
We hope to see you there!