ISO 9001 Twenty Quality Elements

 —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  — —

Sup­port trans­la­tion:
 — —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  —  — —
ISO 9001 Twenty Qual­ity Ele­ments

A look will be taken at the require­ments from the view­point of com­pan­ies devel­op­ing soft­ware. ISO 9001 stand­ard was inten­ded for the man­u­fac­tur­ing industry. The require­ments are inter­preted for soft­ware devel­op­ment in accord­ance with ISO 9000 – 3 and Tick­IT.

There are 20 main ele­ments. Each con­cept is well known in the qual­ity man­age­ment com­munity.

1. Man­age­ment Respons­ib­il­ity

1.1 Qual­ity poli­cy

The stand­ard requires the sup­pli­er man­age­ment to issue a qual­ity poli­cy, where it says the com­pany shall pro­duce qual­ity products.

The qual­ity poli­cy shall:
 — Define the management’s com­mit­ment to qual­ity
 — Define the company’s object­ives regard­ing qual­ity, that is, what man­age­ment means by qual­ity
 — Be rel­ev­ant to the customer’s needs
 — Be under­stood in the organ­iz­a­tion
 — Be imple­men­ted


- State­ment too vague or poli­cy is not under­stood by staff
 — Qual­ity poli­cy is not imple­men­ted.

E.g. of Qual­ity poli­cy

“We achieve qual­ity through motiv­ated and skilled staff, defined work pro­ced­ures, and intens­ive review and test­ing activities.”

1.2 Organ­iz­a­tion

The stand­ard requires doc­u­ment­a­tion of respons­ib­il­ity, author­ity and inter­re­la­tion of all per­son­nel affect­ing qual­ity. This means that if a per­son has a respons­ib­il­ity, it shall be form­ally assigned by the appro­pri­ate man­ager. The per­son should have the author­ity to ful­fil the respons­ib­il­ity.

Accord­ing to ISO, respons­ib­il­ity means:

“a duty to act on one’s own accord when some­thing has to be done without being told”.


- Exist­ing of a respons­ib­il­ity that can­not be ful­filled.


- Pro­ject-line
 — Pro­ject-cus­tom­er
 — Pro­ject-main­ten­ance organ­isa­tion
 — Soft­ware devel­op­ment-hard­ware devel­op­ment
 — Main­ten­ance organ­isa­tion-help desk
 — Sales-devel­op­ment

Resources require that the sup­pli­er:
 — Identi­fy the require­ments for resources
 — Assign trained per­son­nel.

Man­age­ment rep­res­ent­at­ive requires appoint­ment of man­ager rep­res­ent­at­ive with author­ity and respons­ib­il­ity to:
 — Ensure that the com­pany ful­fils the require­ments in ISO 9001
 — Report the per­form­ance of the qual­ity sys­tem to com­pany man­age­ment

1.3 Man­age­ment Review

Qual­ity man­ager should peri­od­ic­ally present the res­ults of
 — Qual­ity audits
 — Stat­ist­ics of qual­ity com­plaints
 — Records of cor­rect­ive action

The res­ults should be presen­ted at a recor­ded man­age­ment meet­ing with notes on who atten­ded, what was presen­ted and what decisions were taken and made.

2. Qual­ity Sys­tem

Qual­ity sys­tem – “the organ­iz­a­tion­al struc­ture, respons­ib­il­it­ies, pro­ced­ures, pro­cesses and resources for imple­ment­ing qual­ity management.”

Pro­ced­ures, rules, decisions shall be put into writ­ing. If you have a rule or pro­ced­ure that is not required by ISO 9001, the stand­ard still requires that it is writ­ten.

A qual­ity manu­al shall con­tain ref­er­ence and doc­u­ment­a­tion of the qual­ity sys­tem.


- An audit is a sample, there­fore if in a sample, there are minor non-con­form­ances, and they are fixed, it can still be a non-con­form­ance because the aud­it­or can sus­pect that there are many more minor non-con­form­ances.
 — Exist­ing writ­ten pro­ced­ures are not adhered to.

3. Con­tract Review

The sup­pli­er checks before sign­ing con­tract that the organ­isa­tion be able to per­form what is required by the con­tract.

