Uma Estratgia para Implantao de uma Gerencia de

Requisitos Visando a Melhoria Dos Processos de Software

Ana Elizabete Souza de Carvalho, Helena Cristina Tavares, Jaelson Brelaz Castro
Centro de Informtica, Univesidade Federal de Pernanbuco
{ana-elizabete.carvalho, helena-cristina.tavares}@serpro.gov.ar, jbc@cin.ufpe.br
Resumo. A indstria de software vem demonstrando crescente interesse em
engenharia de requisitos, isto , entender o que se deseja construir antes de
comear a faz-lo. Esto percebendo que o tempo utilizado no entendimento do
problema um excelente investimento. Os requisitos de software so a base a
partir da qual a qualidade medida. Desta forma, a falta de conformidade aos
requisitos significa falta de qualidade. O modelo de avaliao de maturidade do
processo de desenvolvimento CMM (Capability Maturity Model) considera o
gerenciamento de requisitos como sendo uma das primeiras etapas para
alcanar a maturidade organizacional, e para haver o gerenciamento preciso
que o processo de desenvolvimento de requisitos esteja implantado na empresa.
Desta forma, para se alcanar a gerncia de requisitos necessrio que os
requisitos tenham sido definidos, e importante que a empresa tambm possua
seus processos de desenvolvimento de requisitos definidos.
Este artigo tem por objetivo definir uma estratgia para a implantao dos
processos de desenvolvimento e gerenciamento de requisitos para os projetos de
desenvolvimento e manuteno de software sob responsabilidade do SERPRO,
estabelecendo um entendimento comum entre o cliente e a equipe de projeto
quanto aos requisitos que sero atendidos no projeto de software.
Palavras chaves: requisitos, processos, gerenciamento.

1. Introduo
Ultimamente tem havido um grande interesse na comunidade de engenharia de
software na melhoria do processo. As empresas precisam medir a sua capacidade de
desenvolver software com qualidade. Para isto, esto utilizando o modelo CMM
(Capability Maturity Model), que um modelo gerencial que organiza as melhores
prticas existentes, embora os padres e as prticas que so aplicveis no sejam
completamente definidos.
Em geral, o desenvolvimento de software comercial responde rapidamente s
mudanas tecnolgicas [1]. Por isso, importante investir no processo de melhoria
contnua para o aumento da qualidade focalizando a engenharia de requisitos.
Encontram-se algumas tentativas de uso de requisitos nas organizaes mas,
infelizmente, as tentativas comeam pela fase do gerenciamento do ciclo de vida e
rastreabilidade dos requisitos, iniciada por um processo de avaliao de maturidade
do nvel organizacional SEI-CMM [2], sem antes ter o domnio da importante fase de
descobrimento de requisitos, a partir do descobrimento dos fatos e fenmenos do
32

ambiente ou domnio da aplicao [3]. Por isso, importante que a empresa tambm
possua seus processos para o desenvolvimento de requisitos definidos.
Na prxima Seo, descrita a importncia da Qualidade de Software e o contexto
do SERPRO. Na Seo 3, os processos a serem executados para a implantao da
Gerncia de Requisitos que foram definidos pelo SERPRO so descritos. Na Seo 4,
as fases utilizadas para a implantao dos processos para a gerncia de requisitos
definidos so descritas. Na seo 5 feito um mapeamento entre a proposta
apresentada e as prticas do CMM para a Gerncia de Requisitos. Uma descrio
breve do estudo de caso apresentada na Seo 6 e, a Seo 7 composta das
concluses e trabalhos futuros.

2. Importncia da Qualidade de Software

A cada dia, as empresas tornam-se mais dependentes dos seus sistemas de
informaes. Construir esses sistemas, em tempo hbil para serem teis aos negcios,
com a qualidade e custos adequados sua importncia para a organizao, o desafio
que todos os desenvolvedores esto enfrentando.
Pressman define qualidade de software como conformidade a requisitos
funcionais e de desempenho explicitamente declarados, a padres de
desenvolvimento claramente documentados e a caractersticas implcitas que so
esperadas de todo software profissionalmente desenvolvido [4].
Diversos modelos, ferramentas e propostas tem sido projetadas, desenvolvidas e
sugeridas nos ltimos anos, visando permitir as empresas a se capacitarem
evolutivamente para o projeto de software, agregando cultura empresarial
mecanismos de medies e controle, bem como de evoluir toda a tcnica utilizada
sempre que necessrio.
Entre as abordagens para a melhoria da qualidade, destaca-se aquela que atua nos
processos utilizados por uma organizao de software. O modelo CMM (Capability
Maturity Model) foi desenvolvido para guiar a melhoria da qualidade, por meio da
maturidade da capacidade dos processos de software.
A capacitao do processo permite uma maior previsibilidade de desempenho. A
maturidade de um processo de software de uma organizao ajuda a prever a
habilidade em atingir suas metas. Quanto maior for a capacidade do processo, mais
benefcios podem ser alcanados, tanto para o cliente (interno ou externo) quanto para
os desenvolvedores [5].
O CMM um modelo utilizado para medir a maturidade de uma organizao nos
seus processos de desenvolvimento de software. um modelo gerencial que organiza
as melhores prticas existentes. Segundo o modelo CMM, quanto maior o controle
sobre o processo de desenvolvimento, mais madura a organizao. organizado em
cinco nveis de maturidade, considerados como a principal caracterstica do modelo.
Nvel de maturidade um estgio evolutivo bem definido para alcanar um processo
de software maduro. Cada nvel de maturidade indica um nvel de capacidade do
processo, visando a melhoria contnua do processo de desenvolvimento de software
[6]. Com exceo do nvel 1, cada nvel composto por vrias reas-chave de
Processo (ACPs). Estas reas conduzem ao alcance das metas de melhoria de um
determinado nvel [7].
33

A primeira ACP do CMM para atingir o Nvel 2 (figura 3) a Gerncia de

Requisitos, a qual estabelece as diretrizes para um comum entendimento entre o
cliente e os requisitos de seu projeto de software, que sero conduzidos pela equipe do
desenvolvimento. Este acordo com o cliente a base para planejar e administrar o
projeto de software. O controle das relaes com o cliente depende de um efetivo
controle do processo da mudana. Mas, para que a Gerncia de Requisitos seja
implantada na organizao necessrio que um processo de Engenharia de Requisitos
esteja implantado.
Como Empresa de Tecnologia da Informao, o SERPRO atua num mercado em
permanente ebulio, por isso iniciou um processo para identificao e implantao
das melhores prticas para elevar o estgio de maturidade do processo de
desenvolvimento de software.
Impulsionando este processo est a meta de atingir o nvel 2 de maturidade
segundo o modelo CMM (Capability Maturity Model) do SEI at o final de 2002. E,
os trabalhos iniciais verificaram que a falta de uma efetiva gerncia de requisitos um
dos principais problemas a serem superados.
Dando incio estruturao interna de uma gerncia de requisitos, o SERPRO
participou do projeto Plataforma Tecnolgica em Engenharia de Requisitos Estratgias para o Aumento da Qualidade no Desenvolvimento de Sistemas [8], o
qual teve como objetivo estabelecer bases para o aumento da qualidade dos processos
de produo de software, por meio da cooperao entre universidades e
empresas, com nfase na utilizao da Engenharia de Requisitos.
A plataforma foi extremamente importante para um melhor conhecimento dos
problemas enfrentados pelas organizaes que participaram do projeto e da
possibilidade da cooperao com as instituies de pesquisa para minorar esses
problemas.
Identificados os problemas, os processos a serem executados para a implantao
da Gerncia de Requisitos foram definidos pelo SERPRO e so descritos na prxima
Seo.

