71

I Simpsio Brasileiro de Qualidade de Software

Certificao de Qualidade em Engenharia de Requisitos

Edna Pacheco Zanlorenci
1,2
, Robert Carlisle Burnett
1


e-mail: [ednapz@pr.gov.br] [robert@ppgia.pucpr.br]

1
Pontifcia Universidade Catlica do Paran, PUC-PR (www.pucpr.br)
PPGIA - Programa de Ps-graduao em Informtica Aplicada
Rua Imaculada Conceio, 1155, Prado Velho, cep 80215-901, Curitiba, Paran, BRASIL
2
Companhia de Informtica do Paran - CELEPAR (www.celepar.gov.br)
Rua Mateus Leme, 1561 - Centro Cvico, cep 80510-030 - Curitiba, Paran, BRASIL


Resumo

A excelncia para a certificao de qualidade um dos objetivos das organizaes. No mundo
globalizado, a competitividade um fator de sobrevivncia do negcio. Na rea de software no diferente, seja
no cenrio acadmico, na indstria, na pesquisa & desenvolvimento ou no mercado. Para a Engenharia de
Requisitos, a questo : Como garantir que os processos e os produtos tenham a garantia de qualidade requerida
e adequada s prioridades dos stakeholder? O artigo prope abordar os processos e tcnicas, nas fases do ciclo
de vida de projeto, pela aplicao sistemtica de um script e um checklist para habilitar a validao dos produtos
e promover a certificao de qualidade em Engenharia de Requisitos.

Palavras-chave: certificao, ciclo de vida, modelo, processo, qualidade, Engenharia de Requisitos.

Abstract

The excellency to the quality certification is one of the organizations goals. In the global world,
competitiveness is a survival factor in business. In the software area it is not different, either in the academic,
industry, research & development or market scenery. For the Requirements Engineering (RE) the question is:
How to ensure that processes and products have the quality assurance required and adjusted to the
stakeholders priorities? The article proposal is to approach the RE processes and techniques, in the project
life-cycle phases, through systematic application of a script and a checklist in the processes, to be able for
validate products and to promote the quality certification in RE.

Keywords: certification, life-cycle, model, process, quality, Requirements Engineering.


1 Introduo

A motivao para este trabalho a demanda por parte da indstria de software em obter
a certificao de qualidade na rea da Engenharia de Requisitos, de maneira similar aos
processos ISO/IEC9000 [9] e CMMI [5].
A idia o tratamento de requisitos, aplicado ao contexto de desenvolvimento de
projeto de software. Um elemento primordial a considerar o nvel de maturidade da
organizao na aplicao dos processos da Engenharia de Requisitos [21] (descobrimento,
anlise, validao, documentao e gerncia de requisitos) utilizando-se de tcnicas
adequadas ao ambiente em estudo e s restries de negcio.
A abrangncia da proposta visualizar no ciclo de vida de um projeto de software, as
fases (demanda, estudo de viabilidade, modelo lgico, modelo fsico, construo e
72
I Simpsio Brasileiro de Qualidade de Software
implantao) onde se aplicam os processos da Engenharia de Requisitos e quais produtos
devem ser gerados e avaliados.
A justificativa do esforo obter sucesso na gerao de produtos intermedirios com a
aplicao dos processos de Engenharia de Requisitos, adequados situao e ao momento de
um contexto de desenvolvimento de projeto de software. E, atravs dos resultados parciais,
possibilitar o processo de avaliao durante todas as fases do projeto, para garantir a
qualidade dos processos e dos produtos com a Engenharia de Requisitos.
Existem fatores importantes a considerar no contexto de desenvolvimento de software.
Eles referem-se a restries de prazo, de recursos financeiros, de imposio de tecnologia
aplicvel a um projeto, entre outros e, conseqentemente, implicam na adoo de um ciclo de
vida adequado para a construo do produto e para a abordagem de tratamento da informao.
Dependendo da complexidade da informao a ser tratada, ou seja, o tamanho do
projeto ou a necessidade de conhecimento adicional, as fases que compem o ciclo de vida de
um projeto, podem tornar-se subprojetos de um projeto maior, devendo ser gerenciados como
projetos com escopo e objetivos claros e gerar produtos especficos.
O assunto oportuno porque trata de mtodos de desenvolvimento e de processos da
Engenharia de Requisitos aplicveis s exigncias de qualidade e assim, obter a descrio
mais precisa de requisitos do objeto de contratao para o desenvolvimento de software.
O foco, portanto, o conhecimento exigido das funcionalidades e das caractersticas de
qualidade do produto a construir, apoiadas por um roteiro (script) de descrio de requisitos e
um guia (checklist) para avaliao de processo e de produto em cada fase de projeto.
O artigo trata, na parte 2, o fundamento da abordagem de tratamento dos processos, com
o objetivo de garantia de qualidade e certificao em Engenharia de Requisitos. Na parte 3,
apresenta por fases do ciclo de vida de um projeto, um modelo para certificao e como
aplic-lo aos processos de requisitos. Na parte 4, relata resultados de experimentos com
processos da Engenharia de Requisitos e, na parte 5, apresenta concluso do trabalho.

2 Fundamento da Abordagem

Cabe Engenharia de Requisitos [20], como sub-rea da Engenharia de Software,
aperfeioar os processos para o gerenciamento do ciclo de vida dos requisitos. Deve tambm
propor mtodos, ferramentas e tcnicas que promovam o desenvolvimento do documento de
requisitos, para que este produto retrate o conhecimento do problema, em conformidade
satisfao dos stakeholder e aos padres de qualidade, relacionado ao que se quer produzir
com tecnologia da informao para soluo dos problemas ou como oportunidade de negcio.
A certificao de qualidade em Engenharia de Requisitos est ligada aplicao de seus
processos e a avaliao de produtos gerados, em todo o ciclo de vida de um projeto. Isto
requer um aperfeioamento contnuo dos processos aplicveis Engenharia de Software e um
grau de maturidade da organizao na aplicao dos processos da Engenharia de Requisitos,
adequados a situaes especficas de projeto. O sucesso do processo de desenvolvimento
implica em praticar o uso de padres de qualidade estabelecidos nas normas ISO/IEC: 9000
[9] (gesto da qualidade) 12207[12] (ciclo de vida de processos) 9126-x [10] / 14598 [11]
(qualidade produto), de referncia aos modelos de maturidade dos processos CMMI [5], de
mtodos e tcnicas de gesto PDCA (Planning, Do, Control, Action) e PMBOK [16].
O aperfeioamento dos processos de desenvolvimento de software na organizao
depende do conhecimento terico e, principalmente, da disposio para mudar. O sucesso da
73
I Simpsio Brasileiro de Qualidade de Software
mudana ser obtido se os esforos da organizao estiverem voltados a objetivos comuns de
resolver os reais problemas metodolgicos.
O uso da Engenharia de Requisitos varia em cada organizao. Este assunto
apresentado por Sommerville [18], em seu livro Engineering Requirements, referindo-se a trs
tipos de guia de referncia aplicveis (bsica, intermediria, avanada) e uma lista das dez
mais atitudes para o sucesso do processo, indicando a restrio quanto a considerar o nvel de
maturidade da organizao e o tipo de software a desenvolver.
A abordagem proposta indica prioritariamente, o conhecimento do que para ser feito,
do que tratam os requisitos no domnio da aplicao e quais suas formas de apresentao em
todo o ciclo de vida de um projeto de software. A idia est representada na figura.1, sob trs
aspectos: processos da Engenharia de Requisitos, fases de projeto [22,23] e produtos da fase
de projeto.