Ques­tions that should be asked include:
 — Are the require­ments doc­u­mented and under­stood?
 — Are accept­ance cri­ter­ia included?
 — Have require­ments dif­fer­ing from the tender been resolved?
 — Can the sup­pli­er muster enough resources for the con­tract?
 — Can the sup­pli­er muster the com­pet­ence needed for the con­tract?
 — Can the task be com­pleted in time?

The stand­ard requires that a doc­u­mented pro­ced­ure with reviews be included. The sup­pli­er should identi­fy how con­tract amend­ments and hand­ling of require­ments spe­cific­a­tion between cus­tom­er and sup­pli­er be defined.

4. Design Con­trol

4.1. Gen­er­al
ISO requires that you plan before doing and spe­cify before design­ing.

4.2. Design and Devel­op­ment Plan­ning

Design plan should con­tain:
 — Defin­i­tion of meth­od­o­logy to be used in devel­op­ment of pro­duct
 — Time sched­ules, respons­ib­il­it­ies, work assign­ments and pro­gress con­trol
 — Phases pro­ject will be divided. This includes input, out­put and veri­fic­a­tion of out­put.
 — Descrip­tion of meth­ods and tools to be used

Qual­ity plan should con­tain:
 — Qual­ity tar­gets
 — Cri­ter­ia for accept­ab­il­ity
 — Iden­ti­fic­a­tion of plan­ning, val­id­a­tion and veri­fic­a­tion.
 — Respons­ib­il­it­ies for qual­ity activ­it­ies.

If a com­pany wants to gain ISO qual­i­fic­a­tion the plans must be held in all pro­jects, since ISO cer­ti­fic­a­tion is for the whole com­pany and not for spe­cific pro­jects.

4.3 Organ­iz­a­tion­al and Tech­nic­al Inter­faces

If there is group-work, the inter­faces between them should be iden­ti­fied, doc­u­mented and trans­mit­ted to those need­ing the inform­a­tion. The doc­u­ment­a­tion shall be reviewed reg­u­larly.

4.4 Design Input

Require­ments spe­cific­a­tions con­tain the design input in soft­ware devel­op­ment. This may be done by the pur­chaser or pre­pared by the sup­pli­er using laws and reg­u­la­tions. Another design input includes design cod­ing which is used as input to cod­ing.

The stand­ard wants to ensure that the work pro­duct of each step meets the require­ments.

In soft­ware devel­op­ment, require­ment changes are com­mon so a pro­ced­ure for hand­ling new and changed require­ments from the pur­chaser be cre­ated.

4.5 Design Out­put

Design Out­put: the design doc­u­ment­a­tion and the source code. ISO requires that design doc­u­ments and cod­ing be reviewed before release.

A pro­ced­ure for accept­ance of the design out­put and cri­ter­ia of accept­ance should be cre­ated.

4.6 Design Review

Pro­ject func­tions like cod­ing and test­ing shall be presen­ted at the review. A com­mon meth­od for ensur­ing reviews are check­lists.

4.7 Design Veri­fic­a­tion

This con­sists of reviews, mod­ule test­ing and integ­ra­tion test­ing.

4.8 Design Val­id­a­tion

Final sys­tem test, of the com­plete soft­ware pro­duct togeth­er with the review­ing of user doc­u­ment­a­tion. There should be planned and doc­u­mented val­id­a­tion. Beta test­ing is in con­form­ance with ISO as long as the beta test­ing is covered by a clear agree­ment between sup­pli­er and beta-test­ing cus­tom­er.

4.9 Design Changes

ISO 9001 requires that after release of design doc­u­ment­a­tion or source, all changes shall go through a form­al pro­cess where changes are doc­u­mented, reviewed and approved before imple­ment­a­tion.

Uncon­trolled changes to com­plex tech­nic­al doc­u­ments or pro­grams are extremely dan­ger­ous and as such the stand­ard does not allow it.
5. Doc­u­ment and Data Con­trol

Inform­a­tion that con­trols the development/maintenance of soft­ware. The stand­ard requires that those who need some document/data shall have access to it. Changes to doc­u­ments and data shall be con­trolled.