Feb 3, 2008

Software Design Specification Writing

I spent the last week and today (minus time out for inane tasks that get us nowhere, focus people!) writing the software design specifications (SDS) . Honestly, I could probably spend another week on it. The SDS is key part of FDA 510(k) submission software section and verification and validation (V&V) and I suspect the software section is the section the FDA will rightly focus on. Unfortunately, the guy who wrote the software has a hard time transferring his thoughts from code into English, he wrote a really rough draft then I had to take over once we started looking at it. It is difficult to split the SDS and software V&V into parts that more than one person can work on, which means I get bugged a lot about progress by people who don't understand how one document could take a whole entire week to finish when we had a draft last week, then have other documents to write after that that may take even longer.

Before I left on vacation in December the V&V was scheduled to be done the next week- no one followed up on it and since only one person can really work on it at a time if that person is bugged to do other things, no progress is being made. I posted about getting a draft V&V before. How did it look? Brutal. Now it looks like I'm going to spend next week writing most of it. The software guy thought he should write the V&V first before the SDS and then we could work on the V&V while he wrote the SDS, but that just turned into a big mess. The company is kind of schizophrenic lately and can't seem to focus properly, which is why they had me do the SDS this week instead of two weeks ago right when I got back. If the software documentation is holding you back, every minute engineers aren't working on software documentation is delaying the submission, just keep that in mind before talking to them about anything at all, really.

Anyway, I think ideally you take the software design requirements, add to it so it becomes the SDS, then take the SDS and add the V&V steps, that way your traceability is covered without sitting around cross referencing documents for two days.

4 comments:

Jon said...

I feel your pain! I don't understand why people try to complicate software. Design controls should be addressed just as if it were a mechanical component. I feel your pain!

Anonymous said...

Sounds like you have had your fair share of doc-frustration. I can't tell you how many firms I have seen where people quit because they are fed so up with documentation work (they are usually hired for something else (like R&D), slip into the documentation work and unfortunatelly get good at it.)

We have built a little tool to take some of the pain out of Design History File documentation and make the whole thing a bit easier. If it sounds interesting, drop me line.
karl.larsson@aligned.ch

Unknown said...

I really can't understood why one should waste his time in all these things....I really understood your problem...I usually prefer the software people to handle all the things.

Healthcare Software Development

Steve from San Diego said...

Is there somewhere that has examples of how the SDS should look? I am now tasked with writing one.

Thanks,

Steve