UNIVERSIDADE DO EXTREMO SUL CATARINENSE – UNESC
CURSO DE ESPECIALIZAÇÃO EM GERENCIAMENTO DE BANCO DE DADOS
GIANA DA SILVA BERNARDINO
DEFINIÇÃO DOS REQUISITOS DE UM SOFTWARE PARA UM
SISTEMA DE GESTÃO DA QUALIDADE APOIADA PELA
ENGENHARIA DE REQUISITOS
CRICIÚMA (SC), JUNHO DE 2005.
GIANA DA SILVA BERNARDINO
DEFINIÇÃO DOS REQUISITOS DE UM SOFTWARE PARA UM
SISTEMA DE GESTÃO DA QUALIDADE APOIADA PELA
ENGENHARIA DE REQUISITOS
Monografia apresentada à Diretoria de PósGraduação da Universidade do Extremo Sul
Catarinense - UNESC, para a obtenção do
título de especialista em Gerenciamento de
Banco de Dados.
Orientador: Profª. MSc. Ana Claudia Garcia
Barbosa.
CRICIÚMA (SC), JUNHO DE 2005.
Aos meus pais, meu irmão e meu amor, com
carinho.
AGRADECIMENTOS
Agradeço a orientadora, Professora MSc. Ana Claudia Garcia Barbosa,
por seu auxílio nesta etapa.
A empresa que permitiu divulgar as informações necessárias para
aplicação deste estudo.
A Coordenadora da Qualidade, por sua atenção e tempo dedicado ao
auxílio no desenvolvimento deste estudo.
Aos colegas de trabalho, pela paciência, compreensão e apoio constante
nesta etapa.
A todas as pessoas que de alguma maneira contribuíram e estiveram ao
meu lado nesta caminhada.
RESUMO
A Engenharia de Requisitos tem por objetivo tratar o processo de definição dos
requisitos de software, entender quais são as reais necessidades, bem como a
documentação dos mesmos. Com a crescente evolução desta área, este trabalho
vem auxiliar no entendimento e definição dos métodos e técnicas que facilitam as
tarefas de elicitação, verificação e análise de requisitos. Apresenta um estudo de
caso de uma ferramenta para o apoio no processo de definição dos requisitos para o
desenvolvimento de um software na área de Gestão da Qualidade, sendo abordado
somente o módulo de Gestão de Documentos. O apoio de uma ferramenta nesta
etapa de definição dos requisitos se faz necessário, pois a complexidade dos
sistemas atuais exige que se preste maior atenção ao correto entendimento do
problema antes do comprometimento de uma solução.
Palavras-chave: Engenharia de Requisitos. Desenvolvimento de software. Gestão
da qualidade.
LISTA DE ILUSTRAÇÕES
Figura 1 – Regras do Léxico Ampliado da Linguagem .......................................... 39
Figura 2 – Interface principal da ferramenta .......................................................... 40
Figura 3 – Visualização do cenário na ferramenta ................................................ 41
Figura 4 – Visualização de um termo do léxico na ferramenta .............................. 45
Figura 5 – Visualização do XML formatado ........................................................... 46
Figura 6 – Visualização de um conceito da ontologia ............................................ 47
SUMÁRIO
1. INTRODUÇÃO ................................................................................................... 09
2 ENGENHARIA DE REQUISITOS ....................................................................... 11
2.1 Definição ......................................................................................................... 12
2.2 Requisitos ....................................................................................................... 14
2.3 Fases da Engenharia de Requisitos ............................................................ 15
2.3.1 Elicitação de Requisitos ............................................................................. 16
2.3.1.1 Técnicas de Elicitação de Requisitos .................................................... 17
2.3.2 Análise de Requisitos ................................................................................. 20
2.3.3 Especificação de Requisitos ..................................................................... 20
2.3.4 Verificação de Requisitos .......................................................................... 21
2.3.5 Gerenciamento de Requisitos ................................................................... 21
2.4 Propriedades de um Método de Engenharia de Requisitos ...................... 22
3. SISTEMA DE GESTÃO DA QUALIDADE ........................................................ 24
3.1 Definição ......................................................................................................... 24
3.2 As Normas ISO ............................................................................................... 25
3.3 Automatização do Sistema de Gestão da Qualidade ................................. 26
4. DEFINIÇÃO DOS REQUISITOS DO SOFTWARE ........................................... 29
4.1 Procedimentos Metodológicos ..................................................................... 29
4.2 Descrição do Sistema a ser Automatizado ................................................. 30
4.3 Ferramenta e Técnica Utilizada no Estudo de Caso ................................... 36
4.3.1 Cenários e Léxicos ..................................................................................... 37
4.3.2 Funcionalidades da Ferramenta ................................................................ 39
4.4 Aplicação da Ferramenta e Técnica ............................................................. 42
4.5 Análise dos Resultados ................................................................................ 47
5. CONSIDERAÇÕES FINAIS .............................................................................. 49
REFERÊNCIAS ..................................................................................................... 52
APÊNDICE ............................................................................................................ 56
APÊNDICE A – Quadros dos cenários obtidos na ferramenta C&L ............... 56
APÊNDICE B – Quadros dos léxicos identificados na ferramenta C&L ........ 59
APÊNDICE C – XML do projeto gerado através da ferramenta C&L ............... 61
9
1. INTRODUÇÃO
O ambiente de desenvolvimento de software tem sofrido algumas
alterações na última década. Com o avanço da tecnologia e a construção de
computadores
cada
vez mais poderosos,
um
grande
desafio
surgiu
ao
desenvolvimento de software, estes passaram a absorver cada vez mais
complexidade do mundo real. Estas alterações têm estado na contra-mão da grande
preocupação da indústria de software atual, pois, melhor será o sistema que
conseguir se aproximar e reproduzir o mundo real com qualidade.
A crescente complexidade das aplicações, maior grau de exigência em
relação à qualidade e os prazos restritos requerem o desenvolvimento de técnicas
adequadas. A necessidade de se encontrar métodos que pudessem ajudar na
evolução
do
processo
de
construção
de
software,
culminaram
com
o
desenvolvimento da Engenharia de Software. Entender as necessidades e atender
os desejos dos clientes sempre foi colocado como um dos maiores desafios da
Engenharia de Software.
Neste intuito, a área de Engenharia de Requisitos tem recebido grande
atenção, buscando atender às novas necessidades do usuário e facilitar a execução
das etapas posteriores do processo de engenharia através da definição de
ferramentas e procedimentos corretos.
A postura da Engenharia de Requisitos é a de prover ao analista,
métodos que auxiliem o processo de compreensão e registro dos requisitos que o
software deve atender. Uma compreensão completa dos requisitos do software é
fundamental para um bem sucedido desenvolvimento. Não importa o quanto foi bem
10
projetado ou quanto foi bem codificado, um programa mal analisado e especificado
desapontará o usuário e trará aborrecimentos ao analista.
Para os analistas a grande dificuldade está em entender o problema do
cliente ou usuário, o que ele precisa, o que deseja do software, com a adoção de
métodos, técnicas e ferramentas a elicitação1 das informações necessárias para o
desenvolvimento de software ficará de uma forma mais objetiva, organizada, precisa
e completa.
O principal objetivo deste projeto é desenvolver uma pesquisa na área de
Engenharia de Requisitos, abordando os conceitos atuais. Com base no
levantamento teórico serão avaliadas ferramentas que apóiam esta área, que seja
adequada à realidade das empresas e empregue as técnicas disponíveis no
desenvolvimento de um software para Sistema de Gestão da Qualidade, de forma a
reduzir custos com erros e otimizar o tempo no projeto de desenvolvimento.
O estudo de caso desenvolve-se aplicando uma ferramenta da área de
engenharia de requisitos no desenvolvimento de um software de Sistema de Gestão
da Qualidade, abordando somente a necessidade de desenvolvimento, em primeiro
momento, do módulo de Gestão de Documentos. No segundo capítulo defini-se
Engenharia de Requisitos, abordando os conceitos, as fases e técnicas. O terceiro
capítulo descreve o que é um Sistema de Gestão da Qualidade e sua finalidade,
abordando a necessidade de automatização do mesmo. No quarto capítulo
apresenta-se o estudo de caso, descrevendo o processo atual da Gestão de
Documentos de uma organização, apresentando ferramenta e técnica aplicada, suas
principais funcionalidades, as informações geradas a partir da ferramenta e análise
do resultado.
1
A palavra elicitação vem do inglês elicitation, que significa descobrir algo obscuro.
11
2. ENGENHARIA DE REQUISITOS
A Engenharia de Requisitos vem sendo reconhecida por muitos anos. O
interesse crescente pelo estudo de formas de melhorar a definição de softwares
levou a criação de conferências, simpósios, e seminários que são organizados e
assistidos por Engenheiros de Software, Engenheiros de Sistemas e Engenheiros de
Requisitos.
A Engenharia de Requisitos é uma das etapas mais difíceis e arriscadas
da Engenharia de Software. As conseqüências do desenvolvimento inadequado da
atividade de definição dos requisitos consistem em produção de softwares que não
atendem às necessidades dos usuários, aumento de custos, realização de
atividades desnecessárias ou até mesmo duplicadas, usuários insatisfeitos e,
conseqüentemente, desentendimento com os analistas, além do aumento
considerável da tarefa de manutenção do software.
Entretanto este processo nem sempre acontece de maneira formal,
baseado em técnicas. Em muitas empresas o processo de desenvolvimento começa
de um entendimento verbal entre usuários e analistas, a partir deste entendimento,
todo o trabalho que se faz antes da implementação em computador é extremamente
indiferente, no sentido de que não há muita documentação que possa comprová-lo,
algo que pode ser utilizado posteriormente pelos que trabalharam no processo de
desenvolvimento ou por outras pessoas.
No Brasil existem vários pesquisadores e profissionais interessados no
assunto, ao longo desses anos foram desenvolvidos artigos, trabalhos, workshops,
conferências e simpósios. Ferramentas para este processo e até mesmo o
12
conhecimento específico e detalhado da Engenharia de Requisitos são de difícil
utilização por parte dos analistas, o que faz necessário um estudo desta área que
vem sendo explorada há alguns anos com projetos de pesquisas e desde então tem
atraído grande atenção, tanto da academia como da indústria, com novos métodos,
técnicas e ferramentas.
2.1 Definição
Dentro da Engenharia de Software é a Engenharia de Requisitos que
procura atacar uma parte fundamental no processo de produção de softwares, que é
a definição do que se quer produzir. Um dos aspectos mais importantes é considerar
todas as pessoas envolvidas com o futuro software, usuário, analista e/ou
desenvolvedor, envolvê-los no processo de desenvolvimento é fundamental na
obtenção de todo universo de informações que abrange o sistema.
Muitas definições podem ser encontradas para a Engenharia de
Requisitos, dentre estas, Belgamo (2000, p. 6) define como “[...] a primeira etapa
dentro de todo o processo da engenharia de software, a qual estuda como coletar,
entender, armazenar, verificar e gerenciar os requisitos”.
A principal preocupação na Engenharia de Requisitos é entender quais
são os reais requisitos do software, bem como a documentação dos mesmos, para
Sommerville (2003, p. 103), “Engenharia de Requisitos é um processo que envolve
todas as atividades exigidas para criar e manter o documento de requisitos de
sistema”.
Por ter como objetivo tratar o processo de definição dos requisitos de
software e ter muito em comum com a análise de sistemas, Kotonya (2001a, p. 1)
13
define, “Uso de técnicas sistemáticas e repetíveis para garantir que os requisitos do
sistema estejam completos, consistentes, etc.”
Para Lopes (1999a, p. 2) a análise da Engenharia de Requisitos é
desenvolvida sob os pontos de vista do analista e do usuário.
A fase de engenharia de requisitos é fundamental no processo de
desenvolvimento de sistemas. Do ponto de vista do analista é o
instrumento que define a fronteira entre os processos do domínio e aqueles
que serão automatizados pelo futuro sistema. Do ponto de vista do usuário,
ajuda a entender seus processos, suas necessidades e a identificar de que
modo elas podem ser satisfeitas numa solução informatizada.
O conceito de Engenharia de Requisitos vem mudando ao longo do
tempo, ganhando cada vez mais importância como uma fase crucial no
desenvolvimento de software por tratar de conhecimentos não apenas técnicos, mas
também gerenciais, organizacionais, econômicos e sociais, e esta intimamente
associada à qualidade de software, (ROCCO, 2004, p. 3). As atividades desta área
vão desde a idéia de desenvolver um sistema de software até a modelagem
conceitual do que se vai construir.
Em geral, a Engenharia de Requisitos consiste em desenvolver as
especificações de um software de maneira a atender as necessidades dos usuários
e restrições do domínio da aplicação. Tem por objetivo tratar o processo de definição
dos requisitos de software. Para isso estabelece um processo no qual o que deve
ser feito é elicitado, modelado e analisado. Este processo deve lidar com diferentes
pontos de vista e propor métodos que promovam o desenvolvimento do documento
de requisitos para que este produto esteja em conformidade com as necessidades
dos usuários e aos padrões de qualidade, relacionado ao que se quer produzir com
tecnologia da informação para solução de problemas ou como oportunidade de
negócio.
14
2.2 Requisitos
O levantamento de requisitos é uma atividade intensiva quanto à
comunicação. Segundo Lopes (2002, p.14), é de fundamental importância
entendermos exatamente o que são requisitos de um software, para entendermos a
disciplina de Engenharia de Requisitos. “[...] requisitos são as funções que deverão
ser
incorporadas
pelo
software,
quando
inserido
em
seu
contexto
de
funcionamento”.
A fase de definição dos requisitos se constitui na fase crítica do ciclo de
vida de um software, pois uma compreensão completa dos requisitos de software é
fundamental para um bem-sucedido desenvolvimento do mesmo, uma vez que os
requisitos formam a base para o planejamento, o acompanhamento do
desenvolvimento, e a aceitação dos resultados do projeto.
Belgamo (2000, p. 6) destaca que “[...] requisitos são necessidades
coletadas de clientes e usuários para sabermos 'o quê' o sistema a ser idealizado
fará, sem se preocupar por enquanto, 'como' este será criado”.
Requisitos de um software definem os serviços que o software deve
oferecer e as restrições aplicáveis à sua operação, são em geral descritos de forma
textual e sua especificação depende de diversos fatores, entre eles da pessoa que
está escrevendo os requisitos, das pessoas para quem os requisitos estão sendo
escritos, das práticas gerais da organização que está desenvolvendo os requisitos e
do domínio de aplicação do sistema.
Os requisitos caracterizam-se sob duas formas fundamentais: requisitos
funcionais e requisitos não funcionais. O primeiro está diretamente ligado a
funcionalidade do software, enquanto o segundo reflete os requisitos que expressam
15
restrições que o software deve atender ou qualidades específicas que o software
deve ter, (ZANLORENCI, 1998, p. 3). Conforme classificação define-se:
Requisitos Funcionais: representam o comportamento que um software
deve apresentar diante de certas ações de seus usuários, as funções que o software
deve executar, determinam o funcionamento desejado do software e são passíveis
de especificação objetiva;
Requisitos Não-Funcionais: são os requisitos do produto, que
restringem o software a ser desenvolvido. Quantificam determinados aspectos do
comportamento e são descritos textualmente, refere-se a requisitos de qualidade dos
softwares e não tem especificação objetiva.
A representação dos requisitos tem papel fundamental na condução das
atividades desta área, alguns aspectos podem ser considerados como críticos,
esses aspectos são: definição, análise e gerência de requisitos, os quais formam
algumas das principais fases da Engenharia de Requisitas.
2.3 Fases da Engenharia de Requisitos
O processo de Engenharia de Requisitos como especificado em Kotonya
(2002a, p. 1) e Belgamo (2000, p. 6), pode ser descrito pelas seguintes fases:
elicitação de requisitos, análise de requisitos, especificação de requisitos, verificação
de requisitos e gerenciamento de requisitos. Cada fase apresenta suas
características, apesar de serem normalmente descritas independentemente, elas
consistem de processos iterativos e inter-relacionados que cobrem todo o ciclo de
vida do desenvolvimento de software.
16
2.3.1 Elicitação de Requisitos
A elicitação de requisitos corresponde a identificar junto aos clientes,
usuários e outros envolvidos, quais são os objetivos do software, o que deve ser,
como o software se encaixa no contexto das necessidades do negócio e, finalmente,
como será a utilização do mesmo, (KOTONYA, 2002a, p. 1).
Envolve pessoal técnico trabalhando com os clientes para descobrir sobre
o domínio da aplicação, clientes são questionados para falarem “o quê” o software
deve fazer, ou seja, elicitar os requisitos.
Se a elicitação não for bem feita, a análise, a especificação e a
documentação dos requisitos ficarão comprometidas, inviabilizando todo o processo
e, conseqüentemente, a fase de projeto. O objetivo principal da Engenharia de
Requisitos é evitar tais problemas e isto envolve um significativo esforço na fase de
elicitação. Portanto, é necessário que esta fase seja desempenhada de maneira
criteriosa.
Muitos problemas são encontrados nesta fase, descobrir o que o usuário
realmente necessita é uma das tarefas mais difíceis do processo, um destes é a
comunicação, usuários e técnicos não compartilham o mesmo vocabulário,
expressam os requisitos nos seus próprios termos, sendo que diferentes usuários
podem ter requisitos conflitantes e novos usuários e/ou técnicos podem surgir e o
ambiente de negócios pode mudar. Já durante a elicitação aparecerão problemas
de escopo, ou seja, pode-se trabalhar com requisitos incompletos ou requisitos
desnecessários e de não utilidade para o cliente.
17
Para elicitar os requisitos existem técnicas que se aplicam na sua
obtenção com o propósito de facilitar o trabalho dos analistas e a interação com os
usuários.
2.3.1.1 Técnicas de Elicitação de Requisitos
Várias técnicas de elicitação de requisitos de software têm sido avaliadas
e estudadas, ROCCO (2004) e BELGAMO (2000), “[...] uma técnica deve explorar as
características específicas do problema e como as características do problema
variam muito, precisa-se de um repertório de métodos para cada classe de
problema.” (BELGAMO, apud JAC, 2000, p. 17).
A escolha das técnicas não é uma tarefa fácil. Cada tipo de software pode
requerer técnicas diferentes para a elicitação de requisitos e para ter maiores
possibilidades de escolha e aplicação, a equipe de desenvolvimento deve conhecer
o maior número possível delas, no qual destacam-se as seguintes técnicas:
Observação: Consiste na observação das pessoas na execução de seu
trabalho e na produção de registros detalhados dessas observações. A observação
possibilita um contato pessoal e estreito, o qual apresenta vantagens, pois permite
que o observador identifique importantes detalhes de cada atividade das pessoas
com quem se relacionou, permite a coleta de dados em situações que é impossível
em outras formas de comunicação. A desvantagem do método é por provocar
alterações no ambiente ou no comportamento das pessoas observadas e se basear
muito na interpretação pessoal.
Entrevistas: Entrevistas constituem um mecanismo eficaz para o
levantamento de requisitos gerais do software e no desenvolvimento do
18
entendimento do problema, o analista discute o sistema com diferentes usuários, a
partir da qual elabora um entendimento de seus requisitos. Existem alguns estilos de
entrevistas que podem ser identificadas como: Entrevista não-estruturada ou Aberta,
quando o entrevistador possui a liberdade de percurso para realização da entrevista
sem um conjunto pré-definido de perguntas; Entrevista estruturada ou Fechada,
quando o entrevistador segue um roteiro de perguntas feitas a todos os
entrevistados tendo um conjunto de perguntas pré-definido. Uma das vantagens da
entrevista é que permite a captação imediata e corrente da informação desejada,
sua maior desvantagem é que podem ocorrer domínios de aplicação difíceis de
entender ou ainda, que os usuários estejam tão acostumados a ele que nem
imaginam que detalhes precisam ser esclarecidos.
Prototipação: Consiste na produção de um protótipo de interface do
usuário simples. O objetivo é apresentar muitas alternativas para o usuário antes de
gastar muito esforço, mas deve-se manter o protótipo tão simples o possível. Um
conjunto inicial de entrevistas com os usuários deve ser conduzido para elicitar um
conjunto preliminar de requisitos, usado como base para criar o protótipo. Após a
aceitação do protótipo pelos usuários, os analistas precisam criar um documento de
especificação dos requisitos paralelo ao protótipo de interface.
Cenários: Consistem na produção de exemplos de seções de interação
entre o usuário final e o sistema em uma única situação. Procura-se através de
cenários, representar uma descrição de atividades em um ambiente, os usuários
explicam para os analistas o que eles estão fazendo e a informação da qual eles
precisam do sistema para descrever a tarefa realizada no cenário. Esta técnica
facilita o trabalho dos usuários, simulando tarefas reais relacionadas a um sistema
atual ou a um sistema a ser desenvolvido, além de auxiliar no entendimento dos
19
requisitos, devido ser construído através de uma linguagem facilmente entendida
pelos mesmos.
Análise de Protocolo: Esta técnica necessita que o usuário se engaje
em alguma tarefa e fale correntemente sobre esta tarefa, explicando seu
pensamento sobre o processo. Considera-se que este guia não seja confiável sobre
o que as pessoas envolvidas no processo estão pensando, pode estar sujeito a má
interpretação dos analistas.
JAD
(Join
Application
Development):
Baseia-se
em
sessões
estruturadas e disciplinadas, onde os envolvidos reúnem-se para desenvolver juntos
o processo do software. JAD consiste de cinco etapas: definição do projeto,
pesquisa, preparação para a sessão JAD, a sessão JAD, o documento final. O
processo JAD concentra-se na sessão, e deste modo contribui para a elicitação de
requisitos como significado para validar as informações já coletadas. Esta técnica
promove cooperação, entendimento, e trabalho em grupo entre as pessoas
envolvidas no processo.
QFD (Quality Function Deployment): QFD é um conceito que provê um
significado de interpretar requisitos do cliente em apropriados requisitos técnicos
para cada estágio de desenvolvimento e produção do produto. A fases iniciais do
QFD podem ser descritas como sendo um sistema de identificação e priorização das
necessidades do cliente obtida de cada recurso avaliado. Suas principais vantagens
são enfatizar o projeto para qualidade focando as necessidades do cliente e reduzir
custos através da diminuição dos problemas iniciais. A principal desvantagem desta
técnica é que demanda muito trabalho nas fases de planejamento.
CRC (Cooperative Requirements Capture): CRC é uma sessão de
grupo onde os papéis dos participantes e os papéis do facilitador são claramente
20
definidos. Nesta técnica os participantes do processo não consistem somente de
usuários e facilitadores, mas também de outras pessoas envolvidas indiretamente no
sistema. Diferencia-se das técnicas JAD e QFD pelo enfoque no usuário operativo.
2.3.2 Análise de Requisitos
É o processo onde os requisitos são analisados detalhadamente, o
principal objetivo dessa fase é fornecer descrições abstratas dos requisitos que
possam ser facilmente interpretadas. A meta é analisar se o domínio do problema
está representado e entendido coerentemente.
A análise possui dois propósitos: permitir julgamentos sobre a qualidade
dos requisitos do software e elaborar um modelo do software com os principais
componentes e suas interfaces. Nesta fase o analista deve ser capaz de detectar e
resolver inconsistências e omissões.
Em geral, nem todos os requisitos adquiridos durante o processo de
elicitação poderão ser atendidos. Assim a fase de análise tem um papel fundamental
para avaliar a importância de cada requisito e contribuir para que esses requisitos
sejam priorizados de forma consistente com as reais necessidades.
2.3.3 Especificação de Requisitos
É o processo de criação de um documento de requisitos no qual estão
definidos todos os requisitos analisados, estes devem ser documentados e
formalizados, cujo entendimento deverá ser comum a todos envolvidos no processo
21
de desenvolvimento do software. Esta fase de especificação requer uma descrição
objetiva, precisa e completa.
2.3.4 Verificação de Requisitos
O processo de verificação de requisitos é definido como a atividade na
qual se certifica que o documento de requisitos é consistente com as necessidades
dos usuários. É o processo de assegurar que a especificação de requisitos do
software está em consentimento com os requisitos elicitados e analisados nas fases
anteriores, antes que o documento produzido sirva de base para o desenvolvimento
do software.
2.3.5 Gerenciamento de Requisitos
Gerenciamento de requisitos é o planejamento e controle da atividade de
elicitação, especificação, análise e verificação de requisitos. Esta fase é muito
importante, ou seja, é necessário não somente escrever os requisitos de forma
entendível, mas também permitir que eles possam ser rastreados e gerenciados ao
longo da evolução do software.
Os requisitos de software evoluem devido às mudanças no ambiente do
sistema e conforme os clientes desenvolvem um melhor entendimento de suas
necessidades reais. O Gerenciamento de Requisitos consiste em administrar as
difíceis mudanças dos requisitos durante e depois do desenvolvimento através da
implementação de rastreabilidade.
22
2.4 Propriedades de um Método de Engenharia de Requisitos
Cabe à Engenharia de Requisitos aperfeiçoar os processos para o
gerenciamento do ciclo de vida dos requisitos propor modelos, métodos, técnicas e
ferramentas para a realização destas atividades, porém, não existe um processo
considerado ideal. Atualmente existem ferramentas para gerência de requisitos,
sendo que a grande maioria é propriedade de grandes empresas e não
fundamentadas em processos ou técnicas específicas, esta característica se faz
necessária para atender um maior número de usuários, mas por outro lado, dificulta
o trabalho do analista, pois este tem que definir seu próprio processo.
Lopes (1999b, p. 3) destaca que um método para a Engenharia de
Requisitos deve possuir as seguintes propriedades:
Preciso na definição de sua notação, possibilitando a verificação de sua
consistência e corretitude;
Adequado à comunicação com o usuário final, possibilitando seu
entendimento por pessoas sem treinamento formal;
Hábil no suporte à formulação dos requisitos, permitindo organização da
estrutura de conhecimento dos requisitos e separação de interesses relevantes a
cada área;
Capaz de auxiliar na definição do ambiente no qual o software será
instalado;
Eficiente no suporte à evolução e mudanças dos requisitos, facilitando a
acomodação de alterações sem a necessidade de reconstrução de todo o conjunto
de requisitos;
23
Capaz de oferecer suporte à integração entre as diversas abordagens e
tipos de requisitos;
Eficiente no suporte à comunicação das idéias entre as pessoas
envolvidas no processo;
Passível de apoio por ferramentas, a maior contribuição para a
administração da complexidade em grandes projetos.
Faz se necessário aos analistas, para que a definição dos requisitos seja
a mais eficaz possível, entender o ambiente no qual o software irá funcionar e definir
o método ou modelo que melhor represente o ambiente.
Para capturar os requisitos as técnicas citadas na fase de elicitação de
requisitos podem ser mistas, ou seja, usam fontes combinadas. Uma mesma técnica
pode ser empregada em fases diferentes da Engenharia de Requisitos e com
objetivos diferentes, com o propósito de facilitar o trabalho dos analistas e a
interação com os usuários.
24
3. SISTEMA DE GESTÃO DA QUALIDADE
As organizações enfrentam desafios e demandas relacionados com
lucratividade, qualidade, tecnologia e desenvolvimento sustentável. Para transformar
pressões em vantagens competitivas, precisa manter e aperfeiçoar o desempenho
operacional, sistematicamente. Para conduzir e operar com sucesso uma
organização é necessário dirigi-la e controlá-la de maneira transparente. O sucesso
pode resultar da implementação e manutenção de um sistema de gestão concebido
para melhorar continuamente o desempenho, levando em consideração, ao mesmo
tempo, as necessidades de todas as partes interessadas.
3.1 Definição
Um Sistema de Gestão da Qualidade é um conjunto de elementos que
estão inter-relacionados ou em interação para a melhoria continua de processos
internos e serviços prestados, de forma a garantir aos clientes níveis adequados de
qualidade. A NBR ISO 9000 (ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS,
2000a, p. 9) define “Sistema de Gestão da Qualidade como o sistema de gestão
para dirigir e controlar uma organização, no que diz respeito à qualidade”.
Um sistema de gestão da qualidade incentiva as organizações a analisar
os requisitos do cliente, definir os processos que contribuem para a obtenção de um
produto que é aceitável para o cliente e manter estes processos sob controle. Pode
fornecer a estrutura para a melhoria contínua com o objetivo de aumentar a
probabilidade de ampliar a satisfação do cliente e de outras partes interessadas.
25
3.2 As Normas ISO
A ISO, International Organization for Standardization, é a entidade
internacional que desenvolve as normas em âmbito mundial. Sua sede é em
Genebra – Suíça, representada por praticamente todos os países, tem por objetivo
desenvolver normas em todas as áreas onde relações comerciais são mantidas. No
Brasil é representada pela Associação Brasileira de Normas Técnicas - ABNT,
organização responsável pelo desenvolvimento das normas em nível nacional.
As normas da família NBR ISO 9000 foram desenvolvidas para apoiar
organizações, de todos os tipos e tamanhos, na implementação e operação de
sistemas de gestão da qualidade eficazes, (ASSOCIAÇÃO BRASILEIRA DE
NORMAS TÉCNICAS, 2000b, p. 1). As principais normas que forma esta família são:
ISO 9000 – que estabelece os vocabulários e os fundamentos de um
sistema de gestão da qualidade;
ISO 9001 – que estabelece os requisitos para a implementação de um
sistema de gestão da qualidade;
ISO 9004 – que estabelece as diretrizes para melhorias de desempenho
de um sistema de gestão da qualidade.
A implantação de um Sistema de Gestão da Qualidade segundo a norma
ISO 9001:2000 fornece às organizações, oportunidades de desenvolver e usar
ferramentas pontuais de gerenciamento de uma forma sistêmica, planejada e com
possibilidades de atingir os resultados organizacionais esperados. Para o sistema
ser implantado, certificado e prosseguir de maneira eficaz precisa-se do conjunto de
elementos do Sistema de Gestão da Qualidade inter-relacionados para estabelecer
política e objetivos. A direção e controle incluem o estabelecimento da política da
26
qualidade, dos objetivos da qualidade, do planejamento da qualidade, do controle da
qualidade, da garantia da qualidade e da melhoria da qualidade.
3.3 Automatização do Sistema de Gestão da Qualidade
A ausência de controles automatizados desvia o foco do Sistema de
Gestão da Qualidade para tarefas burocráticas, dificultando a atuação dos
profissionais da organização no verdadeiro papel: conscientização, melhoria e
produtividade.
Os objetivos de um software de Sistema de Gestão da Qualidade
dependem da necessidade de cada empresa e cada cliente. De um modo geral,
essa ferramenta é responsável pelo gerenciamento de documentos, de nãoconformidades, de ações corretivas e preventivas, gestão de treinamento, avaliação
de fornecedores, pesquisa de satisfação dos clientes, gestão de auditorias e
indicadores de desempenho.
As principais necessidades de gerenciamento automatizado buscam obter
mais visibilidade para as melhorias no Sistema de Gestão da Qualidade, maior
alinhamento das ações da qualidade com as estratégias da organização, mais
tranqüilidade nas revisões e aprovações de documentos, forte redução de despesas
com cópias impressas, maior rapidez na divulgação de novas versões de
documentos, menos traumas decorrentes de não-conformidades em documentação,
melhor comunicação entre gestores e usuários, mais segurança no acesso às
informações do Sistema de Gestão da Qualidade e melhores resultados na gestão
de recursos de treinamento.
27
Pesquisas realizadas recentemente (AUTOMAÇÃO, 2003, p. 1), mostram
que 62% das empresas auditadas apresentam não-conformidades em questões
relacionadas à documentação. Os documentos requeridos pelo Sistema de Gestão
da Qualidade devem ser controlados, segundo a norma NBR ISO 9001
(ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, 2000b, p. 4), sendo que a
documentação do Sistema de Gestão da Qualidade deve incluir:
declarações documentadas da política e objetivos da qualidade;
manual da qualidade;
procedimentos documentados requeridos;
documentos necessários à organização para assegurar o planejamento,
a operação e o controle eficazes de seus processos;
O manual da qualidade é o documento da organização que descreve
normalmente de maneira genérica, diretrizes, responsabilidades e os itens do
sistema, nele consta a Política da Qualidade e objetivos da qualidade. Os
procedimentos são normas especificas para executar uma atividade ou um
processo.
Um procedimento documentado deve ser estabelecido para que os
documentos requeridos pelo Sistema de Gestão da Qualidade sejam controlados em
relação: aprovação antes da emissão; análise crítica, atualização e reaprovação;
alterações e situação da revisão devem ser identificadas; versões pertinentes devem
ser aplicáveis e disponíveis nos locais de uso; devem ser mantidos legíveis e
prontamente identificáveis; documentos de origem externa devem ser identificados e
controlados a sua distribuição; deve-se evitar o uso não intencional de documentos
obsoletos e aplicar identificação adequada nos casos em que forem retidos por
qualquer propósito.
28
O controle de documentos deve se estender a todos os documentos
importantes para o Sistema de Gestão da Qualidade, independentemente do modelo
de sistema de qualidade adotado pela organização. Cada organização determina a
extensão da documentação necessária e os meios a serem utilizados no Sistema de
Gestão da Qualidade implantado.
29
4. DEFINIÇÃO DOS REQUISITOS DO SOFTWARE
Para definição dos requisitos se faz necessário uma análise criteriosa da
organização e do sistema a ser automatizado, compreendendo a definição e
identificação dos processos do negócio e, principalmente o conhecimento da
informação do cliente relativa as suas necessidades. O estudo de caso será aplicado
em relação a automatização da Gestão de Documentos, do Sistema de Gestão da
Qualidade implantado na organização X, apresentando a metodologia atual adotada
por esta organização. E, ainda, será apresentada a ferramenta selecionada para o
estudo de caso no apoio a definição dos requisitos, as técnicas implementadas e
funcionalidades. Por fim, a apresentação e análise dos resultados da aplicação
deste estudo de caso.
4.1 Procedimentos Metodológicos
O presente estudo aborda uma pesquisa de caráter bibliográfico,
buscando os materiais e publicações existentes na área da Engenharia de
Requisitos, para definição e avaliação de métodos, técnicas e ferramentas que a
apóiam.
Através desta pesquisa bibliográfica pôde-se identificar uma ferramenta
com as características necessárias e adequadas à realidade das organizações para
o estudo de caso. Este, será aplicado com a finalidade de conhecer detalhadamente
e explorar a funcionalidade e auxílio em relação à definição dos requisitos de um
software.
30
4.2 Descrição do Sistema a ser Automatizado
A organização X possui um Sistema de Gestão da Qualidade, conforme
NBR ISO 9001/2000, implantado e certificado desde 2000, em algumas áreas de
atuação, e que envolve aproximadamente 30 (trinta) colaboradores. Sua meta é
ampliar a certificação para as demais áreas da organização, o que irá aumentar o
número de documentos e colaboradores envolvidos, tornando o controle de
documentos muito mais difícil. Diante do exposto a organização, tem por objetivo
adquirir um sistema de Gestão de Documentos automatizado para contribuir com a
segurança das informações, facilitar o acesso e distribuição dos documentos.
A Gestão de Documentos tem por objetivo permitir o controle da
documentação da organização quanto à criação, aprovação, distribuição, leitura,
arquivamento, cópia de segurança e segurança de rede. Pode-se dizer que, Gestão
de Documentos, é um módulo do Sistema de Gestão da Qualidade, e documento é
qualquer informação contida em qualquer meio físico ou eletrônico.
A estrutura da documentação que rege o Sistema de Gestão da
Qualidade desta organização é definida da seguinte forma: Política da Qualidade,
Manual da Qualidade, Procedimentos e Registros da Qualidade.
Os procedimentos são documentos que reúnem informações específicas
para o gerenciamento dos processos do Sistema de Gestão da Qualidade no que se
refere às atividades desenvolvidas na organização.
É
altamente
recomendável
que
a
organização
estabeleça
um
procedimento padrão que oriente a criação dos procedimentos documentados da
organização. As principais informações e processos referentes ao sistema de
Gestão de Documentos são definidos através deste procedimento padrão, o qual é o
31
procedimento Controle de Documento. Este procedimento tem por objetivo
estabelecer a sistemática de controle dos documentos do Sistema de Gestão da
Qualidade desta organização, descrevendo os seguintes processos: Criação de
Procedimentos, Revisão de Procedimentos, Controle da Lista-Mestra, Distribuição
dos Documentos, Matriz de Documentos, Controle de Documentos Complementares
e/ou Origem Externa, Controle de Documentos Regulamentares e/ou Estatutários,
Controle de Formulários.
Neste procedimento Controle de Documento, é descrito todo o processo
das atividades, a definição dos responsáveis, desde sua emissão e aprovação até
sua revisão e o gerenciamento das informações. Para um melhor entendimento do
sistema a ser automatizado, abaixo descreve-se os principais processos:
Criação de Procedimentos: Para a criação de procedimentos deve ser
encaminhada uma sugestão ao responsável pela área da atividade a ser
documentada. Este analisa a sugestão e verifica a necessidade de elaboração do
procedimento. Se o pedido for aprovado, o Coordenador da Qualidade providencia o
código para o procedimento e define, juntamente com o responsável pela área o
redator. O redator redige o texto do procedimento, em arquivo salvo na unidade de
rede de sua área. O redator comunica o Coordenador da Qualidade, que verifica a
formatação, imprime o mesmo e encaminha para o redator. Caso este aprove o
procedimento, deve encaminhar para a função responsável pela homologação do
procedimento. Caso o procedimento não seja aprovado, a função responsável pela
homologação solicita ao redator que realize as alterações. O redator deve corrigir o
texto, comunicar ao Coordenador da Qualidade para verificar a formatação, e este
deve imprimir e encaminhar novamente à função responsável pela homologação.
32
Revisão de Procedimentos: A necessidade de revisão de um
procedimento pode ser detectada por qualquer colaborador, que deve comunicar ao
redator do procedimento, para que este avalie a necessidade de revisão. A
responsabilidade pela revisão do documento é do redator, que solicita ao
Coordenador da Qualidade que salve o arquivo na unidade de rede referente à sua
área. Após as alterações do documento o redator comunica ao Coordenador da
Qualidade, que avalia as alterações realizadas, verifica a formatação, imprime e
encaminha o procedimento para a função responsável pela homologação, para que
este análise as alterações. Após a homologação do procedimento o Coordenador da
Qualidade deve apagar o procedimento revisado, da unidade de rede da área a qual
se refere o procedimento.
Controle da Lista-Mestra: A lista-mestra contém a relação de todos os
documentos referentes ao Sistema de Gestão da Qualidade, identificando
prontamente a situação da revisão atual. A lista-mestra deve ser revisada, pelo
Coordenador da Qualidade, sempre que ocorrer a inclusão de um novo documento,
a revisão ou cancelamento de um existente. O Coordenador da Qualidade deve
dispor a revisão mais recente nas pastas de consulta de procedimentos. As revisões
obsoletas das listas-mestras devem ser recolhidas pelo Coordenador da Qualidade.
Os documentos cancelados devem permanecer na lista-mestra, com identificação de
‘cancelado’, para que não seja reutilizado o código. O diretório da lista-mestra e
acesso é exclusivo do Coordenador da Qualidade. Os formulários e documentos que
se utilizam os números das revisões dos procedimentos devem ser alterados
conforme a lista-mestra em vigor.
Distribuição dos Documentos: O responsável pela homologação do
documento, quando da redação ou revisão deste, define quais colaboradores
33
receberão cópia controlada dos mesmos. O Coordenador da Qualidade recebe cópia
de todos os documentos referentes ao Sistema de Gestão da Qualidade. O
Coordenador da Qualidade é o responsável pela distribuição das cópias dos
documentos. As cópias controladas devem receber um carimbo com um número de
controle e a data da distribuição e registrado no formulário distribuição de cópias
controladas. Os documentos que não necessitarem de controle devem ser
carimbados com ‘Cópia não controlada’, em vermelho, na primeira página,
informando que se encontram nesta situação. O Coordenador da Qualidade é
responsável pela autorização destas cópias. Nos casos em que houver alteração do
responsável por função e/ou atividade a Coordenação da Qualidade deve registrar
no campo observações do formulário distribuição de cópias controladas, o novo
responsável pelo recebimento da cópia. O possuidor de cópia controlada do
documento, ao receber a cópia revisada deverá devolver a cópia obsoleta para que
a Coordenação da Qualidade possa destruí-la.
Matriz de Documentos: A finalidade principal desta matriz é relacionar
os documentos do Sistema de Gestão da Qualidade, referenciando-os aos requisitos
da NBR ISO 9001/2000. É de responsabilidade do Coordenador da Qualidade
manter a matriz atualizada. O original da matriz de documentos deve permanecer
com a Coordenação da Qualidade, e ser revisada sempre que houver alguma
alteração no seu conteúdo. A matriz de documentos deve ser distribuída nas pastas
de consulta de procedimentos.
Controle de Documentos Complementares e/ou Origem Externa: A
finalidade principal desta matriz é indicar de modo preciso a localização dos
documentos
possibilitando
assim,
rápido
acesso
aos
mesmos.
É
de
responsabilidade do Coordenador da Qualidade manter a matriz atualizada. O
34
original da matriz de documentos complementares e/ou de origem externa deve
permanecer com a Coordenação da Qualidade, e ser revisada sempre que houver
alguma alteração no seu conteúdo. A matriz de documentos complementares e/ou
de origem externa deve ser distribuída nas pastas de consulta de procedimentos.
Controle
de
Documentos
Regulamentares
e/ou
Estatutários:
A
finalidade principal desta matriz é indicar de modo preciso a localização dos
regulamentos, leis ou normas que permitem a realização dos serviços, possibilitando
assim, rápido acesso aos mesmos. É de responsabilidade do Coordenador da
Qualidade manter a matriz atualizada. O original da matriz de documentos
regulamentares e/ou estatutários deve permanecer com a Coordenação da
Qualidade, e ser revisada sempre que houver alguma alteração no seu conteúdo. A
matriz de documentos regulamentares e/ou estatutários deve ser distribuída nas
pastas de consulta de procedimentos.
Controle de Formulários: Os formulários gerados por um determinado
procedimento devem ser apresentados anexos aos mesmos. A alteração de
formulário gera revisão do procedimento que lhe deu origem e demais
procedimentos impactados, quando necessário. O Coordenador da Qualidade é
responsável por disponibilizar a revisão mais recente aos colaboradores. Os
formulários devem ser buscados sempre na unidade de rede de cada área, para
garantir a utilização da versão atualizada. O Coordenador da Qualidade deve manter
uma cópia física da revisão atual de cada formulário, com o objetivo de disponibilizalos aos usuários quando houver problemas técnicos.
Os procedimentos devem obedecer à estrutura definida, conforme modelo
de documento disponível aos usuários, seguindo os critérios do procedimento
Controle de Documentos em relação aos campos e digitação do texto. A codificação
35
a ser utilizada nos procedimentos deve ser seqüencial e os procedimentos
cancelados não devem ter seus códigos reutilizados.
Os originais dos procedimentos devem ser arquivados, pelo Coordenador
da Qualidade, individualmente em pastas suspensas e identificadas com o código do
procedimento. Os originais da revisão anterior dos procedimentos devem receber o
carimbo de ‘Obsoleto’, em vermelho, na primeira página e ser arquivados nas pastas
dos procedimentos.
As cópias dos procedimentos devem ser controladas e arquivadas nas
pastas de consulta, em local de fácil acesso e ser do conhecimento de todos os
usuários dos procedimentos. Os responsáveis pelo recebimento das cópias devem
manter as respectivas pastas atualizadas e organizadas e comunicar ao
Coordenador da Qualidade qualquer irregularidade encontrada. Atualmente a
organização X possui 20 (vinte) pastas distribuídas, nas áreas que possuem os
processos documentados, nas quais deve manter todos os documentos atualizados
conforme descrito acima.
A comunicação entre os usuários é feita de forma verbal, sendo que cada
usuário tem o dever de avisar a situação atual do processo em relação à elaboração,
revisão e aprovação de procedimento ao Coordenador da Qualidade e aos usuários
diretamente relacionados em sua atividade e/ou processo.
Este é o processo das atividades que será aplicado ao estudo de caso,
sendo que é extremamente importante para a definição dos requisitos, que o
analista de sistema tenha consciência do escopo no qual está inserido o
desenvolvimento do software.
36
4.3 Ferramenta e Técnica Utilizada no Estudo de Caso
Através da pesquisa realizada observa-se que a Engenharia de
Requisitos tem apresentado novos conceitos na definição dos requisitos. Muitos
trabalhos destacam ferramentas para gerência de requisitos, tais como RequisitePro,
Doors, CaliberRM, Catalyze e QFD. Na busca de uma ferramenta para aplicar o
estudo de caso muitos problemas foram encontrados, algumas ferramentas não
possuíam versão para análise, outras ferramentas apresentaram erros na instalação,
e sendo que a maioria destas ferramentas são propriedade de grandes empresas e
não fundamentadas em processos ou técnicas específicas.
A ferramenta C&L destacou-se das demais citadas para ser aplicada no
estudo de caso devido ser um software Web gratuito, que facilita a compreensão
através da utilização de uma linguagem natural e força a organização da informação
através de uma estrutura bem definida. Esta ferramenta é parte de um projeto de
pesquisa do grupo de Engenharia de Requisitos da PUC-Rio, encontra-se disponível
no endereço eletrônico http://sl.les.inf.puc-rio.br/cel/aplicacao/. O desenvolvimento
da ferramenta é feito com base na filosofia de desenvolvimento de software livre, ou
seja, o código é disponibilizado livremente para quem tiver interesse. Além de que o
software foi criado inteiramente com o uso de softwares gratuitos.
C&L está centrada nas técnicas de modelagem de requisitos, Cenários e
Léxico Ampliado da Linguagem (LAL). Uma das metas da ferramenta é manter e
disponibilizar a rastreabilidade entre requisitos e código, segundo Silva (2004, p. 02)
“A idéia é integrar cenários e código de maneira a permitir que os diferentes
interessados trabalhem em um conjunto compartilhado de informações sem precisar
conhecer detalhes que não são de sua responsabilidade."
37
O desenvolvido da ferramenta continua em evolução, desta forma, C&L
está criando o processo de geração de ontologias baseadas no LAL. A ferramenta
C&L defende que a ontologia é um produto da engenharia de requisitos, por ter um
núcleo de conhecimento sobre os processos para captura, modelagem e análise de
informações relevantes a um domínio. Conforme destaca Felicíssimo (2004b, p. 14),
"Nosso objetivo é apoiar a interoperabilidade de agentes de software que atuam em
ambientes heterogêneos, regulados por um grande número de ontologias."
A ferramenta está sendo avaliada através de alguns projetos práticos, no
qual foi destacada a necessidade de uma interface gráfica amigável para a
visualização das ontologias geradas e exportadores para as demais linguagens de
representação. Atualmente a ferramenta disponibiliza um link para validação e
visualização das ontologias na Web.
4.3.1 Cenários e Léxicos
Entende-se por cenários a descrição de situações comuns ao cotidiano
dos usuários. Cada cenário descreve, através de linguagem natural semiestruturada, uma situação específica da aplicação, focando seu comportamento.
Existem várias propostas para a representação de cenários, desde a mais informal,
em texto livre, até representações formais. A notação para cenários desenvolvida na
ferramenta C&L é composta por elementos que expressam o objetivo, o contexto,
recursos, atores, atividades bem como restrições e exceções. Abaixo se descreve
detalhadamente os elementos que compõem um cenário:
Título - é o identificador do cenário, é a descrição da finalidade do
cenário, deve ser concreto e preciso;
38
Contexto - é a descrição do estado inicial do cenário, através de précondições, localização geográfica e/ou localização temporal;
Recursos - são entidades passivas necessárias à realização do cenário,
devem ser referenciados em pelo menos um dos episódios;
Atores - são entidades (sistema, organização ou pessoa), que se
envolvem ativamente no cenário. Devem ser referenciados em um dos episódios;
Episódios - seqüência de sentenças simples, condicionais ou opcionais,
correspondente a ações e decisões com participação dos atores. O conjunto de
episódios atende ao objetivo do cenário;
Restrições - são aspectos não-funcionais que podem estar relacionados
ao contexto, recursos ou a episódios específicos;
Exceções - correspondem a situações que podem impedir que o
objetivo do cenário seja atingido e o tratamento correspondente a tal situação.
O processo de construção de cenários está relacionado à existência do
Léxico Ampliado da Linguagem (LAL) na ferramenta C&L. O LAL é a implementação
de conceitos que descreve os símbolos da linguagem do universo de informação do
sistema. É utilizado para facilitar a comunicação e a compreensão de palavras ou
frases peculiares às informações descritas nos cenários. Cada termo do léxico
possui dois tipos de descrição: noção (ou denotação) e o impacto (ou conotação). A
noção é o que o termo significa naquele contexto e o impacto representa como o
termo exerce influência no contexto. Os termos do léxico são classificados em quatro
categorias: objeto, sujeito, estado e verbo. Destaca-se na figura 1 as regras do léxico
aplicadas pela ferramenta. O LAL é escrito em linguagem natural, onde o próprio
usuário com a ajuda do analista de sistema pode escrevê-lo e validá-lo. Através do
LAL o analista consegue compartilhar, analisar e reutilizar o conhecimento.
39
Figura 1 - Regras do Léxico Ampliado da Linguagem
Fonte: Dados da pesquisa
A partir do Léxico Ampliado da Linguagem (LAL) a ferramenta C&L
permite a geração de ontologias, que são especificações formais dos termos do
universo de informação do sistema e as relações entre eles. O LAL provê a
linguagem comum para a comunicação informal entre os interessados no processo
de desenvolvimento de software, clientes, usuários e analista de sistema, enquanto
ontologias
fornecem
este
modelo
de
modo
mais
formal,
permitindo
o
compartilhamento de informações entre máquinas e agentes de software.
4.3.2 Funcionalidades da Ferramenta
A ferramenta C&L possui uma interface amigável e de fácil navegação,
suas principais funcionalidades são: gerenciar usuários e projetos, editar léxico e
cenários, gerar XML e gerar ontologia. A ferramenta possui dois níveis de acesso ao
40
sistema: nível de usuário comum e usuário administrador. Somente o usuário
administrador e os usuários participantes de um projeto podem visualizar, criar,
alterar e remover cenários e termos do léxico de um projeto.
A interface principal é estruturada em três quadros, conforme figura 2. No
quadro superior a ferramenta apresenta um menu com o conjunto de funções que
podem ser realizadas pelos usuários. O quadro do lado esquerdo, apresenta uma
estrutura em árvore com os cenários, termos do léxico e conceitos da ontologia
criados para um projeto.
Figura 2 – Interface principal da ferramenta
Fonte: Dados da pesquisa
Além
das
funções
disponíveis
no
quadro
superior,
usuários
administradores podem acessar as funções ilustradas pelo quadro central. As
funcionalidades exclusivas do usuário administrador de projeto são: verificar os
41
pedidos de alteração dos cenários e dos termos do léxico, adicionar novos usuários,
gerar e recuperar a versão do projeto escrita na linguagem XML, gerar ontologia e
DAML da ontologia do projeto.
Selecionando um cenário ou um termo do léxico, no quadro esquerdo, o
quadro central apresenta o conteúdo do cenário ou do termo do léxico, que são
visualizados para navegação ou alteração. Os atalhos, que se destacam na figura 3
por estarem em negrito, são criados ou excluídos automaticamente a medida em
que os usuários adicionam ou removem cenários ou termos do léxico,
respectivamente. Estes atalhos são criados entre os termos já cadastrados tanto
descritos no léxico quanto os descritos nos cenários do projeto, sendo referenciados
através do relacionamento e assim facilitando a navegabilidade entre os termos de
domínio e permitindo a melhor compreensão de seus relacionamentos.
Figura 3 – Visualização do cenário na ferramenta
Fonte: Dados da pesquisa
42
A idéia que rege a modelagem de requisitos no C&L é de que uma equipe
de desenvolvimento possa trabalhar, em paralelo, descrevendo cenários e termos do
léxico. O usuário administrador é o único que tem o poder de validar os pedidos de
alterações. Cada alteração realizada nos termos do léxico ou nos cenários, antes de
ser efetivada, fica em uma lista de pedidos de alteração, aguardando a validação do
administrador. Este recebe mensagens eletrônicas, avisando quando há pedidos
pendentes a serem validados, podendo aprovar ou não os pedidos.
A geração do XML e da ontologia são funcionalidades disponíveis apenas
para o administrador do projeto. A geração do XML disponibiliza um arquivo XML
com as informações dos cenários e do léxico de um projeto, tendo um papel
fundamental na ferramenta, pois serve como protocolo de exportação para leitura
por outras pessoas. A geração da ontologia é um processo semi-automático, para
gerar uma ontologia é necessário que os termos do léxico tenham sido definidos no
projeto, pois na geração o sistema mapeia os termos do LAL para conceitos da
ontologia, conforme processo e regra definido em Felicíssimo (2004b, p. 4), tendo a
intervenção do usuário apenas naquelas em que haja absoluta necessidade. A
ferramenta C&L disponibiliza uma opção no menu "histórico em DAML da ontologia
do projeto", para posterior visualização na web.
4.4 Aplicação da Ferramenta e Técnica
Inicialmente para aplicar o estudo de caso é necessário, conforme se
destaca nos capítulos anteriores, ter conhecimento da ferramenta e técnica a ser
aplicada e principalmente das atividades da Gestão de Documentos que será
aplicada neste estudo, este considera-se um módulo do Sistema de Gestão da
43
Qualidade. Sendo assim foram realizadas várias pesquisas e leituras dos principais
documentos que englobam estas atividades. Para interagir na ferramenta C&L,
juntamente com o administrador do projeto, o Coordenador da Qualidade foi o
principal usuário na construção dos cenários e dos termos do léxico, por ter um
conhecimento detalhado de toda a sistemática das informações da Gestão de
Documentos.
Aplicando a primeira fase da Engenharia de Requisitos na ferramenta
C&L foram adicionados os cenários, técnica utilizada pela ferramenta para elicitação
dos requisitos, ao projeto criado como 'Sistema de Gestão de Documentos'. Na
construção dos cenários o tempo usado foi alto devido ao detalhamento que
chegaram estes. Os cenários obtidos, apresentados detalhadamente no apêndice,
são os seguintes:
Elaboração de Procedimento
Aprovação de Procedimento
Verificação do Procedimento
Distribuição do Procedimento
Revisão de Procedimento
Cancelamento de Procedimento
Controle de Formulários
Controle da Matriz de Documentos
Controle de Documentos Complementares
Controle de Documentos Regulamentares
Após a inclusão dos cenários pôde-se analisar e verificar as necessidades
de alterações. Com o processo de interação entre os usuários, Analista de Sistema e
Coordenador da Qualidade, existente na ferramenta C&L, tornou-se simples e sem
44
grandes impactos as alterações, pois para cada pedido de alteração faz-se
necessário que o administrador aprove. Com os cenários inseridos a próxima etapa
foi incluir os termos do Léxico. Através de uma análise das palavras e frases
existentes nos cenários pôde-se identificar as mais importantes e de grande impacto
nas funcionalidades do sistema de Gestão de Documentos. Após definição dos
termos, estes foram descritos conforme noção e impacto. A seguir apresenta-se os
termos do léxico identificados na definição dos requisitos do projeto, no apêndice é
apresentado detalhadamente, descrevendo noção e impacto. Os termos são:
Colaboradores
Comitê da Qualidade
Coordenador da Qualidade
Norma
Procedimento
Redator
Responsável pela Homologação
Sgq
Com os termos do léxico inseridos no projeto, automaticamente estes se
relacionaram com os termos existentes nos cenários. Esta referência fez com que
criasse um link nos termos existentes, onde clicando neste termo a ferramenta busca
os cenários ou léxico com o qual se relaciona. Os títulos dos cenários quando
citados em outros cenários recebem o mesmo tipo de referência. Na figura 4, o
quadro central da ferramenta apresenta as informações sobre o léxico redator,
abaixo deste destacam-se os cenários e termos do léxico que referenciam o termo
redator.
45
Figura 4 – Visualização de um termo do léxico na ferramenta
Fonte: Dados da pesquisa
A geração do XML foi feita após os cenários e léxicos estarem
identificados e aprovados pelos usuários envolvidos nas atividades do projeto. A
ferramenta C&L disponibiliza duas opções de gerar o XML, formato padrão ou exibir
formatado. Para exibir o XML fica disponível, no menu ‘Recuperar XML deste
projeto’, somente para o usuário administrador, uma relação de arquivos gerados. A
figura 5 apresenta a estrutura dos cenários e léxicos com a opção de exibir XML
formatado. Quando se faz a opção de gerar o XML em formato padrão na
visualização o arquivo pode ser salvo para uso posterior em outras ferramentas.
46
Figura 5 – Visualização do XML formatado
Fonte: Dados da pesquisa
Finalizando a aplicação do estudo de caso na ferramenta C&L as
ontologias foram geradas criando os conceitos, relações e axiomas. Para cada termo
existente no léxico o processo gerou um conceito na ontologia, no qual possui
referência com o item relações. Os axiomas se referem aos conceitos disjuntos, que
são identificados pelo usuário administrador no final do processo, este deve
relacionar os conceitos da ontologia identificados que não possuem referência com
outros conceitos.
Quando um conceito é selecionado, no quadro central é disponibilizada a
descrição deste e a lista de relações usadas pelo conceito corrente e os conceitos
com os quais ele se relaciona, e em sua descrição, se existir referências para os
termos do léxico, estas terão links para navegação. Na figura 6 se destaca a
visualização do conceito na ferramenta.
47
Figura 6 – Visualização de um conceito da ontologia
Fonte: Dados da pesquisa
4.5 Análise dos Resultados
Com C&L pôde-se verificar a importância de uma ferramenta para
elicitação, análise e gerenciamento dos requisitos, sendo assim, pôde-se definir as
informações necessárias para o desenvolvimento de um software.
Utilizando os cenários tornou-se mais fácil a elicitação, pois esta técnica
permitiu dividir várias situações, tornando possível detalhar bastante cada atividade
e fazendo com que situações antes não apresentadas viessem ser identificadas.
Conseguiu-se também constatar que situações existentes não serão mais
necessárias com a automatização do sistema de Gestão de Documentos. O léxico
apresentou-se muito importante por identificar e descrever termos do projeto para
melhor entendimento dos usuários. Através do relacionamento entre os termos do
48
léxico e dos cenários tornou-se possível conhecer o impacto dos termos em relação
a todas as atividades descritas nos cenários, podendo assim avaliar a função de
cada termo em relação ao projeto. A geração das ontologias veio confirmar as
relações dos termos do léxico com os cenários, descrevendo relações dos termos
antes não identificados através das referências.
A apresentação e formatação das informações e navegação dos links
entre cenários, léxico e ontologia na ferramenta fizeram com que os usuários
identificassem facilmente os requisitos obtidos, possibilitando assim uma boa
elicitação de requisitos e entendimento do projeto. A interação entre os usuários
viabilizada na ferramenta foi muito importante, pois todas as alterações solicitadas
por usuários comuns passaram pela aprovação do usuário administrador, fazendo
com que o administrador do projeto tivesse conhecimento de todas as mudanças
existentes.
Por um lado à ferramenta C&L possibilitou ao analista de sistema
entender mais rapidamente as atividades do sistema, os requisitos do usuário, a
estrutura do código e como estes estão relacionados. Por outro lado os usuários
puderam descrever de forma mais clara e objetiva as informações necessárias para
o sistema e identificar junto ao analista de sistema os requisitos necessários ao
desenvolvimento do software.
49
5. Considerações Finais
A definição do que se quer produzir é considerada como uma etapa crítica
do desenvolvimento de software, não se questiona a importância do processo de
definição dos requisitos nesta etapa, quando utilizadas metodologias clássicas.
Visando melhorar o processo convencional este estudo define a Engenharia de
Requisitos, descrevendo suas principais fases, as quais contribuem para a
elicitação, análise, especificação, verificação e gerenciamento de requisitos.
A Engenharia de Requisitos é responsável por entender as informações
do software e identificar quais e como as tarefas da aplicação devem ser
automatizadas. Com a apresentação das principais técnicas de elicitação de
requisitos pôde-se identificar que muitos processos utilizados atualmente nas
empresas fazem parte destas técnicas, sendo que os processos atuais não possuem
um contexto tão definido como as técnicas descritas e não possuem documento ou
registros desta etapa.
Observa-se também, que não existe uma técnica ideal capaz de
solucionar todos os problemas relativos aos requisitos de software. As técnicas
devem ser utilizadas de acordo com o processo no qual está inserida a elicitação, e
como o processo de elicitação difere-se um do outro, deve-se aplicar não somente
uma técnica, mas sim um conjunto delas.
As técnicas de elicitação de requisitos representam apenas uma fase da
Engenharia de Requisitos, sendo que é necessário não somente elicitar os requisitos
e sim analisar, verificar, documentar e gerenciar. As ferramentas vêem contribuir
50
com estas seguintes etapas, definindo uma estrutura organizacional para todo o
processo de requisitos.
A ferramenta C&L utilizada no estudo de caso mostra-se bastante prática
na geração dos cenários, léxicos e ontologias, no qual são as técnicas utilizadas
para elicitação. A sua estrutura é bem definida, organizando as informações e
facilitando a compreensão através de uma linguagem natural. Os atalhos gerados
automaticamente entre os cenários, léxicos e ontologias, que referenciam os termos
utilizados nestes, facilitam o entendimento das atividades do sistema em estudo
tanto para o analista quanto para os usuários. Esta rastreabilidade também permite
ao analista identificar mais rapidamente o impacto de mudanças nos requisitos, caso
venha existir. A interação entre os usuários que trabalham em um projeto na
ferramenta é implementada de uma forma prática e importante para o processo,
fazendo com que as alterações solicitadas por usuário comum passe pela aprovação
do usuário administrador. Sendo assim, com o auxílio desta ferramenta, o processo
de requisitos se torna mais rápido, menos custoso e documentado.
Através da pesquisa e do estudo de caso pôde-se evidenciar as
potencialidades e deficiências da Engenharia de Requisitos. Com o auxílio de
ferramentas e técnicas no processo de requisitos, é possível detectar e corrigir
precocemente não-conformidades no desenvolvimento de software, evitando desta
forma, sua propagação no processo de desenvolvimento e minimizando os custos e
o tempo gasto. No entanto, não existem muitas ferramentas que dêem suporte total
ao processo de requisitos, existem ferramentas, que de alguma maneira apóiam,
algumas destas ferramentas são produtos comerciais que estão relacionadas a uma
ou um conjunto de técnicas. Deve-se destacar que ferramentas e técnicas ajudam,
mas para entender o problema é preciso que as pessoas envolvidas no processo
51
possuam comunicação, conhecimento, colaboração, habilidade de expressão,
atenção aos detalhes, concisão e domínio do contexto. Com isso, os usuários e
analistas de sistemas envolvidos no processo serão mais efetivos no seu trabalho,
contribuindo para a definição de softwares que melhor atendam as necessidades de
todos.
52
REFERÊNCIAS
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 9000: sistemas de
gestão da qualidade: fundamentos e vocabulário. Rio de Janeiro, 2000.
______. NBR ISO 9001: sistemas de gestão da qualidade: requisitos. Rio de
Janeiro, 2000.
AUTOMAÇÃO de gestão da qualidade. Acttive software S.A. São Paulo, jan. 2003.
Disponível em: <http://www.acttive.com.br/download_form.htm>. Acesso em: 01 mar.
2005.
BELGAMO, Anderson. Um estudo comparativo sobre as principais técnicas de
elicitação de requisitos do software. 2000. 69f.. Dissertação (Mestrado em
Ciência da Computação), Universidade Metodista de Piracicaba, Taquaral, 2000.
BORTOLI, Lis Ângela de. Um método de trabalho para auxiliar a definição de
requisitos. In: SEMANA ACADÊMICA DO CPGCC, 3,1998, Porto Alegre. Anais...
Porto Alegre: UFRGS, 1998. Disponível em:
<http://www.inf.ufrgs.br/pos/SemanaAcademica/Semana98/>. Acesso em: 02 mar.
2005.
BURNETT, Robert Carlisle; ZANLORENCI, Edna Pacheco. Modelo para qualificação
da fonte de informação do cliente e de requisitos funcional. In: WORKSHOP DE
ENGENHARIA DE REQUISITOS, 1998, Maringá. Anais... Rio de Janeiro: PUC,
1998. Disponível em: <http://www.inf.puc-rio.br/~wer98/artigos/39.html>. Acesso em:
23 set. 2004.
CASTRO, Jaelson Freire Brelaz de. Introdução à engenharia de requisitos. In:
JORNADA DE ATUALIZAÇÃO EM INFORMÁTICA, 14, 1995, Canela. Anais...
Canela: Instituto de Informática da UFRGS, 1995. p.1-43.
FELICÍSSIMO, Carolina Howard; LEITE, Julio Cesar Sampaio do Prado; BREITMAN,
Karin Koogan; SILVA, Lyrene Fernandes da. C&L: Um ambiente para edição e
visualização de cenários e léxicos. Rio de Janeiro: Pontifícia Universidade
Católica do Rio de Janeiro, 2004. Disponível em: <http://139.82.24.189/cel/>. Acesso
em: 09 mar. 2005.
53
______. Geração de ontologias subsidiada pela engenharia de requisitos. Rio
de Janeiro: Pontifícia Universidade Católica do Rio de Janeiro, 2004. Disponível em:
<http://139.82.24.189/cel/>. Acesso em: 09 mar. 2005.
FIORINI, Soeli T.; LEITE, Julio Cesar Sampaio do Prado; LUCENA, Carlos José
Pereira de. Organizando processos de requisitos. In: WORKSHOP DE
ENGENHARIA DE REQUISITOS, 1998, Maringá. Anais... Rio de Janeiro: PUC,
1998. Disponível em: <http://www.inf.puc-rio.br/~wer98/>. Acesso em: 20 set. 2004.
KOTONYA; SOMMERVILLE. Respostas às perguntas mais freqüentes sobre
engenharia de requisitos. InfoChoose. Tradução Eduardo Marquioni. São Paulo, n.
40, nov. 2001. Disponível em:
<http://www.choose.com.br/infochoose/artigos/software.asp>. Acesso em: 23 set.
2004.
______. Os processos típicos da engenharia de requisitos: parte 1. InfoChoose.
Tradução Eduardo Marquioni. São Paulo, n. 42, fev. 2002. Disponível em:
<http://www.choose.com.br/infochoose/artigos/software.asp>. Acesso em: 23 set.
2004.
______. Os processos típicos da engenharia de requisitos: parte 2. InfoChoose.
Tradução Eduardo Marquioni. São Paulo, n. 43, mar. 2002. Disponível em:
<http://www.choose.com.br/infochoose/artigos/software.asp>. Acesso em: 23 set.
2004.
______. Os processos típicos da engenharia de requisitos: parte 3. InfoChoose.
Tradução Eduardo Marquioni. São Paulo, n. 44, abr. 2002. Disponível em:
<http://www.choose.com.br/infochoose/artigos/software.asp>. Acesso em: 23 set.
2004.
______. Os processos típicos da engenharia de requisitos: parte 4. InfoChoose.
Tradução Eduardo Marquioni. São Paulo, n. 45, jul. 2002. Disponível em:
<http://www.choose.com.br/infochoose/artigos/software.asp>. Acesso em: 23 set.
2004.
______. Os processos típicos da engenharia de requisitos: parte 5. InfoChoose.
Tradução Eduardo Marquioni. São Paulo, n. 45, jul. 2002. Disponível em:
<http://www.choose.com.br/infochoose/artigos/software.asp>. Acesso em: 23 set.
2004.
54
LOPES, Paulo Sérgio Naddeo Dias. Uma taxonomia da pesquisa na área de
engenharia de requisitos. 2002. 92f.. Dissertação (Mestrado em Ciência da
Computação) – Instituto de Matemática e Estatística, Universidade de São Paulo,
São Paulo. Disponível em: <http://www.ime.usp.br/dcc/posgrad/teses/naddeo.pdf>.
Acesso em: 10 nov. 2004.
______. Engenharia de requisitos: comentário e avaliação da introdução e do
capítulo 1 do livro: requirements engineering. In: SEMINÁRIO DE ANÁLISE DE
REQUISITOS, 1999, São Paulo. Anais... São Paulo: USP, 1999. Disponível em:
<http://www.naddeo.com.br/EngenhariaDeRequisitos1.htm>. Acesso em: 10 nov.
2004.
______. Engenharia de requisitos com pontos de vista: comentário e avaliação
de artigo. São Paulo: USP, 1999. Disponível em:
<http://www.naddeo.com.br/EngenhariaDeRequisitos2.htm>. Acesso em: 23 nov.
2004.
______. Engenharia de requisitos: uma visão geral: relatório de apresentação. São
Paulo: USP, 1999. Disponível em:
<http://www.naddeo.com.br/EngenhariaDeRequisitos1.htm>. Acesso em: 23 nov.
2004.
MARTINS, Luiz Eduardo Galvão; DALTRINI, Beatriz Mascia. Organizando o
processo de elicitação de requisitos utilizando o conceito de atividade. In:
WORKSHOP DE ENGENHARIA DE REQUISITOS, 2001, Buenos Aires. Anais... Rio
de Janeiro: PUC, 2001. Disponível em: <http://wer.inf.pucrio.br/WERpapers/artigos/artigos_WER01/martins.pdf>. Acesso em: 23 set. 2004.
OLIVEIRA, Elaine Harada Teixeira de. Requisitos. Apresentação da disciplina de
engenharia de software. Desenvolvida no departamento de ciência da computação.
Universidade do Amazonas. Disponível em:
<http://www.dcc.fua.br/~elaine/Requisitos25032004.ppt>. Acesso em: 20 set. 2004.
OLIVEIRA, Juliano Lopes. Técnicas e ferramentas para engenharia de requisitos.
Apresentação do Curso de Especialização em Análise e Projeto de Sistemas de
Informação. Disponível em:
<http://www.inf.ufg.br/~juliano/ensino/especializacao/cursoapsi/2004/analise.html>.
Acesso em: 20 set. 2004.
PALADINI, Edson Pacheco. Gestão da qualidade: teoria e prática. São Paulo:
Atlas, 2000. 330 p.
55
PONTIFICIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO. Engenharia de
requisitos. Apresenta informações referente ao projeto PER. Disponível em:
<http://www.er.les.inf.puc-rio.br/er_portugues.htm>. Acesso em: 20 set. 2004.
______. Workshop em engenharia de requisitos. Artigos publicados no WER.
Disponível em: <http://wer.inf.puc-rio.br/index.html>. Acesso em: 20 set. 2004.
PRESSMAN, Roger S. Engenharia de software. São Paulo: Makron Books, 1995.
1056 p.
PROVISION. Proforma corporation. Apresenta um software de análise e
ferramentas de simulação para todos os aspectos de negócio, inclusive estratégia,
processos, sistemas e tecnologia. Disponível em: <http://www.proformacorp.com>.
Acesso em: 23 set.2004.
ROCCO, Giovanni Ely. Engenharia de requisitos. Caxias do Sul: Universidade de
Caxias do Sul, 2004. Disponível em: <http://dein.ucs.br/profs/gerocco>. Acesso em:
23 mar. 2005.
SILVA, Lyrene Fernandes da; LEITE, Julio Cesar Sampaio do Prado; BREITMAN,
Karin Koogan. C&L: Uma ferramenta de apoio à engenharia de requisitos. Rio de
Janeiro: Pontifícia Universidade Católica do Rio de Janeiro, 2004. Disponível em:
<http://139.82.24.189/cel/>. Acesso em: 09 mar. 2005.
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Addison-Wesley, 2003.
592 p.
TORANZO, Marco A.; CASTRO, Jaelson F. B. Uma Proposta para rastreamento de
requisitos e representação de informação. In: WORKSHOP DE ENGENHARIA DE
REQUISITOS, 1998, Maringá. Anais... Rio de Janeiro: PUC, 1998. Disponível em:
<http://www.di.ufpe.br/~formlab/artigos/wer98/wer98_reduzirFolha.html>. Acesso
em: 23 set. 2004.
USERVISION. UserVision RDM. Apresenta uma ferramenta voltada para o
processo de desenvolvimento e gerenciamento de requisitos de software. Disponível
em: <http://www.innovative.inf.br>. Acesso em: 23 set. 2004.
ZANLORENCI, Edna Pacheco; BURNETT, Robert Carlisle. Engenharia de
requisitos: conceitos e fundamentos. Bate byte, Paraná, n. 77, jul 1998. Disponível
em: <http://www.pr.gov.br/batebyte/edicoes/1998/bb77/engenharia.htm>. Acesso
em: 23 set. 2004.
56
APÊNDICE
APÊNDICE A – Quadros dos cenários obtidos na ferramenta C&L
Titulo:
Objetivo:
Contexto:
Atores:
Recursos:
Elaboração de procedimento
Elaborar Procedimento
Necessidade de documentar uma atividade no SGQ, aprovada no Comitê Qualidade.
Usuário
Software, Manuais, Legislação, Norma e Procedimento de Controle de Documentos.
Código e Revisão do documento deve ser seqüencial e único. A data deve ser do dia
Exceção:
em que foi concluída a redação do documento.
O Coordenador da Qualidade deve definir o Código, Redator, Responsável pela
Homologação e Objetivo do Procedimento;O Redator deve preencher os demais
campos do Procedimento: Título, página, campo de aplicação, responsabilidade,
Episódios:
documentos complementares, materiais necessários, método, registro das revisões e
anexos. O Redator deve finalizar a redação do Procedimento;Depois de finalizado o
documento deve ser encaminhado para APROVAÇÃO DE PROCEDIMENTO.
Quadro do cenário elaboração de procedimento
Fonte: Dados da pesquisa
Titulo:
Objetivo:
Contexto:
Atores:
Recursos:
Exceção:
Aprovação de procedimento
Aprovar Procedimento
O Procedimento foi elaborado ou revisado, porém não foi aprovado.
Usuário
Software
O Procedimento não ter sido finalizado na elaboração.
O Responsável pela Homologação deve acessar o Procedimento elaborado e avaliar o
conteúdo.O Responsável pela Homologação deve definir quais colaboradores
receberão cópia controlada.O Responsável pela Homologação deve finalizar a
Episódios:
aprovação caso o Procedimento esteja adequado. Caso não esteja é devolvido ao
Redator com as considerações para alteração.Depois de finalizado e aprovado o
documento deve ser encaminhado para VERIFICAÇÃO DO PROCEDIMENTO.
Quadro do cenário aprovação de procedimento
Fonte: Dados da pesquisa
Titulo:
Objetivo:
Contexto:
Atores:
Recursos:
Exceção:
Verificação do procedimento
Verificar adequação do Procedimento conforme Objetivo e Norma.
O Procedimento foi aprovado.
Usuário
Software, Norma de Referência do SGQ, Procedimento de Controle de Documentos.
O Procedimento não ter sido finalizado na aprovação.
O Coordenador da Qualidade deve verificar a adequação do Procedimento em relação
a Norma de Referência do SGQ e ao Procedimento de Controle de Documentos. O
Episódios: Coordenador da Qualidade deve finalizar a verificação caso o Procedimento esteja
adequado. Caso não esteja é devolvido ao Redator.Depois de finalizado o documento
deve ser encaminhado para DISTRIBUIÇÃO DO PROCEDIMENTO.
Quadro do cenário verificação do procedimento
Fonte: Dados da pesquisa
57
Titulo:
Objetivo:
Contexto:
Atores:
Recursos:
Exceção:
Distribuição do procedimento
Distribuir Procedimento
O Procedimento foi verificado.
Usuário
Software
O Procedimento não ter sido finalizado na verificação.
Os procedimentos finalizados na verificação devem ficar disponíveis ao Coordenador
da Qualidade para distribuição, sendo o responsável pela distribuição das cópias dos
Episódios: documentos.Caso o procedimento venha de uma revisão deve ser feita uma cópia do
procedimento atual e colocar em status alterado, somente o Coordenador da
Qualidade tem acesso a este documento.
Quadro do cenário distribuição do procedimento
Fonte: Dados da pesquisa
Titulo:
Objetivo:
Contexto:
Atores:
Recursos:
Exceção:
Revisão de procedimento
Revisar Procedimento
Necessidade de alterar um Procedimento que está distribuído.
Usuário
Software
O Usuário deve preencher um campo Observação com as alterações proposta ao
Procedimento e enviar ao Responsável pela Homologação do Procedimento.
Uma cópia do Procedimento atual deve ser feita para ser enviada para as alterações.
O Responsável pela Homologação do Procedimento deve avaliar o Pedido de Revisão
e finalizar.
Caso o Pedido de Revisão for aceite deve ser enviado ao Coordenador da Qualidade,
Episódios: caso contrário volta para o usuário que realizou o pedido com a justificativa.
O Coordenador da Qualidade deve avaliar o Pedido de Revisão e finalizar.
Caso o Pedido de Revisão for aceite deve ser enviado ao Redator do Procedimento
para que proceda as alterações e finalize a alteração disponibilizando o Procedimento
para o processo de APROVAÇÃO DE PROCEDIMENTO. Caso o pedido de revisão não seja
aceito pelo Coordenador da Qualidade, volta para o usuário que realizou o pedido e
para o Responsável pela Homologação do Procedimento com a justificativa.
Quadro do cenário revisão de procedimento
Fonte: Dados da pesquisa
Titulo:
Objetivo:
Cancelamento de procedimento
Cancelar Procedimento
Atividade não existe mais na organização e o cancelamento foi aprovado pelo Comitê
Contexto:
da Qualidade.
Atores:
Usuário
Recursos: Software
Exceção: Procedimento deve estar elaborado.
O Coordenador da Qualidade deve acessar o procedimento e cancelar informando o
motivo.
Episódios: O Coordenador da Qualidade deve definir quais Colaboradores tem acesso ao
Procedimento.
Este procedimento deve ficar arquivado somente para leitura com status de Cancelado.
Quadro do cenário cancelamento de procedimento
Fonte: Dados da pesquisa
58
Titulo:
Objetivo:
Controle de formulários
Criar um controle de formulários existentes no SGQ.
O formulário deve ser gerado por um determinado procedimento e deve ser
Contexto:
apresentado em anexo ao mesmo.
Atores:
Usuário
Recursos: Software, Manuais, Legislação, Norma e Procedimento.
Exceção:
O redator deve criar o formulário no momento da ELABORAÇÃO DE PROCEDIMENTO e este
Episódios:
deve estar em anexo ao procedimento.
Quadro do cenário controle de formulários
Fonte: Dados da pesquisa
Titulo:
Objetivo:
Controle da matriz de documentos
Criar um controle da matriz de documentos.
Relacionar os documentos do SGQ, referenciando-os aos requisitos da Norma de
Contexto:
referência.
Atores:
Usuários
Recursos: Software, Norma de Referência, Documentos
Exceção:
O Coordenador da Qualidade deve cadastrar todos os requisitos da Norma de
Episódios:
Referência e relacionar com os documentos existentes no SGQ.
Quadro do cenário controle da matriz de documentos
Fonte: Dados da pesquisa
Titulo:
Objetivo:
Controle de documentos complementares
Criar um controle de documentos complementares e/ou de origem externa.
Indicar de modo preciso a localização dos documentos possibilitando assim, rápido
Contexto:
acesso aos mesmos.
Atores:
Usuário
Recursos: Software, Normas e Procedimento de Controle de Documentos.
Exceção:
O Coordenador da Qualidade deve cadastrar os documentos informando todos os
Episódios:
campos necessários conforme definido no Procedimento de Controle de Documentos.
Quadro do cenário controle de documentos complementares
Fonte: Dados da pesquisa
Titulo:
Objetivo:
Controle de documentos regulamentares
Criar um controle de documentos Regulamentares e/ou Estatutários.
Indicar de modo preciso a localização dos regulamentos, leis ou normas que permitem
Contexto:
a realização dos serviços, possibilitando assim, rápido acesso aos mesmos.
Atores:
Usuário
Recursos: Software, Normas, Leis e Procedimento de Controle de Documentos.
Exceção:
O Coordenador da Qualidade deve cadastrar os documentos informando todos os
Episódios:
campos necessários conforme definido no Procedimento de Controle de Documentos.
Quadro do cenário controle de documentos regulamentares
Fonte: Dados da pesquisa
59
APÊNDICE B – Quadros dos léxicos identificados na ferramenta C&L
Nome:
Colaboradores
Noção:
Pessoa que deve fazer parte do quadro de funcionários da organização
Classificação: Sujeito
Impacto(s):
Pode ser usuário
Sinônimo:
Colaborador
Quadro do termo colaboradores
Fonte: Dados da pesquisa
Nome:
Noção:
Classificação:
Impacto(s):
Comitê da qualidade
Grupo de colaboradores
Sujeito
Planejar, coordenar, orientar e dar suporte ao SGQ.
Realizar análise crítica do SGQ.
Estabelecer os objetivos da qualidade.
Sinônimo:
Quadro do termo comitê da qualidade
Fonte: Dados da pesquisa
Nome:
Noção:
Classificação:
Impacto(s):
Coordenador da qualidade
Deve ser um colaborador
Sujeito
Assegurar, como representante da direção, que os processos necessários para o
SGQ sejam estabelecidos, implementados e mantidos.
Estabelecer e manter procedimento para o controle de todos os documentos e
registros pertencentes ao SGQ.
Controlar alterações dos documentos do SGQ.
Estabelecer e manter procedimentos para identificar, coletar, indexar, acessar,
arquivar, armazenar, manter e dispor os registros do SGQ.
Sinônimo:
Quadro do termo coordenador da qualidade
Fonte: Dados da pesquisa
Nome:
Noção:
Norma
Documentos para estabelecimento de regras, diretrizes ou características técnicas
a serem aplicadas em materiais, produtos, processos e serviços, visando a
garantia dos seus resultados adaptados aos seus propósitos.
Objeto
Elaboração, Verificação, revisão de procedimentos.
Classificação:
Impacto(s):
Sinônimo:
Quadro do termo norma
Fonte: Dados da pesquisa
60
Nome:
Noção:
Classificação:
Impacto(s):
Procedimento
Forma especifica de executar uma atividade ou um processo
Objeto
Devem ser XXA para procedimento Administrativo, XXO para procedimento
Operacional.
Sinônimo:
Quadro do termo procedimento
Fonte: Dados da pesquisa
Nome:
Redator
Noção:
Deve ser um colaborador
Classificação: Sujeito
Impacto(s):
Responsável por redigir o procedimento
Sinônimo:
Quadro do termo redator
Fonte: Dados da pesquisa
Nome:
Responsável pela homologação
Noção:
Deve ser um colaborador
Classificação: Sujeito
Impacto(s):
Responsável por analisar o procedimento em relação à atividade
Sinônimo:
Quadro do termo responsável pela homologação
Fonte: Dados da pesquisa
Nome:
Sgq
É um sistema de gestão para dirigir e controlar uma organização no que diz
Noção:
respeito à qualidade.
Classificação: Sujeito
Impacto(s):
Sistema
Sinônimo:
Sistema de gestão da qualidade
Quadro do termo SGQ
Fonte: Dados da pesquisa
61
APÊNDICE C – XML do projeto gerado através da ferramenta C&L
<?xml version="1.0" encoding="ISO-8859-1" ?>
- <projeto>
<nome>SGQ - Gestão de Documentos</nome>
- <cenario>
<titulo id="elaboracao de procedimento">Elaboração De Procedimento</titulo>
- <objetivo>
<sentenca>Elaborar Procedimento</sentenca>
<PT />
</objetivo>
- <contexto>
<sentenca>Necessidade de documentar uma atividade dentro do SGQ,
aprovado pelo Comitê da Qualidade.</sentenca>
<PT />
</contexto>
- <atores>
<sentenca>Usuário</sentenca>
<PT />
</atores>
- <recursos>
<sentenca>Software, Manuais, Legislação, Norma e Procedimento de
Controle de Documentos.</sentenca>
<PT />
</recursos>
- <episodios>
<sentenca>O Coordenador da Qualidade deve definir o Código, Redator,
Responsável pela Homologação e Objetivo do Procedimento; O
Redator deve preencher os demais campos do Procedimento: Título,
página, campo de aplicação, responsabilidade, documentos
complementares, materiais necessários, método, registro das
revisões, anexos. O Redator deve finalizar a redação do
Procedimento; Depois de finalizado o documento deve ser
encaminhado para aprovação de procedimento.</sentenca>
<PT />
</episodios>
- <excecao>
<sentenca>Código e Revisão do documento deve ser sequencial e
único. A data deve ser do dia em que foi concluída a redação do
documento.</sentenca>
<PT />
</excecao>
</cenario>
- <cenario>
<titulo id="verificacao do procedimento">Verificação Do Procedimento</titulo>
- <objetivo>
<sentenca>Verificar adequação do Procedimento conforme Objetivo e
Norma.</sentenca>
<PT />
</objetivo>
- <contexto>
<sentenca>O Procedimento foi aprovado.</sentenca>
<PT />
</contexto>
- <atores>
<sentenca>Usuário</sentenca>
<PT />
</atores>
62
- <recursos>
<sentenca>Software, Norma de Referência do SGQ, Procedimento de
Controle de Documentos.</sentenca>
<PT />
</recursos>
- <episodios>
<sentenca>O Coordenador da Qualidade deve verificar a adequação do
Procedimento em relação a Norma de Referência do SGQ e ao
Procedimento de Controle de Documentos. O Coordenador da
Qualidade deve finalizar a verificação caso o Procedimento esteja
adequado. Caso não esteja é devolvido ao Redator com as
considerações para alteração. Depois de finalizado o documento
deve ser encaminhado para distribuição do
procedimento.</sentenca>
<PT />
</episodios>
- <excecao>
<sentenca>O Procedimento não ter sido finalizado na
aprovação.</sentenca>
<PT />
</excecao>
</cenario>
- <cenario>
<titulo id="aprovacao de procedimento">Aprovação De Procedimento</titulo>
- <objetivo>
<sentenca>Aprovar Procedimento</sentenca>
<PT />
</objetivo>
- <contexto>
<sentenca>O Procedimento foi elaborado ou revisado, porém não foi
aprovado.</sentenca>
<PT />
</contexto>
- <atores>
<sentenca>Usuário</sentenca>
<PT />
</atores>
- <recursos>
<sentenca>Software</sentenca>
<PT />
</recursos>
- <episodios>
<sentenca>O Responsável pela Homologação deve acessar o
Procedimento elaborado e avaliar o conteúdo. O Responsável pela
Homologação deve definir quais colaboradores receberão cópia
controlada. O Responsável pela Homologação deve finalizar a
aprovação caso o Procedimento esteja adequado. Caso não esteja é
devolvido ao Redator com as considerações para alteração. Depois
de finalizado e aprovado o documento deve ser encaminhado para
verificação do procedimento.</sentenca>
<PT />
</episodios>
- <excecao>
<sentenca>O Procedimento não ter sido finalizado na
elaboração.</sentenca>
<PT />
</excecao>
</cenario>
- <cenario>
63
<titulo id="cancelamento de procedimento">Cancelamento De
Procedimento</titulo>
- <objetivo>
<sentenca>Cancelar Procedimento</sentenca>
<PT />
</objetivo>
- <contexto>
<sentenca>Atividade não existe mais na organização e o cancelamento
foi aprovado pelo Comitê da Qualidade.</sentenca>
<PT />
</contexto>
- <atores>
<sentenca>Usuário</sentenca>
<PT />
</atores>
- <recursos>
<sentenca>Software</sentenca>
<PT />
</recursos>
- <episodios>
<sentenca>O Coordenador da Qualidade deve acessar o procedimento e
cancelar informando o motivo. O Coordenador da Qualidade deve
definir quais Colaboradores tem acesso ao Procedimento. Este
procedimento deve ficar arquivado somente para leitura com status
de Cancelado.</sentenca>
<PT />
</episodios>
- <excecao>
<sentenca>Procedimento deve estar elaborado.</sentenca>
<PT />
</excecao>
</cenario>
- <cenario>
<titulo id="revisao de procedimento">Revisão De Procedimento</titulo>
- <objetivo>
<sentenca>Revisar Procedimento</sentenca>
<PT />
</objetivo>
- <contexto>
<sentenca>Necessidade de alterar um Procedimento que está
distribuído.</sentenca>
<PT />
</contexto>
- <atores>
<sentenca>Usuário</sentenca>
<PT />
</atores>
- <recursos>
<sentenca>Software</sentenca>
<PT />
</recursos>
- <episodios>
<sentenca>O Usuário deve preencher um campo Observação com as
alterações proposta ao Procedimento e enviar ao Responsável pela
Homologação do Procedimento. Uma cópia do Procedimento atual
deve ser feita para ser enviada para as alterações. O Responsável
pela Homologação do Procedimento deve avaliar o Pedido de
Revisão e finalizar. Caso o Pedido de Revisão for aceite deve ser
enviado ao Coordenador da Qualidade, caso contrário volta para o
usuário que realizou o pedido com a justificativa. O Coordenador da
64
Qualidade deve avaliar o Pedido de Revisão e finalizar. Caso o
Pedido de Revisão for aceite deve ser enviado ao Redator do
Procedimento para que proceda as alterações e finalize a alteração
disponibilizando o Procedimento para o processo de aprovação de
procedimento. Caso o pedido de revisão não seja aceito pelo
Coordenador da Qualidade, volta para o usuário que realizou o
pedido e para o Responsável pela Homologação do Procedimento
com a justificativa.</sentenca>
<PT />
</episodios>
- <excecao>
<sentenca />
<PT />
</excecao>
</cenario>
- <cenario>
<titulo id="distribuicao do procedimento">Distribuição Do
Procedimento</titulo>
- <objetivo>
<sentenca>Distribuir Procedimento</sentenca>
<PT />
</objetivo>
- <contexto>
<sentenca>O Procedimento foi verificado.</sentenca>
<PT />
</contexto>
- <atores>
<sentenca>Usuário</sentenca>
<PT />
</atores>
- <recursos>
<sentenca>Software</sentenca>
<PT />
</recursos>
- <episodios>
<sentenca>Os procedimentos finalizados na verificação devem ficar
disponíveis ao Coordenador da Qualidade para distribuição, sendo
o responsável pela distribuição das cópias dos documentos. Caso o
procedimento venha de uma revisão deve ser feita uma cópia do
procedimento atual e colocar em status alterado, somente o
Coordenador da Qualidade tem acesso a este
documento.</sentenca>
<PT />
</episodios>
- <excecao>
<sentenca>O Procedimento não ter sido finalizado na
verificação.</sentenca>
<PT />
</excecao>
</cenario>
- <cenario>
<titulo id="controle da matriz de documentos">Controle Da Matriz De
Documentos</titulo>
- <objetivo>
<sentenca>Criar um controle da matriz de documentos.</sentenca>
<PT />
</objetivo>
- <contexto>
<sentenca>Relacionar os documentos do SGQ, referenciando-os aos
requisitos da Norma de referência.</sentenca>
65
<PT />
</contexto>
- <atores>
<sentenca>Usuários</sentenca>
<PT />
</atores>
- <recursos>
<sentenca>Software, Norma de Referência, Documentos</sentenca>
<PT />
</recursos>
- <episodios>
<sentenca>O Coordenador da Qualidade deve cadastrar todos os
requisitos da Norma de Referência e relacionar com os documentos
existentes no SGQ.</sentenca>
<PT />
</episodios>
- <excecao>
<sentenca />
<PT />
</excecao>
</cenario>
- <cenario>
<titulo id="controle de formularios">Controle De Formulários</titulo>
- <objetivo>
<sentenca>criar um controle de formulários existentes no
SGQ.</sentenca>
<PT />
</objetivo>
- <contexto>
<sentenca>O formulário deve ser gerado por um determinado
procedimento e deve ser apresentado em anexo ao
mesmo.</sentenca>
<PT />
</contexto>
- <atores>
<sentenca>Usuário</sentenca>
<PT />
</atores>
- <recursos>
<sentenca>Software, Manuais, Legislação, Norma e
Procedimento.</sentenca>
<PT />
</recursos>
- <episodios>
<sentenca>O redator deve criar o formulário no momento da elaboração
de procedimento e este deve estar em anexo ao
procedimento.</sentenca>
<PT />
</episodios>
- <excecao>
<sentenca />
<PT />
</excecao>
</cenario>
- <cenario>
<titulo id="controle de documentos regulamentares">Controle De Documentos
Regulamentares</titulo>
- <objetivo>
<sentenca>Criar um controle de documentos Regulamentares e/ou
Estatutários.</sentenca>
66
<PT />
</objetivo>
- <contexto>
<sentenca>Indicar de modo preciso a localização dos regulamentos, leis
ou normas que permitem a realização dos serviços, possibilitando
assim, rápido acesso aos mesmos.</sentenca>
<PT />
</contexto>
- <atores>
<sentenca>Usuário</sentenca>
<PT />
</atores>
- <recursos>
<sentenca>Software, Normas, Leis e Procedimento de Controle de
Documentos.</sentenca>
<PT />
</recursos>
- <episodios>
<sentenca>O Coordenador da Qualidade deve cadastrar os documentos
informando todos os campos necessários conforme definido no
Procedimento de Controle de Documentos.</sentenca>
<PT />
</episodios>
- <excecao>
<sentenca />
<PT />
</excecao>
</cenario>
- <cenario>
<titulo id="controle de documentos complementares">Controle De
Documentos Complementares</titulo>
- <objetivo>
<sentenca>Criar um controle de documentos complementares e/ou de
origem externa.</sentenca>
<PT />
</objetivo>
- <contexto>
<sentenca>Indicar de modo preciso a localização dos documentos
possibilitando assim, rápido acesso aos mesmos.</sentenca>
<PT />
</contexto>
- <atores>
<sentenca>Usuário</sentenca>
<PT />
</atores>
- <recursos>
<sentenca>Software, Normas e Procedimento de Controle de
Documentos.</sentenca>
<PT />
</recursos>
- <episodios>
<sentenca>O Coordenador da Qualidade deve cadastrar os documentos
informando todos os campos necessários conforme definido no
Procedimento de Controle de Documentos.</sentenca>
<PT />
</episodios>
- <excecao>
<sentenca />
<PT />
</excecao>
67
</cenario>
- <lexico>
- <nome_simbolo id="sgq">
<texto>Sgq</texto>
</nome_simbolo>
- <nocao>
- <sentenca>
É um sistema de gestão para dirigir e controlar uma organização
no que diz respeito à qualidade.
<PT />
</sentenca>
</nocao>
- <impacto>
- <sentenca>
sistema
<PT />
</sentenca>
</impacto>
</lexico>
- <lexico>
- <nome_simbolo id="redator">
<texto>Redator</texto>
</nome_simbolo>
- <nocao>
- <sentenca>
Deve ser um colaborador
<PT />
</sentenca>
</nocao>
- <impacto>
- <sentenca>
Responsável por redigir o procedimento
<PT />
</sentenca>
</impacto>
</lexico>
- <lexico>
- <nome_simbolo id="colaboradores">
<texto>Colaboradores</texto>
</nome_simbolo>
- <nocao>
- <sentenca>
Pessoa que deve fazer parte do quadro de funcionários da
organização
<PT />
</sentenca>
</nocao>
- <impacto>
- <sentenca>
Pode ser usuário
<PT />
</sentenca>
</impacto>
</lexico>
- <lexico>
- <nome_simbolo id="responsavel pela homologacao">
<texto>Responsável Pela Homologação</texto>
</nome_simbolo>
- <nocao>
- <sentenca>
68
Deve ser um colaborador
<PT />
</sentenca>
</nocao>
- <impacto>
- <sentenca>
Responsável por analisar o procedimento em relação a atividade
<PT />
</sentenca>
</impacto>
</lexico>
- <lexico>
- <nome_simbolo id="comite da qualidade">
<texto>Comitê Da Qualidade</texto>
</nome_simbolo>
- <nocao>
- <sentenca>
Grupo de colaboradores
<PT />
</sentenca>
</nocao>
- <impacto>
- <sentenca>
Planejar, coordenar, orientar e dar suporte ao SGQ. Realizar
análise crítica do SGQ. Estabelecer os objetivos da qualidade.
<PT />
</sentenca>
</impacto>
</lexico>
- <lexico>
- <nome_simbolo id="procedimento">
<texto>Procedimento</texto>
</nome_simbolo>
- <nocao>
- <sentenca>
forma especifica de executar uma atividade ou um processo
<PT />
</sentenca>
</nocao>
- <impacto>
- <sentenca>
Devem ser XXA para procedimento Admnistrativo, XXO para
procedimento Operacional.
<PT />
</sentenca>
</impacto>
</lexico>
- <lexico>
- <nome_simbolo id="norma">
<texto>Norma</texto>
</nome_simbolo>
- <nocao>
- <sentenca>
Documentos para estabelecimento de regras, diretrizes ou
características técnicas a serem aplicadas em materiais,
produtos, processos e serviços, visando a garantia dos seus
resultados adaptados aos seus propósitos.
<PT />
</sentenca>
</nocao>
69
- <impacto>
- <sentenca>
Elaboração, Verificação, revisão de procedimentos.
<PT />
</sentenca>
</impacto>
</lexico>
- <lexico>
- <nome_simbolo id="coordenador da qualidade">
<texto>Coordenador Da Qualidade</texto>
</nome_simbolo>
- <nocao>
- <sentenca>
Deve ser um colaborador
<PT />
</sentenca>
</nocao>
- <impacto>
- <sentenca>
Assegurar, como representante da direção, que os processos
necessários para o SGQ sejam estabelecidos, implementados e
mantidos. Estabelecer e manter procedimento para o controle de
todos os documentos e registros pertencentes ao SGQ. Controlar
alterações dos documentos do SGQ. Estabelecer e manter
procedimentos para identificar, coletar, indexar, acessar,
arquivar, armazenar, manter e dispor os registros do SGQ.
<PT />
</sentenca>
</impacto>
</lexico>
</projeto>