1 00:00:00,000 --> 00:00:11,240 Hello everybody. Here we are in Austin, Texas at the 2008 TeleLogic User Group. I guess 2 00:00:11,240 --> 00:00:14,660 there's only one. Innovation 2008 it's called. We've got another guest. 3 00:00:14,660 --> 00:00:20,320 My name's Andy Gerd and I'm Senior Product Marketing Manager for the TeleLogic Doors 4 00:00:20,320 --> 00:00:21,800 product at TeleLogic. 5 00:00:21,800 --> 00:00:25,080 Working on the Doors stuff, of course, you're involved in a lot of requirements management 6 00:00:25,080 --> 00:00:32,880 and that sort of thing, obviously. I have to confess, I come from the software world 7 00:00:32,880 --> 00:00:40,720 a lot more than the TeleLogic systems world. To start out with, I'm curious how, if anyway, 8 00:00:40,720 --> 00:00:46,040 how requirements management differs in the customer base that you typically operate in or if there's 9 00:00:46,040 --> 00:00:47,040 any difference at all. 10 00:00:47,040 --> 00:00:52,320 Some of the core principles of what you do with requirements would be the same, whether 11 00:00:52,320 --> 00:00:57,820 you're developing a piece of software that's being used in a financial services application 12 00:00:57,820 --> 00:01:06,060 or whether you're developing perhaps an avionics subsystem or an infotainment system for a 13 00:01:06,060 --> 00:01:14,000 car. But there are also some key differences as well. A lot of it's to do with the degree 14 00:01:14,000 --> 00:01:19,920 of rigor and formality. We're sort of talking about the history of the Doors product. It actually 15 00:01:19,920 --> 00:01:24,920 came out of the guy who created it in the first place, Dr. Richard Stevens, actually came out 16 00:01:24,920 --> 00:01:31,580 of a European Space Agency project, so really grew out of a discipline in the aerospace and 17 00:01:31,580 --> 00:01:38,700 defence industry where you're particularly mandated by the federal and government agencies to show 18 00:01:38,700 --> 00:01:44,580 compliance and traceability back to the original statement of requirements. It's kind of evolved 19 00:01:44,580 --> 00:01:50,580 out of that, so there is definitely a degree of formality in the process. You have to show 20 00:01:50,580 --> 00:01:56,240 that traceability all the way through a product development life cycle. There's also a lot 21 00:01:56,240 --> 00:02:03,080 more perhaps criticality to the system because you're talking about things that are safety or 22 00:02:03,080 --> 00:02:08,080 even life critical in some cases, so you need to have a lot more rigor to the development process 23 00:02:08,080 --> 00:02:11,080 and make sure you're really adhering to the specifications. 24 00:02:11,080 --> 00:02:20,080 I was actually talking to an automotive customer recently. We did an interview with them and one 25 00:02:20,080 --> 00:02:25,080 of the things that they were saying was they're working on this collision avoidance by braking 26 00:02:25,080 --> 00:02:32,080 system and if you miss a requirement there and you're travelling at 70 miles an hour and the 27 00:02:32,080 --> 00:02:38,080 car puts the brakes on, obviously it's catastrophic. There's a degree of difference in the level of complexity 28 00:02:38,080 --> 00:02:45,080 and rigour in the systems development as perhaps in some software development. 29 00:02:45,080 --> 00:02:51,080 It's not just about traceability within requirements. What you want to do to have really good processes 30 00:02:51,080 --> 00:02:58,080 is link the requirements to your designs. Again, whether it's a software design or electronic 31 00:02:58,080 --> 00:03:04,080 or mechanical design, you want it also linked into the test cases that you're going to run. 32 00:03:04,080 --> 00:03:11,080 Those should actually be based off of the requirements because you shouldn't just be testing what you designed worked. 33 00:03:11,080 --> 00:03:14,080 You should actually be testing to prove you actually met the requirements. 34 00:03:14,080 --> 00:03:19,080 I'm also always curious when it comes to life cycle management things. 35 00:03:19,080 --> 00:03:30,080 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 36 00:03:30,080 --> 00:03:40,080 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? 37 00:03:40,080 --> 00:03:49,080 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, 38 00:03:49,080 --> 00:03:57,080 you get into talking about the development life cycle. Whereas actually requirements engineering, requirements management practices are much wider than that. 39 00:03:57,080 --> 00:04:04,080 I mean they're really from cradle to grave. They're really from conception of idea of the product through to end of life. 40 00:04:04,080 --> 00:04:13,080 So 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. 41 00:04:13,080 --> 00:04:24,080 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. 42 00:04:24,080 --> 00:04:31,080 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. 43 00:04:31,080 --> 00:04:38,080 So one of the key elements with requirements management is that it should be very closely linked with your change management process. 44 00:04:38,080 --> 00:04:39,080 Right. 45 00:04:39,080 --> 00:04:47,080 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. 46 00:04:47,080 --> 00:04:55,080 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? 47 00:04:55,080 --> 00:05:05,080 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? 48 00:05:05,080 --> 00:05:12,080 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? 49 00:05:12,080 --> 00:05:19,080 Yes, there's quite a wide range of different applications and different products that people are using it for. 50 00:05:19,080 --> 00:05:27,080 Actually, having mentioned, you know, sort of, you know, there are organizations that have been focused more on the complex part of their systems. 51 00:05:27,080 --> 00:05:30,080 So they might have been using it as the electronic subsystems in a car. 52 00:05:30,080 --> 00:05:31,080 Right. 53 00:05:31,080 --> 00:05:38,080 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. 54 00:05:38,080 --> 00:05:44,080 So even the requirements for the bumpers and the trunk and everything else would all be managed and held together. 55 00:05:44,080 --> 00:05:46,080 Yeah, that's a completely different type of thing. 56 00:05:46,080 --> 00:05:48,080 To get that all linked together. 57 00:05:48,080 --> 00:05:55,080 You know, you've got it used for aircraft, federal defense systems. 58 00:05:55,080 --> 00:06:02,080 It's also actually, though, not only just applicable to those sort of industrial sector type applications. 59 00:06:02,080 --> 00:06:09,080 We are actually seeing that in sort of mission critical enterprise systems in, say, financial services sector as well. 60 00:06:09,080 --> 00:06:16,080 Those types of projects are starting to exhibit the need and the maturity level that we see in the systems world as well. 61 00:06:16,080 --> 00:06:23,080 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. 62 00:06:23,080 --> 00:06:32,080 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. 63 00:06:32,080 --> 00:06:37,080 They already have things like Sarbanes, Oxley, and insurance has HIPAA to comply to. 64 00:06:37,080 --> 00:06:41,080 So, requirements management tool is a good way of enabling you to show that traceability. 65 00:06:41,080 --> 00:06:46,080 Yeah, you know, with rational and telelogic being together, there are some... 66 00:06:46,080 --> 00:06:54,080 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. 67 00:06:54,080 --> 00:06:57,080 Or not so much different, but sort of differently prioritized, right? 68 00:06:57,080 --> 00:06:59,080 And the complexity is slightly different. 69 00:06:59,080 --> 00:07:05,080 And, I mean, you know, the Doors reputation seems to be pretty good in the area that it works in. 70 00:07:05,080 --> 00:07:12,080 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. 71 00:07:12,080 --> 00:07:17,080 Like how, how sort of the roadmaps or the mixture of those two worlds, like you see them sort of playing out? 72 00:07:17,080 --> 00:07:25,080 Obviously, in the total portfolio in IBM now, we have both the telelogic Doors product for requirements management. 73 00:07:25,080 --> 00:07:31,080 There's also the Rational Requisite Pro product on the requirements management side as well. 74 00:07:31,080 --> 00:07:36,080 But what we've seen, although, you know, there's some, there's definitely, you know, some degree of functional overlap. 75 00:07:36,080 --> 00:07:38,080 I mean, they both manage requirements. 76 00:07:38,080 --> 00:07:40,080 They both do traceability type functionality. 77 00:07:40,080 --> 00:07:46,080 What we've actually found is they are actually being used and their strengths are in different domains. 78 00:07:46,080 --> 00:07:51,080 Doors has been primarily used in the industrial sector in systems engineering environments. 79 00:07:51,080 --> 00:07:52,080 Right. 80 00:07:52,080 --> 00:08:00,080 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. 81 00:08:00,080 --> 00:08:11,080 Whereas, Requisite Pro has been more adopted in software development teams and, you know, perhaps the more simpler type IT projects. 82 00:08:11,080 --> 00:08:12,080 Right. 83 00:08:12,080 --> 00:08:13,080 And we see that. 84 00:08:13,080 --> 00:08:17,080 We do see a need for different tools, different tools for different processes. 85 00:08:17,080 --> 00:08:26,080 You know, not everybody, you know, needs, not every requirements management situation actually needs all of the, you know, capabilities. 86 00:08:26,080 --> 00:08:27,080 All the rigor and everything. 87 00:08:27,080 --> 00:08:28,080 Of doors. 88 00:08:28,080 --> 00:08:34,080 And there may be simpler, you know, there may be simpler types of projects that are, you know, well served by Requisite Pro. 89 00:08:34,080 --> 00:08:38,080 And that will continue to be maintained and we're going to continue to move forward. 90 00:08:38,080 --> 00:08:53,080 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. 91 00:08:53,080 --> 00:08:58,080 So traceability, change management, impact analysis, versioning, baselining of the requirements. 92 00:08:58,080 --> 00:09:08,080 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. 93 00:09:08,080 --> 00:09:14,080 Um, and moving into the world of requirement, what's being termed as requirements definition. 94 00:09:14,080 --> 00:09:22,080 So, um, we were working on a product, um, we came and found that Rational were also working on a product. 95 00:09:22,080 --> 00:09:33,080 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. 96 00:09:33,080 --> 00:09:45,080 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. 97 00:09:45,080 --> 00:09:46,080 Right. 98 00:09:46,080 --> 00:09:48,080 And it will be integrated, uh, with DAWs as well. 99 00:09:48,080 --> 00:09:53,080 So, we're already seeing some immediate, you know, opportunities, uh, from, from coming together. 100 00:09:53,080 --> 00:09:58,080 Like you're saying, the, the requirements composer is sort of the idea of gathering together the requirements. 101 00:09:58,080 --> 00:10:05,080 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. 102 00:10:05,080 --> 00:10:06,080 Yeah, exactly. 103 00:10:06,080 --> 00:10:22,080 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. 104 00:10:22,080 --> 00:10:23,080 Right. 105 00:10:23,080 --> 00:10:24,080 Yeah. 106 00:10:24,080 --> 00:10:32,080 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. 107 00:10:32,080 --> 00:10:45,080 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. 108 00:10:45,080 --> 00:10:50,080 And of course, like in the rational portfolio is a huge amount of sort of quality things or testing things. 109 00:10:50,080 --> 00:11:01,080 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. 110 00:11:01,080 --> 00:11:02,080 Yeah. 111 00:11:02,080 --> 00:11:04,080 That's a, that's a, that's a really exciting area actually. 112 00:11:04,080 --> 00:11:11,080 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. 113 00:11:11,080 --> 00:11:17,080 The QA should be linked into the requirements process right the way through the, right the way through the development life cycle. 114 00:11:17,080 --> 00:11:30,080 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. 115 00:11:30,080 --> 00:11:40,080 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. 116 00:11:40,080 --> 00:11:53,080 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. 117 00:11:53,080 --> 00:12:02,080 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. 118 00:12:02,080 --> 00:12:09,080 Um, so in, in Q1, uh, 09, there'll actually be, um, an integration between, uh, between doors and RQM. 119 00:12:09,080 --> 00:12:16,080 So, I mean, the, you know, requirements analyst is, is working inside of doors, um, defining, uh, requirements. 120 00:12:16,080 --> 00:12:20,080 Those requirements can be imported into rational quality manager. 121 00:12:20,080 --> 00:12:21,080 Right. 122 00:12:21,080 --> 00:12:30,080 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. 123 00:12:30,080 --> 00:12:31,080 Right. 124 00:12:31,080 --> 00:12:33,080 It sort of drives the labor that the QA people do, right? 125 00:12:33,080 --> 00:12:34,080 Yeah. 126 00:12:34,080 --> 00:12:44,080 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. 127 00:12:44,080 --> 00:12:51,080 So that the, uh, project manager and the requirements analyst can actually check the progress in terms of quality against requirements. 128 00:12:51,080 --> 00:12:51,080 Right. 129 00:12:51,080 --> 00:12:56,080 Because if you've still got outstanding defects against a requirement, well, it's not fulfilled. 130 00:12:56,080 --> 00:13:01,080 But if you've still, all the tests have passed, well, that requirement is probably ready to be, uh, released into the product. 131 00:13:01,080 --> 00:13:02,080 Well, great. 132 00:13:02,080 --> 00:13:04,080 Well, uh, thanks for taking this time to talk to us. 133 00:13:04,080 --> 00:13:07,080 It's, it's always fun to see what's going on in the world of requirements management. 134 00:13:07,080 --> 00:13:11,300 management. Great, my pleasure. Thanks.