Software Requirements specification vs. Design Specification - Differences

[NathaliaM]

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?

1. Visual stimulations must happen and must be controlled. And, for the Design, to write that the internal pc is in charge of that.
2. 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 =)

[krishna007]

Hi Nathalia

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

[NathaliaM]

no, it does not

[ddunn]

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

[mafjensen - 2011]

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.

[yodon]

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.

[NathaliaM]

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?

[yodon]

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.