While mowing the lawn this weekend, I couldn’t help thinking how much I love the new lawnmower we recently purchased. While it would have taken a couple of hours to do the front and back of the house with our old one,  I can now do it in a fraction of the time with a lot less effort expended. It cuts so much better and the grass collector is great – no more raking to do. Added to that the ‘easi-reel’ feature for storing the power cord, really is ‘easi’ – no more tangled cable (and believe me I can tangle anything!). All in all, I like that it does more for me, leaving me more time to enjoy the garden rather than on maintaining it.

I always get the impression that there is the same desire from business analysts and systems engineers when it comes to producing documentation or metrics from requirements data. Even if an organization has moved to mostly working online within a dedicated requirements management tool, there is usually the need to produce nicely formatted reports for management or customer review. And when this is the case, you don’t want to be spending lots of time and effort to extract, assemble and format the data that you’ve already captured and structured in the requirements management tool.

Fortunately this is an area where vendors and users have come up with ways to automate document generation and metrics reporting, to make it easier and quicker, leaving you more time to concentrate on getting the product or application delivered on time and to customer needs (or sunbath in the garden!).

At the forthcoming Innovate 2011 conference (in Orlando, Florida, June 5 -9), several of the Requirements Definition & Management track sessions will focus on document generation, reporting and metrics:

  • Michael Sutherland of General Dynamics Land Systems will talk about ‘Using the IBM Rational Publishing Engine to Streamline the Document Generation Process’. Michael will describe how Rational Publishing Engine has helped General Dynamics reduce document generation time by 70 percent;
  • Joseph Dress from Constellation Software Engineering will discuss metrics that can be obtained from requirements data, how he automated collection of those metrics from IBM Rational DOORS and demonstrate the metrics achieved on the Goddard-built Lunar Reconnaissance Orbiter (LRO) project; and
  • Bill Betz from IBM will show how to produce out-of-the-box and customized metrics reports and documents from IBM Rational Requirements Composer.

To see details of all the Requirements Definition & Management track sessions and the conference as a whole, and to register (use code RDM11 to get $100 off your registration fee) please visit the Innovate 2011 conference website.

Right, I’m off to enjoy lunch on my newly mowed lawn 🙂

Andy Gurd,  Go-to-Market Manager, IBM Rational.


Yes it’s been a while since you’ve seen anything here, but after a bit of shuffling around and maybe the odd prod or two, the RDM blog is back. Of course having left this for a while there’s ton of great stuff that’s happened that I could talk about. However let’s look forward to something that’s coming up very shortly.  I’m talking about IBM’s Innovate 2011 conference in Orlando, Florida between June 5 and 9. I’m a co-chair of the Requirements Definition & Managment track at this year’s event and I’d like to start by telling you about the top 5 things I think you might be interested in:

  1. Hearing about IBM’s strategy and plans for the requirements definition & management portfolio, seeing demos of latest releases and previews of what’s planned
  2. Learning from experiences of your peers on their implementations of Rational DOORS, Rational Requisite Pro and Rational Requirements Composer
  3. Finding out how IBM business partners can extend your RDM environment with capabilities including product line engineering, dynamic modelling, electronics design and more
  4. Understanding how to better integrate requirements management tools with your complete development process and achieve better results in downstream development effort
  5. Seeing how requirements management is being applied to business challenges in multiple industry sectors

Of course I’ve only briefly touched on some elements of the RDM track. There’s so much more on offer in that track, and over 400 breakout sessions across the whole conference, not counting keynote sessions, the solution center and an appearance by Jeopardy champion, Watson.  To find out more and to register, please visit the Innovate 2011 web site

Look out for further posts here highlighting some of the RDM track sessions and also a preview of what you can expect to hear about developments in the Rational RDM portfolio.

Signing off for now,

Andy Gurd (Go-to-Market Manager, IBM Rational).

Posted by: RationalRDM | November 18, 2009