3. O Processo para Implantao da Engenharia de Requisitos

visando a melhoria da Qualidade de Software
A definio dos processos para a gerncia de requisitos implantados no SERPRO
foram baseadas nas boas prticas existentes na empresa, na cultura da organizao e
nas caractersticas de seus clientes. Pesquisas em bibliografia existente, o apoio de
instituies de pesquisa e a utilizao de benchmarking foram importantes para o
desenvolvimento do projeto.
A figura 1 resume a estrutura adotada. Para alcanar as metas, algumas atividades
precisam ser executadas por pessoas com papis bem definidos. O responsvel por
analisar e selecionar os requisitos coleta os requisitos de software, os quais so
revistos pelo Grupo de Engenharia de Software antes de sua incorporao no projeto.
Uma vez incorporados, os requisitos formam uma baseline, que ser a base para o
Contrato Tcnico entre o cliente e o desenvolvedor. Depois de validados, os requisitos
so utilizados pelo Grupo de Engenharia de Software para planejar os artefatos e as
atividades do desenvolvimento que iro compor o Plano de Desenvolvimento de
34

Software. Os desvios e as solicitaes de alterao de requisitos so revistos antes de

serem incorporados, seus impactos so avaliados, e os compromissos assumidos so
renegociados com as partes interessadas (stakeholders).

Meta 1- Requisitos so controlados

e a baseline estabelecida para a
Gesto da Engenharia
S f

Grupo de Eng.
de Software
responsvel por
analisar e alocar os
requisitos (Hb1)

Requisitos de
Sistemas (alocarHb2)

Rever os Requisitos
antes de serem
incorporados ao projeto
(At1)

Usar os Requisitos
para planejar os
Artefatos e
Atvidades(At2)

Requisito de
Software
Requisitos
Validados

PDS - Plano de
Desenvolvimento
de Software

Baselinede Requisitos:
Contrato Tcnico (Hb2)

Grupo de Eng.
de Software

Novas Baselines

Desvios e SAR'sSolictaes
(
de Alterao de Requisitos)

Habilidade Hb
( )

Meta 2- Planos, produtos, atividades

so mantidas consistentes com os
Requisitos

Rever as Mudanas e
incorporar as
alteraes
apropriadas (At3)

SAR - Solicitao
de Alterao de
Requisitos
Avaliar impactos e
renegociar
compromissos
Notificar /
Renegociar
Partes Interessadas

Atividade (At)
Subatividade
Plano

Responsvel por
analisar e alocar
os requisitos (Hb1)

Figura 1. rea-Chave de Processo Gerncia de Requisitos

Os processos devem definir as atividades que devero ser executadas para que as
metas sejam atingidas. Nesta proposta, os processos da Gerncia de Requisitos foram
divididos em: Definio, Gerenciamento & Mtricas, Validao e Verificao (figura
2) e definem as atividades a serem executadas por uma empresa que desenvolve
sistemas a partir das solicitaes de um cliente.
Ao receber uma Solicitao de Servio, o processo de Definio elabora o
documento de Viso, o Glossrio, o Documento de Requisitos de Software (DRS) e as
Matrizes de Rastreabilidade. Caso uma Solicitao de Alterao de Requisitos (SAR)
seja recebida, o processo para Gerenciamento & Mtricas de requisitos, juntamente
com as Matrizes de Rastreabilidade e o Documento de Requisitos de Software (DRS),
analisa os requisitos impactados, gera uma nova verso atualizada dos requisitos
(baseline), atualiza o Documento de Requisitos de Software (DRS) e comunica as
alteraes s reas envolvidas. Neste processo tambm so coletadas as mtricas para
controle. Durante o processo de Validao, o Documento de Requisitos de Software
(DRS) e demais artefatos so avaliados para a elaborao dos Casos de Testes, alm
das comunicao das reas envolvidas. O processo de Verificao recebe os artefatos
dos modelos do processo de desenvolvimento e avalia se esto de acordo com os
requisitos definidos.
35

As figuras 2 e 3 so apresentadas apenas com as entradas e sadas da tcnica

IDEF0. A Tabela 1 descreve as principais entradas e sadas dos processos descritos
anteriormente.
Solicitaa
de

Vis
Defini

SAR'

Plano de
Glossri
Matrize

1
A

DR
Gerenciament
e

Requisito
Impactado
Nova
DRS
Mtrica
Notificao para
reas

2
A
SAR'

Valida

Casos de
Notificao para
reas

4
SAR'
Verifica
Artefato

Atas de
3
A

Notificao para
reas

Figura 2. Grupos de Processos para a obteno da Gerncia de Requisitos

A figura 4 apresenta o detalhamento do processo para a definio de requisitos
que foi exibido no macroprocesso da figura 2. composto de Elicitao, Anlise
&Documentao e Negociao & Priorizao (figura 4).
O processo de Elicitao dos Requisitos de Software recebe novos requisitos por
meio de uma Solicitao de Servio ou Solicitao de Alterao de Requisitos entre
outras fontes, e uma vez documentados e analisados, so elaboradas as Matrizes de
Rastreabilidade e o Documento de Requisitos de Software (DRS) entram num
processo para negociao de prioridades, conforme detalhado a seguir. A Elicitao
pode ser subdividida nas seguintes atividades, e seguem a ordem seqencial e o
paralelismo explicitado na figura 6 a qual utiliza o diagrama de atividades da UML
[9]:
Efetuar a reunio inicial com o cliente: Devem participar da reunio inicial
com o cliente todos as partes interessadas (stakeholders) candidatos. Nesta
reunio devem ser obtidos os principais assuntos que devero estar presentes
no Documento de Viso.

36

ENTRADA
TIPO
OU SADA
Solicitao
entrada
de Servio
SAR (Solici- entrada
tao de
Alterao de
Requisitos)

DESCRIO

Refere-se ao documento formal por meio do qual o sistema

