Um Mtodo Baseado em Requisitos para Seleo de COTS
Carina Frota Alves, Jaelson Castro
Centro de Informtica, Universidade Federal de Pernambuco
Recife, Pernambuco
E-mail: {cfa, jbc}@cin.ufpe.br
Abstract
The market interest in developing reliable and stable products at
shorter development time and reduced cost, has led to a
increasing surge of interest in Component-Based Software
Engineering. The success of these systems largely depends on the
successful selection of components that meet essential
stakeholders requirements. In this context, the products
evaluation needs to be a simultaneous process with the
requirements acquisition. This paper proposes the CRE Method
(COTS-Based Requirements Engineering) which is based on
requirements to assist the COTS selection process.
Key words: COTS-Based Development, Selection Process,
Requirements Engineering.
Resumo
A necessidade do mercado em desenvolver produtos confiveis e
estveis, num curto intervalo de tempo e com custos reduzidos,
tem conduzido a um crescente interesse para o desenvolvimento
de sistemas baseados em COTS. O sucesso desses sistemas
depende largamente do processo de seleo de componentes que
atenda satisfatoriamente aos requisitos essenciais dos
stakeholders. Nesse contexto, a avaliao dos produtos deve ser
um processo simultneo com a aquisio de requisitos. Esse
artigo prope o Mtodo CRE (COTS-Based Requirements
Engineering) que baseado em requisitos e assiste todo o
processo de seleo COTS.
Palavras-chave: Desenvolvimento Baseado
Processo de Seleo, Engenharia de Requisitos.
1. Introduo
medida que o tamanho e a complexidade dos
sistemas de software cresce, aumenta o interesse em
desenvolver sistemas baseados em componentes COTS
(Commercial-Off-The-Shelf). Os principais benefcios
prometidos por esta nova tecnologia so diminuio de
custos e tempo de desenvolvimento [OBE98] [TRA97].
Em geral, os modelos de engenharia de software
existentes, tais como os modelos Cascata e Espiral
[SOM96], no so adequados para o desenvolvimento
baseado em componentes. Uma vez que esses modelos
no tratam o processo simultneo entre especificao dos
requisitos, descrio da arquitetura e aquisio/integrao
de produtos COTS [FOR99]. Assim como eles no avaliam
o extensivo processo e o custo associado com as atividades
de avaliao e integrao desses componentes. Como
resultado, implementar sistemas baseados em COTS
usando tais modelos normalmente conduz a projetos no
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada
pelo CNPq 203262/86-7
realsticos e inconsistentes [TRA97]. Dessa forma, tm
sido propostos vrios modelos de ciclo de vida especficos
para desenvolvimento baseado em COTS. Normalmente,
eles englobam as seguintes fases: avaliao, seleo,
adaptao, integrao e atualizao [BRO96].
Num processo de Desenvolvimento Baseado em COTS
(DBC), as atividades de avaliao e seleo de produtos
candidatos so alguns dos aspectos fundamentais do seu
ciclo de vida [KON95]. Visto que nesse momento onde
sero analisadas as caractersticas de cada COTS candidato
e a sua conformidade com as necessidades dos
stakeholders. Se um produto inadequado for selecionado,
isso pode acarretar srios riscos e problemas nas fases
seguintes. O sucesso de sistemas baseados em COTS
depende largamente de um preciso entendimento das
capacidades e limitaes de cada produto [NCU00]. A fim
de atingir esse sucesso, a avaliao dos produtos deve ser
um processo simultneo com a aquisio de requisitos dos
stakeholders [ALV00].
Grande parte das pesquisas realizadas na rea de DBC
focaliza os processos de adaptao[VOA97] [MAC98],
integrao [BRO95] [VID96] [DEA97] [DEL97] [HAI97]
e arquitetura [GAR95] [FOX97] [CLE96]. Recentemente,
a comunidade de DBC tem verificado a importncia da
em COTS, fase de seleo e assim vrios modelos tm sido propostos
[KON96] [NCU00] [KUN99]. Entretanto, a maioria deles
no fornece uma abordagem orientada a requisitos. Nesse
contexto, este trabalho prope um mtodo baseado em
requisitos para assistir o processo de seleo de produtos
COTS, chamado CRE (COTS-based Requirments
Engineering). A seo 2 descreve os principais desafios
encontrados no processo de seleo COTS. A seo 3
fornece uma proposta do processo de Engenharia de
Requisitos especfico para DBC. Na seo 4 descrito o
Mtodo CRE e as suas fases. A seo 5 fornece um
exemplo para mostrar o uso do mtodo. Finalmente, a
seo 6 mostra as principais concluses dessa pesquisa.
2. O Processo de Seleo COTS
A seleo de componentes COTS pode ser considerada
o processo para avaliar se determinado produto
previamente desenvolvido apropriado para o uso no
contexto de um novo sistema [HAI97]. Inmeras pesquisas
nessa rea tm enfatizado que um processo de seleo bem
definido e sistemtico fundamental para o sucesso de
qualquer sistema baseado em COTS [KUN99] [NCU99]
[FOX97] [KON96], alm disso as decises realizadas
nesse momento proporcionaro impacto considervel nas
fases seguintes. O processo de seleo est propenso a
diversos riscos e problemas, entre alguns dos fatores
crticos esto por exemplo:
Falta de um processo bem definido Normalmente, o
processo de seleo feito de forma ad-hoc [KON96],
onde no so usados mtodos e ferramentas apropriados e
isso dificulta o planejamento e o aprendizado a partir de
lies anteriores;
Critrio de seleo Existem problemas com a definio
do critrio de seleo, s vezes so includos atributos
desnecessrios e no apropriados para descrever os
produtos candidatos;
Natureza caixa-preta dos COTS A falta de acesso ao
cdigo interno dos COTS dificulta o seu entendimento e
dessa forma torna a avaliao complicada, onde muitas
vezes at mesmo a documentao desses componentes est
incompleta ou errada;
Rpida mudana no mercado A avaliao de COTS
difcil porque o mercado de software muda rapidamente.
Por exemplo: uma nova verso de um produto que est
sendo avaliado pode ter caractersticas diferentes da verso
anterior que podem gerar conflitos com o resto do sistema.
Normalmente, a seleo de produtos no considerada
uma tarefa trivial, ela requer a considerao de mltiplos
fatores e a anlise cuidadosa entre requisitos, aspectos
tcnicos e fatores financeiros. Foram identificas quatro
dimenses (Figura 1) que precisam ser avaliadas durante a
fase de seleo, so elas [ALV00]:
Cobertura do domnio Os componentes precisam
prover totalmente ou parte das capacidades necessrias
para atender aos requisitos essenciais dos usurios, em
alguns casos componentes extras precisam ser
desenvolvidos ou adquiridos para atender tais exigncias;
Restrio de tempo As companhias de software
normalmente operam com prazos curtos, onde sua
competitividade e sucesso no mercado dependem de
entregas dentro do prazo preestabelecido. Todavia, o
processo de seleo uma atividade que consome uma
considervel quantidade de tempo e esforos;
Custo associado Essa uma varivel extremamente
importante, pois os gastos para desenvolver um sistema
baseado em COTS vo alm do custo de aquisio do
produto, os gastos associados mais comuns so:
treinamento, suporte, adaptao e manuteno. Aoyama
[AOY98] descreve um modelo econmico para estimar o
custo do desenvolvimento de um sistema baseado em
COTS;
Garantias do vendedor Um importante aspecto a ser
considerado durante a atividade de seleo verificar o
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada
pelo CNPq 203262/86-7
suporte tcnico que o vendedor prov, onde algumas
questes precisam ser analisadas, por exemplo: reputao e
maturidade do vendedor, nmero e tipo de aplicaes que
j utilizam o produto, garantia de suporte e manuteno.
Figura 1 Dimenses do Processo de Seleo de COTS
Existem basicamente trs estratgias para seleo de
COTS: filtragem progressiva, identificao por
caracterstica chave e montagem de quebra-cabea
[OBE97]. Filtragem progressiva representa uma estratgia
onde um produto selecionado a partir de um grupo de
potenciais candidatos, esse processo comea com uma
grande variedade de candidatos e atravs de mecanismos
de filtragem, os produtos considerados inadequados so
progressivamente eliminados. Na identificao por
caracterstica chave, uma caracterstica particular
selecionada antes de iniciar o processo de seleo, essa
caracterstica pode ser um determinado vendedor ou um
tipo de tecnologia, por exemplo: o critrio de seleo
inicial pode ser procurar somente por produtos Microsoft
ou que utilizam a tecnologia CORBA. Finalmente, o
modelo de montagem de quebra-cabea inicia com a
premissa de que uma soluo COTS vlida precisar
conectar os vrios componentes do sistema como um
quebra-cabea.
Durante o processo de seleo de COTS, fundamental
especificar os requisitos dos stakeholders para permitir que
os produtos sejam avaliados em relao sua
conformidade com tais requisitos. Dessa forma, a prxima
seo prope um processo de Engenharia de Requisitos,
que aborda os novos desafios encontrados durante o
desenvolvimento de sistemas baseado em COTS e trata,
em especial, a fase de seleo de produtos.
3. O Processo de Engenharia de
Requisitos para DBC
Assim como no desenvolvimento de software
tradicional, o processo de Engenharia de Requisitos
fundamental para o sucesso de sistemas baseados em
COTS [NCU00]. Todavia, a maioria dos mtodos para
seleo de COTS existentes na literatura ainda no tratam
o processo de requisitos de forma satisfatria. Alm da
prpria falta de um processo consistente de aquisio e
especificao de requisitos, existem novos problemas e
desafios que precisam ser analisados e resolvidos, por Requisitos sobre o treinamento disponvel (qualidade,
exemplo: como verificar se os vendedores so confiveis, custo);
como comparar produtos concorrentes e que so
especificados usando diferentes vocabulrios, quais Requisitos sobre o mtodo de pagamento (fixo,
atributos de um COTS so crticos para seu uso em prestaes);
determinado domnio, entre outros. Em particular, esse Requisitos sobre o tipo de contrato (direitos, tempo de
trabalho dever enfocar o processo de requisitos.
entrega, aspectos legais).
Uma das principais diferenas entre o processo de
Normalmente, as tcnicas para elicitao de requisitos
Engenharia de Requisitos tradicional e o baseado em
para DBC so as mesmas usadas no desenvolvimento
COTS, que no primeiro mais fcil garantir que os
tradicional. Algumas das tcnicas mais comuns so:
requisitos especificados sejam atendidos, uma vez que o
entrevistas, brainstorming, questionrios e card sorting
sistema ser implementado a partir do documento de
[MAI96]. Cada tcnica particularmente til para uma
requisitos. Assim, se o sistema no atender s necessidades
etapa do processo de aquisio de requisitos. Uma
dos stakeholders, isso pode ter sido resultado de uma m
caracterstica importante do processo de elicitao para
especificao dos requisitos. J no desenvolvimento de
DBC que a descrio dos requisitos no pode ser muito
sistemas baseado em COTS, no pode-se garantir que os
rgida, isto , inicialmente ela deve conter somente os
requisitos dos stakeholders sejam integralmente atendidos
requisitos essenciais ou crticos para no restringir muito o
pois os produtos existentes no mercado j foram
espao de busca de produtos. O principal objetivo dessa
implementados a partir de requisitos preestabelecidos.
descrio facilitar o processo de localizao dos COTS.
Assim deve existir um extenso processo de priorizao e
Em geral, nem todos os requisitos adquiridos durante o
negociao dos requisitos, onde os produtos que sero
processo de elicitao podero ser atendidos. Assim a fase
selecionados devem atender pelo menos aos requisitos
de anlise e negociao tem um papel fundamental para
considerados essenciais ou crticos. A seguir as fases do
avaliar a importncia de cada requisito e contribuir para
processo de Engenharia de Requisitos tradicional propostas
que esses requisitos sejam priorizados de forma consistente
por Kotonia [KOT97] so examinadas sob a perspectiva do
com as reais necessidades dos stakeholders.
desenvolvimento baseado em COTS.
3.2 Anlise de Requisitos para DBC
3.1 Elicitao de Requisitos para DBC
Nesse momento, a partir dos requisitos adquiridos na
Em geral, as atividades realizadas durante a elicitao
fase de elicitao j possvel iniciar o processo de busca
de requisitos para sistemas baseados em COTS so
dos potenciais produtos candidatos. Durante o processo de
semelhantes ao processo tradicional. Entretanto, vale
localizao dos produtos COTS, a anlise dos requisitos
ressaltar que no contexto de DBC, esse processo perde
deve ajudar a discriminar entre produtos semelhantes.
considervel importncia uma vez que muitos requisitos
importante ressaltar que durante essa fase, os requisitos
so elicitados no momento que os produtos COTS so
no-funcionais precisam ser explicitamente modelados.
examinados. Assim o processo de elicitao dos requisitos
Em geral, eles possuem um papel crtico durante o
pode ocorrer ao longo do processo de seleo.
desenvolvimento de software, porm normalmente eles so
Inicialmente, parte-se de uma descrio abstrata das
especificados de modo abstrato e informal, podendo
principais funcionalidades que o produto deve prover,
originar inmeras inconsistncias e ambigidades. Alm
nesse momento deve-se enfocar principalmente os
disso, no trivial verificar se determinado RNF est
requisitos funcionais pois so mais fceis de serem
sendo satisfeito no produto final. Em particular, a avaliao
adquiridos e modelados. Em seguida, so feitos sucessivos
entre produtos que possuem funcionalidades semelhantes
refinamentos dos requisitos, onde os requisitos no-
pode ser feita a partir da anlise dos requisitos no-
funcionais (RNF) devem receber ateno especial j que
funcionais que cada produto atende. Por exemplo, se
eles so importantes critrios para avaliao de produtos
performance for um requisito crtico para um sistema que
semelhantes. Os requisitos contratuais so uma importante
usa COTS, a anlise desse RNF pode ser til para
categoria de requisitos no-funcionais. Eles esto
discriminar entre produtos concorrentes. Nesse caso, ser
relacionados com os acordos e negociaes que devem ser
dada prioridade aos produtos que possuam um bom nvel
realizados entre os vendedores de COTS e a organizao
de performance. Nesse contexto, recomendvel utilizar
que est adquirindo esse produto. Alguns exemplos de
tcnicas para modelar explicitamente RNFs a fim de
requisitos contratuais so:
melhorar o processo de seleo e assim contribuir para o
Requisitos sobre o vendedor (estabilidade, reputao, sucesso de sistemas baseados em COTS.
maturidade); Uma tcnica bem aceita [CYS99] [KOT97] o NFR
(Non-Functional Requirements) Framework [CHU00]. A
principal vantagem dessa abordagem que ela representa
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada

pelo CNPq 203262/86-7

explicitamente os requisitos no-funcionais como metas a
serem obtidas, onde essas metas nem sempre podem ser
inteiramente satisfeitas. Ao contrrio, existem graus de
satisfao que podem ser obtidos. Essa abordagem pode
tratar melhor os aspectos de subjetividade e interatividade
inerentes dos RNFs. Uma premissa fundamental desse
framework que os RNFs possuem a propriedade de
interagir entre si, em conflito ou sinergia.
No desenvolvimento convencional, a anlise dos
requisitos geralmente direta pois os stakeholders
descrevem o futuro sistema atravs de modelos que contm
um conjunto de condies especficas que o sistema deve
suportar e que podero ser usadas como base para a
implementao. Entretanto, a anlise dos requisitos
diferente no desenvolvimento de sistemas baseado em
COTS, pois a especificao dos requisitos deve ser flexvel
ao ponto de aceitar algumas restries de requisitos que
no podem ser atendidos por nenhum produto existente no
mercado, alm de poder incluir funcionalidades j
presentes nos produtos e que no foram inicialmente
descritas [CAR97]. Assim a fase de anlise para DBC deve
suportar um extenso processo de modificao dos
requisitos especificados.
Tambm existem casos onde os produtos presentes no
mercado no atendem a todos os requisitos essenciais.
Assim pode-se tomar basicamente duas decises para
resolver esse problema. A primeira sugere que a
especificao dos requisitos sofra ligeiras alteraes para
suportar tais restries. J a segunda prope que essas
funcionalidades, no podendo ser fornecidas por produtos
existentes no mercado, sejam implementadas da forma
tradicional. Assim, deve ser realizado um extenso processo
de priorizao e negociao de tais requisitos em relao
aos produtos disponveis. Esse trabalho usa a tcnica AHP
[SAA90] para auxiliar esse processo, pois ela tem sido
usada com sucesso em diversos trabalhos para priorizao
de requisitos [KAR96] e seleo de software [NCU00]
[KON96b] [KUN99].
3.3 Documentao de Requisitos para DBC
Nessa etapa, os requisitos so descritos num documento
que deve conter uma especificao detalhada dos requisitos
funcionais e no-funcionais, assim como mostrar as
prioridades de cada requisito. Os requisitos priorizados
podem se enquadrar em quatro categorias:
Essencial e imperativo prioridade muito alta;
Importante prioridade alta;
Baixa importncia prioridade mdia;
Sem importncia prioridade baixa;
importante que o documento de requisitos permita
um efetivo gerenciamento dos requisitos pois geralmente
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada
pelo CNPq 203262/86-7
eles sofrero alteraes ao longo do processo de seleo de
COTS. Um dos principais motivos de mudana na
especificao dos requisitos devido a conflitos entre
requisitos que os produtos no podem atender, no qual a
maioria dos conflitos so relativos aos requisitos no-
funcionais. Assim necessrio que tais requisitos sejam
explicitamente descritos no documento.
Outro aspecto que precisa ser tratado durante essa fase
o rastreamento dos requisitos. Uma vez que
fundamental documentar as decises e modificaes feitas
nos requisitos durante todo o processo de desenvolvimento
baseado em COTS. Em particular, importante descrever
os motivos pelos quais os requisitos tiveram que ser
modificados. Alm disso, o rastreamento de requisitos deve
permitir que os sucessivos refinamentos dos requisitos
fique disponvel para auxiliar o processo de seleo de
COTS. Segundo [GOT94], o processo de rastreamento
garante a satisfao dos stakeholders disponibilizando um
documento que mostra que todos requisitos esto sendo
atendidos. Em particular no desenvolvimento baseado em
COTS, o rastreamento de requisitos possibilita um
entendimento dos motivos pelos quais os produtos foram
priorizados e selecionados.
3.4 Validao de Requisitos para DBC
O processo de validao dos requisitos precisa ser feito
em paralelo com a atividade de avaliao dos produtos
COTS. Normalmente, a validao diretamente afetada
pela disponibilidade dos produtos existentes no mercado e
que satisfazem aos requisitos especificados. Uma possvel
atividade desse processo aceitar as funcionalidades
existentes nos produtos e que no foram especificadas
pelos stakeholders. Um dos principais desafios dessa fase
obter um consenso entre os stakeholders em relao aos
requisitos que tiveram de ser simplificados ou at mesmo
excludos devido falta de produtos que atendessem tais
requisitos. Em casos em que os requisitos crticos no
puderem ser satisfeitos, os stakeholders devem concordar
se eles devero ser implementados.
Em geral, conveniente que todas as fases do processo
de Engenharia de Requisitos sejam realizadas em paralelo
e iterativamente com o processo de seleo. Uma vez que
depois que o produto adquirido pode ser difcil e bastante
dispendioso modificar requisitos j especificados. Ao
contrrio do desenvolvimento tradicional, onde possvel
alterar requisitos durante as fases seguintes do processo,
mesmo que isso signifique um considervel custo
adicional. No desenvolvimento baseado em COTS, no
possvel modificar as caractersticas do produto. Isso
devido caracterstica caixa-preta da maioria dos produtos
disponveis no mercado, que impossibilita acesso ao
cdigo-fonte.
4. O Mtodo CRE
Este trabalho descreve um novo mtodo para assistir o
processo de seleo de COTS, chamado CRE (COTS-
based Requirements Engineering) [ALV00]. Esse mtodo
orientado a requisitos e tem como uma das principais
estratgias enfocar a descrio dos requisitos no-
funcionais durante o processo seletivo. Essa abordagem
bastante promissora pois pesquisas recentes mostram que
os requisitos no-funcionais tm um papel crtico durante o
desenvolvimento de sistemas de software [CYS99]
[CHU00].