Customer Involvement in Rational Requirements Composer 2.0

As we get ready to release Rational Requirements Composer 2.0 next week, I thought it might be interesting for readers to understand the various client groups that have strong influence in developing the capabilities offered by  Rational Requirements Composer.

One of the groups to see the earliest versions of products at IBM Rational is our design partners. Each design partner group represents a different segment of the Rational business. For example, the requirements design partners are a different group than the architecture management design partners.    These small groups of customers begin  working with us at the concept stage of a product. When IBM Rational product managers have an idea for a new product, they talk first to our design partners and discuss their ideas with them. There is no code written at this point. The product manager simply conveys ideas through conversation or maybe a slide presentation. Product managers may explain how this concept came to be – usually as a result of customer requests or complaints or the availability of a  new technology developed by IBM research that allows us to now incorporate best practices in a tool.

After we’ve incorporated their feedback on the product concept, we start thinking about capabilities. Here, our design partners help us prioritize capabilities, platforms, and consumability issues such as performance, migration, and usability. Once we have working code from an early iteration, we give them demonstrations, and again they give us feedback which we do our best to incorporate. Often, we realize that something that seemed obvious to the development team isn’t quite so obvious to users of the product, so we go back to the drawing board to work on improvements.

Another program that’s been very useful in helping us deliver products is the Rational beta program. We have two different types of beta programs: open and managed. In the open beta program, anyone can download the code from jazz.net and give us feedback via both requirements and defects. In the“managed beta”,  we are actively managing the beta program and the engagement with customers. In this program, certain customers agree to install the software, play with it, and give us feedback. For these managed beta customers, there’s a weekly meeting in which the development team demonstrates various capabilities and responds to any questions the customers may have. Any defects opened by these customers have high priority, because we want them to be able to continue testing the software, with as few issues as possible. In addition, managed beta clients complete a survey with their recommendation to ship, or not to ship, the product.  These survey results are very important to IBM Executives.

Additionally our user experience team seeks as much customer involvement as they can get.  The Users First Lounge at many Rational conferences is a great place for the user experience team to gather feedback on existing products and new product development, both working code and features expressed only in Requirements Composer User Interface storyboards.  The user experience team also seeks out design partners and beta customers for one-on-one web conferences to elicit customer needs and validate designs.

These programs provide the entire Rational team with invaluable feedback from a large group of customers with a variety of needs. This ensures we don’t release a product that has totally missed the mark in terms of business value and software quality. As we release Rational Requirements Composer 2.0, we are very thankful to our design partners and beta program participants for all feedback to help us create  an innovative, user-friendly, product that provides value to organizations in defining and managing their requirements.

For more information on these programs, please visit Early Programs. If you’d like to participate please email ratldpp@us.ibm.com for the Design Partner Program or ratlbeta@us.ibm.com for the Beta Program.

The Business Analysis Benchmark Study put out by IAG Consulting has become a great source of information for studying the maturity level of how organizations define and manage their requirements.  Just recently the 2009 edition of the study was finalized and published, and we wanted to know a bit more information on the history of the study and the key findings the folks at IAG found to be most interesting and/or surprising. 

Below are a few questions we asked of Keith Ellis, Vice President of Marketing and Strategic Alliances at IAG Consulting:

How many years has IAG Consulting been putting out this benchmark study?  What initially triggered the idea of doing a study of this magnitude?
We’re in our second year in publishing the study.  In 2008, we focused on the impact of requirements quality on project outcome in larger strategic projects.  In 2009 we expanded the scope to look at the impact of requirements maturity across the spectrum of projects in IT and the impact of this on overall corporate competitiveness.  We also made the 2009 study more ‘solution focused’ – subtitling it “the Path to Success”, and dedicated more of this year’s effort to uncovering exactly how performance change can be made in requirements definition and management maturity.

The idea came from seeing an alignment between:

  • our company’s long-term passion in researching best practices,
  • the skills of our executive team in creating a larger-scale research studies, and,
  • a lack information for CIOs on both the impact of requirements definition and management and effective actions people can take to make improvement. 