contexto
domnio
aplicao
cenrio
stakeholder
arquitetura
funes
dicionrio /
base dados
mtrica qlide
processo
papel
stakeholder
req.nofunc
qualidade
linguagem
comum
polticas de
uso tecnolog
resultado
experimentos
normas e
padres
novo produto
servio
relatrio
tcnico
palestras e
cursos
casos suces-
so cliente
risco
projeto
requisito
funcional
qualificao
requisito
funcionalide
requisito
dependncia
requisito
mdia
requisito
especifica
soluo
req.nofunc
qualidade
processo
negcio
produto
negcio
dicionrio /
base dados
risco
projeto
evento p/
viso proces
ponto vista
stakeholder
req.nofunc
qualidade
alternativas
soluo
linguagem
comum
problema
ponto vista
stakeholder
requisito
funcional
req.nofunc
qualidade
papel
stakeholder
linguagem
comum
risco
projeto
ponto vista
stakeholder
apura
respostas
papel
stakeholder
exigncia
requisito
mdia fonte
informao
mapa repres
stakeholder
stakeholder
risco
projeto
define
contexto
(demanda)
descreve
requisito
(cenrio)
analisa
requisito
(caracterstica
preciso)
valida
requisito
(fonte de
informao)
descreve
evento
(requisito)
especifica
soluo
(evento)
detalha
construo
(funosol)
especifica
infra e uso
(casocliente)
risco
implementa
documenta
requisito
(prioridade risco)
qualificao
fte informa
prioridade
implementa
papel
stakeholder
papel
stakeholder
ponto vista
stakeholder
papel
stakeholder
ponto vista
stakeholder
origem
requisito
mtrica qlide
produto
mtrica qlide
processo
mtrica qlide
produto
Descobrimento
Documentao
Gerncia
Validao
Anlise
Processos da Engenharia de Requisitos Processos da Engenharia de Requisitos
Fases de Projeto Fases de Projeto
Produtos nas Fases de Projeto Produtos nas Fases de Projeto
Definio de
Demanda:
o que, para que,
para quem,
onde
Problemas e Requisitos Funcionais, ponto de vista Stakeholder
Expectativas e Requisitos No Funcionais, viso da qualidade
Requisitos FR/NFR analisados validados e priorizados
Viso de Mtricas Qlide de Processo e de Produto
Viso de riscos e de testes de Projeto
Linguagem Comum ao contexto
Eventos: papis e
responsabilidades
Base Informao
Mtricas Qlide
Riscos e Testes
Alternativas
Processos e
Produtos
Base Dados
MtricasQlide
Riscos e Testes
Funes e
Comunicao
Mudanas
Base Dados
Mtricas Qlide
Riscos e Testes
Uso Tecnologia
Norma,Padro
Resultados
Inform.Tcnica
MtricasQlide
Riscos e Testes
dicionrio /
base dados
risco
projeto
mtrica qlide
processo
mtrica qlide
produto
rastreabilide
requisitos
Demanda
Estudo de Viabilidade
Mod Lgico Mod Fsico Construo Implantao
teste
teste teste
teste
teste
mtrica qlide
processo
mtrica qlide
produto
teste
mtrica qlide
processo
mtrica qlide
produto
mudanas
projeto

Figura.1 - Processos de RE e Fases de Projeto

A figura.1 apresenta a aplicao dos processos da Engenharia de Requisitos nas fases de
projeto. Na parte inicial, apresenta o ciclo dos processos da Engenharia de Requisitos
(descobrimento, anlise, validao, documentao e gerncia de requisitos), relacionados s
fases de projeto. Na parte intermediria, apresenta o tratamento do requisito em cada fase de
projeto (identificao da demanda, estudo de viabilidade, modelo lgico, modelo fsico,
construo e implantao), independente do ciclo de vida a ser adotado para o projeto
(cascata, incremental, iterativo,...). Na parte final, apresenta os produtos gerados em cada fase
de projeto. As figuras elpticas apresentam o objetivo da fase de projeto e as figuras
74
I Simpsio Brasileiro de Qualidade de Software
retangulares, a informao obtida e gerada no curso da fase. A representao uma forma
grfica para sumariar a idia do modelo.
Os processos da Engenharia de Requisitos e os processos de projeto devem ser tratados
num contexto de desenvolvimento de projeto. Independente do ciclo de vida adotado para o
desenvolvimento, as fases de projeto esto presentes, o que varia a intensidade de uso do
processo, ou seja, o tempo despendido em cada um e a forma de iterao entre eles.
Do ponto de vista de obteno da informao, os processos de tratamento de requisitos,
tm seus produtos esperados com detalhamento progressivo medida que evolui o trabalho de
desenvolvimento nas fases de projeto. A tabela.1 tem o objetivo de apresentar a ocorrncia
dos processos de Engenharia de Requisitos, visualizados nas fases de projeto.

Tabela.1 - Relacionamento entre Processos RE e Fases de Projeto
X Fases de Projeto
RE Processo demanda viabilidade mod.lgico mod.fsico construo implantao
REQUISITOS FR NFR FR NFR FR NFR FR NFR FR NFR FR NFR
descobrimento 1 1 2 2 3 3 4 4
anlise x x x x x
validao x x x x x
documentao x x x x x x x x x x
gerncia x x x x
legenda: x = ocorrncia de processos de requisitos (1, 2, 3, 4, grau de detalhamento, do geral para especfico)
requisit os: FR = requisitos funcionais (o que e o que faz)
NFR = requisitos no-funcionais (qualidade do que e do que faz)

