35

C
o
n
t
r
o
l
e

d
e

C
o
n
t
a
m
i
n
a

o

1
2
7
N o v e m b r o 2 0 0 9
GAMP
URS (ESPECIFICAES DE
REQUERIMENTOS DO USURIO)
PARA SISTEMAS COMPUTADORIZADOS
* GTC - Como preparar uma URS (ISPE)
1. INTRODUO
A URS (User requirements Spe-
cifcation) ou (Especifcao de Re-
querimentos do Usurio), no con-
texto de Ciclo de Vida de Sistemas
Computadorizados uma etapa
muito importante para o sucesso de
um projeto de automao e/ou in-
formatizao de um processo, pois
quando descrito de forma clara e
precisa, possibilita a escolha do me-
lhor Fornecedor, produo de uma
Especifcao Funcional detalhada e
precisa, produo da Especifcao
de Projeto, referencia para Anlise
de Riscos, possibilitando a avaliao
do maior nmero possvel de proba-
bilidade de falha, confgurao do
sistema, reduo de custo posterior
ao projeto, entre outras utilidades.
Como podemos ver, a URS tem
um papel muito importante para Va-
lidao dos sistemas Computadori-
zados, desta forma observamos que a
produo de uma documentao to
importante e que pode mudar total-
mente o custo e escopo do seu proje-
to, no pode ser descrita de qualquer
forma ou por um s usurio, preci-
so uma equipe multidisciplinar para
que todas as necessidades (Hardwa-
re, Software, infra-estrutura, parti-
cularidades do projeto), sejam iden-
tifcadas e descritas.
Requisitos mal elaborados sero
no futuro necessidade de mais in-
vestimento, disponibilidade de pro-
fssionais para acompanhamento
das adequaes e transtornos caso
no seja possvel atender a algum re-
quisito descrito de forma incorreta.
Nesta fase devemos ser caute-
losos e nos atentarmos as nossas
necessidades reais, pois uma URS
bem elabora, reduz custo e tempo
de projeto e confiabilidade dos
testes.
2. OBJETIVO
O objetivo deste material ins-
truir os profssionais dos segui-
mentos Farmacuticos, Cosmticos,
Veterinrios e Alimentcios, quanto
elaborao da URS para sistemas
computadorizados.
3. ESCOPO
Este procedimento pode ser usado
por, ou no interesse de usurios de
empresas para defnir a URS para
um sistema computadorizado. Esta
URS orientar o fornecedor sobre o
que o sistema dever fazer e como
ele dever ser fornecido. Servir
tambm como base para a criao
de critrios de aceitao para os Tes-
tes Requerimentos (ou Qualifcao
de Desempenho).
4. PROCEDIMENTO
4.1. Orientaes Gerais
Antes de iniciar a descrio dos
requisitos, muito importante que o
processo atual seja mapeado identi-
fcando qual o processo ser implan-
tado o sistema computadorizado,
objetivando identifcar as possveis
interfaces, particularidades do pro-
cesso, em quais pontos do processo
36
C
o
n
t
r
o
l
e

d
e

C
o
n
t
a
m
i
n
a

o