People intuitively understand that requirements definition and management quality is important – but people tend not to take effective action as a result of this understanding.  It’s like weight loss;  people know the benefits of a healthy lifestyle, but we face an unprecedented wave of increasing obesity as a result of ineffective action.  Similarly, 70% of project failure can be attributed to poor requirements definition and management, yet despite people knowing requirements are important, we’re seeing increasing project failure rates in the recent past (Standish, Chaos Report) rather than decreasing rates.  We wanted to give people the tools they need to diagnose where their organization is experiencing weakness, and be able to map out a strategy that more predictably brings success.

What are some of the most interesting or surprising results your team found in this year’s study?

The magnitude of the performance difference between low maturity companies and high maturity companies continues to blow me away – as does the strength of the correlation between requirements maturity level and project success rates (the higher the maturity, the higher the success rate).  It’s staggering – but we also knew this to be the case from our research last year.

I think the big interesting ones this year were some of the myths we dispelled:  for example finding that lower skilled people in a high maturity organization OUTPERFORM far better people in a low requirements maturity organization.  This really showcases that requirements maturity is not about a deliverable, and, you can’t simply hire great analysts and expect the problem of poor quality requirements to simply go away.  Requirements maturity is much more complex, and improving maturity is about a combination of people, process and technology coming together the right way, with the right organization support to achieve success.  This same finding comes out loud and clear when we compared agile, iterative, waterfall and visualization/prototyping methods to each other and showed that there is an immaterial performance difference between methods for any given level of requirements maturity.  WOW.  Again, the findings scream:  you need to bring together people, process and technology surrounding requirements definition and management maturity if you are to successfully enact performance improvement no matter what your SDLC or development framework. 

There were also some interesting findings when we compared the stock market performance of high maturity firms:  very large, publically traded companies, with institutionalized and consistent practices in requirements definition and management, vastly outperformed their peers.  The ROA of level 4 requirements definition and management firms was 10% higher than the ROA of their peers.  I think we’ll see a growing body of evidence over the next few years that more definitively shows that the maturity of internal practices and disciplines like requirements definition and management can lead to significant and sustainable competitive advantage.  Simply give me 3X the sample size, a bit more historical data, and a market that’s not busy going through the biggest correction since the great depression, and we’d have some better insight in this area.

On the implementation side we demonstrated the impact of IAG’s Requirements Maturity Model as a roadmap for success.  Again, not a surprise given last year’s study and all our client engagements using the model, but it’s important to get out there how to make improvement possible in this complex area and the report documents in detail key steps to achieve success.  Check it out at http://www.iag.biz/benchmark

So, how are you seeing the level of maturity in requirements definition and management practices evolving over the past few years?

I think if we went back 5 to 10 years, you would see a huge difference.  People have come a long way in their thinking.  I’d bet, 10 years ago most companies would be level 0 or 1.  The problem is, the massive breakthrough in performance change only really happens at level 3 or 3.5 and the vast majority of companies are in the 2ish range.  You’ve got a situation where today there is far more intense focus on the area (86% of companies trying to make improvement here), but people are not swinging the bar far enough to really catalyze significant benefit.  People have a lot of blood, sweat and tears tied up in what they’ve accomplished so far.  What I hope is, rather than seeing all this effort  yielding less benefit than they’d like and giving up, that people realize they’ve already pushed through some of the hardest barriers of organizational change and they may be closer than they think to realizing measurable performance gains.  If the current level of focus on improvement is maintained, the next five to seven years could see substantial reductions in project failure rates in the market.

