5

Let's say that your organization is certified to be compliant with ISO 9001 (or an industry-specific interpretation, such as AS 9100 for aerospace) and that your quality management system applies across the organization, including to software development efforts. However, no document in your QMS traces to ISO 90003 (or AS 9115), which provide software-specific interpretations of the documents. Does not tracing to the software-specific interpretations mean that your software development efforts do not need to address the issues?

Let's take a specific example.

In AS9100, section 7.3.3 (Design and Development Outputs) adds a requirement beyond those in ISO 9001 that reads:

e) specify, as applicable, any critical items, including any key characteristics, and specific actions to be taken for these items

The definition of critical item is given as:

Those items (e.g., functions, parts, software, characteristics, processes) having significant effect on the product realization and use of the product; including safety, performance, form, fit, function, producibility, service life, etc.; that require specific actions to ensure they are adequately managed. Examples of critical items include safety critical items, fracture critical items, mission critical items, key characteristics, etc.

And the definition of key characteristic is given as:

An attribute or feature whose variation has a significant effect on product fit, form, function, performance, service life or producibility, that requires specific actions for the purpose of controlling variation.

If you trace to AS9115, it becomes clear what a key characteristic means for software:

Key characteristics in software are those measurable attributes where variability can be measured by the project and can, if left unchecked, adversely impact the project or product in areas (e.g., schedule, cost, maintainability, testability, reliability, portability). Examples of key characteristics include defect severity, complexity factors, nested menus, memory, timing, response time, and throughput targets.

If your organization's QMS has process documentation that is designed to meet the intent of AS9100's Design and Development Output, does that documentation have to account for key characteristics in software? Would a QMS that doesn't address key characteristics in software be in non-compliance?

My interpretation of ISO 9001 and AS 9100 is that it applies to all product development, regardless of the type of product that is being developed. These software-specific documents are additional guidance to remove ambiguities or add additional clarity between the hardware/manufacturing terms of ISO 9001 and AS 9100. If software is part of your product and you are certified to ISO 9001 or AS 9100, you need to ensure that your software development processes conform to the intent of the process. Is this a correct interpretation?

Improve this question
3
  • I would like to be proven wrong, but I think you overestimate this forum. People who are IOS certified to answer such questions would not waste time here, I am afraid. Their hourly rate would not allow it. Best would be asked the company which is certified to do your annual audit - a do it in a way they want it done.
    – Peter M. - stands for Monica
    Jan 29, 2016 at 14:42
  • 1
    @PeterMasiar I think you underestimate Stack Exchange. Many people who are experts in many things post here, and this is the most likely site to attract someone who could answer my question. This is a well-written question that doesn't appear to have an answer elsewhere on the Internet and would be useful to many other people. I'm an expert in software development (check out my profile, particularly on Programmers) and I "waste time" (and by that, I mean contribute my knowledge with the world) on Stack Exchange.
    – Thomas Owens
    Jan 29, 2016 at 14:46
  • As I said I would love to be proven wrong. I agree that is well-written and useful (for very small minority). I've also seen many even less obscure questions to get no answers.
    – Peter M. - stands for Monica
    Jan 29, 2016 at 14:53

3 Answers 3

Reset to default
1

In order to get certified as an organization, you need to say what falls into the scope of the ISO 9001 certification. If the scope in the certificate says "design", then that means that the software development is required to be in compliance with ISO 9001. Typically your overall Quality Manual would call out compliance to ISO 9001, and then the policies for Design and Development would also follow suit.

In order to understand the details of how the standard 9001 applies to software, ISO 90003 is a Guideline that can be used. Just to be clear, this does not mean that you need to trace to ISO 90003 at all, it's just a guideline. Its enough to claim that your design is in compliance with ISO 9001, and therefore your auditors will have a reasonable expectation that the items described in 90003 are there.

Improve this answer
0

First of all, it boils down to how you can prove something during an audit.

Secondly, even if you're not tracing a requirement with a separate document as is defined by a standard, but if there's a translatable effort performed and logged (by any means, such as a version control system), then you shouldn't have a problem to prove that you satisfy the criteria (and I think it's a good idea to get in touch with your auditors about specific requirements).

Improve this answer
4
  • (1 of 2) This doesn't really answer my question. I'm asking what you need to prove during an audit. In my example, AS9100 has requirements for critical items and key characteristics. However, those aren't defined for software in AS9100, but only in AS9115. I'm asking if it's acceptable to say "we ignore AS9115, so we don't have any requirements for software development". In this example, there is 0 documentation of processes surrounding critical items and key characteristics in software and 0 objective evidence of the work happening for software, but processes and evidence for hardware.
    – Thomas Owens
    Jun 22, 2016 at 11:21
  • (2 of 2) In my experiences, showing documented processes for a subset of work and associated evidence is sufficient for many auditors, it seems to be in contradiction to AS9100, which is stated to apply to all product development activities (and not just hardware product development). Just because you happen to get lucky with auditors doesn't mean you're doing the right thing. My question boils down to If there's a general understanding that ISO9000 and AS9100 apply to all product development (including software), even if you claim to not recognize the software guidance in ISO90003 and AS9115.
    – Thomas Owens
    Jun 22, 2016 at 11:28
  • It seems if you have a software deliverable (let's say you're charging for the software component of your product, too), then the purchasers can indeed ask for AS9115 in addition to AS9100. So you probably can't say I'm ignoring AS9115 as it's specifically linked to the overall AS9100, and I would ask for 9115 compliance if I was purchasing your software.
    – AlbusMPiroglu
    Jun 22, 2016 at 23:41
  • An example if you were selling your software to a specific company: boeingsuppliers.com/supplier/faq.html#2
    – AlbusMPiroglu
    Jun 22, 2016 at 23:42
-1

All ISO 9001 require is.

  • Do as you say
  • Say as you do.

Therefore you get ISO 9001 if your quality systems documentations says.

None of our software will do anything useful!

Hence ISO 9001 is meaningless without other standards being in place.

Improve this answer
1
  • This doesn't answer my question.
    – Thomas Owens
    Feb 1, 2016 at 10:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.