solicitado pelo cliente.
Documento que deve ser preenchido quando h necessidade de
alterao ou incluso de requisitos. Especifica e documenta a
alterao de requisitos solicitada pelo stakeholder, estabelecendo as
bases para sua execuo, e condies de execuo (prioridades,
recursos envolvidos, recursos afetados, etc).
Viso
sada
Referem-se a informaes gerais sobre o sistema. Documento onde
fornecido o objetivo do sistema a ser desenvolvido; suas principais
caractersticas, funcionalidades e no-funcionalidades; os
stakeholders. Seu objetivo apresentar o sistema em linhas gerais,
fornecendo uma viso inicial. Documenta o ambiente geral de
processos a ser desen-volvido, fornecendo a todos os envolvidos uma
descrio compreensvel do sistema e suas macro-funcionalidades. O
objetivo do documento Viso definir as necessidades de alto-nvel e
caractersticas do sistema, focando nas potencialidades requeridas
pelos stakeholders e como estes requisitos sero abordados no
sistema.
Glossrio
entrada O objetivo do glossrio fornecer uma terminologia comum sobre o
e sada projeto a todos os envolvidos. Este conjunto de termos e conceitos
originais usado para definir um mapeamento especfico sobre o
domnio do problema, explicando os itens mais relevantes e as
descries de outros componentes do projeto. Alm de facilitar o
entendimento da aplicao, o Glossrio evita ambigidades no
entendimento das informaes, ao longo do processo.
Rastreabilida entrada Neste contexto, as Matrizes de Rastreabilidade mostram os
de
e sada relacionamentos entre os requisitos elicitados.
DRS (Docu- entrada composto pelo detalhamento dos requisitos. A DRS guarda a
mento de
e sada especificao dos requisitos de software, descritos num nvel de
Requisitos
detalhe que possibilite o entendimento de todos os envolvidos. A DRS
de
serve como base de comunicao entre os stakeholders, e ajuda a
Software)
manter um foco integrado no desenvolvimento.
Requisitos
sada
Referem-se aos requisitos que sero alterados em decorrncia da
Impactados
incluso ou alterao de requisitos.
Nova
sada
Baseline ou configurao base um conjunto de requisitos aprovados
Baseline
e revisados que representa o embasamento de um acordo de
evoluo e desenvolvimento; atualizada por meio da incluso ou
alterao de requisitos.
DRS
sada
Corresponde ao Documento de Requisitos de Software alterado em
atualizado
funo da incluso ou alterao de requisitos.
Notificao
sada
Refere-se comunicao a todos os que sero impactados pela
as reas
incluso ou alterao de requisitos.
envolvidas
Mtricas
sada
Informaes coletadas ao longo do gerenciamento de requisitos.
Casos de
sada
Devem estar includos no DRS (Documento de Requisitos de
Testes
Software).
Atas de
sada
Ser utilizada a Ata de Reunio para registrar as no-conformidades.
Verificao
Plano de
sada
Ser utilizado a Ata de Reunio para registrar os compromissos de
Reviso
reviso.

Tabela 1. Entradas e Sadas dos processos descritos

37

Entender o domnio da aplicao: A reunio inicial com o cliente fornecer

a base para determinar quais os principais domnios sero necessrios
estudar mais profundamente para o desenvolvimento do sistema. Uma das
principais dificuldades enfrentadas pelo desenvolvedor de software a
complexidade do domnio do problema [10]. Alm disso, os usurios e
desenvolvedores possuem perspectivas diferentes e fazem suposies
diferentes sobre a natureza da soluo [11]. Quando o desenvolvedor e o
usurio compartilham a mesma linguagem, melhora a comunicao entre
ambos. Em particular, se esta linguagem prpria do usurio esta
comunicao melhora consideravelmente [12].
Identificar as partes interessadas (stakeholders): Identifique as pessoas
interessadas pelo produto, ou participaro do seu desenvolvimento. Para
cada stakeholder importante identificar alm da funo, o nome do
stakeholder.
Glossrio

Solicitao
de Sistemas

Documentao

Elicitao
dos

DRS

& Anlise

Requisitos de

Priorizao

SAR's

Software

A11

A12
Viso

DRS

Negociao
&

3
Matrize
s
(Acompanhamento

Plano de Reviso

A1

e rastreabilidade)

Figura 3. Processos para a Definio de Requisitos

Escolher a tcnica de elicitao: Ao escolher a tcnica de elicitao deve-se

considerar quais as fontes dos requisitos, a disponibilidade das pessoas e os
tipos de requisitos a serem elicitados. A escolha da tcnica apropriada para
elicitar requisitos depende do tempo e recursos disponveis, assim como do
tipo de informao necessria. Algumas das classes de tcnicas de elicitao
so [13]:
o Tcnicas tradicionais inclui o uso de questionrios, entrevistas,
anlise de documentao existente [14];
Questionrios: questes predefinidas so distribudas para uma
amostragem significante e representativa de stakeholders e os
resultados so avaliados. So teis quando a quantidade de
stakeholders extremamente grande. Uma vez que todas as
questes podem ser predeterminadas, mais eficiente na
avaliao de tendncias de opinies a respeito de requisitos
especficos e bem definidos.
Entrevistas: Perguntar questes relacionadas aos stakeholders
e/ou suas necessidades a respeito do problema a ser resolvido e
38

escutar suas respostas [15]. So teis quando stakeholders

possuem muitos conhecimentos subjetivos e esto dispostos a
serem entrevistados. Para ser mais eficiente, o entrevistador
deve ser experiente.
Tcnicas de elicitao de grupo so tcnicas de dinmica de grupo
com o objetivo de entender de forma mais detalhada as
necessidades dos usurios, esto includas: brainstorming, sesses
JAD e RAD [16];
Brainstorming: stakeholders so reunidos em um local, num
ambiente que encoraje a participao, permitindo que todas as
idias sejam declaradas em voz alta (para que os demais
sejam influenciados) e escritas (para que no sejam perdidas)
[17]. mais eficaz quando cada stakeholder possui uma parte
do conhecimento de algum aspecto do problema.
Prototipao implementao parcial de um sistema de forma
rpida para obter feedback para o processo de requisitos. O
prottipo descartado. utilizada para elicitar requisitos quando h
um alto grau de incerteza ou quando necessrio um rpido
feedback dos usurios;
Tcnicas de modelagem fornece um modelo especfico das
informaes que sero adquiridas, e usa esse modelo para orientar o
processo de elicitao. Uma tcnica bastante utilizada o uso de
cenrios para representar as tarefas que os usurios executam
normalmente e aquelas que eles desejam executar [18]. Inclui
mtodos baseados em metas, tais como: KAOS [19] e I* [20] e
mtodos baseados em cenrios como CREWS [21].
Tcnicas cognitivas inclui uma srie de tcnicas originalmente
desenvolvidas para aquisio de conhecimento para sistemas
baseados em conhecimento, alguns exemplos so: Anlise de
protocolo, laddering, card sorting, repertory grids [22];
Tcnicas contextuais surgiu como uma alternativa para as tcnicas
tradicionais e cognitivas, inclui tcnicas de etnografia e anlise
social [23];
Etnografia: observar potenciais usurios em seu ambiente natural.
Resulta em uma percepo mais precisa do problema do que
perguntar aos usurios o que eles fazem [24]. So teis para suporte
automao de uma funo pouco ou no automatizada,
particularmente quando so disponveis a observadores treinados
sem noes preconcebidas do problema e de sua soluo.

Condies especficas do projeto devem definir a tcnica mais eficaz a ser

utilizada [25], ou a combinao delas. No SERPRO, as tcnicas mais
utilizadas so a entrevista, o uso de cenrios com Use Cases e a prototipao,
com o acompanhamento do cliente no s na fase de requisitos, mas durante
todo o processo de desenvolvimento do software. Um benefcio o
comprometimento do cliente e a participao direta na definio dos
39

