Professional Documents
Culture Documents
.A.
rás S
Sede:
Rio de Janeiro
Av. Treze de Maio, 13 - 28º andar
trob
CEP 20003-900 - Caixa Postal 1680
Rio de Janeiro - RJ
Tel.: PABX (021) 210 -3122
ra Pe
Fax: (021) 220-1762/220-6436
Endereço Telegráfico:
NORMATÉCNICA
Origem: Projeto 21:101.01-002:1997
a pa
CB-21 - Comitê Brasileiro de Computadores e Processamento de Dados
CE-21:101.01 - Comissão de Estudo de Qualidade de Software
usiv
NBR ISO/IEC 12119 - Information technology - Software packages - Quality
requirements and testing
excl
Descriptors: Data processing. Quality. Computer program. Information
technology. Software package
uso
Esta Norma é equivalente à ISO/IEC 12119:1994
de
Válida a partir de 30.11.1998
Copyright © 1998,
nça
ABNT–Associação Brasileira de
Normas Técnicas
Palavras-chave: Tecnologia de informação. Processamento 13 páginas
Printed in Brazil/
Lice
de dados. Programas de computador.
Impresso no Brasil
Todos os direitos reservados
Qualidade. Pacotes de software
Sumário 1 Objetivo
Prefácio
1 Objetivo Esta Norma é aplicável a pacotes de software. São exem-
2 Definições plos: processadores de texto, planilhas eletrônicas, ban-
3 Requisitos de qualidade cos de dados, software gráficos, programas para funções
4 Instruções para teste técnicas ou científicas e programas utilitários.
ANEXOS
Esta Norma estabelece:
A Definições de outras Normas
B Exemplo de uma descrição de produto - os requisitos para pacotes de software (requisitos
C Bibliografia de qualidade);
.A.
Prefácio
com relação aos requisitos estabelecidos (instruções
para testes, em particular para teste por terceira parte).
trob
Brasileiras, cujo conteúdo é de responsabilidade dos software (tampouco atividades e produtos intermediários,
Comitês Brasileiros (CB) e dos Organismos de por exemplo especificações); trata somente de pacotes
a pa
Normalização Setorial (ONS), são elaboradas por de software na forma como são oferecidos e liberados
para uso. O sistema de qualidade do produtor (tratado,
usiv
dos CB e ONS, circulam para Votação Nacional entre os Incluem-se como possíveis usuários desta Norma:
nça
Esta Norma inclui os anexos A, B, e C, os quais são 1) especificando os requisitos para um pacote de
informativos. software;
2 NBR ISO/IEC 12119:1998
2) projetando um modelo para descrever pro- 2.2 documento de requisitos: Documento contendo
dutos; quaisquer combinações de recomendações, requisitos
ou regulamentações a serem atendidas por um pacote
3) julgando seus próprios produtos; de software.
4) emitindo declarações de conformidade NOTA - Exemplos: normas ergonômicas ou técnicas, lista de
(ABNT ISO/IEC Guia 22); requisitos (ou modelo de especificação de requisitos) de um
5) submetendo produtos à certificação ou à grupo (exemplo: setor de marketing, associação de usuário ou
Lice
parte (internacional, nacional ou regional) ção da adequação do produto antes de sua aquisição.
excl
certificação ou para emissão de marca de conformi- gerais” (cover information) da ISO 9127. A descrição de produto
dade (ABNT ISO/IEC Guia 25); não é uma especificação, ela atende a um objetivo diferente.
ra Pe
documentação de usuário.
f) compradores que pretendam:
2.6 guia de teste (test case)3): Instrução documentada
1) comparar seus próprios requisitos com os aqui para o responsável pelo teste, que especifica como deve
descritos; ou convém que seja testada uma função ou uma combi-
2) comparar os requisitos necessários para exe- nação de funções. Um guia de teste inclui informações
cutar uma determinada tarefa com a informação detalhadas sobre as seguintes questões:
presente nas descrições de produtos existentes;
- objetivo do teste;
3) procurar por produtos certificados;
- funções a serem testadas;
4) verificar se os requisitos foram atendidos;
- ambiente de testes e outras condições (detalhes
g) usuários que pretendam se beneficiar com pro- de configuração e trabalho preparatório);
dutos melhores.
- dados de testes;
2 Definições
- procedimento;
As definições a seguir se aplicam para os propósitos
Lice
1 Uma função não precisa ser necessariamente acionável pelo - necessidade de que cada pacote de software tenha
a pa
usuário (por exemplo, backup automático ou salvamento uma descrição de produto e documentação de
automático de dados). usuário;
ra Pe
2 Esta definição de função é menos abrangente que a usada - requisitos para a descrição de produto. Em particu-
trob
pela ISO 2382-14:1978 (na definição de falha, defeito/falta (fault), lar, há um requisito que esta descrição deve conter
manutenção e confiabilidade) e mais ampla que as definidas informações específicas e que todas as suas decla-
rás S
pela ISO 2382-2 e ISO 2382-15. rações devem ser passíveis de testes e corretas;
.A.
1)
Este Guia foi cancelado e substituído pelo ABNT ISO/IEC Guia 60.
2)
Este Guia foi cancelado e substituído pelo ABNT ISO/IEC Guia 65.
3)
Nota de tradução - O termo “guia de teste” foi escolhido porque o termo “caso de teste” está sendo usado, de acordo com autores
como Pressman, Schach, Hetzel, Myers e entidades como o IEEE, significando apenas o conjunto de entradas de teste e saídas
esperadas.
NBR ISO/IEC 12119:1998 3
- requisitos para a documentação de usuário; Cada declaração da descrição de produto deve ser correta
e passível de teste.
- requisitos para os programas e dados, caso existam,
incluídos no pacote. NOTA - Este requisito se estende às declarações que citem
documentos de requisitos, se existentes (ver 3.1.2 e).
NOTAS
As subseções a seguir, de 3.1.2 a 3.1.8, especificam o
que a descrição de produto deve incluir ou convém que
1 Os requisitos sobre a documentação de usuário, programas e inclua, podendo incluir declarações adicionais sobre o
.A.
dados contêm muitos requisitos gerais (independente do que produto.
rás S
pode ser prometido em uma descrição de produto), mas não
incluem todas as propriedades que os usuários possam desejar. 3.1.2 Identificações e indicações
trob
2 Certas propriedades da documentação de usuário e das a) Identificação da descrição de produto
ra Pe
mensagens do programa, tais como inteligibilidade e boa
organização e apresentação, podem ser requeridas na visão A descrição de produto deve possuir uma única iden-
a pa
do usuário. Entretanto, devido à dificuldade de testá-las com tificação de documento. A “descrição de produto”
resultados bem definidos e reproduzíveis, são formuladas, pode ser chamada de formas diferentes, por exemplo,
usiv
atualmente, apenas como recomendações. “Descrição Funcional”, “Informação de Produto” e
“Folha de Produto”.
excl
Um pacote de software está em conformidade com esta
b) Identificação do produto
uso
Norma se atende a todos os requisitos definidos nas
subseções 3.1 a 3.3. As recomendações indicadas pelo A descrição de produto deve identificar o produto. A
de
uso da forma verbal “convém que” são opcionais. identificação do produto deve ter no mínimo o nome
nça
do produto e uma versão ou data. Se existirem duas
NOTA - A conformidade de um produto em relação aos requisitos ou mais variantes mencionadas na descrição de
definidos nas subseções 3.1 a 3.3 pode ser difícil ou impossível Lice
produto, então cada variante deve ter no mínimo o
de se provar. Entretanto, um teste (incluindo a revisão da nome do produto, o nome da variante e uma versão
documentação) de acordo com o item considerado suficiente ou data.
para proporcionar a confiança necessária para a certificação
de conformidade de acordo com o ABNT ISO/IEC Guia 2. c) Fornecedor
Nenhuma prova formal é necessária.
A descrição de produto deve conter o nome e o en-
3.1 Descrição de produto dereço de no mínimo um fornecedor.
avaliação da adequação do produto às suas ne- está em conformidade. Neste caso as edições
relevantes devem ser identificadas.
ra Pe
- servir como base para testes (ver seção 4). Os requisitos para colocar o produto em uso devem
usiv
3.1.1 Requisitos gerais sobre o conteúdo da descrição - unidades de processamento incluindo co-
de
processadores;
nça
- ambientes de rede; Deve ser declarada de forma nítida para cada função
mencionada (especialmente para uma opção ou va-
- software de sistema e outros software. riante) se ela é parte:
X à versão Y” pode aparecer; “a partir da versão X” necessita ser mencionada, assim como nem todos detalhes
não deve aparecer.
usiv
X+3 com a qual o pacote de software falharia ao ser exe- Se o uso do produto é limitado por valores-limite
cutado. específicos, estes devem ser fornecidos. São exem-
trob
plos:
g) Interface com outros produtos
rás S
- comprimento de chaves;
devem ser identificados.
Todo componente físico do produto fornecido deve - número máximo de critérios de busca;
ser identificado, em particular todos os documentos
impressos e todos os meios de armazenamento de - tamanho mínimo de amostra.
dados.
No caso de não ser possível fornecer valores-limite
O formato dos programas fornecidos deve ser de- fixos (por exemplo, quando eles dependem do tipo
clarado, por exemplo: programas-fonte, módulos- de aplicação ou do tipo de dado de entrada), as
objeto ou módulos de carga. limitações devem ser estabelecidas. Combinações
permitidas de valores podem ser fornecidas. A
NOTA - A formatação dos meios de armazenamento (por documentação do usuário deve ser referida para
exemplo, formatação dos disquetes) não precisa ser informações mais específicas.
indicada, pois o conjunto de formatações possíveis é de-
terminado pelos requisitos de hardware e software (ver c) Segurança de acesso
3.1.2 f).
Convém que a descrição de produto inclua infor-
Lice
j) Suporte
excl
A descrição de produto deve fornecer uma visão - proteção contra conseqüências danosas decor-
geral das funções disponíveis para o usuário do pro- rentes de erro de usuário;
duto, os dados necessários e as facilidades ofe-
recidas. - recuperação de erro.
NBR ISO/IEC 12119:1998 5
3.1.5 Declarações sobre usabilidade tempo de resposta e taxas de throughput para uma dada
função sob condições estabelecidas (por exemplo, a confi-
a) Interface com o usuário guração do sistema).
O tipo de interface com o usuário deve ser especi- 3.1.7 Declarações sobre manutenibilidade
ficado, por exemplo: linha de comando, menu, jane-
las, teclas de função e função de auxílio. A descrição de produto pode conter declarações sobre
manutenibilidade.
b) Conhecimento requerido
.A.
3.1.8 Declarações sobre portabilidade
rás S
O conhecimento específico requerido para a apli-
cação do produto deve ser descrito. São exemplos: A descrição de produto pode conter declarações sobre
trob
portabilidade.
- conhecimento de uma área técnica;
ra Pe
3.2 Documentação de usuário
- conhecimento de um sistema operacional;
a pa
3.2.1 Completitude
- conhecimento que possa ser adquirido via trei-
usiv
namento especial; A documentação de usuário deve conter as informações
necessárias para o uso do produto. Todas as funções es-
excl
- conhecimento de outro idioma diferente daquele tabelecidas na descrição de produto e todas as funções
em que foi escrita a descrição de produto. do programa que os usuários tenham acesso devem ser
uso
completamente descritas na documentação de usuário.
Devem ser declarados todos os idiomas utilizados
de
na documentação de usuário e na interface com o Todo valor-limite citado na descrição de produto deve
nça
usuário (incluindo mensagens de erro e dados ser repetido na documentação de usuário.
visíveis), tanto os do próprio pacote de software como
os de todos os outros produtos mencionados na des-
Lice
Se a instalação puder ser executada pelo usuário, a do-
crição de produto. cumentação de usuário deverá incluir um manual de
instalação contendo todas as informações necessárias
NOTA - Este requisito excede o da ISO 9127:1988, 6.1.7, (ver 3.3.1 a). Convém que o manual de instalação esta-
onde a menção dos idiomas usados é opcional. beleça o espaço de armazenamento mínimo e máximo
para a instalação do produto.
c) Adaptação às necessidades do usuário
Se algum tipo de manutenção puder ser executada pelo
Se o produto pode ser adaptado pelo usuário, então usuário, a documentação de usuário deverá incluir um
as ferramentas para esta adaptação e as condições manual de manutenção de programa contendo todas as
para seu uso devem ser identificadas. São exemplos: informações necessárias para essa manutenção.
Se a proteção técnica contra infrações a direitos auto- Os documentos da documentação de usuário não devem
trob
rais pode dificultar a usabilidade, então esta proteção apresentar contradições internas entre si e com a
deve ser declarada. São exemplos: descrição de produto. Convém que cada termo tenha um
ra Pe
e) Eficiência de uso e satisfação de usuário Convém que a documentação de usuário seja inteligível
uso
A descrição de produto deve incluir dados sobre a refa a ser atendida pelo produto, utilizando, por exemplo,
eficiência de uso e satisfação de usuário. uma seleção apropriada de termos, exibições gráficas,
nça
Convém que todo documento tenha índice analítico e Este requisito deve ser cumprido ainda que:
remissivo.
- a capacidade seja explorada até os limites espe-
Se um documento não estiver na forma impressa, convém cificados;
que o procedimento para impressão seja indicado.
- tentativas sejam feitas para explorar a capacidade
3.3 Programas e dados além dos limites especificados;
Lice
Após a instalação deve ser possível identificar se os tecla ou combinações de teclas para reinicializar o
ra Pe
c) Correção a) Inteligibilidade
Os programas e dados devem corresponder a todas Convém que as perguntas, mensagens e resultados
as declarações contidas na descrição de produto e dos programas sejam inteligíveis, por exemplo:
na documentação de usuário. As funções devem ser
executadas de maneira correta para a realização de - por uma seleção adequada de termos;
uma tarefa. Em particular, programas e dados devem
estar de acordo com todos os requisitos definidos
Lice
crição de produto.
- pelo fornecimento de informações básicas que
facilitem o entendimento;
de
d) Consistência
uso
Os programas e dados não devem conter contra- - pelas explicações dadas por uma função de
auxílio (Help).
excl
que cada termo tenha um significado único em toda As mensagens de erro devem fornecer informações
a documentação. detalhadas, explicando a sua causa ou forma de
a pa
um número ou texto.
O sistema, compreendendo hardware e software, bem
como os programas que pertencem ao produto, não deve Deve ser sempre possível ao usuário, quando estiver
entrar em um estado no qual o usuário não consiga trabalhando com os programas, descobrir qual
controlá-lo, nem deve corromper ou perder dados. função está sendo executada.
NBR ISO/IEC 12119:1998 7
.A.
projetadas de forma que o usuário possa diferenciá- conformidade com as declarações de portabilidade cita-
las facilmente pelo tipo, por exemplo:
rás S
das em sua descrição.
trob
- solicitações; As instruções contidas nas subseções 4.1 a 4.5 espe-
ra Pe
cificam como um produto deve ser testado em relação
- advertências; aos requisitos de qualidade. Elas incluem tanto o teste
a pa
das propriedades necessárias a todos os produtos de
mesmo tipo, quanto o teste das propriedades especi-
usiv
- mensagens de erro.
ficadas na descrição do produto. Também estão incluídos
excl
Convém que os formatos de tela de entrada, de re- o teste por inspeção dos documentos e o teste caixa-
latórios e de outras entradas e saídas sejam proje- preta.
uso
tados para serem claros e com boa apresentação
e organização. Algumas alternativas poderiam ser: Estas instruções descrevem o teste funcional (teste caixa-
de
preta). O teste estrutural não está incluído porque requer
a disponibilidade do código-fonte.
nça
- campos alfanuméricos sejam alinhados pela
esquerda;
- limites dos campos sejam reconhecíveis; 1 Estas instruções são primeiramente direcionadas para o teste
de terceira parte, de acordo com algum esquema de certificação
- campos obrigatórios sejam reconhecíveis como (ver 1.c). Durante a produção pode ser mais barato ou mais
tal; eficaz usar teste estrutural.
- na detecção de falhas de entrada, as mesmas 2 A seção 4 não contém requisitos sobre pacotes de software
sejam imediatamente realçadas na tela; (todos eles estão contidos na seção 3). Um pacote de software
pode estar conforme, sem ter sido testado em concordância
- quando ocorrer uma mudança no conteúdo da com a seção 4, e tal teste pode ser incapaz de identificar uma
tela, o usuário seja alertado por um sinal auditivo não-conformidade existente.
ou visual.
.A.
c) Operacionalidade
com o respectivo ambiente é tratado como uma não-con-
A execução de funções que têm conseqüências formidade do produto.
trob
mando. Em particular, o processo de apagar dados 5 As orientações sobre avaliação ergonômica estão contidas
ou sobrepô-los, bem como de interromper um pro- na ISO 9241-11.
usiv
A descrição de produto, a documentação de usuário, os Os guias de teste devem ser construídos metódica e
programas e quaisquer dados a serem fornecidos como sistematicamente.
nça
- convém que sejam testados com relação à mas os testes não devem se restringir a estes exemplos.
conformidade com as recomendações da seção 3.
usiv
sistência, etc.).
a) Instalação
Se outros produtos forem mencionados na descrição de
trob
produto, eles só precisam ser testados para as exigências Se, de acordo com a descrição de produto, a ins-
rás S
feitas na descrição do produto submetido a teste. talação puder ser feita pelo usuário, deve ser testado
se os programas podem ser instalados e testados
Os detalhes na descrição de produto, na documentação
.A.
Os detalhes que não forem testados devem ser mencio- Os guias de teste devem cobrir todas as funções
nados nos registros e relatório de teste. As razões para descritas na descrição de produto e na documen-
não testá-los devem ser documentadas nos registros de tação de usuário e devem considerar as combina-
teste. ções de funções que são representativas para a ta-
refa.
4.2.1 Descrição de produto
Os programas devem ser testados para todos os
Deve ser verificada quanto ao cumprimento dos requisitos valores-limite (de acordo com a descrição de produto
e a documentação de usuário) para seus requisitos
Lice
aplicam.
4.2.2 Documentação de usuário
de
Deve ser verificada quanto ao cumprimento dos requisitos explicitamente desaprovadas ou declaradas como
da seção 3 e convém que seja verificada quanto ao cum- proibidas na documentação de usuário (ver 3.3.2)
excl
Devem ser testados quanto ao cumprimento dos requi- Os registros para cada teste devem conter informação
sitos da seção 3 e convém que sejam testados quanto ao suficiente para permitir a repetição do teste
ra Pe
cumprimento das recomendações da seção 3. (ABNT ISO/IEC Guia 25). Eles devem incluir:
trob
Os programas devem ser testados em todos os ambientes - um plano de teste ou especificação de teste conten-
de hardware e software especificados na descrição de do guias de teste (cada guia de teste estabelecendo
rás S
Se existirem diversas variantes do programa, cada uma - todos os resultados associados com os guias de
delas deve ser testada. As funções que, de acordo com a teste, incluindo todas as falhas que ocorreram du-
descrição de produto e documentação de usuário, são rante o teste;
idênticas para um grupo de variantes, podem ser testadas
cada uma em uma variante. - a identificação do pessoal envolvido no teste.
NBR ISO/IEC 12119:1998 9
4.4 Relatório de teste número total de páginas devem aparecer em cada página
do relatório de teste.
Os objetos e resultados do teste (como relatado nos re-
gistros de teste) devem ser resumidos em um relatório de O relatório de teste deve incluir:
teste, que deve ter a seguinte estrutura:
- uma declaração indicando que os resultados de
1 Identificação do produto; teste se referem somente aos itens testados;
.A.
2 Sistemas computacionais usados para o teste - uma declaração de que o relatório de teste não
(hardware, software e suas configurações);
rás S
deve ser parcialmente reproduzido, a menos que
haja a aprovação por escrito do laboratório de teste
3 Documentos usados (com suas identificações);
trob
(ABNT ISO/IEC Guia 25).
ra Pe
4 Resultados dos testes de descrição de produto,
Convém que o relatório de teste esteja de acordo com as
documentação de usuário, programas e dados;
orientações para relatórios de teste que constam no
a pa
ABNT ISO/IEC - Guia 25.
5 Lista das não-conformidades aos requisitos;
usiv
4.5 Teste de acompanhamento
6 Uma lista das não-conformidades em relação às
excl
recomendações, ou uma lista das recomendações
que não foram seguidas, ou uma declaração de que Quando um produto, que já foi testado, é testado nova-
uso
o produto não foi testado quanto à conformidade em mente (levando-se em consideração o teste anterior),
relação às recomendações; então:
de
nça
7 Data do encerramento do teste. - todas as partes modificadas nos documentos,
funções e dados devem ser testadas como se fossem
A seção 4 do relatório de teste (Resultados do teste) deve Lice
um novo produto;
conter uma declaração correspondente a cada subseção
de 3.1 a 4.2. - todas as partes inalteradas com possibilidade de
serem influenciadas pelas partes alteradas ou por
Além da declaração de que o produto não foi testado modificação nos requisitos de hardware e software
quanto à conformidade em relação às recomendações, (de acordo com o conhecimento especializado do
a seção 6 do relatório de teste pode fornecer uma lista responsável pelo teste) devem ser testadas como se
das não-conformidades observadas em relação às reco- fossem um novo produto;
mendações.
- todas as outras partes devem ser testadas, con-
A identificação do relatório de teste (laboratório de teste, siderando-se, pelo menos, casos de testes com se-
identificação do produto, data do relatório de teste) e o leção por amostragem.
/ANEXOS
.A.
rás S
trob
ra Pe
a pa
usiv
excl
deuso
nça
Lice
10 NBR ISO/IEC 12119:1998
Anexo A (informativo)
Definições de outras normas
Definições de alguns termos utilizados nesta Norma, mas A.2.2 Confiabilidade: Conjunto de atributos que eviden-
definidos em outras normas, são citadas aqui para facili- ciam a capacidade do software de manter seu nível de
tar a referência. No momento da publicação da desempenho sob condições estabelecidas durante um
ISO/IEC 12119:1994, as edições indicadas eram válidas período de tempo estabelecido. [ISO/IEC 9126:1991, sem
Lice
cumentado de programas fornecido a diversos usuá- software e a quantidade de recursos usados, sob con-
rios para uma aplicação ou função genérica. dições estabelecidas. [ISO/IEC 9126:1991, sem a nota]
ra Pe
A.1.3 Software de sistema: Software independente da denciam o esforço necessário para fazer modificações
aplicação que suporta a execução de um software apli- especificadas no software. [ISO/IEC 9126:1991, sem a
rás S
A.1.4 Rotina utilitária, programa utilitário: Rotina (um A.2.6 Portabilidade: Conjunto de atributos que eviden-
programa computacional) que fornece serviços gerais, ciam a capacidade do software ser transferido de um am-
freqüentemente necessários. biente para outro. [ISO/IEC 9126:1991, sem a nota]
A.1.7 Interface: Limite compartilhado entre duas uni- produto, processo ou serviço, de acordo com um procedi-
dades funcionais, definido por características funcionais, mento especificado. [ABNT ISO/IEC Guia 2:1991]
nça
ticas de sinal, e outras características, quando apropriado. A.4.2 Dados de teste: Dados utilizados em um problema
[ISO/IEC 2382-9:1984, sem a nota] de teste. [ISO 2382-8:1986]
uso
componentes de hardware ou de software de um sistema nal está operando corretamente. [ISO 2382-8:1983]
computacional. [ANSI/IEEE Std 610.12-1990]
a pa
.A.
requisitos. [ISO/IEC 2382-20:1990]
rás S
trob
/ANEXO B
ra Pe
a pa
usiv
excl
uso
de
nça
Lice
.A.
rás S
trob
ra Pe
a pa
usiv
excl
uso
de
nça
Lice
12 NBR ISO/IEC 12119:1998
Anexo B (informativo)
Exemplo de uma descrição de produto
O exemplo seguinte descreve, de acordo com esta Nor- Alguns detalhes técnicos:
ma, um pacote de software simples e fictício, com o obje-
tivo de mostrar as informações que devem estar presentes - O FIREatWORK pode ser executado em um com-
em toda descrição de produto. putador pessoal Quince Hardcore 119xi e em
Lice
utilização de senha.
- O FiREatWORK necessita de placa gráfica Her-
usiv
tela será iniciada quando você deixar de pressionar algu- - se você deseja a variante para o sistema B.I.T.S. ou
ma tecla e de mover o mouse por um período de tempo para o Gnome;
passível de ajuste. Ela será desativada tão logo você
pressione alguma tecla ou mova o mouse. Contudo, se - se você deseja um FIREatWORK em disquete de
você tiver definido uma senha, o FIREatWORK esperará 3 1/2 ou 5 1/4 polegadas.
que ela seja digitada.
O pacote consiste no programa (módulo de carga) em
Você pode definir sua configuração favorita quanto ao: um disquete e um livrete de documentação, o qual inclui
o guia de instalação.
- tempo que o FIREatWORK esperará para acionar a
É importante saber que:
proteção (1 a 999 minutos, ou não aciona);
- não é necessário qualquer conhecimento especial
- número de fogos de artifício que explodirão em para instalar ou usar o FIREatWORK;
conjunto (1 a 19).
- as mensagens do programa e a documentação
Para tanto, o FIREatWORK usará linha de comando, ou estão escritas em português;
janela, da mesma forma que seu sistema operacional faz
Lice
/ANEXO C
.A.
NBR ISO/IEC 12119:1998 13
Anexo C (informativo)
Bibliografia
ABNT ISO/IEC Guia 2:1998, Normalização e atividades ISO 2382-14:1978, Data processing - Vocabulary -
relacionadas - Vocabulário geral. Part 14: Reliability, maintenance and availability.
ABNT ISO/IEC Guia 16:1978, Códigos de princípios para ISO 2382-15:1985, Data processing - Vocabulary -
sistemas de certificação por terceira parte e normas re- Part 15: Programming languages.
.A.
lacionadas1).
rás S
ISO 2382-20:1990, Data processing - Vocabulary -
Part 20: System development.
ABNT ISO/IEC Guia 22:1998, Critérios gerais para a de-
trob
claração de conformidade pelo fornecedor. ISO 6385:1981, Ergonomic principles of the design of
ra Pe
work systems.
NOTA - Esta declaração é chamada atualmente de “supplier’s
ISO 6592:1985, Information processing systems
a pa
declaration”. (ABNT ISO/IEC Guia 2:1998).
Guidelines for the documentation of computer-based
usiv
ABNT ISO/IEC Guia 23:1993, Métodos de indicação de application systems.
conformidade com normas para sistemas de certificação
excl
por terceira parte. ISO 9127:1988, Information processing systems, User
documentation and cover information for consumer
uso
software packages.
ABNT ISO/IEC Guia 25:1993, Requisitos gerais para a
de
capacitação de laboratórios de calibração e de ensaios. ISO 9241-1:1992, Visual display terminals (VDTs) used
nça
for office tasks - Ergonomic requirements - Part 1:
ABNT ISO/IEC Guia 28:1993, Regras gerais para um General introduction.
modelo de sistema de certificação de produtos por Lice
terceira parte. ISO 9241-2:1992, Visual display terminals (VDTs) used
for office tasks - Ergonomic requirements - Task require-
ABNT ISO/IEC Guia 40:19932), Requisitos gerais para ments.
aceitação de organismos de certificação.
ISO DIS 9241-10,3) Ergonomic requirements for office work
with visual display terminals (VDT)s - Dialogue
ABNT ISO/IEC Guia 44:1993, Regras gerais para es- principles.
quema de certificação internacional ISO ou IEC de pro-
dutos por terceira parte. ISO CD 9241-11,3) Ergonomic requirements for office work
with visual display terminals (VDT)s - Guidance on us-
ABNT ISO/IEC Guia 58:1993, Sistemas de creden- ability.
ciamento de laboratórios de calibração e ensaios -
Requisitos gerais para operação e reconhecimento. ISO CD 9241-12,3) Ergonomic requirements for office work
with visual display terminals (VDT)s - Presentation of in-
NBR ISO 8402:1994, Gestão da qualidade e garantia da formation.
qualidade - Terminologia.
.A.
ISO 2382-02:1976, Data processing - Vocabulary with visual display terminals (VDT)s - Menu dialogues.
arithmetic and logic operations.
a pa
ISO 2382-10:1979, Data processing - Vocabulary - ANSI/IEEE Std 610.12-1990, Glossary of software
nça
1)
Cancelado e substituído pelo ABNT ISO/IEC Guia 60.
2)
Cancelado e substituído pelo ABNT ISO/IEC Guia 65.
3)
A ser publicada.