Figura 2 Processo Iterativo de Aquisio de

Requisitos e Seleo de Produtos
O Mtodo CRE fundamentado no processo iterativo
de aquisio de requisitos e seleo/rejeio de produtos.
No incio desse processo, existem poucos requisitos
descritos e um grande nmero de produtos candidatos. Figura 3 Viso Geral do Mtodo CRE
medida que ele evolui, a quantidade de requisitos aumenta
e assim diminui o nmero de COTS que atendem esses Template1
requisitos, ver Figura 2. Esse processo continua at que um
Metas:
determinado produto satisfaa um nmero suficiente de
requisitos. Resultado final:
Informaes a serem adquiridas:
O Mtodo CRE possui quatro fases que interagem
entre si, so elas: identificao, descrio, avaliao e Sequncia de passos:
aceitao. importante ressaltar que a ordem apresentada Consideraes importantes:
aqui no rgida e a seqncia dos processos no
preestabelecida, onde eles podem ser repetidos inmeras
vezes durante cada fase do mtodo. A Figura 3 mostra os Figura 4 Modelo de Template
principais passos de cada fase do mtodo, assim como
explicita a contnua interao entre suas fases. O Mtodo 4.1 Identificao
CRE orientado a metas, pois as fases do processo so
direcionadas por metas previamente definidas. Cada fase O principal objetivo dessa fase identificar os
do CRE possui um template cujo objetivo fornecer possveis produtos candidatos. A primeira etapa do
diretrizes bsicas para serem seguidas durante a realizao processo de identificao de COTS definir as metas que
das atividades de cada fase do mtodo. Esses templates precisam ser atingidas para obter um processo de seleo
mostram as principais metas e o resultado final que deve bem sucedido. Em geral, uma meta bsica de qualquer
ser obtido em cada fase. Eles tambm descrevem os processo de aquisio de COTS selecionar um produto
principais passos que precisam ser executados, alm de que atenda s principais necessidades dos stakeholders. A
indicar as tcnicas que sero usadas durante cada fase. A definio das metas corresponde elaborao do critrio
Figura 4 mostra um modelo de template que deve de seleo, que precisa ser baseado numa anlise detalhada
direcionar cada fase do mtodo. de fatores que influenciam o processo de seleo.
O primeiro passo para elaborar o critrio de seleo
elicitar os requisitos essenciais, onde esto includos os
requisitos que descrevem as funcionalidades centrais (ex. o
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada

pelo CNPq 203262/86-7

produto deve enviar e receber e-mail pela Internet) e
algumas restries chave (ex. o custo deve ser inferior a R$
X) que os produtos precisam atender. Em geral, os
requisitos essenciais so quase sempre inflexveis e
raramente sofrem alteraes. Nesse estgio, as tcnicas
mais apropriadas para elicitar os requisitos essenciais so
entrevistas e questionrios. J que no necessrio um alto
nvel de detalhamento dos requisitos e essas informaes
podem ser facilmente obtidas a partir de algumas reunies
entre os stakeholders e a equipe de seleo.
O propsito inicial do critrio de seleo identificar
as principais caractersticas que os produtos precisam
atender para iniciar o processo de busca. O objetivo desse
processo encontrar todos os potenciais produtos
candidatos existentes no mercado. A localizao de COTS
uma atividade informal e extremamente dependente de
fatores externos, assim no existe um processo de busca
padro. Porm, existem algumas diretrizes que podem ser
seguidas. Primeiramente, importante usar vrias fontes de
informao para auxiliar a busca, alm disso
aconselhvel documentar todo o processo de busca, mesmo
que a organizao no repita esse processo com freqncia.
Isso permite que o processo de seleo seja uma atividade
sistemtica e bem definida. As principais fontes para
localizao de produtos COTS so:
Bibliotecas internas grandes organizaes possuem
bibliotecas de produtos desenvolvidos por outros setores da
mesma organizao;
Internet existe uma grande variedade de informaes
atualizadas sobre os produtos comerciais existentes no
mercado de software;
Revistas e jornais especializados essas publicaes
normalmente mostram comparaes entre produtos e
possuem uma grande quantidade de anncios de
vendedores COTS;
Vendedores depois que os principais vendedores foram
descobertos, pode-se adquirir informaes sobre os seus
produtos e tambm identificar seus principais
competidores e possveis candidatos no processo de
seleo;
Consultores e especialistas esses profissionais possuem
um bom conhecimento da rea e podem fornecer
informaes sobre os produtos existentes;
Conferncias e feiras geralmente, esses eventos
possuem vrias exibies e stands de venda de produtos de
software;
Outras organizaes identificar e adquirir informaes
com outras organizaes que j passaram por um processo
de seleo semelhante.
Um dos grandes desafios durante a atividade de
localizao de COTS decidir quando parar o processo de
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada
pelo CNPq 203262/86-7
busca. Uma estratgia simples utilizar uma boa
diversidade de fontes de procura, verificar a freqncia que
novas alternativas so descobertas e analisar quando no
existir um nmero considervel de novas descobertas.
Assim, pode-se presumir que os benefcios de uma procura
adicional sero irrelevantes. Uma das principais atividades
da fase de identificao elaborar uma lista com todos os
produtos candidatos. Alm de fornecer informaes gerais
sobre os COTS, cada produto dessa lista possui um escore
de conformidade, que verifica de forma quantitativa se o
produto atende aos requisitos essenciais. A seguinte escala
de conformidade proposta:
Conformidade Escore
No atende o requisito 0
Atende com srias restries 1
Atende parcialmente 2
Atende 3
Tabela 1 Escore de Conformidade entre Produtos e
Requisitos
Nessa etapa acontece o processo de rejeio dos
produtos que no atendem uma quantidade mnima de
requisitos essenciais. Esse tipo de deciso especfico para
cada projeto e cabe equipe de seleo estipular uma
pontuao mnima que o produto candidato deve atingir.
Para tratar situaes como essa, foram definidas regras de
situao que so baseadas em implicaes lgicas do tipo
IF < condio> THEN < ao>. Abaixo mostrada uma
regra para tratar o processo de rejeio inicial de produtos.
Ifescore_total>=pontuao_min
Thenincluirprodutonalista
Elserejeitarproduto
Pela prpria imposio desse processo inicial, quase
sempre o nmero de requisitos relativamente pequeno e
eles so pouco detalhados. Portanto, nesse estgio o
documento de requisitos consiste somente de uma breve
descrio dos requisitos essenciais. O resultado mais
significativo da fase de identificao uma lista com os
produtos candidatos que ser examinada detalhadamente
nas prximas fases. Nesse estgio inicial, o critrio de
seleo descreve somente os requisitos essenciais.
Entretanto, outros aspectos precisam ser considerados para
realizar uma seleo de COTS consistente com as
necessidades dos stakeholders.
4.2 Descrio
Nessa etapa, o critrio de seleo dever ser
detalhadamente elaborado, onde ser dado destaque
especial aos requisitos no-funcionais. Portanto, ser
realizado um novo processo de elicitao de requisitos.
Alm das tcnicas tradicionais de elicitao, como
entrevistas e questionrios, o Mtodo CRE sugere o uso de
outras tcnicas como card sorting e laddering. Para usar a
tcnica de card sorting, os stakeholders devem separar os
produtos, que esto descritos em vrios cartes, em
categorias especficas. J a tcnica laddering fornece um
tratamento padronizado e hierrquico dos requisitos que
esto sendo adquiridos. As duas tcnicas so
particularmente teis para adquirir informaes sobre
categorias de produtos, alm de informaes hierrquicas
sobre requisitos e propriedades de produtos [NCU99].
Depois que os requisitos foram elicitados, eles
precisam ser efetivamente especificados de forma que
desapaream possveis ambiguidades e contradies entre
os requisitos. Nesse contexto, a especificao dos
requisitos no-funcionais uma atividade complexa pois
quase sempre eles so descritos pelos stakeholders de Figura 5 Exemplo de Decomposio no NFR
modo abstrato e informal. Alm disso, a prpria natureza Framework
do processo de requisitos para DBC dificulta ainda mais Um importante processo que ocorre durante essa fase
essa atividade. Um dos principais motivos porque alm o mecanismo de feedback. Ele consiste de uma troca
da complexidade do processo de especificao, tambm constante de informaes entre o processo de requisitos e a
necessrio verificar se o COTS pode atender esses descrio dos produtos. Inicialmente, os requisitos so
requisitos de qualidade. Dessa forma, mesmo que os elicitados e a descrio dos requisitos originada. A partir
requisitos no-funcionais sejam explicitamente dessa descrio, os produtos candidatos so localizados e
especificados, difcil avaliar se o produto atende esses obtida uma descrio dos produtos. O Mtodo CRE sugere
requisitos pois geralmente os vendedores no fornecem que a anlise das caractersticas dos produtos permita que
uma descrio detalhada e precisa dos aspectos de novas funcionalidades, ainda no especificadas pelos
qualidade dos produtos. Alm disso, no existe garantia stakeholders, sejam descobertas e includas no documento
alguma de que os produtos atendam a todos os requisitos de requisitos, ver Figura 6. Esse mecanismo permite uma
no-funcionais especificados. Mesmo diante de todas essas melhoria do processo de desenvolvimento baseado em
dificuldades em relao especificao de requisitos no- COTS e consequentemente contribui para satisfao dos
funcionais, esse processo fundamental para seleo stakeholders.
adequada de produtos COTS. Os principais benefcios para
enfocar requisitos no-funcionais durante essa fase so:
ajudam a discriminar entre produtos semelhantes;
so mais crticos do que outros requisitos funcionais;
incluem restries de arquitetura (ex. compatibilidade,
portabilidade e interoperabilidade);
fornecem informaes sobre possveis problemas de
adaptao e integrao dos produtos ao restante do Figura 6 Mecanismo de Feedback
sistema; Outra atividade importante dessa fase obter
esto diretamente relacionados com a satisfao dos informaes mais detalhadas sobre os produtos, onde tais
informaes sero usadas para avaliar a conformidade do
stakeholders.
produto com os aspectos descritos no critrio de seleo.
Diante desses aspectos, uma das principais metas dessa Algumas possveis fontes de informao so:
fase descrever explicitamente os requisitos no- documentaes, especificaes, manuais de uso e de
funcionais usando o NFR Framework [CHU00] e utiliz- configurao, outras organizaes que utilizam o produto,
los para auxiliar o processo de deciso. A Figura 5 mostra etc. O Mtodo CRE fornece um checklist para guiar o
um exemplo de decomposio do requisito no-funcional processo de aquisio de informaes sobre os produtos.
segurana nos requisitos integridade, disponibilidade e Esse checklist dividido em duas categorias bsicas:
confidencialidade. Um aspecto importante desse aspectos do produto e aspectos do vendedor. A Tabela 2
framework que ele usa a noo de softgoal para descrever mostra um exemplo genrico de checklist, no qual a equipe
os requisitos no-funcionais, que explicita a idia de que os de seleo precisa adapt-lo para suas necessidades
RNFs possuem nveis de satisfao. especficas. A partir das informaes obtidas com a
utilizao do checklist, possvel elaborar uma verso
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada

pelo CNPq 203262/86-7

mais completa e detalhada da lista de produtos candidatos. associado de cada alternativa a fim de obter um processo
Nesse estgio, deve ser feito um novo escore de de avaliao seguro e consistente.
conformidade entre cada produto candidato e os requisitos
Como essa atividade pode ser bastante trabalhosa,
elicitados durante a fase de descrio. Alm disso, os
recomendvel realiz-la somente nesse momento pois o
outros escores obtidos anteriormente, relativos aos
nmero de alternativas para avaliar menor. Entretanto,
requisitos essenciais, podem ser reavaliados pois o CRE
isso no rgido e dependendo de cada situao, a equipe
baseado na interao contnua entre as suas fases.
de seleo pode decidir realizar a estimativa dos custos de
Checklist cada produto logo na fase de descrio.
Aspectos do Produto Aspectos do O Mtodo CRE sugere o uso de modelos de custo que
vendedor
permitam uma comparao entre os custos de cada produto
Custos associados Maturidade COTS. O modelo COCOTS (COnstructive COTS)
Conformidade c/ normas Perodo de entrega [COC98], por exemplo, um avano do modelo
ISO econmico COCOMO [BOE00] e fornece uma abordagem
para estimar os custos associados para integrao de
Capacidades Estabilidade
solues COTS. Esse modelo trata explicitamente cada
Benefcios Treinamento atributo associado com o custo das alternativas COTS. A
Restries Reputao
maior restrio desse tipo de modelo a necessidade de
customizar e calibrar os valores para cada processo de
Controle de verses Qualidade do suporte seleo. O Mtodo CRE fornece duas estratgias para
avaliar os benefcios de cada alternativa a fim de realizar o
processo de tomada de deciso. A abordagem mais simples
Tabela 2 Checklist de Descrio do Produto
utiliza a tcnica WSM (Weighted Scoring Method). Essa
At esse estgio, quase sempre a lista de produtos tcnica fornece a seguinte frmula para obter a pontuao
candidatos possui vrias alternativas aparentemente de cada produto em relao sua conformidade com os
semelhantes. Portanto, no conveniente tomar uma critrios examinados:
deciso somente com base na lista de produtos e no critrio n