Where do you think companies should be investing their efforts to address requirement needs in the long-term?
I think the answer changes depending on the organization.  You really need to assess the overall maturity of the organization across 6 competency areas (process, techniques, staff, deliverables, organization and technology) and identify where organizations are strong or weak.  I’ve got clients that have great deliverables and technique (probably level 4 or 5), but weaknesses in staff, process and organization kill their effectiveness.  I’ve got others that have pretty a strong staff, and have deliverables structure that’s killing them.  I have others that are extremely strong in the later stages of the requirements definition and management lifecycle, but are very weak at the upfront requirements planning and elicitation layers.  The point being, it’s essential to know the current strengths upon which you can build, and the weaknesses that require the greatest level of immediate focus to create an effective action plan.

I think another issue faced by companies is they really need to showcase the performance impact of great requirements maturity.  You can never ignore that people need to experience a new process before they can internalize how it’s different.  When people experience well facilitated requirements discovery sessions, see how their team is coming together, and get a few projects delivered on-time and on budget, then all of a sudden other business stakeholders will want to get on board.  You’ll go from no one wanting an analyst on their project, to the corporate leadership clamoring for resources and wanting to get the best-of-the-best analyst team allocated to their project.

How does IAG plan to make use of the findings in the benchmark study in your own consulting efforts?
We’ve been using the Requirements Maturity Model for a number of years now when we’ve been putting together Requirements Centers of Excellence for Fortune 500 class companies.  We have about five of these on-going at any given point in time although different companies call them different things:  RCoE, Community of Practice, Requirements Management Office, Requirements Standards Office, etc…  In these, the requirements maturity model helps us assemble the blueprint for organization change.  With this research behind us, we’ve got high confidence that the path recommended not only yields better results, it is optimized in the path to achieve these results.

We’re also seeing more companies come to us looking to benchmark their organization’s maturity level.  Many of these have taken great strides forward already, and want to get a more objective assessment that baselines the maturity of their organization, compares various parts of the organization against each other, and finds gaps.  Seeing these kinds of engagements tells me there are a lot of organizations out there whose leadership are absolutely convinced of the value of great requirements definition and management maturity – and they’re taking it to the next level.  Not only are these organizations already mature – they’re gunning to radically outperform everyone.  What’s exciting to watch is just how much performance improvement they’re experiencing and the corporate commitment they’re getting as a result.

Posted by: RationalRDM | September 21, 2009

Rational Requirements Composer Beta 2.0 is Now Live!

IBM Rational announces today that  the Beta 2 download of IBM Rational Requirements Composer is now available on jazz.net. In honor of this, I wanted to summarize some of the new capabilities included. With this version, project teams can define requirements more effectively and manage them efficiently.  I’ve seen many of the new features demo’ed in this beta  and think that both new and existing customers will be thrilled! Rational has worked closely with customers through the managed beta and design partner programs while developing Requirements Composer and it is really evident in the features and ease of use. Some of the new features include:

1) Review and approval capability. This is one of my favorites and will help users improve the effectivenss of capturing, elaboration, and defining requirements. They’ll be able to conduct formal and informal review processes, comment within the scope of the reviews, and send automatic notifications to review participants.

2) Web client for reviewer and occasional users will enable organizations to achieve consensus with stakeholders faster by shortening the review and approval cycles. In addition to the web-based review and approval workflow, there are customizable user dashboards and viewlets that provide information about project membership, recent activity, collaboration, and reviews.

3) Reports and Document Generation is one of the features most often requested from our customers.  This capability will automate tasks for generating and publishing hand-offs, contracts, reports, and traditional reviews. Users will be able to generate use case survey documents and requirements specifications using out-of-the-box reporting using  Rational Publishing Engine. They’ll also be able to generate reports based on requirements, use-case diagrams, and use case artifacts. Reports can be formatted for Microsoft Word, HTML, or PDF.

4) With Artifact Collections and Project Snapshots, users can better organize requirements and related artifacts, understand project scope, and prioritize tasks. They can create and use collections to facilitate review and approval and to specify scope. They can also create snapshots that capture, point to, and use specific versions of sets of artifacts.

