BARON: Welcome to this IBM Rational podcast. I'm Bruce Baron, Marketing Manager for IBM Rational Requirements Definition and Management Solutions. The title of today's podcast is, Early, Often and Aligned: Requirements Definitions for Business-Driven Solutions, an IBM case study. And joining me is Vishy Ramaswamy. Vishy is the product architect and development lead for the Rational Requirements Composer, IBM's new collaborative solution for requirements definition. Vishy has responsibilities for delivering Requirements Composer 1.0, as well as introducing new and innovative capabilities in this product as it moves forward. Defining new products, services and capabilities is a source of differentiation for most organizations. And it is a high-stakes endeavor. In today's climate, you don't get a second chance. An innovative organization like IBM keeps the pipeline full of new products and services for our clients by being clear on what innovations the market can adopt. Vishy is here to discuss how IBM use Requirements Composer to define the product, shipping it early and often in iterations, and using scenario-driven approaches to deliver -1-
a business-driven application that is transforming the way that applications are being created and delivered inside IBM. Hello, Vishy. Welcome to the podcast. RAMASWAMY: Hi, Bruce. Thank you. BARON: So let's start off with an easy question. What are the pain points around defining correct requirements that organizations struggle with today? RAMASWAMY: Bruce, some of the biggest pain points that we have seen both with customers that we have been dealing with is the significant gap that actually exists between IT and the business -- so, the business analyst trying to communicate to the IT folks like the architects who are actually implementing software, there is a gap that currently exists. There's also an uncertainty that's driven by perception and knowledge and communication gaps during the requirements definition process. So it's partly seeing that customers, people who are engaging in the requirements definition process are completely not clear what the business context is, what are they actually trying to solve, and how to gather data around these aspects so that you can communicate better to IT to solve a particular problem. -2-
In relation to that, we also have customer feedback that comes back in some of the pain points, customers are saying that requirements are ubiquitous and continue to be labor-intensive. So they are very careful in terms of their investment at this because they don't see a repeatable process that has been successful for them. They are always conflicted about requirements. They want more confidence in the process around defining requirements. They always believe, and through their experience that they their return on investment will be incrementally better on requirements definition than on management alone kind of thing. Eighty percent of the software development projects are failing because of poorly defined requirements. And most of the effects that you already see in the industry today is that poorly defining, if you don't define the requirements well, your solution definition is a problem. And then the bigger part of this that comes in is managing actually change that happens to the business, which means business reengineering, how are businesses adapting to change becomes a lot more complicated if the initial set of elaboration and elicitation in terms of your business has not being done correctly. -3-
BARON: So, Vishy, how does Rational Requirements Composer help to address these requirement definition problems? RAMASWAMY: The fundamental goal and the motivation behind Requirements Composer was specifically to address some of the pain points that I talked before, Bruce. So the overall goal is to try to foster a focused, natural, real-time contextual collaboration using various techniques that are again, well-established techniques in the industry and artifact types. So focusing on actually understanding the right business context. Use the appropriate techniques to define the business context. Focus on discovering requirements in the first place, more than just management of requirements. Put infrastructures in place that help you validate these requirements as you're actually understanding the business context and elaborating on these discussions. This is basically through constant collaboration between stakeholders, business folks and IT folks. And also, support specification techniques which is other than or beyond rich text, which is a standard or a normal shortcoming that exists in the industry today is like massive Word documents or massive rich text documents and -4-
stuff that use other forms of techniques, graphical or otherwise, to actually capture the pieces of information that you need and then extract requirements out of it after you have collaborated enough with all the interested parties. So that is one of the themes, if you want to understand Composer is what I call as clarity, collaboration enables correctness. The clarity basically reflects the part of identifying the individual pieces of the business that are involved in the change that you need to capture, whether you're doing business process diagrams to capture the business, you're doing system use cases. You want to build a business glossary to make sure that your terminology is communicated correctly and efficiently. You're doing user experience modeling, using sketching or storyboarding to make sure that the applications that you're building, the look and feel and the usability of these applications are agreed upon way in advance before you actually even write one line of code. So that's the overall theme that basically Composer brings forward saying, clarity and collaboration on these facts and these artifacts will enable correctness in the way you extract your requirements. -5-
And what is actually enabled by addressing those pain points by giving you a tool that has these techniques on which you can collaborate on and extract the requirements, you're essentially enabling and pulling the requirements definition process, you have a consistent way to do definition, validation and management of requirements through the lifecycle. It also establishes that more and clearer communication among business stakeholders and IT folks, wherever they are located. It doesn't matter whether you're located in one team or geographically separated. And obviously, a consistent process which you can follow and trace back to will also reduce your project rework, faster project execution and lower your cost delivery. BARON: Excellent, Vishy. Improved requirements definition, more and clearer communications, less project rework, all things that are very critical to organizations today. And speaking of organizations, as the lead developer at IBM on the creation of Rational Requirements Composer, talk about how IBM used Rational Requirements Components to enable more agile requirement definition process in their software engineering. -6-
RAMASWAMY: The Agile practices that we have taken when we were building composer, the main one is green thread based development. Green thread based development is basically defining usage scenarios of the product itself as the customer or the user -- in this case the business analyst -- is using the tool from an end-to-end scenario point of view, not just talking about individual pieces of functionality, but building an entire story of saying, okay, the analyst is trying to bring in or start a project. He gets in some raw information. He brings that into the composer collaboration server. He organizes that information in terms of folders and structures. He might do some tagging and directory organization. Then he basically builds his team of analysts who are going to start collaborating on the different techniques. They might start off using interface sketching, or they might start off business process diagraming, and then building those pieces together and then linking these artifacts and then extracting requirements and then eventually managing them. So that's the kind of story that we actually build and then have that as a driver for us for all the development releases that we have during the entire product release. -7-
This also enables us to actually start producing examples like the CD example where you can see that it actually builds an entire story and shows the value of the different techniques and the capabilities that are put together that have the correct business value in terms of doing requirements definition and then extracting requirements. So the green thread based development has been a significant driving force for us. The second part, as our CTO and our general manager would say, is that we reduce our development cycle to shorter milestones so that we can actually do a little bit of development and then immediately share the drivers with our customers and our field and our support teams for them to start using the tool and basically giving us feedback. So two ways it helps us is that it validates our assumptions and also our way of looking at the pain points and get immediate feedback. So we are always getting that feedback either through our managed data customers that we get a select set of customers to come in and work with us, and we have released three betas over the year. So every beta and every milestone, we make sure that we demonstrate the entire green thread or parts of the green thread where obviously things have not been done yet. We would have gaps because we haven't worked on it. But still -8-
we'll have the ability to demonstrate an end-to-end scenario so that constantly you're always thinking of the value propositions at the end of the day. We have design partner programs where also we bring in customers and talk about specific issues or specific problems, pain points that we probably don't have enough information or just share our thoughts with them. So, for example, the concept of review and approval in requirements definition; we have some ideas, and how do we do reviews of requirements that is being collaborated by a few business analysts before we finalize them and give it to IT folks and say, okay, these are the requirements that we have gone through a review process and made sure. And those type of discussions are happening before we even write code. We sit down with our customers, have brainstorming sessions, which is again one of the Agile ways to bring them back directly into the room and talk to them about specific parts on how they would approach the problem or what their usage model is. The next thing we also did, as part of not only keeping the milestone shorter, is that we did internal pilot programs within IBM. So we went and gave Composer in one of its beta versions, to our service side practitioners, our business -9-
analysts from GBS, and set up an entire pilot program for three weeks where we basically gave them the tool and they installed the tools in their internal site and their practitioners who are actual business analysts started using the tool. Then they gave us some valuable feedback in terms of some of the usability issues around different techniques like, for example, the difficulty in one particular technique over the other, or just having more help information or the linkages that need to exist so that the flow of information for them is more natural in the way they work or normally business analysts work. The other part that we also felt very good about that is getting involved with field and support teams right from day one, and these are the people who are also enabling talking to the customers or troubleshooting with customers when they use the product is educating them constantly. And education for us comes twofold: we share the green thread, we tell them the story -- the same story we tell everybody, we tell our field, our support teams while doing troubleshooting and helping the customer. We allow them to actually use the tool. And then they are involved in our development lifecycle -10-
planning when we plan features for each milestone, they provide valuable feedback in terms of us prioritizing one feature over the other saying, you know this might...this can wait, but this one is more important because it has more value in the story that we are providing. So this constantly educating the support team was also part of the process and recreate as a development team documentation and artifacts and samples, like the CD example. By giving them more and more examples to understand the tool, bring the value of the tool, make them actually use the tool. And the last one I call is drinking our own champagne, which is, we basically use our own tool to build Composer. And the way we have done it is that we use cell post servers within IBM Rational that we basically host any of the milestone drivers that come out and do the requirements definition process for composer itself. It only makes sense that we can define requirements for our own product by having our own story. We have our story of what our green thread is, and we capture that green thread using the definition techniques like collaboration diagrams using business process diagrams, support cross product integrations or definition of green threads for products. -11-
We use that and we use system use cases, to do...we do use case diagramming, and we define the system use cases for the product. We have a dedicated usability team that uses all the user experience tooling part of Composer by drawing sketches, storyboards and creating the screen flows of how Composer looks and how Composer interacts. And that itself is playing with our own tool, so it gives us the pain points where we, maybe as not necessarily as business analysts itself, like even for developers who are in the Agile space, can also be looking at how to use the tool. But ending up with those specific integration points was critical for us, and that's why we continuously use. So we used business process sketching, user experience tooling. We had rich text documents that to the point where we were doing our design meetings and program management meetings on composer with our agendas and collaborating on them by getting comments from the leads and the developers. Building our own glossary terminology was also a good starting point, and we are going to build a glossary for Rational using Composer. And then now we're starting to do hosting composer on cell [post] servers so that we can bring other projects within IBM to start self hosting on Composer so that they can do their requirements definitions also on -12-
composer. BARON: So Vishy, this is great. Is there a way that you could sum it up or provide us a set of tricks and tips that folks need to be focused on when they're doing requirements definition? RAMASWAMY: The same three themes that I talked about earlier, which is the only three things, you can think of it as ideas or notions that you've got to keep in your head when you look at composer itself, is, we always think about clarity when you're doing requirements definitions. You need to find out that all the data that you need to capture the business context is correct. Second is collaboration. Make sure that you're collaborating enough with all the interested parties and that will basically enable correctness for you so that you can actually extract requirements and not run into just troubleshooting them later on, kind of thing. BARON: Thank you so much for taking time out to discuss Early, Often and Aligned Requirements Definition for Business-Driven Solutions, An IBM Case Study. We really appreciate it, and we appreciate you speaking to how an organization like IBM uses requirements definitions tools and techniques to build a collaborative, inclusive process. -13-
RAMASWAMY: BARON: All right, thanks a lot, guys. That was Vishy Ramaswamy, product architect and the development lead for the Rational Requirements Composer product. If you are interested in more information on Rational Requirements Composure, check out the product page at www.ibm.com/rational/announce/rrc. And if you are interested in more podcasts like this one, check out the Rational Talks to You podcast page at www.ibm.com/rational/podcasts. This has been an IBM Rational podcast. I'm Bruce Baron. Thanks for listening. Keep tuning in as Rational Talks To You. [END OF SEGMENT] -14-