Hi,

My problem is that I can't see exactly the difference between a software requirements specification and a software design specification.

We produce a medical device designed to perform examinations of visual functions. It includes both hardware and software, and I'm working with the “Premarket Submissions for Software Contained in Medical Devices» to the FDA.

Our medical device is already built. So, for the part “Software Requirements Specification – HARDWARE REQUIREMENTS”, should I write, for example :

“We need a device where the patient can accommodate your head, where we can find a monitor for the eye's stimulation and one camera...” Or, should I describe our device? Because it's a requirement for the software. Without this device, the software will not be useful. But, what would be the software design in this case?

Another example, a internal pc is in charge of the generation of visual stimulations. What should I put in the Requirements?


Visual stimulations must happen and must be controlled. And, for the Design, to write that the internal pc is in charge of that.
To write that a internal pc is in charge of the generation of visual stimulations. And for the design, to describe how theses stimulations were generated.
Saying that the operating system is windows vista and the programming language is C is a requirement or a design?

Thanks =)

Hi Nathalia

Does the hardware already has a FDA approval? or do you want to just market a new software?

no, it does not

In general:
A requirements specification defines what the customer wants.
A design specification defines how you satisfy what the customer wants.

The first question to ask yourself when defining software requirements is if anyone would complain if you did it any different. (If nobody, that is HW engineers, customers, management etc., complains, then it is not a requirement). So the question will be if anyone would complain about a change of operating system? etc..

Then comes the design phase. This is where you will give requirements to yourself. Any design decision will be reflected as requirements on other parts of the system. It is up to the software engineers to decide how deep down they would like to specify requirements. (If this array is this size, then the index to it should be limited to etc...) this would be valid as a requirement, but it will also increase the workload beyond reason.

All the responses so far are good, useful, and accurate. To put just a little spin on things, remember that specifications need to be verified. Specifications should thus be stated in a manner to allow them to be verified. You can say something like "the software shall control stimulations" but verifying that would be a challenge. Depending on what controlled stimulation means, you might say something like "selection of stimulation pattern x shall trigger a light pulse for z seconds +/- <tolerance>."

Good specification writing is much more than just a narrative of what your device does. You are held accountable for whatever requirements you specify. Be sure they establish accuracy, tolerance, etc. Hope this helps.

Thanks, yours answers helped a lot!


So... at the requirements, I should introduce just the externals hardware that I shall to use... and the hardware that are due to my design, i should introduce them at the design specifications. Right?

That sounds like a reasonable approach. Issues will drift into those gray areas and you just need to make a decision on where to put things.

One final note: it's a good practice to describe the hw/sw interfaces into a separate document.

Hi,

My problem is that I can't see exactly the difference between a software requirements specification and a software design specification.

We produce a medical device designed to perform examinations of visual functions. It includes both hardware and software, and I'm working with the “Premarket Submissions for Software Contained in Medical Devices» to the FDA.

Our medical device is already built. So, for the part “Software Requirements Specification – HARDWARE REQUIREMENTS”, should I write, for example :

“We need a device where the patient can accommodate your head, where we can find a monitor for the eye's stimulation and one camera...” Or, should I describe our device? Because it's a requirement for the software. Without this device, the software will not be useful. But, what would be the software design in this case?

Another example, a internal pc is in charge of the generation of visual stimulations. What should I put in the Requirements?



Visual stimulations must happen and must be controlled. And, for the Design, to write that the internal pc is in charge of that.
To write that a internal pc is in charge of the generation of visual stimulations. And for the design, to describe how theses stimulations were generated.
Saying that the operating system is windows vista and the programming language is C is a requirement or a design?

Thanks =)




I work for a medical device company too. In the hardware requirements section of your SRS, enter the hardware that your software needs in order for it to work as intended. That would include the CPU type, memory requirements, cache, any board additions, HD size, OTS equipment, etc. Since your device was already built, you can get this information from what was built. However, all of this info should have been documented before the software was coded.

Normally, the OS, the programming language, IDE and any coding conventions are described in the SDD; along with the design of the software (i.e., flow charts, modules, I/O info, etc.). The SRS describes what the software is required to do. The SDD describes how you design the software to do what it needs to do, as described in the SRS.

Good day
The document you query is now regarded by the regulators as the document that essentially references the whole validation effort. Get your User Requirements Specification (URS) correct and the validation task can be properly scoped. We use a three level URS to achieve the regulatory requirement for traceability from the the individual requirements as detailed in the URS through to the DQ/IQ/OQ/PQ.

Everything below is word for word from the FDA:

Except from guidance document.

A documented software requirements specification provides a baseline for both validation and verification. The software validation process cannot be completed without an established software requirements specification (Ref: 21 CFR 820.3(z) and (aa) and 820.30(f) and (g)).

Excerpt from a recent Warning Letter,
Failure to validate computer software for its intended use according to an established protocol when computers or automated data processing systems are used as part of production or the quality system as required by 21 CFR § 820.70(i). For example:

A) Your firm uses off-the-shelf software (HEAT Help Desk) to manage customer support service calls and to maintain customer site configuration information; however, your firm failed to adequately validate this software in order to ensure that it will perform as intended in its chosen application. Specifically your firm's validation did not ensure that the details screen was functioning properly as intended. The details screen is used to capture complaint details and complaint follow-up information which would include corrective and preventative actions performed by your firm when service calls are determined to be CAPA issues.


B) Off-the-shelf software (Microsoft SharePoint) is being used by your firm to manage your quality system documents for document control and approval. However, your firm has failed to adequately validate this software to ensure that it meets your needs and intended uses. Specifically at the time of this inspection there were two different versions of your CAPA & Customer Complaint procedure, SOP-200-104; however, no revision history was provided on the SharePoint document history. Your firm has failed to validate the SharePoint software to meet your needs for maintaining document control and versioning.


Regards
Alex Kennedy
Validation Online.

I've referred to these types of requirements as "engineering requirements" as opposed to development requirements. After a product, whether sw or hw or both, is developed, the use of it in a system imposes requirements on other parts of the system.

Development requirements are requirements imposed on a developing design -- restricting design decisions until a final implementation is reached.

Sorry for the late reply -- I just joined up

Dindo