5) Shared Dashboard Filters enable better collaboration among stakeholders through the ability to view and share critical project information. They are able to save dashboard filters to share views of project artifacts with other team members.

6) Attributes view customization allows users to examine attribute values across multiple artifacts and requirements. They can also reorder columns.

7) And finally, there are several enhancements that expand the variety of techniques to elicit, capture and elaborate requirements. These include:

  • Support for tables in documents
  • Commenting enhancements
  • Performance improvements
  • Migration of  data from v1.x to v2.0
  • The ability to Upload v1.0 artifacts and archives directly to v2.0
  • Improvements to business process diagram rendering and editing with layout and alignment functions
  • Improved wiring and copy/paste capabilities
  • Derby as the default database
  • Having a separate DB2 index database is no longer necessary   


You can download the Rational Requirements Composer 2.0 beta and provide feedback on jazz.net here.


Posted by: RationalRDM | September 8, 2009

Validating Requirements

I was at the Agile Conference 2009  recently and heard an interesting talk about validating requirements. The speaker talked a lot about differences between validating requirements in waterfall and agile. She found that validation of requirements with her agile partners was done early and often unlike waterfall and primarily done through conversations with customers. While conversations can be very quick, relying solely on conversations can be problematic as you can easily misinterpret what is said or forget an important point. I’ve listed below several different practices for validating requirements and some pros and cons of each. Ultimately, I think it’s important to use as many of these practices as possible. They will help capture those high quality requirements that ensure delivery of the right product to customers.

 1) Conduct conversations/face to face meetings – conversations can be great for quickly uncovering incomplete and inaccurate requirements. However, there are several things that you have to do to make sure conversations are effective:

Participants :  you have to make sure the right people are taking part in the conversation. You need to have a representative from all your stakeholder groups: testers, developers, architects, customers.  Conversations can be very challenging for geographically distributed teams.

Capturing feedback: Someone needs to very meticulously capture the main points of the conversation: capture defects, missing requirements, etc… This is probably the greatest potential weakness in conducting conversations.

Communicating feedback to all stakeholders: It’s unlikely everyone will be able to participate in the conversations but they still need to know the results and to be able to provide their own feedback.

Capturing post-conversation feedback – What happens after the initial conversation? You need a way to capture feedback after the initial meeting has occurred. Sometimes my best ideas occur when I’m out walking the dog and I’m thinking about what happened during a meeting.

2) Provide written feedback from inspections of requirement documents – I admit it. I like things written down. E-mail or logs from instant messaging, for example. I can’t tell you how often I go back to chat histories or my email to review the details of what someone said. So much is often lost through conversations even with someone taking notes. Things can be misinterpreted. Having people review a document and then respond to it in written format avoids that. It may not be as quick as a meeting or conversation. And you run the risk of people not participating, but when they do, it can be very effective.

3) Include customers – I’m often surprised at how few people really talk with end-users to validate requirements. No matter how well you think your product manager or architect or sales people know the customers, they always have a slightly different perspective. Just watch a requirements validation meeting when customers are present. You’ll be amazed at the difference. Often the organization doesn’t want to include customers for fear they will divulge confidential information. But with legal agreements it’s not a problem. IBM Rational has both extensive beta programs and design partner programs. The feedback we’ve gotten through these programs greatly enhances the solutions we produce. I can’t imagine not having our customers involved from the beginning. We’d certainly have a lot of false starts.

5) Validate all types of  requirement artifacts such as documents, use cases, sketches, storyboards, business process diagrams – I think we also have to have different ways of validating requirements depending on the artifact type. In Rational Requirements Composer, Rational’s collaborative, jazz-based, requirements definition and management solution, different user types have their choice of defining requirement artifacts through rich text, user stories, use cases, business progress diagrams, and sketches and storyboards. You would most likely use different techniques to validate rich text documents vs. use case diagrams, for example. The really good thing about Composer, though, is that with a central repository, a project dashboard, and collaborative platform, both general and very granular feedback can be provided by stakeholders – including external customers if they have been given access.