documentos. Um cuidado, porm, deve ser tomado para a tendncia da no

utilizao dos processos para alterao de requisitos.
Incio
Efetuar a reunio inicial
com o Cliente
C1
.

Escolher e executar
Tcnicas de Elicitao

Identificar os
stakeholders
.

Entender o domnio
da aplicao

C2

Elaborar a lista de
Requisitos Candidatos
Estudar: os Requisitos candidatos sistemas
similares e os documentos do cliente
C3

Elaborar o Glossrio

Elaborar o documento de Viso

C4

Fim

Figura 4. Processos para a Elicitao de Requisitos

Elaborar a lista de Requisitos Candidatos: o objetivo desta atividade

descrever os principais requisitos do sistema, de forma a obter a essncia do
sistema, de forma que representar as principais necessidades e
funcionalidades do sistema e dever ser includa no documento de Viso.
Estudar os Requisitos Candidatos, os sistemas similares e os documentos
coletados com o cliente: documentos devem ser inspecionados, arquivos e
sistemas similares, para melhor compreender o contexto do sistema, e avaliar
a possibilidade de reusabilidade de requisitos e de solues.
Elaborar o Glossrio: para evitar ambigidades e facilitar a leitura de
documentos do sistema, importante a definio de um glossrio, onde os
principais termos utilizados pelo domnio da aplicao e
pelos
desenvolvedores e usurios devem ser definidos.
Elaborar o documento de Viso: o objetivo desta atividade descobrir os
principais requisitos do sistema, de forma a obter a essncia do sistema.
Deve-se avaliar o conjunto de requisitos essenciais para a definio do
Documento de Viso do software e este deve incluir o escopo do projeto e
suas limitaes, bem como as principais caractersticas do software a ser
desenvolvido.

A Documentao & Anlise (figura 7) deve possuir as seguintes atividades:

40

Descrever os requisitos e os seus atributos: depois que os requisitos do

sistema so elicitados, eles devem ser documentados com um nvel
apropriado de detalhes. Na maior parte das organizaes os requisitos so
escritos em linguagem natural, pois uma notao que de fcil
entendimento para uma grande variedade de stakeholders. Entretanto, o nvel
de abstrao dos requisitos varia de acordo com a organizao e deve ser
definido de acordo com o projeto ou at mesmo com o tipo de requisito. O
principal foco da pesquisa em documentao de requisitos prover notaes
e linguagens de especificao. Desde linguagem natural [26] lgica [27],
diferentes linguagens tm sido propostas para expressar e descrever
requisitos. Pesquisas atuais tm reconhecido que o gerenciamento de
requisitos uma atividade crucial no processo de engenharia de requisitos,
ou seja, necessrio no somente escrever os requisitos de forma entendvel
mas tambm permitir que eles possam ser rastreados e gerenciados ao longo
da evoluo do sistema [28].
Incio

Descrever os Requisitos e seus

atributos
C1

Definir a Fronteirado
Software

Utilizar Check List para

analisar Requisitos

Analisar os Riscos dos

requisitos

C2
Classificar os Requisitos
C3
Elaborar o Documento de
Requisito de Software (DRS)

Definir as Matrizes de
Iterao e Rastreabilidade

C4

FIm

Figura 5. Processo Documentao & Anlise

Definir a Fronteira do Software: freqentemente os stakeholders no tm

certeza do que deve ou no estar no software a ser desenvolvido, o que faz
com que requisitos desnecessrios sejam includos durante a fase de
Elicitao de requisitos. Por isso, deve-se avaliar o conjunto de requisitos
essenciais para a definio do Documento de Viso do software. O
Documento de Viso deve incluir o escopo do projeto e suas limitaes, bem
como as principais caractersticas do software a ser desenvolvido [29].
importante que seja documentado os argumentos tcnicos e/ou econmicos
que justificam a excluso dos requisitos do escopo do software.
41

Utilizar um Checklist para analisar os requisitos: para facilitar, otimizar e

tornar mais completa a anlise de requisitos, deve-se definir um checklist,
por meio do qual cada requisito deve ser analisado. Alm de reduzir a
probabilidade de erros, a utilizao de um checklist uma forma de reutilizar
o conhecimento em anlise de requisitos entre diferentes projetos. Caso fique
muito grande deve-se particion-lo, de forma a criar vrios checklists que
possam ser distribudos para diferentes analistas. O checklist deve ser
periodicamente revisado e validado por analistas experientes para verificar a
necessidade de alteraes. importante conscientizar os analistas de que o
checklist deve ser apenas um guia e que podem existir outros problemas no
cobertos pelo checklist.
Analisar os Riscos dos requisitos: uma forma de identificar os requisitos
que podero causar mais problemas aos desenvolvedores. Deve-se identificar
os problemas que podero surgir, a probabilidade destes problemas e os
efeitos decorrentes desses problemas para cada requisito ou para grupos de
requisitos. Explicitar os riscos associados aos requisitos nesta fase uma
forma de avaliar se os requisitos esto incompletos, se precisam ser
modificados ou se necessria a definio de procedimentos para reduo da
probabilidade do problema ocorrer e do impacto, caso ocorra.
Classificar os requisitos: o objetivo da classificao dos requisitos agruplos de forma a identificar requisitos semelhantes. importante que o nmero
de classes definido no seja muito grande, pois ficam muito poucos
requisitos por classe. Geralmente, fica em cinco ou seis tipos de requisitos.
Uma vez classificados, os requisitos de uma mesma classe devem ser
comparados e analisados, pois conflitos e sobreposies so mais freqentes
em requisitos de um mesmo tipo. Requisitos similares tambm podem ser
comparados e pode-se visualizar melhor a falta de algum requisito. A
classificao dos requisitos deve ser definida no Guia de Classificao de
Requisitos.
Definir as Matrizes de Iterao e Rastreabilidade: numa matriz de interao,
cada requisito deve ser comparado com os demais de forma a identificar se
so conflitantes, sobrepostos ou independentes. Se a quantidade de requisitos
for muito grande, deve-se definir a matriz para uma classe especfica de
requisito ou para os requisitos de um subsistema.
Elaborar o Documento de Requisito de Software (DRS): o documento de
requisitos o meio atravs do qual possvel descrever as restries quanto
s caractersticas do produto e quanto ao processo de desenvolvimento, a
interface com outras aplicaes, a descrio sobre o domnio e as
informaes de suporte ao conhecimento do problema [30]. Em geral,
necessrio que o documento de requisitos seja entendvel por todos os
envolvidos no processo de engenharia de requisitos pois ele servir como um
contrato entre usurios e desenvolvedores.

Durante a Negociao & Priorizao (figura 8) as seguintes atividades so feitas:

Escolher a tcnica de negociao: o processo de negociao de requisitos

tenta resolver conflitos entre usurios sem necessariamente comprometer a
42

satisfao dos objetivos de cada usurio. Em geral, os modelos de

negociao identificam as principais necessidades de cada usurio, ou seja,
atribuem prioridades aos requisitos, em seguida analisam esses resultados
para tentar garantir que os requisitos mais crticos sejam atendidos. Em [31],
Karlsson descreve um estudo de caso realizado num projeto Ericsson em que
duas importantes tcnicas para priorizao e negociao de requisitos foram
comparadas. As tcnicas avaliadas foram AHP [32] e QFD [33], os
resultados obtidos indicaram que a tcnica AHP apesar de ter sido
considerada complexa, apresentou melhores resultados.
In c io