1
2
7
N o v e m b r o 2 0 0 9
GAMP - Gerenciamento da Calibrao
sero implantados o sistema.
recomendvel que os requisitos
tcnicos e operacionais sejam des-
critos separadamente no mesmo do-
cumento, possibilitando a identifca-
o e reviso das informaes com
mais clareza.
Descrever a classifcao dos re-
quisitos para que seja possvel iden-
tifcar se o mesmo :
- Informativo: no exatamente
um requisito e sim uma informao
que ser dada aos fornecedores para
auxili-los na elaborao de suas
propostas;
- Construo: requisito que obri-
gatoriamente ser verifcado durante
o comissionamento do item requeri-
do (equipamento, sistema ou rea),
mas que no ser, necessariamente,
avaliado durante a qualifcao des-
se item;
- Regulatrio: requisito que no
necessariamente ser avaliado du-
rante o comissionamento, mas ser,
obrigatoriamente, avaliado durante a
qualifcao do item requerido;
- Desejado: requisito que se deseja
na construo de um determinado
projeto (equipamento, sistema ou
rea) mas que poder no ser for-
necido pelo fornecedor ou mesmo
desconsiderado se acarretar custos
demasiados ou mesmo difculdade
tcnicas para atend-lo.
Uma URS defne, clara e preci-
samente, o que os usurios dese-
jam que o sistema faa. Ele defne
as funes a serem executados, os
dados com os quais o sistema ir
operar, e o ambiente de operao.
A URS defne tambm quaisquer
requerimentos no funcionais, limi-
taes, tais como tempo e custos e o
que ser fornecido. A nfase dever
ser nas funes requeridas e no nos
mtodos de implementao destas
funes.
Dependendo de como o usurio
defne o sistema, dever ser men-
cionado na URS a que normas e/ou
guias o sistema dever seguir para
atender as sua necessidades.
A URS dever se referir e inter-
pretar as normas GxP relevantes,
como apoio para o time de projeto e
para o fornecedor, de forma a desen-
volver um sistema de acordo com os
requerimentos GxP.
As seguintes orientaes devero
ser seguidas durante a produo das
especifcaes:
- Cada requerimento deve ter um
nico nmero de referncia, para fa-
cilitar a rastreabilidade e a referncia
cruzada com outras especifcaes e
com os testes;
- Cada requerimento dever ser es-
pecifcado apenas uma nica vez e
deve ter no mximo 250 palavras;
- Os requerimentos no devero es-
tar duplicados;
- A URS dever expressar requeri-
mentos e no solues;
- Cada requerimento dever ser tes-
tado ou verifcvel de vrias formas;
- A URS dever ser entendida por
todos os usurios e fornecedores:
ambigidades e jarges devero ser
evitados;
- Os requerimentos devero ser prio-
rizados. A URS dever distinguir en-
tre requerimentos essenciais (uso dos
verbos deve ter, deve fazer, deve
atender) e os de caractersticas mera-
mente desejveis ( desejvel que).
4.2 Contedo do Documento
Esta seo defne quais sees e
sub-sees sero includas na URS.
Todas as sees e sub-sees estaro
presentes. Caso no haja requerimen-
tos especifcados em alguma seo
ou sub-seo, ento a seo ou sub-
seo dever ser anotada como no
aplicvel.
User Requeriments
specification
Especificao
funcional
Especificao de
projeto
Especificao de
mdulo
Codificao de
mdulos
Teste do mdulo
Teste de integrao
Teste funcional
Teste de
requerimento
V
e
r
i
f
i
c
a

o
E
s
p
e
c
i
f
i
c
a

o
FIGURA 1
37
C
o
n
t
r
o
l
e

d
e

C
o
n
t
a
m
i
n
a

o