de seleo, necessrio realizar uma avaliao mais

Pont_Produtoa =
onde: a representa uma alternativa e n j 1
( peso * escore aj )
o
criteriosa dos benefcios de cada alternativa. Entretanto,
nmero de critrios
avaliar e analisar as caractersticas relevantes desses
O peso e o escore dessa frmula so na verdade a
produtos requer um considervel espao de tempo, quase
prioridade de cada requisito e o escore de conformidade. A
sempre maior do que a organizao tem disponvel
Tabela 3 mostra os possveis valores desses atributos. O
[KON95]. Assim, o Mtodo CRE recomenda que somente
resultado final da aplicao dessa frmula em todas
os candidatos mais promissores passem para a prxima
alternativas um ranking dos produtos candidatos em
fase, que o processo de avaliao.
relao s caractersticas do critrio de seleo que foram
avaliadas. O mtodo WSM adequado para usar em
4.3 Avaliao processos de tomada de deciso simples, onde existe um
O principal objetivo dessa fase avaliar a pequeno nmero de critrios.
adequabilidade de cada produto em relao ao critrio de Conformidade Escore Prioridade Peso
seleo. Em muitas situaes o critrio de seleo to
No atende o requisito 0 Baixa 1
detalhado que no possvel ser totalmente avaliado
dentro do prazo disponvel. Portanto, uma opo vivel Atende com srias 1 Mdia 2
fazer um ranking da importncia de cada critrio e iniciar o restries
processo de avaliao com os atributos mais relevantes. Atende parcialmente 2 Alta 3
Em geral, custo um atributo fundamental durante o Atende 3 Muito alta 4
desenvolvimento de qualquer sistema de software. Em
particular, para desenvolvimento baseado em COTS, o
custo uma restrio crtica j que essa forma de Tabela 3 Valores dos Atributos Peso e Escore
desenvolvimento baseia-se na promessa de reduo de Outra estratgia para assistir o processo de tomada de
custos e tempo de desenvolvimento. Nesse contexto, deciso a tcnica AHP [SAA90]. A utilizao dessa
importante ressaltar que o custo de DBC no somente o tcnica mais complexa que a WSM, porm os resultados
preo de aquisio do produto, tambm esto associados obtidos so mais consistentes e confiveis. O primeiro
custos com adaptao, integrao, treinamento de pessoal, passo para usar a tcnica AHP decompor as informaes
entre outros. Dessa forma, essencial estimar o custo numa hierarquia de metas, critrios e alternativas, ver
Figura 7. Em seguida, determinada a importncia relativa
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada

pelo CNPq 203262/86-7

de cada critrio, onde so usadas comparaes aos pares scripts ou wrappers. A tcnica de wrapper[MAC98],
para avaliar a importncia de um critrio em relao ao tambm conhecida como capa de proteo, coloca uma
outro. Uma das principais vantagens da tcnica AHP que barreira de software ao redor do COTS, disabilitando-o de
ela pode ser usada em processos decisrios extremamente exibir funcionalidades no desejadas. Um outro aspecto
complexos, onde os critrios precisam ser decompostos em importante para ser examinado so as restries de
vrios sub-critrios hierarquicamente relacionados. Essa arquitetura (ex. compatibilidade, portabilidade e
caracterstica compatvel com os resultados obtidos a interoperabilidade) que os produtos devem estar em
partir da decomposio dos requisitos no-funcionais conformidade com os padres preestabelecidos.
obtida com a utilizao do NFR Framework. Em casos Normalmente, esse um aspecto bastante crtico e
complexos de tomada de deciso, pode ser utilizada uma complexo durante o processo de seleo.
ferramenta comercial que realiza todos os clculos
importante salientar que normalmente os testes de
necessrios da tcnica AHP, chamada Expert Choice
aceitao so demorados e portanto nem sempre
[EXP00]. O resultado final da fase de avaliao uma lista
recomendvel realizar testes em todos os produtos
de candidatos COTS atualizada com um ranking das
candidatos. A equipe de seleo deve levantar os custo e
melhores alternativas.
considerar quais os reais benefcios para realizar testes de
aceitao em todos os produtos candidatos. Uma
alternativa para casos com limitaes de recursos realizar
testes somente com alguns produtos, aqueles onde existe
um alto grau de incerteza sobre os vendedores e as
caractersticas do produto.
Durante a fase de aceitao acontece a validao final
dos requisitos. Assim pode ser verificado quais requisitos
so atendidos pelo produto que ser selecionado e quais
no puderam ser obtidos. Nessa etapa, a equipe de seleo
precisa analisar se algum requisito importante no foi
atendido e se haver necessidade de implement-lo da
Figura 7 rvore Hierrquica da Tcnica AHP forma tradicional. Outro aspecto importante dessa fase
verificar possveis conflitos entre o COTS que ser
escolhido e o restante do sistema. Existem situaes em
4.4 Aceitao que o conflito to crtico que pode inviabilizar a
Um dos principais objetivos da fase de aceitao integrao desse produto. Nesses casos pode-se optar pelo
realizar sesses de demonstrao dos produtos para prximo candidato no ranking.
verificar se a descrio fornecida pelos vendedores Nesse momento, devero ser examinados os detalhes
realmente confivel. Geralmente, os vendedores dos aspectos legais e contratuais que no puderam ser
disponibilizam verses demo de seus produtos, que podem verificados com o checklist da fase de descrio. A equipe
ser usadas durante os testes de aceitao. recomendvel de seleo precisa verificar com cuidado os aspectos
que a equipe de seleo instale os produtos candidatos em
contratuais de cada alternativa a fim de realizar
ambiente operacional para simular sua execuo numa julgamentos coerentes sobre os riscos e custos que eles
situao real. Durante esse estgio, alguns dos aspectos de esto dispostos a assumir quando o produto for adquirido.
qualidade mais comuns a serem examinados so: Uma licena entre o vendedor e a organizao que est
Integrabilidade; comprando o produto COTS precisa especificar pelo
menos alguns aspectos chave, por exemplo [CHA98]:
Interoperabilidade;
direitos que o vendedor autoriza (concesso de uso);
Compatibilidade;
formas de pagamento;
Usabilidade;
riscos e responsabilidades que cada parte assume;
Performance.
suporte, manuteno e garantias que o vendedor
Dessa forma, a equipe de seleo pode observar a fornece;
adequabilidade de cada produto num ambiente mais
realstico do que simples descries encontradas em confidencialidade do produto licenciado.
documentaes e manuais. Durante os testes de aceitao Geralmente, o vendedor no d direito de acesso ao
possvel verificar a necessidade de futuras adaptaes entre cdigo-fonte pois ele faz parte dos seus direitos de
o produto e o sistema, assim j pode-se especificar alguns propriedade intelectual. Entretanto, segundo dados do SEI
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada

pelo CNPq 203262/86-7

