Upload
hoangkhanh
View
214
Download
0
Embed Size (px)
Citation preview
Gerência de RequisitosCarla Alessandra Lima Reis (UFPA)
www.ufpa.br/lts
I Workshop Paraense de Tecnologia de Software
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Roteiro Introdução/Motivação
Visão geral da Engenharia de Requisitos
Gerência de Requisitos
Rastreabilidade
GRE no MPS.BR
Exemplos de Ferramentas
2
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Objetivo da Gerência de
Requisitos
O objetivo da Gerência de Requisitos é garantir que
os todos os requisitos aprovados sejam
adequadamente transformados em artefatos,
assim como garantir que cada artefato produzido
tenha tido sua origem em requisitos aprovados.
4
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Níveis de Maturidade MPS.BR
5
Gerenciado Quantitativamente
Parcialmente
Gerenciado
Gerenciado
Parcialmente
Definido
Largamente
Definido
Definido
Em Otimização
5
Medição - MED / Gerência de Configuração - GCOAquisição - AQU / Garantia da Qualidade - GQAGerência de Portfólio de Projetos - GPP
Avaliação e Melhoria do Processo Organizacional - AMPDefinição do Processo Organizacional - DFPGerência de Reutilização - GRUGerência de Recursos Humanos - GRHGerência de Projetos - GPR (evolução)
Desenvolvimento de Requisitos - DREProjeto e Construção do Produto - PCPIntegração do Produto - ITPVerificação - VER / Validação - VAL
Gerência de Decisões - GDEDesenvolvimento para Reutilização - DRUGerência de Riscos - GRI
G
F
E
D
C
Gerência de Requisitos - GRE
Gerência de Projetos - GPR
A
BGerência de Projetos - GPR (evolução)
(sem processo específico)
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
8
Custos gerados por
problemas em requisitos
Segundo Boehm e Papaccio (apud Pfleeger,
2004), o custo relativo para o conserto de um
problema de requisitos em cada fase de
desenvolvimento de sistema é:
$1 na fase de análise de requisitos
$5 na fase de projeto do sistema
$10 na fase de codificação
$20 na fase de teste de unidade
$200 após a entrega do sistema
[Conte 2007]
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Reis, 2007 10
Situação típica
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
12
Requisitos
Um requisito é uma característica do sistema ou a descrição de
algo que o sistema é capaz de realizar, para atingir os seus
objetivos. [Pfleeger (2004)]
Um requisito é descrito como uma propriedade que o software
deve exibir para resolver algum problema no mundo real.
[SWEBOK (2004),]
[Conte 2007]
© Carla A. Lima Reis, 2007 13
Requisitos não são apenas Software!
Sistemas podem ser compostos de subsistemas de vários tipos
System
Subsystem
1
Subsystem
2
Subsystem
3
Assembly a Assembly b Assembly c
Software Program yHardware Device x
(Alexander, 2001)
[Conte 2007]
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
14
Importância dos
Requisitos
Estudo feito pelo Standish Group em 1995 (Pfleeger, 2004)
350 companhias e 8.000 projetos de software
Resultados:
31% dos projetos cancelados antes de estarem completos
Em pequenas companhias, somente 16% dos projetos foram
entregues no prazo e no orçamento inicialmente estabelecidos
Em grandes companhias, apenas 9% atenderam esses critérios
[Conte 2007]
© Carla A. Lima Reis, 2007 15
Causas para os projetos falhos –
Standish Group
Fatores de Projetos Críticos % Resp.
1. Requisitos Incompletos 13.1%
2. Falta de Envolvimento do Usuário 12.4%
3. Falta de Recursos 10,6%
4. Expectativas Irreais 9,9%
5. Falta de Apoio Executivo 9,3%
6. Mudança de Requisitos e Especificações 8,7%
7. Falta de Planejamento 8,1%
8. Sistema não mais necessário 7,5%
Requisitos estão envolvidos na maioria das causas!
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
17
Engenharia de
Requisitos
É o processo de:
Descobrir,
Analisar,
Documentar e
Verificar
...as funções e restrições do sistema
Sommerville (2003)
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Reis, 2007 18
Atividades da Engenharia
de Requisitos
A Engenharia de Requisitos consiste de dois grupos de
atividades relacionadas:
Desenvolvimento de Requisitos (Elicitação, Análise,
Modelagem e Validação)
Gerência de Requisitos (Identificação, Configuração,
Priorização, Rastreabilidade)
© Carla A. Lima Reis, 2007 19
Elicitação, Análise, Modelagem e Validação
Gerência de Requisitos
Novos
requisitos
elicitados
Versões aceitas,
rastreabilidade,
progresso
O Desenvolvimento de Requisitos cria e interpreta os requisitos
A Gerência de Requisitos organiza e mantém registro dos mesmos
Atividades da Engenharia de
Requisitos
[Conte 2007]
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
21
Classificação de
Requisitos
Requisitos Funcionais
Requisitos diretamente ligados a funcionalidade
do software, descrevem as funções que o software
deve executar
Um requisito funcional descreve uma interação
entre o sistema e seu ambiente
Exemplo: “O sistema deve prover um formulário
um relatório com os resultados dos testes clínicos
de um paciente”
[Conte 2007]
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
22
Classificação de
Requisitos
Requisitos Não-Funcionais
São requisitos que expressam condições que o
software deve atender ou qualidades específicas
que o software deve ter
Em vez de informar o que o sistema fará, os
requisitos não-funcionais colocam restrições no
sistema
Exemplo: “As consultas ao sistema devem ser
respondidas em menos de três segundos”
[Conte 2007]
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 24
Desafio Atual no
Processo de Requisitos Gerência de Requisitos
O que se deve gerenciar?
É possível gerenciar efetivamente requisitos?
Qual o ganho com o gerenciamento?
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 25
Gerência de Requisitos Principais Objetivos da Gerência de Requisitos:
Gerenciar mudanças nos requisitos acordados
Gerenciar os relacionamentos entre os requisitos
Gerenciar as dependências entre os documentos de
requisitos e outros documentos produzidos
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
26
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
27
Mudança de Paradigma Formalização (Hazan, 2004):
Antes do Processo de Gerência de Requisitos
“Quem definiu isso? Vou tentar me lembrar...”
Depois do Processo de Gerência de Requisitos
“Quem definiu isso? Foi a área de negócio XYZ no dia 10 de
janeiro segundo consta aqui nessa ata...”
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
28
Mudança de Paradigma
Gerenciamento (Hazan, 2004):
Antes do Processo de Gerência de Requisitos
“Como o usuário pode estar insatisfeito com a mudança de
prazo se estamos fazendo tudo que ele quer?”
Depois do Processo de Gerência de Requisitos
“Informe ao usuário que os novos requisitos acarretarão um
desvio de 20% no prazo e 5% no custo”
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
29
Rastreabilidade de
Requisitos
Um requisito é rastreável se for possível
identificar:
Quem solicitou o requisito
Porque o requisito existe
Quais os requisitos relacionados
Como os requisitos se relacionam a outras
informações
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
30
Rastreabilidade
Seu objetivo é criar vínculos (links) entre os requisitos e outros
itens do sistema
A rastreabilidade é importante para auxiliar a avaliar o impacto
de mudanças nos requisitos (“forward” para o projeto)
E também para demonstrar a completa satisfação dos
requisitos (“backward” do projeto/design)
Rastreabilidade pode ter outros usos e propósitos:
Apoiar verificação
Criar vínculos a documentos de referência
Criar vínculos entre termos e suas definições…
31
Rastreabilidade backward/forward
Requisitos do
Usuário
Projeto do
Sistema
Especificações
do Sistema
forward – p/ avaliar o impacto de mudança
backward – p/a rastrear a origem de um componente
Links lógicos podem ser seguidos em qualquer direção
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
32
Ferramentas de Apoio à Gerência
dos Requisitos
Ferramentas de Gerência de Requisitos devem
oferecer facilidades para:
Identificação e Armazenamento dos Requisitos;
Gerenciamento de mudanças, que ajudem a garantir
que as mudanças solicitadas foram avaliadas e
tratadas corretamente;
Rastreabilidade, que auxiliem a encontrar
dependências entre os requisitos.
33
Recursos para Gerência dos Requisitos
- Site: www.volere.co.uk/index.htm
ReqManager (TABA)
Analyst Pro (Goda
Software, Inc.)
CaliberRM (Borland)
Catalyze (SteelTrace)
Cradle (3SL -
Structured Software
Systems Ltd)
Doors (Telelogic AB)
Objectiver (Cediti)
RDT (Igatech)
Reconcile (Compuware
Corporation)
Requisite Pro (IBM
Rational Software)
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
34
Exemplo de Ferramenta para Rastreabilidade
Impacto de requisitos no projeto
(em outro documento) é encontrado
por vínculos (links)
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
35
Matriz de Rastreabilidade
Tabela utilizada para documentar os
relacionamentos entre os requisitos
Normalmente criam-se diferentes níveis de
requisitos em uma matriz de rastreabilidade:
Requisitos do Cliente,
Requisitos do Sistema,
Módulos de Código,
Casos de Teste...
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
36
Matriz de Rastreabilidade(Hazan, 2004)
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
37
Matriz de Rastreabilidade(Hazan, 2004)
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
38
Matriz de Rastreabilidade(Hazan, 2004)
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
39
Política de Rastreabilidade de
Requisitos Ao adotar um processo de Gerenciamento de
Requisitos, a organização precisa definir sua Política
de Rastreabilidade de Requisitos que deve incluir:
A informação de rastreabilidade que será mantida;
As técnicas e ferramentas que serão utilizadas;
Processo de coleta das informações de rastreabilidade: quem e
quando
Processo de atualização das informações de rastreabilidade,
após alterações
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Rastreabilidade dos
Requisitos
Estabelecimento da Rastreabilidade Bidirecional
Um mecanismo que permita rastrear a dependência
entre os requisitos, os planos do projeto e os produtos
de trabalho deve ser estabelecido, para:
Facilitar a avaliação do impacto das mudanças de
requisitos que possam ocorrer, por exemplo, nas
estimativas do escopo, nos produtos de trabalho ou nas
tarefas do projeto.
A rastreabilidade bidirecional deve ser tanto horizontal
quanto vertical
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Rastreabilidade dos
Requisitos
Itens que devem ser rastreáveis
A rastreabilidade só é efetiva para a avaliação do
impacto das mudanças se existe rastreabilidade
bidirecional entre os itens com impacto no produto:
Requisitos
Produtos de trabalho
Planos do projeto
Códigos de unidade ou módulos do software
Casos de Teste
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Gerência de Mudanças e
de Inconsistências
Procedimentos da Gerência de Mudanças
Durante o projeto, os requisitos podem mudar por uma série de motivos:
Requisitos adicionais podem ser incorporados no projeto e/ou
Mudanças podem ser feitas nos requisitos já existentes.
As necessidades de mudanças devem ser registradas e um histórico das decisões acerca dos requisitos deve estar disponível
Estas decisões são tomadas através da realização de análises de impacto da mudança no projeto e pode incluir aspectos como: influência em outros requisitos, expectativa dos interessados, esforço, cronograma, riscos e custo.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Gerência de Mudanças e
de Inconsistências
Identificação de Inconsistências entre
requisitos e outros produtos de trabalho
A consistência entre os requisitos e os produtos de
trabalho do projeto deve ser constantemente
avaliada e os problemas identificados devem ser
corrigidos.
As inconsistências identificadas devem ser
registradas, e ações corretivas executadas a fim
de resolver as inconsistências.
As ações para correções das inconsistências
devem ser acompanhadas até que sejam
resolvidas.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Gerência de Mudanças e
de Inconsistências
Identificação de Inconsistências entre requisitos e
outros produtos de trabalho (cont.)
Quando há mudanças nos requisitos:
Devem ser identificados os impactos da mudança com a
utilização do instrumento de rastreabilidade dos requisitos
Deve-se examinar se os demais artefatos estão
consistentes com as alterações realizadas como, por
exemplo: verificar se a planilha de estimativas está
contemplando todos os requisitos e mudanças; verificar se
as mudanças dos requisitos foram incorporadas ao
escopo do projeto
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Resultados esperados
de GRE
46
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do processo Capacidade do Processo
A capacidade do processo é representada por um
conjunto de atributos de processo descrito em
termos de resultados esperados.
A capacidade do processo expressa o grau de
refinamento e institucionalização com que o
processo é executado na organização
47
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
48
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do Processo
49
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do Processo
50
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do Processo
51
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
52
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do Processo
53
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do Processo
54
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do Processo
55
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do Processo
56
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do Processo
57
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do Processo
58
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Capacidade do Processo
59
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Exemplos de artefatos
61
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Exemplos de artefatos Parte de uma solicitação de mudança
62
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
Matriz de
Rastreabilidade
63
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 65
Gerência de Requisitos no
TABA Ferramenta para Apoio à Gerência de Requisitos
ReqManager
Vídeo disponível em www.cos.ufrj.br/taba http://ramses.cos.ufrj.br/taba/index.php?option=com_docman&task=doc_download&gid=25&Itemid=119
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 66
Ferramenta
GatherSpace
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 67
Ferramenta
GatherSpace
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 68
Ferramenta GatherSpace
Rastreabilidade
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 69
Ferramenta RTH
(free)http://www.rth-is-
quality.com/home.php
Rastreabilidade
Testes de requisitos
Registro de defeitos
relatórios
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 70
Requisite Pro (Rational)
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 71
Caliber Analyst – Borland
www.borland.com
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 72
Caliber – diagrama de
rastreabilidade
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 73
DOORS (http://www.telelogic.com/products/doors/doors/index.
cfm)
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 74
DOORS
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 75
DOORS
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 76
DOORS
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Rei/ Rodrigo Reis, 2007 77
Enterprise Architect
(http://www.sparxsystems.com.au/)
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Reis, 2007 78
Bibliografia indicada –
Parte I Pfleeger, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2ª edição – 2004, 8587918311
Pressman, R.S. Engenharia de Software. 6ª edição. McGraw-Hill, 2006. (http://www.rspa.com/)
COCKBURN, A. Escrevendo Casos de Uso Eficazes: Um Guia Pratico para Desenvolvedores de Software. Bookman, 2005, 853630457X
Paula Filho, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª edição – 2003.
Sommerville, Ian. Software Engineering. (7th Edition). Addison-Wesley Publishing Co, 2006, 0321313798. (http://www.aw.com/sommerville_br)
Nuseibeh, Easterbrook Requirements Engineering - a roadmap -. (http://www-di.inf.puc-rio.br/~karin/pos/roadmap.pdf)
Neil A. Maiden and Cornelius Ncube. Acquiring COTS Software Selection Requirements. IEEE Software, 15(2):46-56, Mar 1998.
Goguen, Joseph - Requirements Engineering as the reconciliation of social and technical issues - in Requirements Engineering: Social and Technical Issues edited by Joseph Goguen and Marina Jirotka - Academic Press 1994.
Requrements Engineering in the health care domain - L. Cysneiros - RE03- IEEE Joint International Requirements Engineering Conference - Essen, Alemanha, 2003. pp.350-356.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Reis, 2007 79
Bibliografia
indicada/Referências Alexander I., Robertson, S., “Understanding Project Sociology by Modeling Stakeholders”,
IEEE Software, Jan – Feb 2004
Hazan, C., “Implantação de um Processo de Gestão dos Requisitos seguindo o CMMI”, VI Simpósio Internacional de Melhoria de Processo de Software, São Paulo, Nov. 2004
Pfleeger, S. “Engenharia de Software – Teoria e Prática”, 2ª Edição, Prentice Hall, 2004
SWEBOK 2004 – disponível em www.swebok.org
Leite, J.C.S.P., “Entrevistas”, em Livro Vivo : Engenharia de Requisitos, http://livrodeengenhariaderequisitos.blogspot.com/, 2007
Breitman, K. Requisitos. Minicurso – Requisitos – XXII Simpósio Brasileiro de Engenharia de Sofware 2007 – João Pessoa
Conte, T. Gerência de Requisitos. Mini-Curso. COPPE-UFRJ, 2007
Vasconcelos, A. “Visão geral sobre a engenharia de software. UFPE.
- Lab. Tecnologia de SoftwareRede Paraense de Pesquisa em Tecnologias de Informação e Comunicações
© Carla A. Lima Reis, 2007 80
Referências na web Laboratório de Engenharia de Requisitos da UFPE
(http://www.cin.ufpe.br/~ler/home/home.html)
Livro Vivo sobre Engenharia de Requisitos, Prof. Julio Leite
(http://livrodeengenhariaderequisitos.blogspot.com/)
www.inf.puc-rio.br/~karin/pos
Cenários e Léxicos (Sl.les.inf.puc-rio.br/cel)
Artigos do Workshop de Engenharia de Requisitos (wer.inf.puc-
rio.br/WERpapers/)