Hello everybody. Here we are in Austin, Texas at the 2008 TeleLogic User Group. I guess there's only one. Innovation 2008 it's called. We've got another guest. My name's Andy Gerd and I'm Senior Product Marketing Manager for the TeleLogic Doors product at TeleLogic. Working on the Doors stuff, of course, you're involved in a lot of requirements management and that sort of thing, obviously. I have to confess, I come from the software world a lot more than the TeleLogic systems world. To start out with, I'm curious how, if anyway, how requirements management differs in the customer base that you typically operate in or if there's any difference at all. Some of the core principles of what you do with requirements would be the same, whether you're developing a piece of software that's being used in a financial services application or whether you're developing perhaps an avionics subsystem or an infotainment system for a car. But there are also some key differences as well. A lot of it's to do with the degree of rigor and formality. We're sort of talking about the history of the Doors product. It actually came out of the guy who created it in the first place, Dr. Richard Stevens, actually came out of a European Space Agency project, so really grew out of a discipline in the aerospace and defence industry where you're particularly mandated by the federal and government agencies to show compliance and traceability back to the original statement of requirements. It's kind of evolved out of that, so there is definitely a degree of formality in the process. You have to show that traceability all the way through a product development life cycle. There's also a lot more perhaps criticality to the system because you're talking about things that are safety or
2:03even life critical in some cases, so you need to have a lot more rigor to the development process and make sure you're really adhering to the specifications. I was actually talking to an automotive customer recently. We did an interview with them and one of the things that they were saying was they're working on this collision avoidance by braking system and if you miss a requirement there and you're travelling at 70 miles an hour and the car puts the brakes on, obviously it's catastrophic. There's a degree of difference in the level of complexity and rigour in the systems development as perhaps in some software development. It's not just about traceability within requirements. What you want to do to have really good processes is link the requirements to your designs. Again, whether it's a software design or electronic or mechanical design, you want it also linked into the test cases that you're going to run. Those should actually be based off of the requirements because you shouldn't just be testing what you designed worked. You should actually be testing to prove you actually met the requirements. I'm also always curious when it comes to life cycle management things. That sort of post-deployment or post-delivery process is like getting the feedback cycle in so that you're not only concerned with the creation of the software and you kick it out the door and wish it well. How are you finding people use Doors to track the software out in the wild and improve it? It's true actually. We quite often get into the trap perhaps sometimes of talking about, even when we talk about systems rather than software, you get into talking about the development life cycle. Whereas actually requirements engineering, requirements management practices are much wider than that. I mean they're really from cradle to grave. They're really from conception of idea of the product through to end of life.
4:04So that's not only when it's gone to manufacturing and you've shipped it out of the door, but it's all of the issues that might come back through warranty and maintenance. So they're all through to how you are going to phase out that particular, perhaps, fleet of aircraft or ships or whatever it might be or models of cars. As you're phasing those out, there'll be requirements that respect to that as well. So yeah, you have to have that process ongoing. So one of the key elements with requirements management is that it should be very closely linked with your change management process. Right. Because you're going to get in change requests or that change request could be a defect to something that's actually gone wrong in the product. Perhaps after delivery, do you want that fed back in to perhaps change the requirements for the next time you build a similar product of that type? I'm always curious to hear, after the general discussion of requirements management and things, what is it actually like beyond the door there, out in the wild and everything? And I mean, are there some, you know, no one ever likes to name names or anything, but I mean, are there some interesting sort of uses of doors that you've seen out there? Yes, there's quite a wide range of different applications and different products that people are using it for. Actually, having mentioned, you know, sort of, you know, there are organizations that have been focused more on the complex part of their systems. So they might have been using it as the electronic subsystems in a car. Right. Now they're actually, you know, we've got customers now who are now saying, we want to manage the requirements for the whole, for the whole car. So even the requirements for the bumpers and the trunk and everything else would all be managed and held together. Yeah, that's a completely different type of thing. To get that all linked together. You know, you've got it used for aircraft, federal defense systems. It's also actually, though, not only just applicable to those sort of industrial sector type applications. We are actually seeing that in sort of mission critical enterprise systems in, say, financial services sector as well.
6:09Those types of projects are starting to exhibit the need and the maturity level that we see in the systems world as well. One of the things we've seen and the uptake of requirements management in the industrial sector is driven by a lot of regulatory compliance and need to demonstrate conformance. Well, of course, with, you know, what's going on right now, I suspect there'll be even more regulations and enforcement put in place on the financial services sector. They already have things like Sarbanes, Oxley, and insurance has HIPAA to comply to. So, requirements management tool is a good way of enabling you to show that traceability. Yeah, you know, with rational and telelogic being together, there are some... And you sort of addressed some of these ideas that there's sort of, I don't know, an existing or different way of doing requirements management in the software world. Or not so much different, but sort of differently prioritized, right? And the complexity is slightly different. And, I mean, you know, the Doors reputation seems to be pretty good in the area that it works in. And I wonder, and you were getting to this with some of the financial service things, but I wonder if there's some, if there's a pull of software people coming into Doors or vice versa. Like how, how sort of the roadmaps or the mixture of those two worlds, like you see them sort of playing out? Obviously, in the total portfolio in IBM now, we have both the telelogic Doors product for requirements management. There's also the Rational Requisite Pro product on the requirements management side as well. But what we've seen, although, you know, there's some, there's definitely, you know, some degree of functional overlap. I mean, they both manage requirements. They both do traceability type functionality. What we've actually found is they are actually being used and their strengths are in different domains. Doors has been primarily used in the industrial sector in systems engineering environments. Right. And, you know, more recently some crossover into what we sort of define, I suppose, as more complex or enterprise, you know, type IT applications. Whereas, Requisite Pro has been more adopted in software development teams and, you know, perhaps the more simpler type IT projects.
8:11Right. And we see that. We do see a need for different tools, different tools for different processes. You know, not everybody, you know, needs, not every requirements management situation actually needs all of the, you know, capabilities. All the rigor and everything. Of doors. And there may be simpler, you know, there may be simpler types of projects that are, you know, well served by Requisite Pro. And that will continue to be maintained and we're going to continue to move forward. One of the really exciting things I think on the roadmap that we realized very soon after starting to talk together with the rational requirements team was that we were both thinking of expanding out from focusing on managing of requirements. So traceability, change management, impact analysis, versioning, baselining of the requirements. To what about the problem of actually capturing the requirements, you know, correctly and accurately and actually making sure those requirements are a true reflection of what the customer needs. Um, and moving into the world of requirement, what's being termed as requirements definition. So, um, we were working on a product, um, we came and found that Rational were also working on a product. And what we're going to do is the Rational requirements composer is actually, uh, coming out in its first version, very soon, um, integrated with Requisite Pro, focused more on IT software development. Um, but what we're going to do in, uh, middle of next year is we're going to bring out, uh, say there'll be another version of, uh, requirements composer with more systems requirements definition capabilities built into it. Right. And it will be integrated, uh, with DAWs as well. So, we're already seeing some immediate, you know, opportunities, uh, from, from coming together. Like you're saying, the, the requirements composer is sort of the idea of gathering together the requirements. And not, you know, making that easier for people who have the requirements on their head to express it to the people who will help fulfill those requirements. Yeah, exactly. It's definitely for people like, uh, business analysts who, and requirements, um, analysts who would work, you know, directly with, you know, customer stakeholders inside a business in order to discuss with them what their requirements are and get a good idea and formulate those requirements.
10:22Right. Yeah. Before they can become things that get managed throughout the rest of the life cycle in, indoors or records in pro depending on what type of application it is you're, you're managing. You were talking earlier about how, you know, I, I was asking about the sort of the full life cycle of, of software requirements tracking, or just the life cycle of software development, which obviously is run by tracking the requirements and seeing if you're getting what you want. And of course, like in the rational portfolio is a huge amount of sort of quality things or testing things. And, and I wonder how, how the existing like door stuff sort of fits into the QA process and like how, how you're sort of integrating with or working together with those existing sort of QA sorts of frameworks that are out there. Yeah. That's a, that's a, that's a really exciting area actually. Um, we, we've always seen, you know, quite a pool to make sure that what you're doing in the testing world is linked with requirements. The QA should be linked into the requirements process right the way through the, right the way through the development life cycle. And, you know, we've had some, uh, built in, uh, simple capabilities inside of doors for setting up test cases and linking them back to requirements and recording, you know, test runs of manually run tests. Uh, and then we've had integrations with, uh, you know, third party test management tools in, in order to facilitate, um, linking requirements and test cases and so on together. Uh, but actually, uh, rational are coming out right now with, um, uh, new, uh, product in the test planning and test case, um, planning area in that, uh, they're bringing out product called, uh, rational quality manager. And, you know, we see this as a really, you know, key area that organizations do want to link, you know, QA up with the requirements process. Um, so in, in Q1, uh, 09, there'll actually be, um, an integration between, uh, between doors and RQM. So, I mean, the, you know, requirements analyst is, is working inside of doors, um, defining, uh, requirements. Those requirements can be imported into rational quality manager. Right. So, the QA person working inside of quality manager will allocate them to a test plan, will derive test cases from those requirements, will then go off and actually execute those tests.
12:30Right. It sort of drives the labor that the QA people do, right? Yeah. And after the test cases are actually executed, the, um, the test status information will actually come back out, or quality manager, back into, back into doors. So that the, uh, project manager and the requirements analyst can actually check the progress in terms of quality against requirements. Right. Because if you've still got outstanding defects against a requirement, well, it's not fulfilled. But if you've still, all the tests have passed, well, that requirement is probably ready to be, uh, released into the product. Well, great. Well, uh, thanks for taking this time to talk to us. It's, it's always fun to see what's going on in the world of requirements management. management. Great, my pleasure. Thanks.