E s co lh e r a T c n ic a d e
N e g o c ia o

P rio riz a r o s R e q u is ito s

D e fin ir o s m ile s to n e s e o s
p o n to s d e re v is o

A tu a liz a r o D R S

F im

Figura 6. Processo Negociao & Priorizao

Priorizar os Requisitos: uma vez escolhida a tcnica de negociao, ela deve

ser usada para no apenas para resolver conflitos, mas tambm para priorizar
os requisitos. Ao priorizar os requisitos, importante que os riscos e a
complexidade dos requisitos sejam observados de forma mitigar possveis
atrasos nos milestones a serem definidos.
Definir os milestones e os pontos de reviso: de acordo com a priorizao, os
requisitos so agrupados para estabelecer baselines de implementao,
facilitando a definio dos milestones e pontos de reviso.
Atualizar o Documento de Requisitos de Software: o resultado obtido a partir
da tcnica de priorizao deve ser incorporado ao Documento de Requisitos
de Software, enriquecendo a documentao sobre os atributos dos requisitos.

Durante processo de Gerenciamento & Mtricas (figura 9) as seguintes atividades so

executadas:

Receber as Solicitaes de Alterao de Requisitos (SAR): O grupo de

engenharia de requisitos recebe as solicitaes de alterao de requisitos ou
43

por formulrio padronizado ou por meio de sistema de solicitao de

demandas.
Registrar novos requisitos: Os novos requisitos tambm devem ser recebidos
formalmente ou por formulrio padronizado ou por meio de sistema de
solicitao de demandas.
Verificar requisitos relacionados: uma vez preenchidas as matrizes de
rastreabilidade, de forma que tenham sido estabelecidos relacionamentos de
rastreamento entre os requisitos, necessrio verificar os requisitos
relacionados para que seja avaliado o impacto desta incluso ou alterao
posteriormente.
Incio

C1

Registrar novos Requisitos

Receber as SAR's
C2

Verificar Requisitos Relacionados

Avaliar Impacto
C3

Elaborar Relatrio de
Impacto nos Requisitos

Notificar os
envolvidos

C4

Coletar Mtricas

Fim

Figura 7. Processo de Gerenciamento & Mtricas

Elaborar relatrios de Impacto nos Requisitos: uma vez decidida a

alterao, mantido um histrico de alteraes para cada requisito,
permitindo uma viso cronolgica das principais mudanas nos requisitos,
inclusive em seus atributos. O autor, a data-hora, a descrio e a justificativa
da alterao tambm so documentados.
Notificar os envolvidos: todos os envolvidos devido alterao dos
requisitos devem ser notificados.
Coletar Mtricas: as mtricas desempenham um papel essencial na deteco
dos desvios, fornecendo meios para a visualizao de discrepncias e
identificao de pontos fora de uma situao projetada. As mtricas devem
ser utilizadas e coletadas periodicamente para o devido acompanhamento das
atividades da Gerncia de Requisitos, fornecendo tambm uma indicao da
44

volatilidade dos requisitos. A equipe de gerncia de requisitos deve definir

quais mtricas sero utilizadas no projeto, de acordo com suas caractersticas
peculiares.
Durante processo de Validao (figura 10) as seguintes atividades so executadas:
Usar Checklist de Validao: checklists estruturam o processo de validao
de forma que aspectos importantes no sejam esquecidos. Embora sejam
semelhantes aos checklists de anlise, os checklists de validao devem
focalizar aspectos de qualidade do documento de requisito como um todo,
bem como os relacionamentos entre os requisitos. Algumas questes podem
ser relacionadas para checar se algum requisito est ausente; se os requisitos
esto consistentes e no contraditrios; se o documento est estruturado de
forma a facilitar o entendimento; se foi feito o rastreamento dos requisitos;
ou se o documento est de acordo com os padres.
Definir os casos de teste dos requisitos: definir um ou mais casos de testes
que posteriormente permitam verificar se o sistema satisfaz o requisito, alm
de uma forma de validar os requisitos, pode servir como base para os testes
finais do sistema. Ao escrever o caso de teste, o requisito estar sendo escrito
de um ngulo diferente. Cada caso de teste deve possuir, no mnimo, um
identificador, os requisitos a ele relacionados e a descrio do teste. Se
utilizados em uma ferramenta, os casos de testes podem estar diretamente
associados aos requisitos, alm de permitir que os testes possam ser feitos
automaticamente.
Incio
C1

Usar os checklist
de validao

Definir os casos de
teste dos requisitos

C2

Executar a Inspeo Formal

para Validao
Desvios resolvveis
internamente

Desvios no resolvveis
internamente

D1

Notificar Gerente de
Projeto e envolvidos

Notificar Gerncia Snior

Final

Figura 8. Processo de Validao

Executar as Inspees Formais: nas inspees formais um grupo deve

validar os requisitos de forma sistemtica, descobrir os problemas
relacionados a eles e entrar em um acordo a respeito de como solucion-los.
45

Durante o encontro, que deve ser coordenado por algum que no esteja
envolvido na definio dos requisitos a serem validados, o engenheiro de
requisitos deve apresentar os requisitos e os problemas encontrados devem
ser anotados para posterior discusso. Diferentemente de inspees de
programas [34], onde os erros so simplesmente informados ao autor do
programa, as inspees de requisitos devem definir as aes a serem tomadas
para a devida correo.
Durante processo de Verificao (figura 12) as seguintes atividades so executadas:
Incio

Verificar os Requisitos

Avaliar os Desvios

Desvios resolvveis
internamente

D1

Notificar Gerente
Projeto e envolvidos

Desvios no resolvveis
internamente

Notificar Gerncia
Snior
Final

Figura 9. Processo para Verificao

Verificar os Requisitos: importante verificar se os requisitos encontram-se

implementados corretamente nos modelos do processo de desenvolvimento
de software. interessante que esta verificao seja feita por pessoas que
conheam os modelos e a padronizao adotada pela empresa, mas no
tenham se envolvido na especificao dos requisitos. Uma vez sendo
encontradas inconsistncias, estas devem ser avaliadas. Neste processo,
podem ser utilizadas matrizes de rastreabilidade com os modelos do processo
de desenvolvimento de software definidos.
Avaliar os Desvios: o objetivo avaliar junto aos grupos envolvidos o
impacto das inconsistncias ou desvios encontrados. importante que seja
avaliado, pois muitas vezes os desvios podem originar alteraes nos
requisitos.
Notificar os Gerentes e as Partes Interessadas: caso os desvios possam ser
resolvidos internamente, a gerncia de projeto e os envolvidos so
notificados. Caso contrrio, a gerncia snior comunicada para tomada de
aes corretivas e acompanhamento.
46

4. As Fases para Implantao