1
2
7
N o v e m b r o 2 0 0 9
GAMP - Gerenciamento da Calibrao
4.2.1 Introduo
Esta seo dever conter as se-
guintes informaes:
- Quem produz o documento, sob qual
autoridade e para qual propsito;
- A situao contratual do docu-
mento;
- Relacionamento com outros docu-
mentos.
4.2.2 Viso Geral
Esta seo dever fornecer as
consideraes do sistema sobre o
porque dos requerimentos e o que
requerido e, dever conter ainda as
seguintes sub-sees:
- Estratgias e estudos prvios;
- Objetivos-chave;
- Benefcios;
- Funes principais e interfaces;
- Requerimentos GxP aplicveis;
- Outros requerimentos aplicveis;
- Normas a serem atendidas.
4.2.3 Requerimentos Operacionais
Esta seo ir declarar os requeri-
mentos operacionais:
- Funes do sistema;
- Dados;
- Interfaces;
- Ambiente no qual o sistema ir
operar.
Sero identifcadas as exigncias
crticas para a operao. Descrio
de processos ou fuxogramas devem
ser includos de modo a facilitar o
entendimento.
Algumas consideraes especiais
devero ser levadas em conta para os
requerimentos GxP, sendo que deve-
ro ser claramente defnidas com re-
ferncias para as normas relevantes,
sempre que possvel.
As seguintes sub-sees devero
ser includas:
Funes
Esta sub-seo ir defnir as se-
guintes informaes:
- Quais os processos de negcios re-
levantes, que sero suportados pelo
sistema;
- Funes requeridas;
- Informao sobre o processo ou so-
bre o sistema manual existente;
- Clculos, incluindo todos os algo-
ritmos crticos;
- Modos de operao (startup, shu-
tdown, testes, restaurao e recom-
posio de dados);
- Performance and timing requeri-
dos. Estes devero ser quantitativos
e no ambguo;
- Ao requerida em caso de falha
do sistema;
- Alarmes;
- Segurana;
- Garantia.
Dados
Esta sub-seo dever declarar os
dados a serem utilizados pelo siste-
ma. Devero constar as seguintes
informaes:
- Defnio dos dados, incluindo
identifcao dos parmetros crticos
e limites vlidos;
- Capacidade;
- Velocidade de acesso;
- Arquivamento;
- Segurana e integridade dos dados;
- Consideraes sobre o atendimen-
to aos requisitos de GxP ou outras
normas regulatrias aplicveis ao
sistema, bem como 21 CFR Part 11
(desejvel a ttulo de necessidades
futuras a atender regulamentao).
Interfaces
Esta sub-seo dever defnir to-
das as interfaces do sistema. Dever
conter as seguintes sub-sees:
- Interface com usurios: ser de-
fnida em termos de nveis de acesso
(operador do sistema, administrador
de dados, gerente do sistema) ou
funes especfcas;
- Interface com outros sistemas;
- Interface com equipamentos (sen-
sores, atuadores, por exemplo). In-
cluir tambm entradas e sadas para
o sistema de controle de processo.
Ambiente fsico
Esta sub-seo ir defnir o am-
biente fsico no qual o sistema de-
ver trabalhar. Conter as seguintes
sub-sees:
- Layout: layout fsico das insta-
laes ou outros locais de trabalho
que possam ter impacto no sistema,
como por exemplo links para outros
sistemas remotos ou limitao de es-
pao;
- Condies fsicas e ambientais
(sujeira, poeira ou ambientes est-
reis);
- Condies atmosfricas: se o
sistema ir trabalhar num ambiente
com gases infamveis, solues ci-
das/bsicas, etc;
- Infra-estrutura fsica: descrever
a infra-estrutura de redes, ambien-
tes e as devidas especifcaes para
atender aos requisitos.
Ambiente de Software e Hardware
Esta sub-seo ir defnir o am-
biente de software e hardware no
qual o sistema dever trabalhar.
Conter as seguintes sub-sees:
- Sistema Operacional: descrever
a especifcao mnima do sistema
operacional (e verso) sob o qual o
sistema a ser desenvolvido ir tra-
balhar;
- Atualizao do sistema operacio-
nal: impacto e formas de interao;
- Hardware necessrio: descrever
quais hardwares sero utilizados e
suas especifcaes mnimas.
4.2.4 Requerimentos no Operacionais
Esta seo ir descrever os reque-
rimentos no funcionais do sistema
automatizado, podendo conter, mas
no se limitando a:
- Treinamento;
- Documentao exigida;
- Manuteno do sistema;
- Atualizao de verses / correes
de defeitos e/ou falhas.
38
C
o
n
t
r
o
l
e

d
e

C
o
n
t
a
m
i
n
a

o