O tratamento da informao, requisitos no ciclo de vida do produto, conforme a viso
anteriormente disposta, parte da idia de que em cada fase de projeto tem-se uma verso de
descrio de requisitos, tanto funcionais (FR) como no-funcionais (NFR) [4,6], que se
constituem em um produto intermedirio no projeto, para cada fase de projeto. Isto no
significa que as fases so como blocos fechados, mas que necessrio obter uma verso
negociada do produto em cada fase e, a cada passagem de fase, este produto se consolida com
refinamentos sucessivos, agregando informaes tambm fase anterior.
A informao um produto que envolve opinio e ponto de vista de pessoas [13,14],
com interesses e prioridades diversos. Para captura, so utilizadas tcnicas apropriadas ao
ambiente e adequadas ao perfil e disponibilidade de tempo do pblico-alvo. Para
representao, so utilizadas ferramentas de domnio do engenheiro de requisitos [5,8] que,
necessariamente, no so de conhecimento e domnio da fonte de informao.
O planejamento, a execuo, o controle e a avaliao de resultados so essenciais na
aplicao dos processos da Engenharia de Requisitos em um projeto:
- o descobrimento de requisitos, que inicia na fase de entendimento da demanda e somente
pode-se dar por concludo ao final da fase de modelo fsico da soluo de projeto. Isto se
justifica porque um processo indutivo e completado medida que a informao discutida
detalhadamente;
- a anlise de requisitos, que se faz presente na fase de estudos de viabilidade, objetiva a
verificao de conflitos de informao e mais aprofundado com as informaes das fases de
modelo conceitual e modelo fsico do projeto. Trata as relaes de dependncia e de
relacionamento entre os requisitos;
- a validao de requisitos complementar ao processo de anlise de requisitos. Trata as
relaes de exigncias, do ponto de vista dos stakeholder, como fonte para qualificao de
prioridade de implementao e precedncia dos requisitos;
75
I Simpsio Brasileiro de Qualidade de Software
- a documentao, que se constitui em uma atividade contnua de registro das informaes
obtidas da fase de entendimento da demanda at a implantao, incluindo peculiaridades da
fase de construo;
- o processo de gesto de mudana de requisitos [5], justifica-se em relao verso final
negociada de requisitos, aps a fase de modelo fsico, ao iniciar a fase de construo.
Entretanto, o rastreamento de requisitos [15] quanto relao de dependncia, prioridade,
precedncia de informao, desde que se faa uso de uma ferramenta adequada de registro
destes atributos em uma base de dados especfica, possvel tratar durante todo o processo de
documentao.
Roteiro do Processo
de Descrio de Requisitos
nas Fases deProjeto
contexto
(foco, idias)
lxico
linguag comum
(script)
problema
(fatos / fenmenos)
domnio
(abrangncia,
fronteira)
cenrio
(local)
stakeholder
(ator, diretor,..)
exigncia
(personagem pea)
ponto de vista
(direo, platia)
papel
(atuao)
requisito
funcional
(o qu e faz)
descreve
descreve
possui
atribui
exerce
parte
possui
requer
define
caracteriza
atuam
representado
possui
especificao
(como realizar)
compe-se
detalha
evento
(estmulo/resposta)
arquitetura
da soluo
(construir produto)
documenta
constitui dicionrio /
base de dados
(documentao)
alternativas
de soluo
(dados soluo)
processos
de negcio
(dados processo)
mtrica
qlide produto
(quantitativa)
produtos
negcio
(resultado)
requisito
no funcional
(como e faz)
define
define
polticas,
uso tecnologia
(infra-estrutura)
normas,
padres
(metodologia)
resultado e
Inform tcnica
(aplicao)
funcionalidade
(para que)
origem
( quem, onde)
prioridade
(precedncia)
risco
projeto
(possibilidades)
mtrica
qlide processo
(quantitativa)
qualifica
requisito
(dependncia)
qualifica fonte
informao
(exigncia)
apura
respostas
(dados qtitativos)
prioridade/
risco requisitos
(dados qlitativos)
mapa repres
stakeholder
(atuao)
dependncia requisito
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
2
2
2
2
3
3
3
4
4
4
2
2
5
6 6 6
Legenda #:
1 - demanda
2 - estudo preliminar
3 - modelo lgico
4 - modelo fsico
5 - construo
6 - implantao
teste
(verificao)
2
transferncia
de tecnologia
(divulgao)
6
define
mudanas
projeto
(alterar soluo)
5

Figura.2 - Roteiro de Descrio de Requisitos, nas Fases de Projeto

A execuo sistemtica dos processos depende da aplicao de um roteiro (script),
conforme apresentado na figura.2, direciona a constituio do produto referenciado pelos
requisitos, considerando-se as fases de projeto da proposta. O roteiro constitui-se de duas
etapas fundamentais: a primeira, abrange as fases 1 e 2 de projeto, respectivamente, demanda
e estudo de viabilidade; a segunda abrange as fases de modelo lgico, fsico, construo e
implantao do projeto. A primeira fase trata do conhecimento e priorizao dos requisitos; a
segunda fase trata do refinamento dos requisitos, propiciado pelo detalhamento dos modelos e
implementao de alternativa de soluo selecionada.

3 Modelo para Certificao

Para a aplicao do modelo de abordagem, foi feita uma adaptao do guia de referncia
de Sommerville [18], ao roteiro do processo de descrio de requisitos (figura.2), revisada
aps a aplicao prtica em projetos com escopos diferentes.
76
I Simpsio Brasileiro de Qualidade de Software
O guia de referncia, em cada fase de projeto, apresentado em quatro partes: lista de
atividades, processos da Engenharia de Requisitos, tcnicas de captura e de representao dos
requisitos e operacionalizao da avaliao do resultado.
O foco do modelo com o resultado, de forma que o produto o componente principal.
Cada fase de projeto atendida por processos da Engenharia de Requisitos, constitudos de
atividades, utilizando tcnicas para gerao de produtos. A execuo das fases de projeto
direcionada pelos requisitos definidos como prioritrios. Cada fase de projeto deve ter seu
planejamento, sua execuo e controle e a avaliao de seus produtos, privilegiando a
qualidade do processo e, conseqentemente, a qualidade do produto final.
A etapa de planejamento faz uso das atividades aplicveis ao projeto, para os produtos
esperados. O uso do roteiro (script) apia o fluxo de procedimentos e, a aplicao do guia
(checklist) adequado ao projeto, permite a avaliao do processo e dos produtos resultantes.
As etapas de execuo e de controle caracterizam-se pelo desenvolvimento dos produtos
da fase, realizando as atividades previstas para a elaborao dos mesmos.
A etapa de avaliao verifica a condio de uso (padro ou convencional) da atividade
para o projeto e a checagem (obrigatria ou opcional) do resultado.

3.1 Fase de Entendimento da Demanda

Na fase de entendimento da demanda inicial (tabela.2), obtm-se os requisitos como
informaes genricas, no declaradas, sero baseadas no entendimento do contexto do
negcio [3,13], do ponto de vista dos stakeholder envolvidos com a encomenda do produto.