6) Hold facilitated use case workshops – Use case workshops can be incredibly effective if you have the right participants and people are fully engaged. Many times I’ve seen major requirement errors uncovered in these workshops, often found by a tester who was present and thinking about how they were going to develop test cases.

7) Developing conceptual test cases which are independent of implementation – Testers can start to write conceptual test cases as requirements are defined. Just as a use case workshop, these test cases are very good at identifying ambiguities and uncovering missing requirements as they find mismatches between requirements and test cases.

8) Collect customer acceptance criteria – Acceptance testing should focus on the most important usage scenarios for customers and include non-functional requirements too, such as performance. Having your customers develop acceptance criteria is one of the most important methods of validating requirements. If they are not happy with the product, your time and money is wasted.

These are just some of the practices that are important to employ in validating requirements. Using these will help any development methodology be more effective in practice. IBM Rational has incorporated some of the best practices above into Rational Requirements Composer: project transparency, various methods to capture requirements, web review and validation, linking requirements to work items and test cases.

For another perspective on this topic, read the white paper in the business analysis e-kit: Getting your requirements right: Collaborate with stakeholders to work smarter  

What else have you experienced that works (or doesn’t)?  Please respond by commenting below.

From Andy Gurd, Senior Go-To-Market Manager for IBM Rational Systems Marketing:

 Like a full-flavored, tender fillet steak, a vintage Bordeaux and a ripe Stilton, requirements management (RM) practices are better when matured.

 But how do you know when your RM practices are at the right level of maturity for your organization or industry? How do your organization’s practices compare to those of your competitors?

 At IBM, we’ve been gaining experience of and advising clients on best practices in RM for over 20 years, and we’ve seen lots of different approaches across different industries, organizations, and projects. To help you see where your practices rank with what we, based on that experience, believe to be the best practices, we’ve created an online assessment questionnaire that guides you through a number of questions on your organization’s current RM practices. Your answers are scored and totalled and you are ranked against three levels of RM process maturity. Along with your ranking, you are directed to resources like white papers, webcasts and training courses that provide information you can use to help your organization build on their RM practices.

 You can take the assessment here. And please come back here and give us your feedback on the questions, the resources and your views on what makes requirements management practices mature. Oh, and if you’ve got some good tips on where to get great steak, wine or cheese, please feel free to drop those in too!

Posted by: RationalRDM | July 9, 2009

Planes, Trains and Automobiles and the ‘Iron Triangle’

This week’s blog comes to us from Andy Gurd, Senior Go-To-Market Manager for IBM Rational Systems Marketing.

Over the past 9 months or so I’ve been putting more effort into understanding what the challenges are for engineering/development teams in different industries, what requirements management needs they have, and how improving their requirements related practices helps them tackle the specific challenges of their market sector. What’s interesting is that although the business challenges of application software and product development often boil down to the classic ‘cost-time-quality iron triangle’ (otherwise known – in the reverse order (!) as better, faster, cheaper), the emphasis put on each of these, and the terminology used to talk about them, can be different across industry sectors.

Let’s take quality first. My particular focus is on the industrial sector – the automotive, aerospace & defense (A&D) and electronics industries. Improving quality is the number one reason for and benefit from improving requirements related practices that I’ve heard from anyone I’ve spoken to across these sectors. As I wrote in my previous entry – the payback in requirements practice improvements is often largest in areas like finding defects sooner and introducing fewer defects, therefore reducing testing and rework time and cost. Quality failures are expensive and embarrassing, regardless of what sector they occur in. As a systems design manager from a global telecoms manufacturer says, in a recent podcast interview “downtime for a system at one of our customers would end up with very poor press and they would lose their customers.” But quality failures are not just expensive to the business – in the automotive, A&D, and medical devices sectors they can be life threatening, which means a greater emphasis must be put on practices that improve and ensure quality, like requirements engineering. As an independent consultant in the automotive sector working on projects like collision avoidance systems says, ‘If I was to miss a requirement the impact could be catastrophic’ (Hear more in this interview on requirements engineering in the auto industry).