Inicialmente, foram definidos os processos (vide Seo 3) e os padres
documentados que devero ser utilizados, conforme a poltica de Gerncia de
Requisitos aprovada para o SERPRO. Tambm foi definido um plano de treinamento
para ser utilizado pelas equipes.
Em cada regional foi escolhido um projeto para ser desenvolvido utilizando os
procedimentos para a Gerncia de Requisitos definidos. A equipe deste projeto deve
estar preparada para disseminar o conhecimento para as demais equipes do Plo,
aproveitando os conhecimentos adquiridos.
Primeiramente algumas atividades foram executadas para a avaliao da situao
da Gerncia de Requisitos e definio da poltica, dos procedimentos, dos padres
documentados e do plano de treinamento que devero ser utilizados pelas equipes na
implantao da Gerncia de Requisitos.
Para a implantao do processo de melhoria, nove fases (figura 14) devem ser
seguidas at que se consiga o resultado esperado. Ao longo de toda a implantao os
processos devem ser avaliados e continuamente ajustados de acordo com o feedback
obtido. O processos podem selecionados para serem implantados ou omitidos de
acordo com as caractersticas e necessidades da organizao. Por exemplo, uma
organizao que j possui profundo conhecimento do negcio do cliente pode omitir a
atividade entender o domnio da aplicao.
A seguir, so descritas as nove fases que foram seguidas para implantao dos
processos:
Fase 1 - Conscientizao: nesta fase, deve-se identificar a situao atual,
definir o status desejado (estabelecendo metas), e tomar aes para reduzir a
distncia entre o status atual e o almejado. O status atual pode ser obtido por
meio de observaes e de questionrios e entrevistas aos desenvolvedores
em relao ao conhecimento e utilizao dos Processos de Engenharia de
Requisitos. Uma vez obtidas as informaes, estas devem ser consolidadas e
apresentadas aos gerentes e desenvolvedores, o que pode ser feito por meio
de uma workshop, de forma a conscientizar e mobilizar os gerentes e
desenvolvedores para a promoo das prticas e mudanas requeridas pelo
programa. Neste evento podem ser organizadas palestras sobre o tema.
fundamental o apoio gerencial para as aes e iniciativas de aprimoramento
de processos de Engenharia de Requisitos. Manter esse comprometimento e
repass-lo para os analistas parte fundamental do processo de melhoria.
Fase 2 - Preparao: durante a preparao devem ser escolhidos os grupos
de trabalho. Estes grupos devem estar profundamente familiarizados com a
filosofia e os termos utilizados nos processos de Engenharia de Requisitos. O
grupo de trabalho GT-Requisitos definido para planejar e acompanhar
todas as tarefas do projeto de melhoria da capacidade. Este grupo visa
garantir que o processo de implantao do modelo como um todo flua de
maneira adequada. Este grupo deve aprovar, com a participao da alta
gerncia, um cronograma com as macro-atividades e deve modific-lo
sempre que se fizer necessrio. da responsabilidade do GT-Requisitos
acompanhar e atualizar este cronograma. Dependendo do tamanho da
47

organizao podem ser definidos subgrupos de trabalho, onde o coordenador

deve ser um membro do GT-Requisitos. O grupo de trabalho GT-Pessoaschave deve ser composto por pessoas que detm o conhecimento de como
o processo de desenvolvimento e manuteno de software na empresa.
Devem ser entrevistadas e treinadas primeiro de acordo com a necessidade e
a disponibilidade. Este grupo pode mudar medida que aumenta a
compreenso dos processos de software. importante que nesta fase esteja
circulando na empresa informaes a respeito do trabalho sendo
desenvolvido, o que pode ser feito por meio de jornais internos, circulares, email ou circulao de revistas e livros que tratem sobre o tema. Pode-se
tambm disponibilizar informaes na Intranet da empresa.

Fase 8 - Implantao
Fase 1 - Conscientizao
Fase 7 - Definio de Papis e
Responsabilidades

Fase 9 Acompanhamento
e Ajustes

Fase 3 - Treinamento

Fase 6 - Definio dos

Processos
Fase 5 - Elaborao do Plano
de Melhoria

Fase 2 - Preparao

Fase 4 - Levantamento de

Figura 10. Fases para a Implantao

Fase 3 - Treinamento: o GT-Requisitos tambm deve definir um Plano de

Treinamento, priorizando a participao das pessoas que compe os grupos
de trabalho. O treinamento deve preferencialmente ser preparado e aplicado
por integrantes do GT-Requisitos, pois deve ser dada uma ateno especial
para a adaptao dos termos do modelo de melhoria para a cultura da
empresa. Todos os termos devem ser definidos e explicados fazendo, quando
possvel, um mapeamento para os termos equivalentes utilizados na empresa.
A importncia do treinamento deve-se tambm oportunidade de trocar
experincia entre diferentes equipes de desenvolvimento, especialmente em
empresas com diferentes plos de desenvolvimento, cada qual trabalhando
com um ambiente e caractersticas de projeto prprias. Durante o
treinamento, importante que um componente do GT-Requisitos anote as
sugestes e consideraes que porventura apaream, pois podem ser de
grande utilidade tanto para os prximos treinamentos como para utilizao
ao longo do processo de melhoria.
48

Fase 4 - Levantamento de Processos Engenharia de Requisitos existentes: o

primeiro passo para a melhoria o conhecimento de como est o seu
processo de desenvolvimento. Uma empresa pode ter vrias maneiras de
executar uma mesma tarefa como desenvolver e manter software.
importante que o GT-Requisitos tome conhecimento de todos os processos
de Engenharia de Requisitos existentes na empresa. Este conhecimento
dever ser provido por reunies, entrevistas e coletas de documentos com o
GT-Pessoas-chave. Deve-se avaliar as polticas, padres e processos atuais
de Engenharia de Requisitos existentes na organizao, identificando os
pontos fortes e fracos.
Fase 5 - Elaborao do Plano de Melhoria: o Plano de Melhoria do
Processo de Engenharia de Requisitos a base para o futuro esforo de
melhoria e deve estar de acordo com o cronograma definido anteriormente.
O GT-Requisitos deve preparar o Plano de Melhoria contendo os processos
e documentos existentes de modo que fique claro os pontos em que h
necessidade de melhoria e o impacto benfico que pode causar ao processo.
Pode recomendar aes para solucionar as carncias identificadas e at
estimar o tempo e recursos necessrios para cada atividade de melhoria.
Fase 6 - Definio dos Processos: a definio dos Processos a serem
implantados deve ser elaborada tendo como base com as boas prticas
existentes na empresa, o Plano de Melhoria definido, o tipo, as restries e a
cultura da organizao. So importantes pesquisas em bibliografia existente,
instituies de pesquisa e, se possvel, a utilizao de benchmarking.
Fase 7 - Definio de Papis e Responsabilidades: nesta fase devem ser
especificados os papis e as responsabilidades das pessoas que executaro as
atividades de desenvolvimento e gerenciamento de requisitos. Deve-se
definir um mapeamento para as funes existentes na Empresa.
Fase 8 - Implantao: a fase de Implantao deve possuir o planejamento e
a execuo, inicialmente para o projeto-piloto e posteriormente, para os
demais projetos. Para iniciar a implantao importante que o GTRequisitos defina um Plano para Projeto-piloto, onde seja especificado o
projeto escolhido, as pessoas envolvidas, os treinamentos necessrios, alm
os prazos esperados. A implantao do projeto-piloto deve ser acompanhada
pelo GT-Requisitos e as dificuldades encontradas devem ser documentadas
para posterior anlise e avaliao dos Processos definidos.
Fase 9 Acompanhamento e Ajustes: esta fase deve acompanhar a aplicao
das prticas de Gerncia de Requisitos implantadas, avaliando-as e
promovendo os refinamentos necessrios. Nesta fase, devero ser executadas
aes para atender a prtica de Verificao definida pelo CMM para a
Gerncia de Requisitos.