(Software Engineering Institute) [SEI00] na prtica, cerca
de 30% dos produtos COTS adquiridos como caixa-preta
necessitam de algumas mudanas no seu cdigo durante o
processo de adaptao. Nesses casos, necessrio negociar
com o vendedor formas de obter acesso parte do cdigo-
interno ou ento sugerir que ele realize as alteraes
necessrias. O resultado final dessa fase a seleo do
produto que, sob os aspectos considerados durante as fases
do Mtodo CRE, se mostrar o mais adequado para
satisfazer as necessidades dos stakeholders.
5. Exemplo
Nessa seo apresentado um exemplo de uso do
Mtodo CRE num processo de seleo de produtos de e-
mail. Esse exemplo possui dois objetivos bsicos, o
primeiro descrever como o critrio de seleo deve ser
elaborado e refinado durante as fases do Mtodo CRE. O
outro objetivo mostrar como o NFR Framework pode ser
usado para auxiliar o processo de tomada de deciso entre
produtos candidatos. Inicialmente, o critrio de seleo
composto pelos requisitos essenciais. No contexto de
pacotes de e-mail, um requisito fundamental que o
sistema permita receber e enviar mensagens pela Internet.
A partir dessas informaes, pode-se comear o processo
de localizao dos possveis COTS candidatos. A Tabela 4
mostra uma possvel lista de produtos de e-mail existentes
no mercado de software. Essa lista o resultado final da
fase de identificao.
Produtos Candidatos
Eudora
Pine
OutLook Express
Pegasus
Netscape Messenger
Tabela 4 Lista com os Produtos COTS Candidatos
Em seguida, o critrio de seleo precisa ser refinado
para permitir que os produtos sejam examinados
detalhadamente em relao aos requisitos dos stakeholders.
Em particular, os requisitos no-funcionais precisam ser
cuidadosamente descritos pois eles so mais difceis de
serem especificados e avaliados. A Tabela 5 mostra o
critrio de seleo com alguns requisitos funcionais e no-
funcionais que o sistema de e-mail precisa atender. Em
relao aos requisitos funcionais, o escore de
conformidade de cada produto pode ser obtido diretamente
pois a descrio desses requisitos explcita e bem
definida. Dentre os requisitos no-funcionais, muitos
podem no ser claros o suficiente para guiar o processo de
avaliao dos produtos e assim precisam ser explicitamente
tratados. Uma exceo o RNF 4 que pode ser facilmente
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada
pelo CNPq 203262/86-7
avaliado pois a compatibilidade com determinada
plataforma uma informao bsica que qualquer
descrio de produtos disponibiliza. Em particular, ele
um importante critrio de eliminao de produtos.
Enquanto os RNF 1, 2 e 3 precisam ser descritos com mais
detalhes para que os produtos sejam efetivamente
avaliados. Nesse momento deve-se usar o NFR
Framework para detalhar tais requisitos. A Figura 8 mostra
o grfico com a decomposio e a interao desses
requisitos obtida com a utilizao do NFR Framework. De
acordo com esse grfico, o requisito Usabilidade, por
exemplo, foi decomposto em Facilidade de aprendizado,
Claridade e Simplicidade que o usurio utiliza o sistema.
J o requisito Segurana foi decomposto no requisitos
Integridade, Disponibilidade e Confidencialidade. Em
seguida, o requisito confiabilidade pode ser
operacionalizado pelos mtodos Identificao e
Autorizao dos usurios. Um aspecto importante desse
grfico que depois que os RNFs foram refinados,
puderam ser identificados alguns relacionamentos entre
requisitos que aparentemente no estavam relacionados.
Nesse exemplo, o relacionamento negativo, isto , existe
uma relao de conflito entre os requisitos. Em particular,
a operacionalizao Autorizao[usurio] interage em
conflito com Simplicidade[sistema]. Ou seja, os mtodos
para autorizao dos usurios influenciam negativamente a
simplicidade do sistema. Em situaes como essa
necessrio um extenso processo priorizao e negociao
desses requisitos, onde a participao dos stakeholders
assume um papel fundamental.
Critrio de Seleo
Requisitos Funcionais
1. O sistema deve ter um corretor ortogrfico.
2. O sistema deve permitir que o usurio predefina tipo e
tamanho da fonte.
3. O sistema deve classificar as mensagens por tipo (ex. data,
tamanho, assunto, etc.)
4. O sistema deve permitir acesso direto arquivos atachados.
5. O sistema deve fornecer a criao de assinaturas.
6. O sistema deve permitir a criao de rascunho das
mensagens.
Requisitos No-Funcionais
1. O sistema deve fornecer mecanismos de segurana.
2. O sistema precisa ser de fcil uso para usurios inexperientes
(i.e. boa usabilidade).
3. O sistema precisa ter boa interoperabilidade com outros
aplicativos.
4. O sistema deve ser compatvel com a plataforma Windows.
Tabela 5 Critrio de Seleo Refinado
 A partir do refinamento desses requisitos no-
funcionais, pode-se verificar a conformidade de cada
produto candidato com tais requisitos. A prxima etapa do
Mtodo CRE realizar a avaliao dos produtos em
relao ao critrio de seleo. Nesse caso, aconselhvel
aplicar a tcnica WSM pois o critrio de seleo simples
e existem poucos produtos para serem avaliados. O
resultado desse processo um ranking dos produtos, onde
o primeiro colocado considerado a melhor alternativa em
Interoperabilidade
Portabilidade Flexibilidade
[sistema] [sistema]
- Simplicidade
Integridade Disponibilidade
Legenda
Softgoal Operacionalizao
Figura 8 Decomposio dos requisitos no-funcionais usando o NFR Framework
6. Concluses
Esse artigo apresentou uma proposta para adaptar
o processo de Engenharia de Requisitos com o
objetivo de atender aos novos desafios e necessidades
do desenvolvimento baseado em COTS. Alm disso,
foi proposto um mtodo para assistir o processo de
seleo de produtos COTS. A principal vantagem do
Mtodo CRE que ele fornece uma abordagem
baseada em requisitos que guia todas as fases do
processo de seleo. Esse mtodo possibilita um
modelo prtico e iterativo para especificar requisitos
dos stakeholders enquanto os produtos esto sendo
avaliados.
Ainda existem algumas limitaes presentes no
Mtodo CRE que espera-se superar em futuras
pesquisas. Em particular, o processo de priorizao e
negociao dos requisitos bastante complexo e
precisa ser tratado com maior profundidade para
tornar o mtodo mais eficaz. Em [RYA97], proposta
uma ferramenta que utiliza a tcnica AHP para
suportar a priorizao de requisitos. Assim, um dos
objetivos futuros dessa pesquisa verificar a
usabilidade dessa ferramenta no contexto especfico
de requisitos para desenvolvimento baseado em
COTS. Uma outra possvel abordagem para tratar a
complexidade do processo de priorizao de
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada
pelo CNPq 203262/86-7
relao aos requisitos do critrio de seleo. Como
sistemas de e-mail no so crticos, pode no ser
necessrio realizar testes de aceitao. Finalmente, os
aspectos legais devem ser examinados antes que o produto
seja adquirido. Depois que todas as etapas do Mtodo CRE
so executadas, verifica-se que o produto Outlook Express
foi o que obteve o maior escore de conformidade com o
critrio de seleo.
Usabilidade
Segurana
Customizao
[sistema] Facilidade
de Aprendizado[usurio] Claridade
[sistema] [sistema]
Confidencialidade
-
Identificao[usurio] Autorizao[usurio]
Contribuio E Interao negativa
requisitos a definio de regras de situao para
resolver conflitos entre requisitos e mostrar possveis
caminhos alternativos para guiar o processo de
seleo. O Mtodo CRE descreve vrias tcnicas e
mtodos que podem ser usados durante a realizao
de cada fase, e dependendo da complexidade de cada
processo de seleo, pode ser desnecessrio utilizar
algumas das tcnicas descritas. Atualmente, esto
sendo realizados estudos de caso reais para validar a
aplicao do Mtodo CRE num contexto industrial.
7. Referncias
[ALV00] Alves, C. Castro, J. e Alencar, F. Requirements
Engineering for COTS Selection. 3rd Workshop on
Requirements Engineering, Rio de Janeiro, Julho,
2000.
[AOY98] Aoyma, M. New Age of Software Development: How
Component-Based Software Engineering Changes the
Way of Software Development. International
Workshop on Component-Based Software
Engineering, Abril, 1998.
[BRO95] Brown, A.W. Carney, D. e Mcfalls, M. D. Technical
Report CMU/SEI-95-SR-007 Proceedings SEI/MCC
Symposium on Use of COTS in Systems Integration.
Junho, 1995.
[BRO96] Brown, A. W. e Wallnau, K. C. Engineering of
Component-Based Systems, Component-Based
Software Engineering. Software Engineering Institute,
IEEE Computer Society Press, 1996.
 [CAR97] Carney, D. Assembling Large Systems from COTS