What about the ‘time’ factor, doesn’t everyone want to reduce ‘time-to-market’? Well let’s look at what this means. If I’m developing a software package or consumer electronics product then yes, I want to get to market at the right time and ahead of my competition, to maximise my revenue opportunities. Therefore I would look for ways to reduce development cycle times, and I’d look for requirements practices to help me improve productivity. But if I’m building the software and/or electronics for a radar system for a new fleet of aircraft carriers, does ‘time-to-market’ really matter? Certainly time is still important, but from the perspective that I need to deliver my components to my customer on the agreed schedule (If I’m 6 months early in my delivery and the ship is still years away from completion, there’s no real benefit to be had. However if I’m late it could cause slippages to the whole project and I’ll likely incur heavy financial penalties.) I’d be interested in requirements practices that can help me better manage project scope and stay in control of schedules if changes are requested.

Lastly, but probably most importantly, we come to ‘cost’. This is where I’d say most industry sectors have the same objectives – they of course want to reduce development costs. I say ‘most’ because again there are exceptions. While no one would want to increase costs, if you have a development budget allocated to you, you often want to make sure you spend all of that budget to ensure you get at least that amount again when the next round of funding occurs. In this case it’s more important to be able to manage project scope and have increased visibility of project status to be able to improve predictability of your spending.

And of course you have to be able to balance the ‘cost-time-quality’ triangle. In talking to various practitioners across industry sectors, I’ve learnt that effective requirements practices can help you maintain that balance, and most importantly reduce or stay in control of costs without sacrificing (and even improving) quality, and reducing time-to-market/staying in control of your schedules.

Find out more about the challenges and benefits of requirements engineering in the following industry sectors:
Telecommunications Network Equipment Providers

This post comes to us from Andy Gurd, Senior Go-To-Market Manager, IBM Rational Systems Marketing

At the recent Rational Software Conference (RSC) in Orlando, requirements engineering seminars in the UK, and in conversations with colleagues and customers, we’ve been having many discussions about the business value and the return on investment (ROI) from improving requirements practices.

In one presentation at RSC, an IBM customer, developing a web application that uses the Electronic Medical Record to provide patient data analytics vital to the treatment and care of medical patients, told how putting in place improved requirements practices and deploying a requirements management tool, they achieved a 69% net reduction in the cost of test preparation, testing, and rework; and that they are now delivering similar functionality in less than 25% of the calendar time it took before the improved practices were deployed.
But it’s not only ‘hard’ benefits like cost savings and productivity improvements we’ve heard mentioned. The team developing the healthcare web app also experienced ‘soft’ benefits like improvements in team morale because they are now able to more accurately deliver what the customer wants – and sooner. Another example of a ‘soft’ benefit came from a large government defense agency. The central administration for the requirements tools and processes at this agency are helping the users to achieve a much more personal goal of ‘more golf time’ by providing tools and processes to help them become more efficient.

One common pattern that seems to emerge from talking to organizations that have focused efforts on improving their requirements practices is that the payback has to be viewed from a complete lifecycle perspective. While we’ve certainly heard customers say that they’ve been able to streamline their requirements capture, review and approval process and reduced the time it takes to sign off a requirements baseline or define the user stories for a sprint, we mostly hear that the larger payback comes from reduced rework time and costs. But that doesn’t mean that it has to take years before you see a return on your investment in improving your requirements practices – in the example we gave above of the healthcare web app, the team achieved those results within six months of deploying new practices and a requirements management tool.

What have been your experiences? How did you make the business case to invest in improving your requirements process? Where have you have seen the benefits? We’d love to hear your comments.