5. Estratgia x CMM
A tabela 2 descreve as prticas-chave para Gerncia de Requisitos do CMM
relacionando em que parte desta proposta as principais aes a serem executadas so
definidas.
49

Co

Hb

At

Prticas do CMM
O projeto segue uma poltica organizacional
1
para gerenciar os requisitos de software.
Para cada projeto, est estabelecida a
responsabilidade para analisar os requisitos
1 de sistema e aloc-los ao hardware,
software ou outros componentes do
sistema.
Os requisitos de software esto
2
documentados

Fase 6 - Definio dos Processos

Fase 7 - Definio de Papis e

Responsabilidades

Processo de Definio

Esto disponveis os recursos e fundos

3 necessrios para gerenciar os requisitos de
software.

Fase 1 - Conscientizao
Fase 2 - Preparao
Processo de Definio
Processo de Elicitao de Requisitos

Os membros do grupo de engenharia de

software e de outros grupos relacionados a
4
software esto treinados para realizar suas
atividades de gerncia de requisitos.

Fase 3 - Treinamento

O grupo de engenharia de software revisa

1 os requisitos de software, antes de serem
incorporados ao projeto.

Processo de Gerenciamento & Mtricas

Processo de Documentao & Anlise
Processo de Negociao & Priorizao
Processo de Validao
Processo de Verificao

3
Ve

Estratgia

1
2

O grupo de engenharia de software utiliza

os requisitos de software como base para
confeccionar os planos de
desenvolvimento do software, desenvolver
produtos de trabalho e realizar atividades.
Revisar as alteraes nos requisitos de
software e incorpor-las ao projeto de
software.
A gerncia snior revisa, periodicamente,
todas as atividades de gerncia dos
requisitos de software.
O gerente de projeto revisa periodicamente
ou por evento, todas as atividades de
gerncia dos requisitos de software.
O grupo de garantia de qualidade de
software revisa e/ou audita as atividades e
produtos de trabalho utilizados para
gerenciar os requisitos de software,
reportando seus resultados.

Processo de Verificao

Processo de Gerenciamento & Mtricas

Fase 9 - Acompanhamento e Ajustes

Fase 9 - Acompanhamento e Ajustes

Processo de Validao

Tabela 2. Prticas-chave e estratgia

6. Estudo de Caso
Tendo definido as diretrizes para a implantao da gerncia de requisitos, um
projeto-piloto foi conduzido para validar a estratgia estabelecida. A deciso sobre
qual sistema adotar foi tomada com base num perfil especfico. O sistema deveria
atender s seguintes caractersticas:
a.

possuir um cliente disposto a ser o pioneiro no processo de implantao da

gerncia e requisitos;
50

b.

possuir uma tcnica devidamente treinada ou disponvel para treinamento nos

conceitos de engenharia de requisitos, em especial sobre processos para a
melhoria da qualidade;

c.

possuir um escopo mnimo definido e controlvel;

d.

ser de importncia para o contexto das organizaes participantes (SERPRO e

Cliente);

e.

ser de fcil insero no contexto da gerncia de requisitos do SERPRO.

O sistema escolhido foi o SAD (Sistema de Apoio Deciso), um sistema de

apoio deciso, possibilitando aos usurios de alto escalo do Cliente realizar
consultas analticas sobre uma base de dados que agrega, para vrias reas de atuao
do usurio, inmeras informaes sobre as suas atividades fins. Dando suporte ao
projeto, um data warehouse congrega dados provenientes dos principais sistemas do
cliente, obtidas por meio de um complexo processo de extrao, agregao e carga.
Uma interface Web prov a acessibilidade s consultas para usurios habilitados em
todo pas. Isto possvel por meio das funcionalidades OLAP (On-line Analytical
Process) [35]. Dentre estas funcionalidades, o SAD possibilita ao usurio trabalhar a
informao, manipulando a sua apresentao para permitir anlises de diversas
maneiras, segunda diferentes critrios.
um projeto de grande porte, envolvendo o processamento de 21 bases de dados
de assuntos e extrao distintas, o que implica na especificao de requisitos para 21
equipes de desenvolvimento. Vale ressaltar que as equipes esto localizadas nas
diversas regies do pas.
Tendo escolhido o projeto piloto, foi inicializado o processo para a implantao da
gerncia de requisitos. Foram utilizadas ferramentas automatizadas para
gerenciamento de mudanas, gerenciamento de requisitos, gerenciamento de
configurao e testes.
Em processos de desenvolvimentos iterativos como os aplicados no SERPRO,
uma das chaves para a qualidade do produto final o acompanhamento eficiente dos
requisitos, como forma de garantir que todos os requisitos fluam corretamente entre
todos os envolvidos, sem que requisito algum seja perdido, mal interpretado ou
simplesmente adicionado sem a anuncia do cliente.
Durante o processo de Definio, foram utilizadas como tcnicas de elicitao
prototipao e entrevistas ao usurio. A prototipao auxiliou o usurio na descoberta
de requisitos no imaginados previamente. Durante as entrevistas, foram elaborados
os documentos Glossrio e Viso, cuja importncia foi bastante evidenciada tanto
pelos desenvolvedores como pelo cliente
No passo seguinte de Anlise & Documentao, os requisitos foram
documentados utilizando os documentos Guia de Classificao de Requisitos,
Especificao de Casos de Uso e Especificao Suplementar. Estes dois ltimos
juntos compe o DRS (Documento de Requisitos de Software do sistema). A escrita
dos requisitos utilizou Use Cases para requisitos funcionais e descries textuais para
os requisitos no-funcionais e restries.
Uma vez definidos e instanciados os documentos, os processos de Negociao &
Priorizao se seguiram, onde o Analista de Requisitos apresentou os documentos de
requisitos por meio de um Workshop envolvendo o cliente com o intuito de validar o
51

seu contedo, identificando possveis erros e priorizando os requisitos os requisitos

dentro da seqncia de iteraes, alm da definio dos milestones e pontos de
revises.
Durante todo o processo de desenvolvimento, o processo de Gerenciamento &
Mtricas, por meio das Solicitaes de Alteraes de Requisitos (SARs) , o usurio
pde formalizar as alteraes necessrias nos requisitos equipe de projeto, as quais
eram recebidas por meio da ferramenta de correio eletrnico da Empresa para que o
Analista de Requisitos, utilizando a Matriz de Rastreamento, pudesse gerar o
Relatrio de Impacto de Requisitos e negociar ento as alteraes. Aps a aprovao
das alteraes, todos os envolvidos eram notificados formalmente (por meio de
mensagem de correio eletrnico), os documentos, alterados e uma nova baseline
gerada.
Por fim, durante a execuo dos processos de Validao e Verificao, coube ao
grupo de garantia de qualidade de software verificar a conformidade dos documentos
com os padres definidos. Checklists de validao fornecem a base para esta
atividade.
O estudo de caso completo encontra-se disponvel em [36].