Tabela.2 - Guia de Referncia da Fase de Entendimento de Demanda
guia de referncia - entendimento demanda (*) processo tcnica (#) operacionalizao
atividades da fase de projeto des ana val doc ger captura/repres interpretao uso ckl
definir o contexto x x conhecimento objeto de estudo p o
conhecer a linguagem comum ao contexto x x conhecimento forma de comunicao p o
conhecer a documentao histrica x x conhecimento o que existe p o
observar as restries de domnio x x conhecimento fronteiras p o
definir fronteiras do sistema x x conhecimento domnio aplicao p o
identificar cenrios para descobrir requisitos x x conhecimento ambiente p o
identificar os stakeholder (internos e externos) x x conhecimento universo stakeholder p o
identificar papis/responsabilidades stakeholder x x conhecimento quem e o que faz p o
ser sensvel a fatores polticos e organizacionais x x conhecimento fonte de influncias c x
usar conceitos de negcio no descobrimento x x conhecimento negcio c x
estabelecer um patrocinador para o projeto x x conhecimento responsvel contrato c o
assegurar a participao dos stakeholder x x conhecimento compromisso c o
gerar documento inicial de demanda x x conhecimento documento demanda p o
(*) processo: des - descobrimento, ana - anlise, val - validao, doc - documentao, ger - gerncia
(#) operacionalizao uso: p - padro, c- convencional ckl: o - obrigatrio, x - opcional

As atividades devem seguir o roteiro para contextualizao do assunto.
Os processos desta fase abrangem o descobrimento e a documentao do que para ser
feito e para quem . As tcnicas utilizadas para captura devem ser as adequadas ao ambiente
do negcio, observando a disponibilidade de tempo da fonte de informao. A representao
da informao documental, podendo ser em linguagem natural.
O produto um documento inicial de demanda, cujo contedo orienta-se pelos
elementos constitutivos do script (figura.2, #1): contexto, domnio da aplicao, cenrios,
linguagem comum ao contexto, stakeholder, papis e responsabilidades dos stakeholder, cuja
finalidade orientar o planejamento das atividades da fase seguinte, o estudo de viabilidade.
77
I Simpsio Brasileiro de Qualidade de Software
A certificao de qualidade desta fase est em cumprir os itens obrigatrios e o foco
principal o entendimento do contexto do negcio e identificar o universo dos stakeholder.

3.2 Fase de Estudo de Viabilidade (estudo preliminar)

Na fase de estudo de viabilidade (tabela.3), o conhecimento depende da participao de
pessoas do cliente e com a habilidade para tal, necessitando de representao dos nveis
decisrios da organizao.

Tabela.3 - Guia de Referncia da Fase de Estudo de Viabilidade
guia de referncia - estudo de viabilidade (*) processo tcnica (#) operacionalizao
atividades da fase de projeto des ana val doc ger captura/repres interpretao uso ckl
usar templates para descrio de requisitos x x descrio roteiro descrio c x
usar linguagem simples e concisa x x descrio sentena simples p o
suplementar linguagem natural c/outra descrio x x descrio notaes, frmulas c x
identificar o problema/oportunidade de soluo x x conhecimento denominao p o
descrever requisitos funcionais x x conhecimento essncia p o
identificar requisitos no-funcionais x x conhecimento essncia c x
identificar restries, preferncias e premissas x x conhecimento essncia c x
especificar requisitos quantitativamente x x conhecimento volume c x
coletar requisitos de mltiplos pontos de vista x x conhecimento diversidade pontovista p o
associar papis e responsabilidades stakeholder x x conhecimento quem e o que faz p o
capturar riscos do projeto x x conhecimento tcnica c x
capturar mtricas preliminares de qualidade x x conhecimento tcnica c x
capturar marcos de testes do projeto x x conhecimento tcnica c x
fazer reuso de requisitos x x anlise economia trabalho c x
identificar unicamente cada requisito x x anlise denominao p o
identificar a funcionalidade do requisito x x anlise denominao p o
identificar a relao de dependncia requisito x x anlise denominao p o
qualificar a exigncia do requisito x x anlise denominao p o
usar checklist para anlise dos requisitos x x anlise analisar requisitos p o
classificar requisitos c/abordagem multidimenso x x anlise relacionamentos c x
complementar a linguagem comum do contexto x x anlise forma de comunicao c x
usar plano para conflitos e resoluo conflitos x x negociao relacionamento c x
usar matrizes de interao para encontrar conflitos
e sobreposio de pontos de vista de requisitos
x x negociao relacionamentos c o
prover software para suporte a negociaes x x negociao registro aplicao c x
usar checklist de validao x x validao atributos crticos p o
usar equipes multidisciplinares para reviso x x validao representa stakeholder p o
analisar representatividade stakeholder na reviso x x validao representa stakeholder c o
priorizar requisitos funcionais x x validao priorizao p o
avaliar viabilidade do sistema x x validao realizar estudo prvio p o
gerar documento linguagem comum ao contexto x documentao documento p o
gerar documento de requisitos funcionais
qualificados e priorizados e, req.no-funcionais
x documentao documento p o
gerar documento risco implementao requisitos x documentao documento p o
gerar documento de rastreabilidade de requisitos x documentao documento p o
(*) processo: des - descobrimento, ana - anlise, val - validao, doc - documentao, ger - gerncia
(#) operacionalizao uso: p - padro, c - convencional ckl: o - obrigatrio, x - opcional

As atividades desta fase so as mais extensas, abrangem quatro processos para
requisitos e so fundamentais para o conhecimento da informao. Os processos so
iterativos, constituem-se de descobrimento, anlise, validao e documentao.
O processo de descobrimento deve ser estimulado na linguagem em que a fonte de
informao est acostumada, deve existir negociao prvia do mtodo a ser aplicado e o
compromisso a ser assumido. Deve-se ter o cuidado com palavras rejeitadas no contexto, por
78
I Simpsio Brasileiro de Qualidade de Software
exemplo, problema. O resultado da caracterizao do requisito depende da interpretao do
engenheiro de requisitos, pois a metodologia a ser aplicada no processo deve ser menos
formal, por exemplo, distino entre requisito funcional (funo) e no-funcional (qualidade
da funo). As informaes devero ser obtidas de pessoas com pontos de vista variados,
segundo Leite [14], dentro de um contexto definido.
O processo de anlise deve ser aplicado aos requisitos funcionais para avaliar conflitos
[1,2], ambigidades, repetio. O de validao, deve ser aplicado aos requisitos funcionais
para verificar a relao de dependncia, precedncia e prioridade de atendimento e, por fim, o
processo de documentao deve registrar e representar toda a informao coletada e analisada.
A representao da informao documental, podendo ser em linguagem natural,
complementada com alguns modelos de representao, de domnio do analista.
Os produtos so: documento da linguagem comum ao contexto, documento descritivo
dos requisitos funcionais qualificados e priorizados e a viso inicial de requisitos no-
funcionais ou de qualidade; documento preliminar de riscos de implantao de requisitos;
documento que visualiza o rastreamento de requisitos, condies preliminares para teste e
caractersticas genricas de qualidade. Os contedos dos documentos orientam-se pelos
elementos constitutivos do script (figura.2, #2): fundamentados a partir do ponto de vista do
problema e do requisito. A finalidade orientar o planejamento das atividades da fase
seguinte, a construo do modelo lgico com definio de alternativas de soluo.
A certificao de qualidade desta fase est em cumprir as atividades obrigatrias e o
foco principal a obteno da descrio dos requisitos representativos do contexto,
devidamente qualificados, relacionados e priorizados, envolvendo uma amostra representativa
do universo dos stakeholder.

3.3 Fase de Modelo Lgico

Na fase de modelo lgico (tabela.4), o processo de descobrimento (tabela.1) apresenta o
esforo na definio clara de papis e de responsabilidades dos stakeholder pelos eventos, a
viso preliminar dos processos de negcio, restries e premissas.

Tabela.4 - Guia de Referncia da Fase de Modelo Lgico
guia de referncia - modelo lgico (*) processo tcnica (#) operacionalizao
atividades da fase de projeto des ana val doc ger captura/repres interpretao uso ckl
associar papis stakeholder aos eventos x x conhecimento quem e o que faz p o
complementar a linguagem comum do contexto x x conhecimento forma de comunicao c x
capturar riscos do projeto x x conhecimento tcnica c x
capturar marcos de teste x x conhecimento tcnica c x
capturar mtricas de qualidade x x conhecimento tcnica c x
usar diagramas apropriados x x modelagem representao c x
usar mtodos para modelagem sistemas x x modelagem mtodo p o
representar os eventos com viso dos processos x x modelagem representao p o
incrementar o dicionrio de dados x x modelagem representao dado p o
documentar os links entre requisitos e modelos x x modelagem refinamento p o
desenvolver modelos complementares sistema x x modelagem ilustraes c x
checar requisitos no-funcionais, qualidade x x Anlise essncia c o
definir alternativas de soluo x x Anlise representao soluo p o
proceder refinamento da descrio dos requisitos x x validao complementar dados c x
gerar documento com eventos/processos x documentao documento p o
gerar documento verso base de dados x documentao documento p o
gerar documento de alternativas de soluo x documentao documento p o
(*) processo: des - descobrimento, ana - anlise, val - validao, doc - documentao, ger - gerncia
(#) operacionalizao uso: p - padro, c - convencional ckl: o - obrigatrio, x - opcional
79
I Simpsio Brasileiro de Qualidade de Software

As atividades desta fase so especficas de detalhamento dos eventos do negcio e,
conseqentemente, contribuem para o refinamento dos requisitos j identificados.
Os processos so iterativos, constituem-se de descobrimento, anlise, validao e de
documentao dos eventos associados aos requisitos priorizados. Os processos de anlise e de
validao devem ser aplicados aos requisitos funcionais e no-funcionais, com o objetivo de
complementar as informaes existentes. O processo de documentao deve registrar e
representar toda a informao coletada e analisada. As tcnicas utilizadas para captura e
representao devem ser adequadas a uma linguagem acessvel ao pblico-alvo, observando a
essncia do processo que a comunicao entre os participantes. A representao da
informao documental, utilizando-se modelos.
Os produtos so: documento do modelo de representao dos eventos associados aos
requisitos com papis e responsabilidades dos stakeholder, documento descritivo da base de
dados, documento preliminar de riscos e de teste de projeto, mtricas de qualidade e do
documento que prope alternativas de soluo. Os contedos dos documentos orientam-se
pelos elementos constitutivos do script (figura.2, #3): detalhando os eventos a partir dos
requisitos funcionais, gerando opes de alternativas de soluo, cuja finalidade orientar o
planejamento das atividades da fase seguinte, a construo do modelo fsico da alternativa
selecionada para a especificao tcnica de processos e produtos do negcio.
A certificao de qualidade desta fase est em cumprir as atividades obrigatrias e o
foco principal a obteno dos modelos de representao dos eventos, especificando
alternativas de soluo com o uso de tecnologia da informao.

3.4 Fase de Modelo Fsico

A fase de modelo fsico (tabela.5), representa na especificao da soluo, os processos
de negcio e os produtos.

Tabela.5 - Guia de Referncia da Fase de Modelo Fsico
guia de referncia - modelo fsico (*) processo tcnica (#) operacionalizao
atividades da fase de projeto des ana val doc ger captura/repres interpretao uso ckl
capturar riscos do projeto x x conhecimento tcnica p o
capturar marcos de teste x x conhecimento tcnica p o
capturar mtricas de qualidade x x conhecimento tcnica p o
definir sistemas usando especificao formal x x descrio notaes linguagem c x
modelar a arquitetura do sistema x x modelagem link subsistemas p o
definir processo operacional x x modelagem fcil de executar p o
representar os processos de negcio x x modelagem representao p o
representar os produtos de negcio x x modelagem representao p o
estabelecer o modelo fsico de dados x x modelagem representao dado p o
priorizar requisitos no-funcionais x x anlise essncia / prioridade p o
proceder refinamento da descrio dos requisitos x x validao complementar dados c x
definir polticas de gesto de requisitos x x gerncia mudana p o
definir polticas de gesto de qualidade x x gerncia mtricas qualidade p o
definir polticas de rastreamento de requisitos x x gerncia dependncia requisitos c x
manter condio de rastreamento manual x x gerncia rastreamento c x
gerar documento de processos e produtos x documentao documento p o
gerar documento verso base de dados x documentao documento p o
gerar documento de gerncia de riscos x documentao documento p o
gerar documento de gerncia de testes x documentao documento p o
gerar documento de mtricas de qualidade x documentao documento p o
(*) processo: des - descobrimento, ana - anlise, val - validao, doc - documentao, ger - gerncia
(#) operacionalizao uso: p - padro, c - convencional ckl: o - obrigatrio, x - opcional
80
I Simpsio Brasileiro de Qualidade de Software

As atividades desta fase so especficas de detalhamento das funes de soluo.
essencial completar a descrio e o refinamento dos requisitos no-funcionais, as
caractersticas de qualidade e as mtricas, principalmente, a definio de prioridade de
atendimento dos mesmos em relao s necessidades de negcio e soluo de software
adotada.
Os processos so iterativos, constituem-se de descobrimento, anlise, validao e
documentao da especificao de soluo em como atender aos requisitos estabelecidos. As
tcnicas utilizadas para captura e representao so de domnio da equipe de projeto e
voltadas para o pblico-alvo que construir o projeto. A representao da informao
documental, utilizando-se modelos.
Os produtos so: documento do modelo de representao dos processos e produtos de
negcio, documento descritivo da base de dados, documento de riscos de projeto, documento
de testes, documento que prope mtricas para avaliao de qualidade do produto de software.
Os contedos dos documentos orientam-se pelos elementos constitutivos do script (figura.2,
#4): detalhando os processos e produtos a partir da especificao da soluo, orientando a
arquitetura e comunicao entre as funes, cuja finalidade orientar o planejamento das
atividades da fase seguinte, a construo do software e, especialmente, fundamentar os
processos de gerncia de requisitos, gerncia de testes, gerncia de riscos e gerncia de
qualidade do software.

3.5 Fase de Construo

A fase de construo (tabela.6) alm de representar a arquitetura das funes de
software, o marco inicial dos processos de gesto de requisitos, de riscos, de testes e de
qualidade, pois nesta fase que se tem a descrio completa da arquitetura da funo que
implementar a funcionalidade e as caractersticas de qualidade dos requisitos estabelecidos.
Um fato particular o registro das solicitaes de mudanas que ocorrerem aps o projeto da
soluo ter sido concludo.

Tabela.6 - Guia de Referncia da Fase de Construo
guia de referncia - construo (*) processo tcnica (#) operacionalizao
atividades da fase de projeto des ana val doc ger captura/repres interpretao uso ckl
detalhar a arquitetura das funes x x modelagem link subsistemas p o
checar requisitos no-funcionais x x anlise priorizao p o
avaliao de riscos de requisitos x x anlise prioridade, qualidade p o
propor casos de teste de requisitos x x validao teste qualidade p o
organizar inspeo formal de requisitos x x validao checagem requisitos c x
identificar mudanas na soluo projetada x x validao mudana de requisitos c x
gerar documento de arquitetura de funes x documentao documento p o
gerar documento de comunicao entre funes x documentao documento p o
gerar documento verso base de dados x documentao documento p o
gerar documento de gerncia de riscos x documentao documento p o
gerar documento de gerncia de testes x documentao documento p o
gerar documento de mtricas de qualidade x documentao documento p o
(*) processo: des - descobrimento, ana - anlise, val - validao, doc - documentao, ger - gerncia
(#) operacionalizao uso: p - padro, c- convencional ckl: o - obrigatrio, x - opcional

As atividades desta fase correspondem ao registro das ocorrncias de construo do
software. Os processos so iterativos, constituem-se de descobrimento, anlise, validao e de
documentao da arquitetura e comunicao entre funes em como atender aos requisitos.
81
I Simpsio Brasileiro de Qualidade de Software
As tcnicas utilizadas para captura e representao so de domnio da equipe que desenvolve
o projeto. A representao da informao documental.
Os produtos so: documento do modelo de representao da arquitetura e comunicao
entre funes, documento descritivo da base de dados, documento de riscos de projeto,
documento de validao de testes, documento que valida mtricas para avaliao de qualidade
do software. Os contedos dos documentos orientam-se pelos elementos constitutivos do
script (figura.2, #5): detalhando as funes, cuja finalidade orientar o planejamento das
atividades da fase seguinte, a implantao do software e, especialmente, fundamentar os
processos de transferncia de tecnologia, polticas, normas e padres e resultados da
aplicao.
A certificao de qualidade desta fase est em cumprir as atividades obrigatrias e o
foco principal o relato de avaliao dos processos de gerncia de requisitos quanto s
mudanas, de gerncia de riscos do projeto, de casos de testes e de mtricas de qualidade dos
processos e dos produtos.

3.6 Fase de Implantao

A fase de implantao (tabela.7) o marco inicial da divulgao da tecnologia
construda, pois nesta fase que se tem a viso completa da funcionalidade e as caractersticas
de qualidade do software.

Tabela.7 - Guia de Referncia da Fase de Implantao
guia de referncia implantao (*) processo tcnica (#) operacionalizao
atividades da fase de projeto des ana val doc ger captura/repres interpretao uso ckl
escrever um esboo de manual de usurio x descrio negcio c x
definir uma estrutura padro de documento x descrio formato padro p o
explicar como usar o documento x descrio por tipo de leitor p o
fazer um relato de negcio para o sistema x descrio objetivos negcio c x
definir termos especialistas x descrio glossrio termos p o
lay-out documento para facilidade de leitura x descrio texto fcil de ler c o
ajuda para leitores encontrarem a informao x descrio lista contedo c o
fazer um documento fcil para mudar x descrio fcil modificao c o
usar base de dados para gerenciar requisitos x x gerncia automatizar c x
definir polticas de gesto de mudanas x x gerncia avaliar impacto p o
identificar requisitos volteis x x gerncia negcio c x
registrar requisitos rejeitados x x gerncia algo j discutido c x
gerar documento de transferncia de tecnologia x documentao documento p o
(*) processo: des - descobrimento, ana - anlise, val - validao, doc - documentao, ger - gerncia
(#) operacionalizao uso: p - padro, c - convencional ckl: o - obrigatrio, x - opcional

O processo essencialmente documental. As tcnicas utilizadas para captura e
representao dos resultados so voltadas para o usurio. A representao da informao a
formalizao de procedimentos e de uso dos produtos.
Os produtos so: documento do modelo de uso da tecnologia, normas e padres e
resultados aplicativos. Os contedos dos documentos orientam-se pelos elementos
constitutivos do script (figura.2, #6): detalhando os procedimentos, cuja finalidade orientar
o planejamento das atividades de implantao, a gesto de mudanas e a gesto de qualidade.
A certificao de qualidade desta fase est em cumprir as atividades obrigatrias e o
foco principal o preparo do ambiente e as condies e polticas para implantao do
software.

82
I Simpsio Brasileiro de Qualidade de Software
4 Aplicao do Modelo

A aplicao prtica relata o estudo de uma organizao estatal que foi constituda para a
gesto de fundo capitalizado de previdncia pblica, de regime prprio, com capitalizao e
foco atuarial. A organizao, com trs anos de existncia, juntou atribuies de um rgo que
tratava penses, com as atribuies de outro rgo que tratava de aposentadorias e
contribuies para a futura aposentadoria. Com isto, herdou toda a base de dados e sistemas
dos referidos rgos na forma em que funcionavam e teve alocados recursos humanos das
mais diversas reas de atuao previdenciria, notadamente, governo federal, estadual e
municipal.
A abordagem de estudo do sistema de informaes para este novo ambiente, foi mapear
a situao existente e congregar esforos em andamento para a manuteno do legado e criar
funcionalidades imediatas.
Utilizando-se deste material histrico, do Plano Diretor de Informtica, da Legislao
que constituiu a nova organizao, a abordagem de encaminhamento visualizava o projeto
global com fases distintas: licitao independente e, a relativa ao objeto de estudo como um
todo: demanda, estudo preliminar, modelos lgico e fsico, transio dos sistemas atuais e
construo de nova soluo.

4.1 Fase de Entendimento da Demanda

Tratava-se de um caso complexo de desenvolvimento de sistema de informaes [23], a
considerar os fatos ambientais. A demanda inicial ter um sistema novo, um novo cadastro
cujas informaes s possam ser mantidas pela organizao, atender ao pblico cliente com
informaes atualizadas e ter informaes para gesto do negcio.
O problema maior em questo era como definir o que era para ser feito, quais os
problemas relacionados, qual a precedncia de atendimento s necessidades expostas, como
os processos se inter-relacionam e, conseqentemente, quais so os requisitos de
funcionalidade e de qualidade dos produtos que fazem parte do contexto de demanda.
As restries de participao de pessoal com conhecimento para serem fonte de
informao dos processos era a concorrncia com o desempenho dirio de suas atividades,
sendo estas, consideradas prioritrias.
O produto resultante desta fase foi uma proposta de trabalho contendo a anlise da
situao e submetendo apreciao a metodologia de tratamento da informao a ser adotada
na fase seguinte.

4.2 Fase de Estudo de Viabilidade (preliminar)

Aps vrias reunies de negociao sobre a necessidade de comprometimento das
pessoas responsveis pela tomada deciso, ficou contratado que o trabalho pelo tamanho,
volume e esforo a serem despendidos, necessitaria ser dividido em fases. Isto permitiria
apresentar produtos intermedirios para avaliao de resultados e negociao de continuidade
A fase de trabalho, denominada de fase de estudos preliminares ou de viabilidade,
formalizou um planejamento de atividades usando a tcnica de reunio presencial com
representantes individuais das reas diretivas, assessorias tcnicas e gerncias da organizao,
apresentando um cronograma, cujo objetivo era criar um produto (documento preliminar de
83
I Simpsio Brasileiro de Qualidade de Software
requisitos) gerado com a participao do grupo decisrio da organizao. O enfoque era o
conhecimento dos requisitos de negcio, priorizados.
A abordagem adotada nesta fase foi orientada pelo roteiro de descrio de requisitos
(figura.2). A partir das informaes sob o ponto de vista dos stakeholder, foram listados os
problemas, requisitos, restries e premissas do corpo diretivo e gerencial da organizao.
Na seqncia, foram aplicados os processos de anlise, validao e qualificao dos
requisitos [19,20], obtendo-se um documento de requisitos com as informaes priorizadas.
A necessidade de informao era conhecer o ambiente e a pretenso das pessoas quanto
a o qu fazer para adequar realidade da nova organizao, sem deixar de atender aos
processos operacionais em andamento. A documentao gerada nesta fase faz parte do
conhecimento das Informaes de Negcio do Sistema Previdencirio sob os aspectos:
restries de negcio, premissas visualizadas, problemas e necessidades de negcio,
oportunidade de aplicao de tecnologia da informao e os requisitos do ponto de vista
diretivo e gerencial, eventualmente, algumas declaraes de requisitos do ponto de vista
operacional.

4.3 O Tratamento da Informao (requisitos no ciclo de vida do produto)

O documento preliminar de requisitos resultou num total de 185 requisitos genricos.
Foi necessria uma classificao prvia pela similaridade de tratamento do tema, antes da
qualificao dos requisitos para avaliao de relacionamento de dependncia e respectiva
prioridade definida.
Uma caracterstica particular apareceu na negociao desta fase do trabalho. Pela
complexidade e esforo a ser despendido nas atividades, principalmente pelo recurso tempo e
participao das mesmas pessoas de linha de produo em repetidos processos de definio,
optou-se que na fase seguinte, a de modelo lgico ou conceitual, o trabalho deveria apresentar
como resultado, definio de alternativas intermedirias para implementao imediata.
Alocando esforos nas atividades que inicialmente agregariam maior valor [10,17]. Para isso,
deveria ser referncia a hierarquia de requisitos definida na fase de estudo de viabilidade.
A negociao da fase seguinte foi condicionada a restries e premissas:
apresentao de proposta de alternativa de produo de resultados imediatos;
adaptao dos sistemas existentes (inovao e melhoria);
construo de base gerencial tcnica: datawarehouse;
atendimento da fila de solicitaes em andamento;
apresentao de alternativas de implementao de novas funes prioritrias.

4.4 As fases Seguintes...

A fase de modelo lgico evidenciou no ambiente da organizao a necessidade de
criao de uma linguagem comum (lxico), a partir da anlise do vocabulrio diverso
existente. Outro elemento presente necessidade da definio clara de papis e
responsabilidades para as pessoas. E, na seqncia, a formalizao dos processos de negcio
para a nova organizao. Isto representa um esforo adicional ao processo, porque o resultado
do trabalho dever ser construir a nova forma de funcionamento organizacional.
A fase de modelo fsico ficou para ser desenvolvida aps a concluso do modelo lgico
e opo pelas alternativas de soluo.
84
I Simpsio Brasileiro de Qualidade de Software
Nas fases de construo e de implantao, fazia-se necessrio comear pelas prioridades
da organizao.

4.5 Resultados Obtidos

O fator mais importante na aplicao da abordagem foi a evidncia de que ao partir-se
do modelo terico de utilizao dos processos da Engenharia de Requisitos em um projeto,
deve-se sempre aproveitar o momento e as circunstncias que levem ao conhecimento efetivo
do negcio, o que para fazer. Partindo deste princpio, foi primordial obter um documento
de requisitos devidamente revisado, com as prioridades destacadas e apontando para a
precedncia de criao dos modelos de representao dos eventos e base de dados, na busca
de alternativas de soluo.
Outro fator foi ter conseguido a participao do corpo diretivo da organizao,
enfocando o tratamento da informao (problemas e expectativas, requisitos, restries,
premissas) e no da tecnologia. Com o mapeamento de prioridades, o corpo gerencial teve a
definio das linhas de ao e apontamentos de gesto do negcio.
Do ponto de vista de certificao de qualidade, a aplicao dos processos da Engenharia
de Requisitos no modelo (exceto o de gerncia), foi efetiva e propiciou a referncia para a
negociao da seqncia do projeto.

5 Concluso

A proposta de abordagem do guia de referncia para contribuir no processo de
certificao de qualidade em Engenharia de Requisitos o resultado da aplicao prtica em
projetos com escopos diferentes, realizados at a fase de modelo fsico do projeto. A
observao que o conhecimento, tendo como foco a descrio dos requisitos, leva reflexo
de alguns fatores relevantes a considerar na certificao de qualidade dos processos.
Cabe aqui relembrar a tabela.1, Relacionamento dos Processos de ER com as Fases de
Projeto, como um referencial para esta anlise. O processo de descrio de requisitos uma
atividade indutiva e continuada. Tem contedo mais genrico na fase de entendimento da
demanda. medida que se avana nas demais fases de projeto, exige-se detalhamento e mais
formalismo. As descries de funcionalidade tornam-se mais especficas e completas e as de
no-funcionalidade (qualidade) tambm o so.
Aplicando-se a avaliao a cada trmino de fase de projeto, a negociao de entrega de
resultados intermedirios que dirigir a continuidade do mesmo, ou seja, a passagem para a
fase seguinte do projeto ou de um novo projeto.
A capacitao e o nvel de maturidade da organizao devem estar voltados para a
gerao de produtos intermedirios e/ou finais a cada fase de projeto utilizando um script
formal para o conhecimento, anlise, validao, documentao e gerncia da informao. Da
mesma forma que a utilizao de um checklist para avaliao dos processos e produtos
resultantes a cada fase de projeto permitir a aceitao do produto para a fase seguinte.
Concluindo, a certificao de qualidade em Engenharia de Requisitos, compreende a
somatria de fatores; a organizao estar apta para aplicao dos processos e a avaliao
sistemtica de resultados. um processo complexo, cujo objeto a definio clara de
requisitos e sua aplicabilidade ao ciclo de vida de um projeto. A forma de utilizao dos
processos quem dirigir a continuidade e aperfeioamento de procedimentos na organizao
e no somente o fato de se obter um marco inicial de estar certificado para tal.
85
I Simpsio Brasileiro de Qualidade de Software

Referncias

[1] Boehm, Barry; IN, Hoh. Identifying Quality-Requirement Conflicts.
1.ed. USA : IEEE Software, 1996, march, p 25-35.
[2] Boehm, Barry. Software Model Conflicts and How to Avoid Them.
SBES98, XII Simpsio Brasileiro de Engenharia de Software, Maring, Paran.
1.ed. Brasil : SBC, Tutorial 1998, outubro, 80 p. (http://www.sunset.usc.edu)
[3] Castro, Jaelson; Alencar, Fernanda; Cysneiros, Gilberto, Mylopoulos, John. From Early
Requirements Modeled by the I* Technique to Later Requirements Modeled in Precise UML.
WER'00, III Workshop de Engenharia de Requisitos
1ed. Brasil : Rio de Janeiro, Anais WER 2000, julho, vol.1, n.1, p 92-108.
[4] Chung, Lawrence; Nixon, Brian A.; Yu, Eric; Mylopoulos, John. Non-functional
Requirements in Software Engineering. 1ed. USA : Kluwer Academic Publishers,2000, 439 p.
[5] CMMI Project. CMM Integrated Systems/ Software Engineering. Carnegie Mellon
University. Continuous Representation vol.1
1ed. USA : CMU/SEI, Pensylvania, version 0.2b (Public Release DRAFT) 1999.
[6] Cysneiros, Luiz Mrcio; Leite, Jlio C.S.P; Sbat Neto, Jaime de Melo. Non-Functional
Requirements for Object-Oriented Modeling. WER'00, III Workshop de Engenharia de
Requisitos. 1ed. Brasil : Rio de Janeiro, Anais WER 2000, julho, vol.1, n.1, p 109-125.
[7] Doorn, Jorge; Leite, Jlio C.S.P; Kaplan, Gladys N; Hadad, Graciela D.S. Inspeccin del
Lexico Extendido del Lenguaje. WER'00, III Workshop de Engenharia de Requisitos.
1ed. Brasil : Rio de Janeiro, Anais WER 2000, julho, vol.1, n.1,p 70-91.
[8] FOCALPOINT. Prioritizing Requirements: "What we want always exceeds what we can
afford". (http://www.focalpoint.se/Metod/e_index.htm)
[9] ISO/IEC, International Standard Organization. JTC1 - Joint Technical Committee.
Information Technology - Software Engineering - Product quality ISO/IEC 9000.
1.ed. Geneve : ISO/IEC, 2000.
[10] ISO/IEC, International Standard Organization. JTC1 - Joint Technical Committee.
Information Technology - Software Engineering - Product quality ISO/IEC 9126-x. part1
Quality model; part2 External metrics; part3 Internal metrics; part4 Qualit y in use.
1.ed. Geneve : ISO/IEC, 1996.
[11] ISO/IEC, International Standard Organization. JTC1 - Joint Technical Committee.
Information Technology - Software Engineering - Product quality ISO/IEC 14598 (1-6)
1.ed. Geneve : ISO/IEC, 1998.
[12] ISO/IEC, International Standard Organization. JTC1 - Joint Technical Committee.
Information Technology - Software Engineering - Lifecycle Process ISO/IEC 12207.
1.ed. Geneve : ISO/IEC, 1995.
[13] Kilov, Haim. Business Specifications, The Key of Successfull Software Engineering.
1.ed. USA : Prentice Hall PTR, Inc. New Jersey 07458, 1999, 301 p.
[14] Leite, Jlio C.S.P. Viewpoints on Viewpoints. ISAW-2 International Workshop on
Multiple Perspectives in Software Development. (San Francisco,CA,USA). 1ed. USA : ACM.
Joint Proceedings SIGSOFT96, 1996, p 285-288.
[15]Pinheiro, Francisco A.C. Formal and Informal Aspects of Requirements Tracing.
WER'00, III Workshop de Engenharia de Requisitos. 1ed. Brasil : Rio de Janeiro, Anais WER
2000, julho, vol.1, n.1, p 38-53.
86
I Simpsio Brasileiro de Qualidade de Software
[16] PMBOK, A Guide to the Project Management Body of Knowledge. 1ed. USA : PMI.
Project Management Institute. Four Campus Boulevard, Newton Sq, Pennsylvania USA,
2000, 216p.
[17] Ryan, Kevin. Requirements Engineering - getting value for money. SBES98, XII
Simpsio Brasileiro de Engenharia de Software, Maring, Paran. 1.ed. Brasil : SBC
Sociedade Brasileira de Computao, Tutorial, 1998,outubro,55 p.
[18] Sommerville, Ian; Sawyer, Pete. Requirements Engineering, A good practice guide. 1ed.
UK : Chichester, Baffins Lane, John Wiley & Sons Ltd. 1997, 391p.
[19] Zanlorenci, Edna P; Burnett, Robert C. Modelo para qualificao da fonte de informao
cliente e de requisito funcional. WER'98 de Engenharia de Requisitos.
SBES98, 1ed. Brasil : SBC, Anais WER 1998, outubro, vol.1, n.1, p 39-48.
[20] Zanlorenci, Edna P; Burnett, Robert C. Descrio e Qualificao de Requisitos: Um
Modelo Aplicvel Anlise e Validao da Informao. 1ed. Brasil : Pontifcia Universidade
Catlica do Paran - PUCPR. Dissertao de Mestrado. 1999, julho, 229p.
[21] Zanlorenci, Edna P; Burnett, Robert C. Ferramenta de Apoio aos Processos de ER, nas
Fases de Projeto. WER'00, III WS de Engenharia de Requisitos.
1ed. Brasil : Rio de Janeiro, Anais WER 2000, julho, vol.1, n.1, p 181-193.
[22] Zanlorenci, Edna P; Burnett, Robert C. O Ciclo de Vida de Requisitos, nas Fases de
Projeto. I WS Engenharia de Software. 1ed. Chile : Punta Arenas, Anais JCC 2001,
novembro, vol.1, n.1, CD.
[23] Zanlorenci, Edna P; Burnett, Robert C. O Tratamento da Informao (Requisitos no
Ciclo de Vida do Produto) Caso Prtico: Sistema de Informaes de Previdncia. WER'01, IV
WS de Engenharia de Requisitos.
1ed. Argentina : Buenos Aires, Anais WER 2001, novembro, vol.1, n.1, p 55-73.