Specifications as requirements?

[OccamMan]

My company is building a major subsystem for another company's large medical device - even though we're not directly on the hook to the FDA (our customer is), we want to produce documentation that our customer can successfully use with the FDA. Our subsystem will be sold to this customer and others as an off-the-shelf product once complete.

We're looking to nail down the interfaces between our subsystem and other subsystems, and a question has come up around specifications vs. requirements. An example might illustrate this best:

Let's suppose that our subsystem needs compressed air from the system, specified at 98-102 PSI, delivered through a specific fitting. It seems to me that we should be testing our subsystem to ensure that it functions properly to this specification. And once we lock this down (advertise it to customers), it begins to feel like a requirement rather than just a specification, i.e., since we're publishing a specification that says we work at 98-102 PSI delivered through a specific fitting, it now becomes a requirement that we actually do so, and we should trace through to testing to make sure the requirements have been met.

So... should this specification turn into a requirement? Or should it stay as a specification, presumably with some traceability to testing?

Advice appreciated!

 

[SmallBizDave]

The word 'requirement' seems somewhat generic - specifications can be requirements. But there is a difference (however slight) in how we treat 'customer requirements' versus internally generated requirements, all of which can end up as specifications.

In general, one has more flexibility in testing internally generated requirements. In this example it may be the difference between testing only at a worst case pressure (for an internally generated requirement) or testing at low, high and median pressures (for a customer requirement). Interesting question. Other viewpoints welcome.

 

[adamsjm]

Here is a quick 4 page presentation showing the cascade of requirements and the feedback loop of specification based upon QFD and the V-model. This may give you some ideas on how to work with your customers.

 

[Ronen E]

My company is building a major subsystem for another company's large medical device - even though we're not directly on the hook to the FDA (our customer is), we want to produce documentation that our customer can successfully use with the FDA. Our subsystem will be sold to this customer and others as an off-the-shelf product once complete.

We're looking to nail down the interfaces between our subsystem and other subsystems, and a question has come up around specifications vs. requirements. An example might illustrate this best:

Let's suppose that our subsystem needs compressed air from the system, specified at 98-102 PSI, delivered through a specific fitting. It seems to me that we should be testing our subsystem to ensure that it functions properly to this specification. And once we lock this down (advertise it to customers), it begins to feel like a requirement rather than just a specification, i.e., since we're publishing a specification that says we work at 98-102 PSI delivered through a specific fitting, it now becomes a requirement that we actually do so, and we should trace through to testing to make sure the requirements have been met.

So... should this specification turn into a requirement? Or should it stay as a specification, presumably with some traceability to testing?

Advice appreciated!

From this description, I couldn't understand what would you be doing differently if you termed it "a requirement" vs. "a specification". I also couldn't quite figure what the FDA has got to do with it.

Sorry,
Ronen.

 

[Ajit Basrur]

Interesting discussion here ...

There is a Guidance Document "General Principles of Software Validation" that has defined the difference between "Specification" and "Requirement" - http:// www. fda. gov/ downloads/RegulatoryInformation/Guidances/ucm126955.pdf - DEAD LINK - SEE ATTACHED FILE


A requirement can be any need or expectation for a system

A specification is defined as ?a document that states requirements.? (See 21 CFR ?820.3.) It may refer to or include drawings, patterns, or other relevant documents and usually indicates the means and the criteria whereby conformity with the requirement can be checked.

.

 

[OccamMan]

That's really interesting Ajit, thanks, just what I'm looking for.

So, in the example that I gave above, where our subsystem requires 98-102 PSI compressed air through a specific fitting to function properly, do you think that this now becomes a requirement for the subsystem which is tracked and traced to tests like any external requirement imposed by a customer?

 

[OccamMan]

Ronen -

That's what I'm trying to figure out - if we have a specification that comes from an engineering need (e.g., requires 100 W at 120VAC), should that then be treated the same as a requirement imposed by a customer need (e.g., the device shall target the tumor with an accuracy of X).

The medical bit was added as there may be some regulatory implication to how this is handles, and there does seem to be such an implication based on Ajit's response.

 

[MIREGMGR]

My view:

Requirements are real, and technically determined and defined.

Specifications are what somebody says they are. Assuming the somebody is competent and honest, the specification doesn't go outside the bounds of the corresponding requirement. There are various reasons, though, why a specification might differ from the corresponding requirement in the opposite direction, i.e. "inwardly" from the bounds of the corresponding requirement.

 

[Ronen E]

Ronen -

That's what I'm trying to figure out - if we have a specification that comes from an engineering need (e.g., requires 100 W at 120VAC), should that then be treated the same as a requirement imposed by a customer need (e.g., the device shall target the tumor with an accuracy of X).

The medical bit was added as there may be some regulatory implication to how this is handles, and there does seem to be such an implication based on Ajit's response.

So, according to this post, what you're actually asking is how to treat requirements from different sources. IMO, as far as compliance with the requirements is concerned, it doesn't matter what the source is, once the requirement has been accepted / recognized by your org as binding (be it customer, regulatory, technical or other). Criticality and nature of the requirement matter more, especially in the context of verifying / validating compliance.

WRT the FDA -- given that you're acting as a component supplier, only few regulatory requirements apply directly to you (though many more may be transposed to you via contractual obligations towards your customer(s)). Before applying any FDA guidance, it's important to understand the scope of its application.

Cheers,
Ronen.