We are just back from the Rational Software Conference (RSC) where we made a number of important product announcements in our requirements product portfolio and introduced our strategy for DOORS and RequisitePro evolving to Jazz. There was a lot of excitement, a little bit of anxiety, and a really great discussion. Our key note audience consisted of traditional Rational customers as well as new customers from the former Telelogic company. In this blog, we hope to answer everyone’s questions and put their minds to rest about the future of IBM’s requirements management solution because
Rational is committed to protecting our customers’ investments in both DOORS and RequisitePro.

Probably one of the most important topics at the conference was Rational’s strategy for requirements management. Rational is committed to protecting our customers’ investments in both RequisitePro and DOORS. Our strategy for our RM products can be summarized as “evolution, not revolution for RequisitePro and DOORS customers”. We know we need to introduce innovations in our tools that can be consumed by our customers in their organization. We know that there is a cost in doing upgrades and migrations, and we need to bring new capabilities that are so valuable that it’s well worth the effort to move forward.

We intend to use the services of the Jazz platform to solve the hard problems customers are asking us to solve and enable them to do requirements management in the context of a solution set that involves other Rational and 3rd-party tools.

We do not anticipate RequisitePro and DOORS converging into a single product. RequisitePro is optimized for iterative IT-focused projects while DOORS is optimized for development of systems which include mechanical, electrical, embedded and complex IT.

In IT delivery environments, the cost of mid-course corrections are much lower and iterative methodologies embrace iterative refinement of the vision, allowing you to embark on a voyage of discovery as your project progresses. As you are defining requirements, the project team and stakeholders are learning more in each iteration about what the project really needs to deliver to be successful. In these scenarios, organizations are prioritizing requirements for each iteration and employing “just enough” requirements management to efficiently analyze impacts, understand what needs to change, make the changes and keep project execution on track. Many teams use RequisitePro in this context. If you are managing requirements using a backlog, Requirements Composer with Rational Team Concert is the basis for an effective solution.

In systems engineering projects that is a far higher need for formality For many projects, failure can cost lives. Cost of mid-project corrections or after-sale defect correction is much higher than for IT projects. Thus it’s far more important to invest as much as practical into getting your requirements right up front and carefully managing them through the lifecycle. The functionality provided by DOORS is particularly good in this context as it is effective at managing the inter-dependancies of large scale requirements specifications.

Moving forward RequisitePro is moving onto the Jazz platform, and we’ll be using Jazz Foundation services to deliver major enhancements like revisions of requirements, better baselining, and automation for review and approval. Look for a preview of RequisitePro’s future on Jazz as early as the end of this year. To give you an idea of the user experience, take look at Rational Requirements Composer, as these products are converging onto a common architecture and shared user experience. We are currently working with our RequisitePro customers to ensure we will deliver the value they need. We, of course, will also extend beyond today’s capabilities, increasingly focusing on optimizations and quality enhancers for the analyst and enabling requirements-driven application lifecycle management (ALM).

You can use Rational Requirements Composer with RequisitePro today, and you will be able to use Requirements Composer with DOORS later this year, to improve the quality of the requirements you are managing across the lifecycle with those offerings. Later this year, we are delivering improved automation for Collaborative ALM scenarios where Requirements Composer is used with Rational Team Concert and Rational Quality Manager for those teams employing highly iterative software development techniques. If you didn’t have the opportunity to see this in action at this year’s conference (RSC), visit us on Jazz.net.

As the systems industry changes in terms of increased complexity while responding to commercial pressures, the demands on an RM tool increases. In order to respond to these demands DOORS plans to migrate its server onto the Jazz Foundation Server. While still taking an evolutionary approach in order to make customers investments in their requirements and customizations safe, DOORS will utilize central services offered by Jazz to deliver on some of those longer term industry demands. In the shorter term DOORS is taking an aggressive approach of integrating to IBM Rational Jazz based offerings. An integration to IBM Rational Quality Manager has recently been released and an integration to IBM Rational Requirements composer is expected by the end of 2009.

« Newer Posts - Older Posts »