Components: Opportunities, Cautions, and
Complexities. SEI Monographs on the Use of
Commercial Software in Government Systems, Junho,
1997.
[CHA98] Chaves, A. Tornabene, C. e Wiederhold, G. Software
Component Licensing: A Primer. IEEE Software,
outubro 1998.
[CHU00] Chung, L. Nixon, B. Yu, E. e Mylopoulos, J. Non-
Functional Requirements in Software Engineering.
Kluwer Academic Publisher, 2000.
[CLE96] Clemen, P. T. Making Hard Decisions : An
Introduction to Decision Analysis. Hardcover 2 edio,
1996.
[COC98] http://sunset.usc.edu/research/COCOTS/index.html
[CYS99] Cysneiros, L. M. e Leite, J. C. Integrating Non-
Funcitonal Requirements into Data Modeling. 4th
International Symposium on Requirements
Engineering. Limerick, Irlanda. Junho, 1999.
[DEA97] Dean, C. J. e Vigder, R. M. System Implemention
Using Commercial-Off-The-Shelf Software.
Proceedings of the 1997 Software Technology
Conference. Maio, 1997.
[DEL97] Dellarocas, C. Toward a Design Handbook for
Integrating Software Components. Proceedings of the
Fifth International Symposium on Assessment of
Software Tools - SAST97. Junho, 1997.
[EXP00] http://www.expertchoice.com
[FOR99] Foreman, J. On The Front Lines of COTS Lessons
learned, speculation for the future. Relatrio tcnico,
Software Engineering Institute, 1999.
[FOX97] Fox, G. Marcom, S. e Lantner, K. A Software
Development Process for COTS-based Information
System Infrastructure. Proceedings of the Fifth
International Symposium on Assessment of Software
Tools - SAST97. Junho, 1997.
[GAR95] Garlan, D. Allen, R. e Ockerbloom, J. Architectural
Mismatch: or Why It's Hard to Build Systems Out of
Existing Parts. Proceedings of the 17th International
Conference on Software Engineering, Seattle, 1995.
[GOT94] Gotel, O. e Finkelstein, A. An Analysis of the
Requirements Traceability Problem. 1st International
Conference on Requiremets Engineering, Colorado
Springs, EUA. Abril, 1994.
[HAI97] Haines, G. Carney, D. e Foreman, J. Component-Based
Software Development/COTS Integration. Software
Engineering Institute, Carnegie Mellon University,
USA. Janeiro, 1997.
[KAR96] Karlsson, K. Software Requirements Prioritizing. 2nd
International Conference on Requirements
Engineering, 1996.
[KON95] Kontio, J. A COTS Selection Method and Experiences
of Its Use. Proceedings of the 20th Annual Software
Engineering Workshop, Maryland, Novembro, 1995.
[KON96] Kontio, J. A Case Study in Applying a Systematic
Method for COTS Selection. Proccedings of the 18th
International Conference in Software Engineering,
Berlin, Maro, 1996.
[KOT97] Kotonya, G. e Sommerville, I. Requirements
Engineering Processes and Techniques. Chichester,
John Willy & Sons, 1997.
[KUN99] Kunda, D. e Brooks, L. Applying Social-Technical
Approach for COTS Selection. Proceedings of the 4th
UKAIS Conference, University of York, April 1999.
[MAC98] Macgraw, G. e Viega, J. Why COTS Software
Increases Security Risks. Reliable Software
Technologies. Sterling VA USA. Junho, 1998.
[MAI96] Maiden, N. e Rugg, G. ACRE: Selecting Methods for
Requirements Acquisition. Software Engineering
Journal, vol 5. 1996.
Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada

pelo CNPq 203262/86-7

[NCU00] Ncube, C. A Requirements Engineering Method for [SAA90] Saaty, T. The Analytic Hierarchy Process. New York:
COTS-Based Systems Development. Ph.D thesis. McGraw-Hill, 1990.
School of Informatics, City University, Londres. Maio, [SEI00] www.sei.cmu.edu
2000. [SOM96] Sommerville, I. Software Engineering. 5 Edio.
[NCU99] Ncube, C e Maiden, N. A. M PORE: Procurement- Addison-Wesley, 1996.
Oriented Requirements Engineering Method for the [TRA97] Tran, V e Liu, D. A Procurement-centric Model for
Component-Based Systems Engineering Development Engineering Component-based Software Systems.
Paradigm. International Workshop on Component- Proceedings of the Fifth International Symposium on
Based Software Engineering, Maio, 1999. Assessment of Software Tools - SAST97. Junho,
[OBE97] Oberndorf, P. Facilitating Component-Based Sofware 1997.
Engineering: COTS and Open Systems. Proceedings of [VID96] Vidger, M. R. Gentleman, W. M. e Dean, J. COTS
the Fifth International Symposium on Assessment of Software Integration: State-of-the-Art. Disponvel na
Software Tools - SAST97. Junho, 1997. WEB www.sel.iit.nrc.ca/abstracts/NRC39198.abs,
[OBE98] Oberndorf, P. e Brownsworld, L. Are You Ready for 1995.
COTS? Software Institute Engineering. Agosto, 1997. [VOA97] Voas, J. A Defensive Approach to Certifying COTS
[RYA97] Ryan, K. e Karlsson, J. Prioritizing Software Software. Technical Report. Reliable Software
Requirements in na Industrial Setting. International Technologies Corporation, Sterling VA USA. Agosto,
Conference on Software Engineering, 1997. 1997.

Esse trabalho foi desenvolvido enquanto o autor estava visitando o Departamento de Cincia da Computao, Universidade de Toronto. Essa pesquisa foi parcialmente suportada

pelo CNPq 203262/86-7