1
2
7
N o v e m b r o 2 0 0 9
GAMP - Gerenciamento da Calibrao
4.2.5 Restries
Esta seo defnir as restries
que devero constar nas especifca-
es do sistema.
- Cronograma e marcos apropriados;
- Compatibilidade: dever levar em
conta quaisquer sistemas ou hardwa-
re existentes e as estratgias e polti-
ca da empresa;
- Disponibilidade: dever mostrar
os requerimentos de recuperao e
defnir perodos de disponibilidade
mxima para a manuteno ou o
tempo ocioso;
- Limitaes dos procedimentos
como obrigaes estatutrias, as-
suntos legais, mtodos de trabalho e
nvel de habilidade dos usurios;
- Manuteno, incluindo facilidade
de manuteno, capacidade de ex-
panso, avanos, expectativa de vida
e suporte.
4.2.6 Ciclo de Vida
Esta seo defnir quaisquer re-
querimentos referentes ao ciclo de
vida do desenvolvimento. Ele ir
conter as seguintes sub-sees:
- Desenvolvimento (padres mni-
mos a serem aplicados metodolo-
gia do fornecedor, procedimentos
para gerenciamento do projeto e
garantia de qualidade, mtodos de
projeto obrigatrios);
- Testes (requerimentos especiais para
testes, teste de dados, testes de carre-
gamento e simulaes requeridas);
- Entrega: esta seo defnir como
e porque meios sero entregues as
etapas contratuais. Dever indicar o
seguinte:
- Como ser a identifcao dos itens
a serem entregues;
- Como ser entregue (formato e tipo
de mdia);
- Quais documentos sero entregues
pelo fornecedor (especifcao fun-
cional, especifcaes de teste e es-
pecifcao de projeto);
- Quais dados sero preparados ou
convertidos;
- Ferramentas a serem utilizadas;
- Cursos e Treinamentos a serem
efetuados;
- Facilidades de arquivamento;
- Suporte: Esta sub-seo ir defnir
que suportes sero necessrios aps
a aceitao do sistema.
Como exemplo de Ciclo de Vida,
mostramos o diagrama em V (f-
gura 1), aplicado para um Software
Categoria 5 (ver item 4.2.8), este por
sua vez o mais completo de todos.
4.2.7 Normas, Regulamentos, Guias
Esta seo dever conter defni-
es sobre as normas, regulamentos
e guias que o fornecedor dever se-
guir para poder desenvolver o siste-
ma e entregar um sistema completo,
testado e com todas as documenta-
es necessrias para uma valida-
o posterior.
4.2.8 Categoria de Software
e Hardware
Esta seo dever conter as def-
nies tanto para o hardware como
para o software no que se refere a
categoria que o sistema est inclu-
da. No caso se for seguido o guia
do GAMP5 o hardware poder ser
classifcado como categoria 1 a 2 e
o software poder ser classifcado
como catagoria 1 a 5. Lembrando
que a na nova verso do GAMP5 a
categoria 2 para software foi elimi-
nada.
4.2.9 Glossrio
Esta seo dever conter defni-
es de quaisquer termos que no
sejam comuns aos leitores deste do-
cumento e/ou termos tcnicos utili-
zados.
4.2.10 Aprovaes
Esta seo dever listar os res-
ponsveis tanto do lado do cliente
como do fornecedor para a apro-
vao do documento elaborado.
A aprovao deve conter data e
assinatura dos responsveis. ne-
cessrio que exista um campo para
o elaborador do documento, um
campo para o revisor do documen-
to e um (ou mais) campo(s) para a
aprovao do documento.
* GTG Como Preparar uma
URS (ISPE)
Coordenador do Grupo:
Nicols Cosentino Giltec
Integrantes do Grupo:
Jos Augusto de Souza Arajo
Engenews
Alessandro Pdua Stiefel
Kleber Costa - Cristlia
Marcelo Decanio de Oliveira
Boehringer Ingelheim
Ivan Antonio Canever Inca
Consultoria e Qualidade
Bibliograa
GAMP5 A Risk-Based Approach to Compliant GxP Computerized
Systems (ISPE)
999-V90-001 URS para Sistemas Computadorizados (Giltec)