How is requirements management handled in the world of embedded software development? In Embedded software for medical devices: Differences to consider in the SDLC, we heard from Mace Volzing, Software Development Manager at IntraPace, about the methodology used when developing abiliti, a device to control hunger in obese patients. In this second part of the interview, SearchSoftwareQuality.com finds out more about how IntraPace managed...
the requirements for the embedded software in this unique medical device. Read part 1.
SSQ: Let’s talk about the requirements process. You use the Jama Contour tool to manage your requirements?
That’s correct. We’ve got three projects that we’ve run here over the last two years; each project has about 25 steps in it, which means 25 documents. All of those 25 documents are interrelated, so you’ll have a requirement spec which will have test requirements, which then links upward. So there’s a chain of documents that you’ll see. You’ll have a marketing spec, a product spec, an engineering spec, and then test requirements below that, and all of those link together through Contour, which is incredible when you go to do any kind of maintenance later or any kind of change request later on.
SSQ: So before you used Contour did you use a different requirements management system or was it more spreadsheets and Word documents?
When I came to work for IntraPace, I had the luxury of starting from scratch. It was a startup company, and I had done it a couple of different ways at other companies, and I had seen it done many different ways at other companies, so I had the luxury of coming in and “trying to do it right” the first time. I think we picked the right tool. I had great success getting people involved in it from all levels of the company. From getting the marketing spec driven from people who aren’t engineers, to still use the tool. And that was one of the things I was really excited about when I started using it was that I could sell it to non-technical engineers. As you’re adding value, you’re making this easier for everybody down the line. And the tool is easy enough to use that they were willing to jump in and do that.
SSQ: What would you say was the biggest deciding factor when choosing a requirements management tool?
Usability. I looked at probably over 70 different solutions and I looked at three things: Can I get the non-engineers in the company to buy in and use it? Is it simple enough to put it in front of them and give them 10 minutes of instructions and have them up and running and using it? And cost: For a small company -- we’re 30 people -- it wasn’t something that was going to sink our budget and then flexibility. I needed the ability to generate output from the tool in a way that would make the quality folks in the company happy. And Contour and Jama was very supportive in the early days creating customer reports. We’d put a call in to them, and we’d have a call back that same day with answers on how to do whatever it is we were trying to do. We were a little bit on the leading edge with some of the reports, and they were very good at helping us get it done.
SSQ: I’m curious how you test requirements that are dependent on a human. So if one of the requirements is something like determining when a person feels full, how would you test that?
That would be a marketing requirement that would be way up high on the level. So that marketing requirement would come down into 10 engineering requirements, which would come down into 30 different test cases. Each of those test cases would then be implemented in terms of verifying that they were across all boundaries, across all inputs. So you look at the system as a black box when you get down there, and what you’re giving an example of is a very high level marketing requirement. So that would break down into multiple engineering requirement like, “Okay, well in order to do that, we can’t allow the voltage to go beyond here when we’re simulating.” Does that make sense?
SSQ: I see what you’re saying; you can break it down into analytical things that can be tested without the need for a human.
Yeah, it depends on what the requirement is.
SSQ: Software that runs on a device is going to have some requirements on which that device has to operate, and do you need to get a simulator for the device in the early stages of the coding, or do you put sensors on the device to see if those things are operating the way they need to?
Yes, we’ll use a national instruments test span, which gives us all kinds of inputs and outputs. It’s got built-in oscilloscopes; it’s got resistive ladders we can put in, so yes, we do build a simulated environment and world that we test with, and we control that with all the automated testing.
SSQ: And in this case, the deployment piece would be surgically implanting this into somebody, correct?
SSQ: So how would you execute the user acceptance test where you would want to see how this feels?
That’s done early in the process. There’ll be safety testing and it’s typically done in animals. So we’ll take it out and we’ll do all our safety testing on animals to make sure we’re not going to burn the stomach lining or do things that will do harm to humans. In terms of making sure the device meets all the requirements, it’s like any other software testing. You just make sure that all the parameters match, and you don’t go beyond.
SSQ: Do you have further regulations because your device is going to be implanted in somebody? So you have more rigid requirements that have to be passed? Would you be liable if there was a mishap and someone had a medical issue because of device?
Certainly the company is liable. It’s our responsibility to make sure a safe product gets on the market.
SSQ: But are there certain FDA requirements that need to be met in order to prove that you performed appropriate software quality procedures?
Right. So the FDA has guidelines -- not requirements. They have a big list of this is what you should do. And most of it’s designed around design control, and what they want to see is traceability and did everything get thought about. You have to show you have design control in place, and you do extensive risk analysis on all of your risk levels. There may be three different levels you can come in at, so depending on the type of device you are, it equates to the level that you have to manage the risk. In terms of design control, their goal is you’ve got to have a documented lifecycle and design process you follow so when they come into audit you what they look at is: are you following the process that you documented? Are you doing everything you said you’d do? If it says we do 100% coverage on code reviews, do you have documentation that shows that you did that? If it says we have 100% coverage on requirements and showing that we tested those requirements, do you have documentation that shows that you did that? A lot of my job is making sure that the documentation is available and correct so when we get audited by the FDA, we can show them all the work we did.
SSQ: If you do that, are you protected? There are accidents that happen out of their control that you can’t know so if there were an anomaly, maybe because of a pre-existing medical condition.
I don’t know the answer to that. I would defer to the legal department. I would guess that’s on the doctors.
SSQ: Are there things you need to do to protect yourself from legal action?
It’s medical device software and software lifecycle processes ANSI62304 are the standard you need to follow when developing medical device software. That’s what we comply to -- it is 60 pages long.
Do they tell you what kind of methodology you need to use?
They don’t go into specifics. They allow you the freedom to implement any type of methodology you want in terms of design control or dev processes so they are flexible it’s not a rigid you have to do ABCDE.
Do you find using Contour is working for you regardless of what methodology you’re using?
Absolutely. It’s flexible, it’s nice in terms of giving traceability back and forth; I can go in there and create a report, which will give me traceability from the product requirement all the way down to the test taking, so it’s a very nice tool.