7. Concluso e Trabalhos Futuros

Este trabalho apresentou uma estratgia para a implantao de uma gerncia de
requisitos baseada em trs pilares bsicos: qualidade, requisitos e processos. Para que
a qualidade seja alcanada primordial que os requisitos tenham sido bem definidos e
controlados e, para isto, devem haver processos estabelecidos e implantados.
Gerenciamento de requisitos reconhecido como um importante pr-requisito
para desenvolver software de alta qualidade e definidos como a habilidade de
descrever e seguir a vida de um requisito, em ambas as direes.
As dificuldades mencionadas pela equipe de engenharia de requisitos foram a
mudana da cultura para desenvolvimento de software, a definio de requisitos
utilizando um paradigma novo para a equipe, as caractersticas peculiares dos
requisitos para um sistema de data warehouse e a grande quantidade de documentos
gerados.
Entretanto, foi ressaltada a importncia da utilizao dos processos definidos, que
direcionaram as atividades e utilizao dos padres e da integrao com outros
grupos, como o de garantia de qualidade de software e o de gerncia de configurao,
que responsabilizou-se pelo versionamento e pelo relacionamento entre os
documentos.
Como trabalhos futuros, deve-se ter o acompanhamento da execuo dos
processos em toda a empresa com a extrao de mtricas para que o processo evolua
de acordo com as mudanas organizacionais, visando a melhoria contnua.

Bibliografia
[1]

Sommerville, I., "Software Engineering", 6th Edition, Addison-Wesley, 2001.

52

[2]

SEI-Software Engineering Institute, "Capability Model for Software", 1a ed. USA:

Carnegie Mellon University, Pittsburgh, Pennsylvania, 1997.

[3]

Zanlorenci, E. P., "Descrio e Qualificao de Requisitos: Um Modelo Aplicvel

Anlise e Validao da Informao", Tese de Mestrado, PUC-PR, 1999.

[4]

Pressman, R., "Software Engineering: A Practioner's Approach", McGraw-Hill, 2000.

[5]

Zahran, S., "Software Process Improvement", Addison Wesley, 1998.

[6]

Paulk M. C. et all., "The Capability Maturity Model", version 1.1 (CMU/SEI-93-TR24), Software Engineering Institute, Carnegie Mellon University, Pittsburgh,
PA(USA),1993.

[7]

Fiorini, S. T., Staa A., Baptista R. M. ,"Engenharia de Software com CMM", Brasport,
1998.

[8]

Leite, J., Castro, J., Pinheiro, F.,"Plataforma Tecnolgica em Engenharia de Requisitos

Estratgias para o Aumento da Qualidade no Desenvolvimento de Sistemas",
http://www.cic.unb.br/~facp/per/perhome.html

[9]

Booch, G., Rumbaugh, J E, Jacobson, I., "The Unified Modeling Language User
Guide", Addison Wesley, 1999.

[10] Booch, G., "Object Oriented Design with Applications", The Benjamin/Cumming
Publishing Company, Inc., Redwood City, 1991.
[11] Gil, G., Figueroa, D., Oliveros, A., "Produccin Del LEL em um Dominio Tcnico.
Informe de um caso", III Workshop de Engenharia de Requisitos. Rio de JaneiroBrasil, 2000.
[12] Leite, J. "Applications Language: A product
Departamento de Informtica, PUC-RJ, 1989.

of

Requirements

Analysis",

[13] Nuseibeh, B. E, Easterbrook, S., "Requirements Engineering: A Roadmap",

Proceedings of the 22nd International Conference on Software Engineering. Limerick,
Ireland. Jun. 2000.
[15] Gause, D. E, Weinberg, G.M., "Exploring Requirements, Quality before Design",
1989.
[16] Damian, A., Hong, D. E, Li, H., "Joint Application Development and Participatory
Design", disponvel em www.cpsc.ucalgary.ca/~pan/seng/613/report.html
[17] Couger, D., "Creative and innovation in information systems", Londom: International
Thomson, 1995.
[18] Schneider, G. E, Winters, J., "Applying Use Cases: a practical guide", AddisonWesley. 1998.
[19] Lamsweerde, A., Darimont, R. E., Letier, E., "Managing Conflicts in Goal-Driven
Requirements Engineering", IEEE Transactions on Software Engineering, Special Issue
on Managing Inconsistency in Software Development. Nov. 1998.
[20] Yu, E., "Modeling Strategic Relationship for Process Reengineering", PhD thesis,
Computer Science Department, University of Toronto, Toronto, Canada, 1995.

53

[21] Maiden, N., "CREWS-SAVRE: Scenarios for Acquiring

Requirements", Automated Software Engineering, 1998.

and

Validating

[22] Shaw, M. E, Gaines, B., "Requirements Acquisition", Software Engineering Journal,

vol 11, 1995.
[23] Viller, S. E., Sommerville, I., "Social Analysis in the Requirements Engineering
Process: from ethnography to method", 4th International Symposium on Requirements
Engineering, Limerick, Ireland, Jun, 1999.
[24] Gogen, J. E, Jirotka, M. "Requirement Engineering", Boston, Mass.: Academic Press,
1994.
[25] Davis, A. M., "Achieving Quality in Software Requirements" SQP 1, NO. 3. 1999.
[26] Ambriola, V. E., Gervasi, V., "Processing Natural Language Requirements", 12th
International Conference on Automated Software Engineering. Lake Tahoe, EUA.
Nov. 1997.
[27] Antoniou, G., "The Role of Non-monotonic Representations in Requirements
Engineering", International Journal of Software Engineering and Knowledge
Engineering, vol 8. 1998.
[28] Gotel, O. E., Finkelnstein, A., "An Analysis of the Requirements Traceability
Problem", 1st International Conference on Requirements Engineering, Colorado
Springs, EUA. Apr. 1994.
[29] Wiegers K. E. ,"When Telepathy Won't Do: Requirements Engineering Key Practices",
Cutter IT Journal, May, 2000.
[31] Karlsson, K. E., Ryan, K., "Software Requirements Prioritizing", 2nd International
Conference on Requirements Engineering. Apr. 1996. pp. 110 116.
[32] Saaty, T., "The Analytic Hierarchy Process", New York: McGraw-Hill, 1990.
[33] Hauser, J. E., Clausing, D., "The House of Quality", The Harvard Business Review, vol
3. 1988.
[35] Codd, E. F., Codd, F. B., Salley, C. T., "Providing OLAP (Online Analytical
Processing) to User Analyst: an IT Mandate", Arbor Software White Paper,
http://www.arborsoft.com/OLAP.htm, 1993.
[36] Carvalho, A. E., "Uma Estratgia para Implantao de uma Gerncia de Requisitos
visando a Melhoria dos Processos de Software", Dissertao de Mestrado, UFPE,
Brasil, 2001.

54