Universidade
Católica de
Brasília
PRÓ-REITORIA DE PÓS-GRADUAÇÃO E PESQUISA
STRICTO SENSU EM GESTÃO DO CONHECIMENTO
E TECNOLOGIA DA INFORMAÇÃO
Mestrado
BRASÍLIA
2009
EXTRACÃO DE PADRÕES DE ENGENHARIA DE
REQUISITOS E APRENDIZAGEM ORGANIZACIONAL:
UM ESTUDO DE CASO
Autor: Sóstenes Leite da Silva Lucena
SÓSTENES LEITE DA SILVA LUCENA
EXTRAÇÃO DE PADRÕES DE ENGENHARIA DE REQUISITOS E APRENDIZAGEM ORGANIZACIONAL: UM ESTUDO DE CASO
Dissertação apresentada ao Programa de Pós-Graduação Stricto Sensu em Gestão do Conhecimento e Tecnologia da Informação da Universidade Católica de Brasília, como requisito parcial para obtenção do Título de Mestre.
Orientador: Prof. Dr. Gentil José de Lucena Filho
Co-orientador: Prof. Dr. Rodrigo Pires de Campos
Ficha elaborada pela Coordenação de Processamento do Acervo do SIBI – UCB.
L935e Lucena, Sóstenes Leite da Silva.
Extração de padrões de engenharia de requisitos e aprendizagem organizacional : um estudo de caso / Sóstenes Leite da Silva Lucena. – 2009.
122 f. ; il. ; 30 cm
Dissertação (mestrado) – Universidade Católica de Brasília, 2009. Orientação: Gentil José de Lucena Filho
Co-orientação: Rodrigo Pires de Campos
1. Engenharia de software. 2. Engenharia de requisitos. 3. Aprendizagem organizacional. I. Lucena Filho, Gentil José de, orient. II. Campos, Rodrigo Pires de, co-orient. III. Título.
A Deus que sempre está presente em minha vida.
Aos meus pais, Leonardo e Sevirina, a quem devo a oportunidade desta conquista, os quais não apenas confiam, mas acreditam no meu futuro.
As minhas irmãs, Suelle e Sionelly, que apesar dos ‘arengues’ dão apoio no meu dia-a-dia.
A minha namorada Priscila Kelly, a quem agradeço todas as conversas que tivemos, ajudando-me a vencer os muitos obstáculos da vida.
Ao meu grande amigo Robério, que desde o primeiro momento em que pensei no mestrado, tornou-se um incentivador.
Ao grande Ricardo, pelas grandes intervenções nos bons e maus momentos que passei.
A todo o pessoal da antiga SUNMF, especialmente a Eliza e Cláudia, a quem devo muito o que aprendi.
Ao ex-serpriano Carlos Eduardo, forte incentivador do meu trabalho na empresa e no mestrado.
A minha equipe DE1ER: Wescley (goiano), Fernanda (Yan), Elizia (minha tradutora), Sandra (Fofis), Célia (a preocupada), Adelair (que não é baú) e Alexandra (nova Sra. SIAFI).
A Edna, também do SERPRO, a quem até hoje devo chocolates por me ajudar a conseguir algumas informações para compor este trabalho.
Ao meu atual chefe, Marcelo Mesquita.
Aos demais colegas da DEBSA.
Ao meu supervisor de grupo Fabio Rilston, a quem devo apoio a este trabalho.
Ao meu nobre colega André Mariz, pessoa a quem devo parte da descoberta de importantes pontos de minha vida.
Aos amigos que fiz em Brasília: Lindomar, Kátia, Joel, Lia, Francisco Carlos, Luciana e Márden.
Ao professor Rodrigo, que me ajudou a construir um novo modelo mental.
Referência: LUCENA, Sóstenes Leite da Silva. Extração de padrões de engenharia de
requisitos e aprendizagem organizacional: um estudo de caso. 2009. 122 f. Dissertação (Mestrado em Gestão do Conhecimento e Tecnologia da Informação) – Universidade Católica de Brasília, Brasília, 2009.
A Engenharia de Requisitos (ER) é uma das áreas da Engenharia de Software que mais propagam problemas nas demais durante o desenvolvimento de um projeto. Uma das razões para tais problemas está na utilização do processo de ER de forma não padronizada, gerando assim, especificações com requisitos incompletos, ambíguos ou ausentes. Os padrões de ER, por sua vez, apresentam-se como as melhores práticas de utilização da engenharia de requisitos. Um processo de extração destes padrões foi desenvolvido por uma equipe alemã de engenheiros de requisitos em 2004 e, por ser bastante recente, ainda não se observa o uso deste processo em larga escala nas organizações responsáveis pelo desenvolvimento de software. O trabalho inicialmente desenvolvido pela equipe alemã foi adaptado e, em seguida, aplicado em uma unidade de desenvolvimento do Serviço Federal de Processamento de Dados (SERPRO). A adaptação e a realização do processo deu-se, não somente para extrair os padrões de ER, mas num foco mais amplo: encontrar indícios de aprendizagem organizacional durante a realização do processo de extração. Ao término da extração foram elaborados seis padrões de ER que passaram a fazer parte da primeira coleção de padrões da organização. Paralelamente, com base em cinco disciplinas de aprendizagem, identificaram-se diversos elementos de aprendizagem organizacional não apenas durante, mas antes e após a realização do processo.
Requirement Engineering (RE) is one of the areas of Software Engineering that causes more problems during a project development. One of the reasons for such problems is the use of a not standardized process of RE, thus generating incomplete specifications with ambiguous or lack of requirements. RE patterns, in turn, present the best practice of requirement engineering. An extraction process of these patterns was developed by a team of German requirement engineers in 2004 and due to the fact of being recent, it does not yet observes the use of this process on a large scale in software development organizations. The work initially developed by German team was adapted and applied to a department Serviço Federal de Processamento de Dados – SERPRO (Government company responsible for data processing). The adaptation and the accomplishment of the process were used not only to extract the RE patterns, but in a wider focus: to find remains of organizational learning during the accomplishment of the extraction process. Six RE patterns were elaborated at the end of the extraction to be part of the first collection of patterns of the organization. Based on the five disciplines of learning, several elements of organizational learning were identified before and after the accomplishment of the process.
Figura 1 – Mudança de estrutura nas unidades de desenvolvimento do SERPRO ... 16
Figura 2 – Organização e distribuição das equipes na DEBSA ... 16
Figura 3 – Processo da Engenharia de Requisitos e o Modelo Espiral ... 28
Figura 4 – Capturando padrões a partir da observação em casos de estudo ... 39
Figura 5 – Observações semelhantes a partir de projetos distintos ... 44
Figura 6 – Metáfora da mola sob stress de forças contrárias ... 47
Figura 7 – O ‘local da janela’ no formato proposto ... 47
Figura 8 – Visão geral do processo de extração do padrão ... 50
Figura 9 – Estrutura de um caso de estudo ... 51
Figura 10 – Os padrões utilizam os mesmos elementos básicos como observações ... 52
Figura 11 – Visão geral dos assuntos abordados neste trabalho e suas interconexões ... 68
Figura 12 – Paralelos entre a nomenclatura utilizada na ER e no PSDS ... 72
Figura 13 – Processo de extração de padrões de ER na organização em estudo ... 74
Figura 14 – Resumo do delineamento metodológico ... 77
Figura 15 – Padrão “Desenvolva protótipo durante a elicitação de requisitos” e o conflito de forças ... 88
Tabela 1 – Objetivos da Engenharia de Requisitos agrupados por categoria ... 25
Tabela 2 – Entradas e Saídas do Processo de Engenharia de Requisitos ... 27
Tabela 3 – As cinco disciplinas de aprendizagem organizacional: síntese ... 64
Tabela 4 – Observação O1 do caso de estudo do projeto BSPSDS ... 82
Tabela 5 – Obtendo a tarefa T a partir da observação O1 ... 82
Tabela 6 – Obtendo as forças F e F a partir da observação O1 ... 83
Tabela 7 – Obtendo a ação A a partir da observação O1 ... 83
Tabela 8 – Obtendo o resultado R a partir da observação O1 ... 84
Tabela 9 – Observação O2 do caso de estudo do projeto SIAFI ... 85
AO – Aprendizagem Organizacional
DE1ER – Setor de Especificação de Requisitos da DEBSA
DEBSA – UG da SUPDE, localizada em Brasília
ER – Engenharia de Requisitos
GI – German Informatics Society
ISO – International Standards Organization
OA – Organizações que Aprendem
PSDS – Processo SERPRO de Desenvolvimento de Soluções
SERPRO – Serviço Federal de Processamento de Dados
SUPDE – Superintendência de Desenvolvimento do SERPRO
UG – Unidade de Gestão
UML – Unified Modeling Language
1 INTRODUÇÃO ... 14
1.1 MOTIVAÇÃO E CONTEXTO DO TRABALHO ... 14
1.2 OBJETIVOS ... 17
1.2.1 Objetivo geral ... 17
1.2.2 Objetivos específicos ... 17
1.3 JUSTIFICATIVA E RELEVÂNCIA DO ESTUDO ... 18
1.4 ORGANIZAÇÃO DO TRABALHO ... 18
2 ENGENHARIA DE REQUISITOS ... 20
2.1 INTRODUÇÃO ... 20
2.2 VISÃO GERAL DE REQUISITOS ... 21
2.3 ENGENHARIA DE REQUISITOS E O CICLO DE VIDA DO DESENVOLVIMENTO 24 2.4 O PROCESSO DE ENGENHARIA DE REQUISITOS ... 26
2.4.1 Elicitação de requisitos ... 28
2.4.2 Análise e negociação de requisitos ... 31
2.4.3 Documentação de requisitos ... 33
2.4.4 Validação de requisitos ... 34
2.4.5 Gerenciamento de requisitos ... 36
2.5 CONSIDERAÇÕES FINAIS ... 38
3 PADRÕES DE ENGENHARIA DE REQUISITOS... 39
3.1 INTRODUÇÃO ... 39
3.2 PADRÕES ... 40
3.3 OS PADRÕES DE ENGENHARIA DE REQUISITOS ... 42
3.3.1 Requisitos para os padrões da Engenharia de Requisitos ... 43
3.3.2 Estrutura de um padrão de Engenharia de Requisitos ... 46
3.3.3 O processo de extração do padrão ... 49
3.3.3.1 Atividade “coletar casos de estudo” ... 50
3.3.3.2 Atividade “analisar observações” ... 51
3.3.3.3 Atividade “extrair padrões candidatos” ... 52
3.3.3.4 Atividade “elaborar padrões” ... 52
3.4 CONSIDERAÇÕES FINAIS ... 53
4 PADRÕES DE ER E APRENDIZAGEM ORGANIZACIONAL ... 54
4.1 INTRODUÇÃO ... 54
4.2 APRENDIZAGEM ORGANIZACIONAL ... 55
4.3 OS PADRÕES DE ER E AS ORGANIZAÇÕES QUE APRENDEM ... 58
4.3.1 As cinco disciplinas de aprendizagem ... 58
4.3.1.1 Domínio pessoal ... 59
4.3.1.2 Modelos mentais ... 60
4.3.1.3 Visão compartilhada ... 61
4.3.1.4 Aprendizagem em equipe ... 62
4.3.1.5 Pensamento sistêmico ... 63
4.3.2 O caminho da aprendizagem organizacional ... 64
5.3 DELINEAMENTO METODOLÓGICO ... 69
5.3.1 Desenvolvimento da teoria ... 69
5.3.2 Seleção do caso ... 70
5.3.3 Delimitação do estudo ... 70
5.3.4 Condução do estudo ... 70
5.3.5 Preparação ... 71
5.3.5.1 Adaptação do processo para extração dos padrões de ER na organização em estudo ... 73
5.3.5.2 A coleta dos indícios de aprendizagem na organização em estudo ... 75
5.3.6 Resumo do delineamento metodológico ... 76
5.4 CONSIDERAÇÕES FINAIS ... 78
6 ESTUDO DE CASO ... 79
6.1 INTRODUÇÃO ... 79
6.2 ANÁLISE GERAL DOS PROCEDIMENTOS INTERNOS DA DEBSA ... 79
6.3 EXTRAINDO PADRÕES DE ER NA DEBSA ... 81
6.3.1 Coletando e analisando ... 81
6.3.2 Outros casos de estudo ... 85
6.3.3 Extraindo o padrão candidato ... 86
6.3.4 Elaborando a descrição do padrão ... 88
6.4 INDÍCIOS DE APRENDIZAGEM ORGANIZACIONAL NA DEBSA ... 89
6.5 CONSIDERAÇÕES FINAIS ... 92
7 DISCUSSÃO ... 93
8 CONCLUSÃO E PERSPECTIVAS FUTURAS ... 97
1 INTRODUÇÃO
1.1 MOTIVAÇÃO E CONTEXTO DO TRABALHO
A Engenharia de Software foi criada em resposta aos problemas enfrentados no
desenvolvimento de software e tem estado em crescente progresso, produzindo novas
metodologias, paradigmas e ferramentas. Dentre suas várias atividades, uma das que apresentam
maiores problemas quando feita de forma inadequada é a Engenharia de Requisitos (FAULK,
1997).
Engenharia de Requisitos é um campo de estudo, dentro do contexto da Engenharia de
Software, que está relacionado à identificação, validação e documentação das funções e restrições
que precisam ser respeitadas por um software em sua construção e operação (LOPES, 2002). A
Engenharia de Requisitos (ER) de software é uma atividade que engloba a descoberta,
documentação e manutenção do conjunto de requisitos de um sistema de software
(SOMMERVILLE e SAWYER, 1997).
Entretanto, apesar da crescente evolução nas pesquisas, a utilização da Engenharia de
Requisitos de maneira não orientada, pode derivar muitas formas, gerando, dessa maneira, a não
padronização de seu uso e conseqüentemente resultados práticos distintos. Mas, há como
padronizar a sua utilização?
Segundo Fischer (2002), disciplinando as pessoas, no sentido de fazê-las proceder de
acordo com regras estabelecidas, sem inibir a criatividade, a padronização traz à tona as
necessidades de educação, treinamento e capacitação, além da motivação profissional do ser
humano. Por meio da padronização, torna-se possível a incorporação de experiências pessoais ao
domínio tecnológico da empresa. A padronização visa reduzir a variabilidade dos processos de
trabalho sem prejudicar sua flexibilidade.
Todavia, um programa de normalização ou padronização só será efetivamente implantado
se existir a participação de todos os envolvidos na elaboração dos procedimentos e normas. A
participação das pessoas neste ponto é determinante, e o comprometimento de todos os
envolvidos se torna imprescindível (OLIVEIRA, 1991). Seguindo esta linha, pergunta-se: então
Segundo Hagge e Lappe (2004), é possível estabelecer padrões de ER. Estes são
derivados de casos de estudo e descrevem práticas em Engenharia de Requisitos que têm sido
utilizados com sucesso em diferentes projetos.
A utilidade do conceito sobre padrões está essencialmente no fato dele permitir repassar
experiências e torna-las facilmente disponíveis (SOUVEYET e DENECKERE, 1999, p. 3). “A
busca e a aplicação de padrões indica um progresso humano”, afirmou Coad (1992 apud
SOUVEYET e DENECKERE, 1999).
Assim, o objetivo dos padrões de ER é fazer o conhecimento e a experiência em
engenharia de requisitos reutilizáveis. Os padrões são escritos em um formato que faz seu o
conteúdo facilmente acessível (HAGGE e LAPPE, 2006). Mas o que, de fato, motiva a
construção deste trabalho?
Há alguns meses, durante a reestruturação de Unidades de Gestão (UG) do Serviço
Federal de Processamento de Dados (SERPRO)1, diversas UG foram fundidas em uma. Até setembro de 2007 toda UG controlava, a partir da sede, suas respectivas projeções que, até então,
eram unidades responsáveis pelo desenvolvimento e manutenção dos sistemas de seus clientes.
Entretanto, a partir de outubro daquele ano, algumas unidades passaram a ter uma única gerência.
A UG responsável por tal gestão foi chamada de “Superintendência de Desenvolvimento”, ou
simplesmente, “SUPDE”. Em julho do ano seguinte, evento semelhante ocorreu com outras
unidades. A Figura 1 ilustra a reestruturação das unidades de desenvolvimento do SERPRO.
Com a nova estrutura as unidades de desenvolvimento da SUPDE foram centralizadas nas
regionais. Em Brasília, por exemplo, havia uma unidade para cada uma das projeções das
seguintes UG: SUNAF, SUNMF, SUNMP, SUNNE e SUNSP; todas passaram a ser uma única
UG: DEBSA.
1 O Serviço Federal de Processamento de Dados (SERPRO) é uma empresa de informática vinculada ao Ministério
Figura 1 – Mudança de estrutura nas unidades de desenvolvimento do SERPRO Fonte: Elaboração do autor
Antes da formação da DEBSA, todas as UG de Brasília trabalhavam de forma
independente. Suas interações se davam apenas quando os sistemas que estavam sob sua
responsabilidade necessitavam de integração. Entretanto, logo após a criação da DEBSA, os
empregados que compunham as antigas UG foram distribuídos em onze equipes (Figura 2),
elevando, desta maneira a integração e o conhecimento entre as pessoas. Uma destas equipes foi
intitulada ‘Setor de Especificação de Requisitos de Brasília’, ou simplesmente ‘DE1ER’.
Naquele momento a DEBSA incumbiu à equipe DE1ER a elaboração de um
planejamento para identificar, analisar, registrar e disseminar as melhores práticas na utilização
do processo de requisitos e conseqüente elaboração de seus respectivos artefatos.
Na busca por uma solução, foi encontrada uma pesquisa realizada pelos alemães Hagge e
Lappe (2006), os quais afirmam que, no contexto da Engenharia de Requisitos, “a recorrente
observação das melhores práticas em diferentes projetos em um formato instrutivo são
considerados padrões de ER”; e complementam o trabalho afirmando que a utilização de padrões
de ER favorece a aprendizagem organizacional.
Assim, este trabalho vem fomentar o atendimento da incumbência determinada para a
equipe DE1ER e visa, em primeira ordem, responder ao seguinte questionamento: que padrões
podem ser extraídos a partir do uso do processo de Engenharia de Requisitos na DEBSA e que
elementos de aprendizagem organizacional podem ser observados na extração daqueles?
As cinco disciplinas de aprendizagem apresentadas por Senge (2004) são delineadas neste
trabalho. Segundo o autor “as cinco disciplinas se mostram essenciais para a construção da
organização que aprende” e “a prática destas disciplinas gera um ciclo de aprendizagem contínua
e profunda”.
1.2 OBJETIVOS
1.2.1 Objetivo geral
O objetivo deste trabalho é explorar a relação entre o processo de padrões de Engenharia
de Requisitos e a aprendizagem organizacional.
1.2.2 Objetivos específicos
Os objetivos específicos são:
• Extrair padrões de Engenharia de Requisitos;
• Identificar elementos das cinco disciplinas no processo de extração dos padrões de
1.3 JUSTIFICATIVA E RELEVÂNCIA DO ESTUDO
A Engenharia de Requisitos ainda não é uma ciência completa. Muitos problemas que
ocorrem no processo de ER desencadeiam nas demais áreas da Engenharia de Software. Todavia,
a transformação das melhores práticas de ER em padrões de uso em uma organização, reduz os
problemas durante o desenvolvimento.
No entanto, como todo indivíduo, uma organização possui suas características
particulares. Dessa maneira, os padrões de uma organização podem não ser úteis para outra, em
razão de suas diferenças culturais, políticas, etc.
Ainda que isso não quer dizer que não se devem utilizar experiências de outras
organizações, é necessário descobrir padrões próprios.
Neste contexto, acredita-se que durante o processo de descoberta de padrões de ER, tal
como o estabelecimento destes em uma organização, ocorre um processo ainda mais amplo: a
Aprendizagem Organizacional.
Nesse sentido, um campo de investigação se abre, com o intuito de buscar não somente
estabelecer os padrões de ER em uma organização, como também encontrar indícios de
aprendizagem organizacional por trás de todo o processo.
1.4 ORGANIZAÇÃO DO TRABALHO
Este trabalho está organizado em oito capítulos. Na introdução descreveu-se a motivação,
definiu-se o problema, apresentaram-se os objetivos, a justificativa e relevância do estudo, a
metodologia, a delimitação e a estrutura do trabalho.
No capítulo 2 é feita a revisão bibliográfica sobre Engenharia de Requisitos. Discorre-se
sobre a visão geral de requisitos; a engenharia de requisitos e o ciclo de desenvolvimento; além
do de seu processo em conjunto com suas atividades.
No capítulo 3 especializa-se o tema de Engenharia de Requisitos. É apresentado o
conceito de ‘padrão’ e seqüencialmente este é tratado no contexto da ER. São apresentados, além
No capítulo 4 é apresentada a definição de Aprendizagem Organizacional defendida por
autores consagrados no tema. Em seguida, é realizada a conexão entre os padrões de ER e as
cinco disciplinas de aprendizagem.
O capítulo 5 delineia a metodologia utilizada neste trabalho. São descritas a classificação,
a seleção do caso, a delimitação do estudo e a preparação para o estudo de caso. Nesta é
apresentada a adaptação do processo para a extração dos padrões de ER para a organização em
estudo, tal como deu-se a coleta dos indícios de aprendizagem organizacional na mesma.
O capítulo 6 discorre sobre os resultados da realização do processo de extração de padrões
de ER na DEBSA, além os indícios de aprendizagem organizacional observados nesta.
O capítulo 7 tece discussões sobre os padrões de ER, tal como seu relacionamento com a
aprendizagem organizacional.
E, por fim, o capítulo 8 encerra o trabalho, trazendo as conclusões, contribuições e
2 ENGENHARIA DE REQUISITOS
2.1 INTRODUÇÃO
Quando a “Crise do Software” foi nomeada nos anos 60, muito esforço foi direcionado
para encontrar as causas da síndrome de problemas (NAUR e RANDELL, 1969). Ainda na
década de 70, investigações determinaram que deficiências nos requisitos estavam entre as mais
importantes causas do problema: “Em quase todo projeto de software a falha nos objetivos de
desempenho e custo, requisitos inadequados desempenham o papel mais expressivo na falha do
projeto” (ALFORD e LAWSON, 1979). O desenvolvimento da especificação de requisitos “em
muitos casos parece trivial, mas provavelmente é a parte do processo que leva a mais falhas que
qualquer outra” (SCHWARTZ, 1975).
Em 1996, o Instituto de Software Europeu (European Software Institute - ESI) apresentou
os problemas relacionados à Engenharia de Requisitos (ER) como sendo os maiores ofensores
para o sucesso dos projetos da Engenharia de Software. Um questionário distribuído a 3.805
empresas na Europa, aplicado aos profissionais desta área, apontou a seguinte classificação dos
problemas: especificação de requisitos (53%), gerência de requisitos (43%), documentação (36%)
e teste (35%) (ESI, 1996).
Levantamentos recentes no Instituto de Engenharia de Software (Software Engineering
Institute - SEI), nos Estados Unidos, ainda confirmam deficiências na especificação e na gerência
de requisitos como os principais aspectos responsáveis pela atual crise de software. No Brasil,
estudos recentes corroboram essa constatação (PINHEIRO et al., 2003).
Desta maneira, a Engenharia de Requisitos passou a obter maior interesse dos
pesquisadores acerca de como elicitar, coletar, analisar e especificar formalmente os requisitos de
um sistema (HSIA, apud CESPEDES, 2002, p. 2).
Pesquisadores como Maiden (1996), Leite (1997), Viller (1999), Leffingwell (2000),
Nuseibeh (2000), Gunter (2000), Young (2001), Coughlan (2002), Toranzo (2002), Gottesdiener
(2002), Rupp (2002), Lausen (2002), Hickey (2002), Carvalho (2003), Pinheiro (2003), Falbo
(2004), Sommerville (2005), entre outros, têm investigado temas relacionados à Engenharia de
A partir dessas pesquisas, um grande conjunto de processos2, métodos3, técnicas4 e ferramentas computacionais5 foram criadas e são, atualmente, utilizadas pela Engenharia de Requisitos, durante o processo de desenvolvimento de software. Com a evolução da ER, porém,
várias empresas têm procurado aperfeiçoar os métodos para capturar, analisar, validar e gerenciar
os seus requisitos. A ER tem auxiliado os engenheiros de software nesse sentido, provendo
mecanismos que auxiliam no entendimento do que o cliente precisa; na análise de suas
necessidades; na avaliação da exeqüibilidade da solução proposta; na negociação de uma
estratégia adequada à sua construção; na elaboração de uma especificação livre de ambigüidades;
na validação dessa especificação junto aos clientes/usuários; e, finalmente, no gerenciamento dos
requisitos coletados à medida em que estes são transformados em um sistema operacional
(THAYER e DORFMAN, 1997).
Este capítulo apresenta uma visão geral sobre a Engenharia de Requisitos. Inicialmente,
são tecidas considerações a respeito do que seja “requisito”. Em seguida, conceitua-se
Engenharia de Requisitos e sua importância no processo de desenvolvimento de software.
Posteriormente são apresentadas as fases do processo de engenharia de requisitos e suas
principais características. A última seção encerra o capítulo tecendo as considerações finais sobre
a importância da engenharia de requisitos para a qualidade de um projeto de software.
2.2 VISÃO GERAL DE REQUISITOS
Uma das primeiras medidas do sucesso de um sistema de software é verificar se ele
atende às necessidades dos clientes (NUSEIBEH e EASTERBROOK, 2000). Num dos primeiros
trabalhos realizados na área, Bell e Thayer (1976) observaram que muitos requisitos são
inadequados, inconsistentes, incompletos e ambíguos e exercem um grande impacto na
qualidade do software final. A partir dessa observação, eles concluíram que “requisitos para um
2 Processo é um roteiro (uma série de passos) que ajuda a criar, a um tempo, um resultado de alta qualidade
(PRESSMAN, 2002, p.17).
3 Método é uma forma de selecionar técnicas, forma de avaliar alternativas para ação científica. Assim,
enquanto as técnicas utilizadas por um cientista são fruto de suas decisões, o modo pelo qual tais decisões são tomadas depende de suas regras de decisão. “Métodos são regras de escolha; técnicas são as próprias escolhas" (Hegenberg, apud MORESI, 2004, p.15); O método é o conjunto das atividades sistemáticas e racionais que, com maior segurança e economia, permite alcançar o objetivo - conhecimentos válidos e verdadeiros - traçando o caminho a ser seguido, detectando erros e auxiliando as decisões do cientista (MORESI, 2004, p.16).
4 Técnica é o como fazer (PRESSMAN, 2002, p.19).
5 As ferramentas computacionais fornecem apoio automatizado, ou semi-automatizado para o processo e para
dado sistema não aparecem naturalmente; ao contrário, eles precisam ser projetados e revisados
continuamente”.
Estudos indicam que, quando detectados apenas depois do software implementado, erros
em requisitos de software são até 20 vezes mais caros de se corrigir que qualquer outro tipo de
erro, e até 200 vezes mais custosos do que seriam se corrigidos durante a fase de engenharia dos
requisitos (BOEHM, 1981; 1984). Estudos recentes comprovam que os problemas relacionados
aos requisitos do sistema afetam boa parte das organizações que desenvolvem e usam sistemas de
software (JOHNSON, 2001; ESPITI, 1996). Corroborando essa constatação, novos estudos
reconhecem a Engenharia de Requisitos como uma das fases mais importantes do processo de
engenharia de software (VAN LAMSWEERDE, 2000; PINHEIRO et al., 2003).
Todavia, a fim de melhorar a qualidade dos requisitos, é necessário definir inicialmente o
que são realmente “requisitos”. Existem inúmeras definições disponíveis na literatura para o
termo. Segundo Kotonya e Sommerville (1997), um requisito pode descrever:
1) Uma facilidade no nível do usuário; por exemplo, um corretor de gramática e
ortografia;
2) Uma propriedade muito geral do sistema; por exemplo, o sigilo de informações
sem a devida autorização;
3) Uma restrição específica no sistema; por exemplo, o tempo de varredura de um
sensor;
4) Uma restrição no desenvolvimento do sistema; por exemplo, a linguagem que
deverá ser utilizada para o seu desenvolvimento.
Uma definição bastante simples para requisitos é dada por Macaulay (1996), segundo o
qual requisito é “simplesmente algo de que o cliente necessita”. Segundo Jackson (1995),
requisitos são fenômenos ou propriedades do domínio da aplicação que devem ser executados,
normalmente expressos em linguagem natural, diagrama informal ou outra notação apropriada ao
entendimento do cliente e da equipe de desenvolvimento. Este trabalho segue a definição de
Dorfman e Thayer (1990), os quais conceituam requisitos como sendo:
a) uma capacidade do software necessitada pelo usuário para resolver um problema e
b) uma capacidade de software que um sistema (ou um componente) deve atingir ou
possuir para satisfazer um contrato, padrão, especificação ou outra documentação
formalmente imposta.
Além de requisitos, outra definição necessária é a de Engenharia de Requisitos. Segundo
o Institute of Electrical and Electronics Engineers (IEEE), engenharia de requisitos corresponde
ao processo de aquisição, refinamento e verificação das necessidades do cliente para um sistema
de software, objetivando-se ter uma especificação completa e correta dos requisitos de software
(IEEE, 1984). Zave (1997) coloca que a engenharia de requisitos está relacionada com a
identificação de metas para serem atingidas pelo sistema a ser desenvolvido, assim como a
operacionalização de tais metas em serviços e restrições. A definição de Loucopoulos e
Karakostas (1995) será adotada no contexto desta dissertação. Os autores descrevem a engenharia
de requisitos como um processo sistemático de desenvolvimento dos requisitos por meio de um
processo iterativo e cooperativo de análise do problema, documentação das observações
resultantes numa variedade de formatos, e checagem do entendimento obtido. Em termos
simples, o objetivo desse processo é desenvolver uma especificação de requisitos (COMPUTER,
1985), o que envolve uma integração de conceitos relacionados com aspectos de representação,
sociais e cognitivos (POHL, 1993). Essa diversidade de fatores faz da engenharia de requisitos
uma área eminentemente multidisciplinar, em que aspectos sociais e humanos desempenham um
importante papel (ZAVE, 1997; NUSEIBEH e EASTERBROOK, 2000).
Existem pelo menos três grandes benefícios ao se desenvolver uma especificação de
requisitos (LOUCOPOULOS e KARAKOSTAS, 1995):
1) O documento gerado provê um ponto focal para o processo de comunicar um
entendimento sobre um dado domínio, negócio e o próprio sistema-alvo. A
especificação funciona, então, como uma linguagem para representar conteúdos;
2) A especificação serve como parte de um acordo contratual, um artifício que pode se
tornar bastante relevante para o relacionamento com agentes externos como clientes
e fornecedores;
3) A especificação pode ser usada para avaliar o produto final e assim ter um papel
Uma especificação de requisitos completa abrange uma ampla gama de requisitos.
Tradicionalmente, os requisitos de software são classificados em requisitos funcionais,
não-funcionais e organizacionais (SOMMERVILLE, 2001; ALENCAR, 1999):
• Requisitos Funcionais. São as declarações das funções que o sistema deve oferecer, como o sistema se comporta com entradas particulares e como ele deve
reagir em situações específicas. O termo função é usado no sentido genérico da
operação que pode ser realizada pelo sistema, seja por meio de comandos dos
usuários, ou seja pela ocorrência de eventos internos ou externos ao sistema. Em
alguns casos, os requisitos funcionais podem também explicitamente definir o que
o sistema não deve fazer.
• Requisitos Não-Funcionais. São as restrições nas funções oferecidas pelo
sistema. Incluem restrições de tempo, restrições no processo de desenvolvimento,
padrões, e qualidades globais de um software, como manutenibilidade,
usabilidade, desempenho, custos e várias outras.
• Requisitos Organizacionais. Derivados diretamente de procedimentos e políticas organizacionais e relacionados com os objetivos e metas da organização.
A necessidade de se estabelecer os requisitos de forma mais precisa é crítica à medida que
o tamanho e a complexidade do software aumentam. Os requisitos exercem influência uns sobre
os outros. Por exemplo, o requisito de que o software deve ter grande portabilidade pode implicar
que o requisito desempenho não seja satisfeito.
2.3 ENGENHARIA DE REQUISITOS E O CICLO DE VIDA DO DESENVOLVIMENTO
Desenvolver sistemas constitui uma atividade de projeto (design) (LOUCOPOULOS e
KARAKOSTAS, 1995). Segundo Dasgupta (1991), um projeto de sistema tipicamente envolve
os seguintes aspectos: (a) um conjunto de requisitos a ser satisfeito por algum artefato; (b) a saída
do processo com algum tipo de documento de especificação de projeto; e (c) a materialização da
especificação detalhada no artefato que é implementada por um desenvolvedor, o qual não detém
Esses aspectos deixam aparente a estreita relação entre a engenharia de requisitos e a
atividade de projetar software, bem como o grau de dificuldade enfrentado por engenheiros de
sistema ao tentar traduzir requisitos do usuário numa solução de software. De fato, o software em
si não possui valor se seus usuários não conseguem utilizá-lo para satisfazer suas necessidades de
resolução de problemas. A análise de requisitos é o processo que visa a descoberta de requisitos;
sua análise para identificar relevância, inconsistências, ausência de requisitos e praticidade; e a
negociação dos requisitos finais para o sistema (KOTONYA e SOMMERVILLE, 1997).
Em contrapartida, os diversos relacionamentos e restrições que os requisitos exercem uns
sobre os outros são muito difíceis de ser controlados. Principalmente se considerarmos que
algumas decisões de projeto que afetam um ou mais requisitos só serão tomadas em fases
adiantadas do desenvolvimento (STRAW01, 2001). Dessa forma, os requisitos precisam ser
gerenciados ao longo de todo o ciclo de vida do projeto. Isso requer a definição e uso de
processos, métodos e ferramentas dentro do contexto de uma estratégia global de
desenvolvimento, comumente referenciada na literatura como modelo de processo de software
(PRESSMAN, 2002). Inúmeros modelos de processo incluem atividades de engenharia de
requisitos em seu conjunto (ROYCE, 1970; FLOYD, 1984; BOEHM, 1988, 1998a; ARANGO,
1988; McDERMID e ROOK, 1993; DAVIS e SITARAM, 1994; KRUCHTEN, 1999). Em geral,
essas atividades atendem a três grupos principais de objetivos (ZAVE, 1997) conforme descrito
na Tabela 1.
Tabela 1 – Objetivos da Engenharia de Requisitos agrupados por categoria.
G1
Investigação de objetivos, funções e restrições de uma aplicação de software
Reduzir as barreiras de comunicação
Gerar estratégias para converter objetivos vagos em propriedades ou restrições específicas
Compreender prioridades e graus de satisfação Associar requisitos com os vários agentes do domínio Estimar custos, riscos e cronogramas
Assegurar completude
G2 Especificação do software
Integrar representações e visões múltiplas
Avaliar estratégias de soluções alternativas que satisfaçam os requisitos Obter uma especificação mais completa, mais consistente e menos ambígua
Validar a especificação (verificar que ela satisfaz aos requisitos)
Obter especificações que sejam apropriadas para as atividades de projeto (design) e implementação
G3 Gerenciamento da evolução e das famílias do software
Reutilização de requisitos durante o processo de evolução
Reutilização de requisitos no desenvolvimento de software similares Reconstrução de requisitos
Normalmente, a engenharia de requisitos é considerada a atividade inicial do processo de
desenvolvimento (CARVALHO, 2002). Informações sobre sistemas já existentes, necessidades
das partes interessadas (stakeholders), padrões da organização, regulamentações, informações do
domínio da aplicação, entre outros insumos, são fornecidos como entrada ao processo de análise
dos requisitos, o qual produz como resultado requisitos acordados, uma especificação de
requisitos e um modelo de requisitos. Quando a fase de requisitos é executada de forma
incompleta ou inconsistente, os artefatos resultantes comprometem a qualidade do produto
desenvolvido nas etapas seguintes do processo de software (Projeto, Implementação e Testes).
Em contrapartida, os benefícios que a aplicação correta dos princípios de engenharia de requisitos
pode trazer ao processo de desenvolvimento incluem:
• Concordância entre desenvolvedores, clientes e usuário sobre o trabalho a ser feito
e quais os critérios de aceitação do sistema;
• Uma base precisa para a estimativa dos recursos (custo, pessoal, prazos, ferramentas e equipamentos);
• Melhoria na usabilidade, manutenibilidade e outras qualidades do sistema;
• Atingir os objetivos com o mínimo de desperdício.
Na seção seguinte é apresentado como o processo de engenharia de requisitos é
estruturado de forma a atingir esses objetivos.
2.4 O PROCESSO DE ENGENHARIA DE REQUISITOS
De acordo com a International Standards Organization (ISO), o termo processo é
definido como “um grupo de atividades inter-relacionadas que se caracterizam por uma série de
entradas específicas que agregam valor e fornecem uma série de saídas específicas para clientes
externos e internos”.
O processo de engenharia de requisitos é um conjunto estruturado de atividades que são
seguidas para derivar, validar e manter um documento de requisito (KOTONYA e
SOMMERVILLE, 1997). Uma descrição completa do processo deve incluir: (a) quais atividades
das atividades; (d) suas entradas e saídas; e (e) as ferramentas usadas para suportar a engenharia
de requisitos.
Embora o processo de Engenharia de Requisitos varie de uma organização para outra,
podendo diferir inclusive na mesma organização, suas entradas e saídas, na maioria dos casos,
são similares. O processo de Engenharia de Requisitos é um processo de projeto (design) com
entradas e saídas, como descrito na Tabela 2.
Tabela 2 – Entradas e Saídas do Processo de Engenharia de Requisitos.
ENTRADA OU SAÍDA TIPO DESCRIÇÃO
Informações dos Sistemas Existentes Entrada Refere-se a informações gerais sobre o sistema que será substituído ou criado e de outros sistemas com o qual o sistema deverá interagir.
Necessidades das partes interessadas (stakeholders)
Entrada Refere-se a uma descrição das necessidades das partes interessadas para apoiar seu trabalho.
Padrões corporativos Entrada Refere-se a padrões e normas adotadas pela empresa para o desenvolvimento de sistemas, incluindo métodos para o desenvolvimento, práticas para garantia de qualidade etc.
Normas e regulamentos Entrada Normas e regulamentos externos que se apliquem ao sistema.
Informações do Domínio Entrada Informações gerais sobre o domínio do sistema.
Requisitos Definidos Saída Descrição dos requisitos levantados, avaliados e aprovados pelas partes interessadas.
Especificação do Sistema Saída Uma especificação mais detalhada do sistema a ser desenvolvido.
Modelos do Sistema Saída Um conjunto de modelos que descrevem o sistema a partir de diferentes perspectivas.
Fonte: Kotonya e Sommerville (1997)
Dentre as várias propostas para modelos de processo de engenharia de requisitos
existentes na literatura, o contexto dessa dissertação segue o modelo proposto por Kotonya e
Sommerville (1997). O modelo está baseado num ciclo em espiral (Figura 3), em que o início do
processo ocorre com a execução de atividades de elicitação de requisitos, seguidas pela análise e
negociação desses requisitos, sua documentação e posterior validação. O processo se repete ao
longo dos ciclos da espiral tantas vezes quanto sejam necessárias, até que se atinja um ponto de
decisão de aceitação do documento final de requisitos. Para Nuseibeh e Easterbrook (2000), esse
modelo espiral constitui-se, na prática, de um conjunto de processos interativos, interelacionados
Não obstante, a aplicabilidade do modelo dependerá, dentre outros fatores, do domínio da
aplicação considerada. No capítulo 5 a proposta de Kotonya e Sommerville (1997) é adaptada
para contemplar aspectos de requisitos peculiares ao processo de desenvolvimento do SERPRO.
Por ora, as seções seguintes descrevem a natureza e o propósito das fases que integram
originalmente o referido modelo.
Figura 3 – Processo da Engenharia de Requisitos e o Modelo Espiral Fonte: Kotonya e Sommerville (1997), adaptado.
2.4.1 Elicitação de requisitos
Elicitar6 requisitos é a atividade relacionada com a identificação dos requisitos do sistema, a partir de consulta aos representantes de cada grupo de usuários; da análise de documentos do
domínio em questão; do conhecimento desse domínio; e/ou de pesquisas de mercado. A
finalidade geral do processo de elicitação é identificar os fatos que compõem os requisitos do
sistema, de forma a prover o mais correto entendimento do que dele é esperado. Outro papel
relevante dessa atividade é a descoberta das necessidades das diferentes classes de usuários
6 [Do lat. elicitus, part. pass. de elicere, extrair , tirar de , + -ar2; ingl. (to) elicit.] Verbo transitivo direto.
(SHARP et al., 1999). Aliado a esse processo de descoberta, uma elicitação de requisitos
consistente requer também uma criteriosa análise da organização, do domínio da aplicação e dos
processos organizacionais (KOTONYA e SOMMERVILLE, 1997).
Dessa forma, elicitar requisitos apresenta inúmeros desafios. Segundo Toranzo (2002), os
principais problemas que afetam a etapa de elicitação podem ser classificados em quatro
categorias:
i) Problemas de Escopo. Vinculados ao desconhecimento de informações do sistema relativas à organização (restrições, objetivos, metas e expectativas), ao
ambiente organizacional (fatores sociais, econômicos e políticos), ao projeto e a
sua interface computacional (necessidades/restrições de software e hardware do
sistema);
ii) Problemas de Entendimento. Relacionados a dificuldades de comunicação entre desenvolvedores e usuários, e à falta de entendimento dos requisitos informados
entre ambas as partes, incluindo problemas humanos relativos à aquisição e
disseminação do conhecimento;
iii) Problemas Técnicos. Nesta categoria estão inclusos alguns problemas que afetam o sucesso do processo de elicitação, tais como (a) mudanças tecnológicas no
software e hardware; (b) usuários exigindo sistemas cada vez maiores e
complexos; (c) mudanças de requisitos com o tempo; (d) existência de muitas
fontes de informação para os requisitos; (e) dificuldades com o reuso de
conhecimento pelos analistas;
iv) Problemas de Comportamento Humano. Decorrentes da interação entre as pessoas, envolvendo aspectos tanto individuais quanto coletivos.
Para resolver esses problemas, várias técnicas de elicitação têm sido propostas. A seguir,
são descritas as principais categorias de técnicas de elicitação de requisitos:
• Técnicas Tradicionais. Utilizadas regularmente em várias áreas do conhecimento, como por exemplo a aplicação de questionários, a observação e a
• Técnicas de Elicitação em Grupo. Visam melhor compreender o pensamento e comportamento dos grupos, com o intuito de captar de maneira mais detalhada as
necessidades dos usuários. Como principais exemplos dessa categoria,
destacam-se as técnicas de Workshop e Brainstorming (LEFFINGWELL e WIDRIG, 2000),
as sessões de JAD (Joint Application Design) (SOLTYS e CRAWFORD, 1999) e
RAD (Rapid Application Development) (ROBINSON, 1996).
• Prototipação. Um protótipo é uma versão inicial do sistema que está em fase de desenvolvimento. Em sistemas de hardware, protótipos são usados com freqüência
para testar e experimentar os projetos de sistema. Em sistemas de software,
protótipos auxiliam na elicitação e validação dos requisitos de sistema
(KOTONYA e SOMMERVILLE, 1997). A prototipação é especialmente
recomendada quando há um alto grau de incerteza ou quando é necessário um
rápido feedback dos usuários (DAVIS, 1992).
• Técnicas de Modelagem. Nos últimos anos, técnicas de modelagem vêm
conquistando maior importância para as organizações, desenvolvedores e usuários.
Elas apresentam um modelo específico das informações que serão adquiridas,
utilizando-o para orientar o processo de elicitação. Exemplos já consagrados na
literatura incluem métodos baseados em metas como KAOS (Knowledge
Acquisition in autOmated Specification) (VAN LAMSWEERDE et al., 1991) e i*
(YU, 1995); e técnicas baseadas em cenários, como casos de uso (JACOBSON,
1992) e Crews (1995 apud MAIDEN, 1998), as quais procuram representar as
tarefas que os usuários executam normalmente e aquelas que estes desejam
executar (LEITE et al., 1997; SCHNEIDER e WINTERS, 1998).
• Técnicas Cognitivas. Originalmente desenvolvidas para a aquisição de conhecimento para sistemas baseados em conhecimento, como por exemplo a
análise de protocolo, laddering, card sorting e repertory grids (SHAW e
GAINES, 1996).
• Técnicas Contextuais. Surgiram como uma alternativa às técnicas tradicionais e cognitivas. Incluem técnicas como a etnografia e a análise social (VILLER e
envolve um grupo de pessoas que cooperam para o desenvolvimento de diferentes
tarefas. A natureza dessa cooperação é freqüentemente complexa e variante de
acordo com as pessoas envolvidas, o ambiente físico e a organização na qual o
trabalho acontece. Nesse contexto, técnicas contextuais exploram a observação
para desenvolver um entendimento completo e detalhado de culturas particulares,
como no caso da etnografia, o qual uma sociedade ou cultura é observada durante
um extenso período, após o qual são apresentadas informações sobre todas as suas
práticas constituintes e sua importância no processo produtivo.
• Reuso de Requisitos. Do ponto de vista de requisitos, “reuso” objetiva reutilizar ao máximo o conhecimento existente durante o desenvolvimento do sistema.
Existem inúmeras situações onde o reuso de requisitos é recomendado: (a) quando
os requisitos esclarecem um aspecto do domínio da aplicação, como por exemplo
restrições operacionais; (b) quando o requisito está relacionado com uma interface
comum entre aplicações no mesmo ambiente; (c) quando requisitos refletem
procedimentos de uso repetido e padrão ao longo do sistema; (d) quando os
requisitos descrevem políticas da empresa que podem ser reutilizadas em outros
sistemas. Apesar das dificuldades inerentes, técnicas como análise de domínio
(PRIETO-DIAZ, 1990), clichês (BALZER, 1988) e casos de uso (JACOBSON,
1992) demonstram que o reuso de especificações de requisitos de software pode
contribuir para o aumento da produtividade e a unificação de processos internos.
2.4.2 Análise e negociação de requisitos
A análise e negociação de requisitos envolvem atividades que visam a descoberta de
problemas com os requisitos de sistema e estabelecer um acordo de mudanças que satisfaça todos
os afetados. O processo de análise e negociação é caro e demorado porque requer pessoas
qualificadas e experientes para dedicar tempo à leitura cuidadosa de documentos e identificação
das implicações contidas nas declarações presentes nesses artefatos (KOTONYA e
SOMMERVILLE, 1997). Na maioria das vezes, atividades de análise e negociação de requisitos
são executadas de forma paralela ou intercalada, em conjunto com atividades de elicitação de
Durante o processo de análise, os requisitos são examinados a fim de detectar omissões,
redundâncias, incompletudes e/ou requisitos irreais. A preocupação está em identificar os
requisitos que são realmente necessários ao desenvolvimento do sistema e ao atendimento das
necessidades dos clientes.
A negociação envolve a discussão dos conflitos encontrados entre requisitos e a busca por
uma solução de comum acordo que debele o conflito e atenda aos anseios de todas as partes
envolvidas. Os requisitos finais devem exprimir um compromisso que é governado pelas
necessidades da organização em geral, os requisitos específicos de diferentes partes interessadas,
e restrições de projeto, implementação, prazo e orçamento para o desenvolvimento do software
(KOTONYA e SOMMERVILLE, 1997). Para tanto, os modelos de negociação geralmente
identificam as principais necessidades dos usuários, priorizando-as a fim de assegurar que os
requisitos mais críticos a elas relacionados sejam atendidos o quanto antes. Isso envolve a
interação entre gerente de projeto e clientes para o planejamento e organização das versões
intermediárias do sistema final.
A seguir são apresentadas as técnicas mais comumente utilizadas no processo de análise e
negociação:
• Listas de Verificação (Checklists). Correspondem a listas de questões que o analista pode fazer uso para avaliar cada requisito. Checklists são úteis porque
fornecem uma referência sobre o que procurar e reduzem as chances de que
requisitos importantes deixem de ser checados. Ao final da checagem, pode-se
disponibilizar uma lista de inconsistências encontradas, as quais podem ser
solucionadas por meio de negociação ou, caso necessário, nova elicitação de
requisitos.
• Matrizes de Interação. Utilizadas para denotar a interação entre requisitos e
facilitar o processo de análise de possíveis conflitos entre estes. A forma mais
simples de construção dessas matrizes é usar uma tabela e rotular suas linhas e
colunas com identificadores de requisitos. Valores numéricos indicam a relação
entre cada um dos requisitos mapeados, evidenciando conflitos ou sobreposições.
analisados para avaliar o impacto que essas relações, e eventuais mudanças nas
mesmas, possam ter no desenvolvimento do sistema.
• Prototipação. Os protótipos criados na etapa de elicitação podem ser aperfeiçoados na etapa de análise e negociação, possibilitando uma análise mais
rica dos requisitos do sistema. Além disso, protótipos contribuem para um maior
envolvimento entre as partes interessadas durante as atividades de elicitação,
análise e negociação de requisitos.
• Reuniões. São provavelmente o meio mais eficiente de negociação e resolução de conflitos entre requisitos. Reuniões de negociação são conduzidas em três etapas:
(i) explicação sobre a natureza dos problemas de requisitos; (ii) discussão entre as
partes sobre como resolver os problemas, observando as prioridades estabelecidas;
(iii) resolução dos conflitos pela tomada de ações corretivas.
2.4.3 Documentação de requisitos
Nesta fase, os requisitos acordados são anotados num documento que reúne, num nível
apropriado de detalhe, o escopo de requisitos que servirá como base para o processo de
desenvolvimento do software. O documento de requisitos serve como um contrato entre usuários
e desenvolvedores, e deve ser formatado e estruturado de acordo com padrões organizacionais
(KOTONYA e SOMMERVILLE, 1997).
De acordo com a norma IEEE (IEEE, 1998), o documento de requisitos deverá possuir
declarações não-ambíguas, ser completo, verificável, consistente, modificável, rastreável e
utilizável durante todas as fases do ciclo de vida do requisito. Alguns autores conceituam o
documento de requisitos de software como sendo o meio utilizado para descrever as restrições
quanto às características do produto e ao processo de desenvolvimento, a interface com outras
aplicações, a informação sobre o domínio da aplicação e informações de suporte ao
conhecimento do problema. Nesse sentido, o documento de requisitos deve promover o suporte à
verificação, validação e gerenciamento do projeto; promover a redução do tempo total e esforço
codificação e testes do sistema; permitir o rastreamento e gerenciamento dos requisitos ao longo
da evolução do sistema.
Existem muitas maneiras diferentes de estruturar um documento de requisitos. Este pode
ser definido como um único artefato, ou ser formado pela associação de diferentes artefatos que
provêem visões de requisitos específicas para cada faceta do desenvolvimento, uma abordagem
comum nos modernos documentos de requisitos de software (LEFFINGWELL e WIDRIG,
2000). No geral, requisitos são descritos em linguagem natural e, como tal, são passíveis de
apresentar efeitos colaterais como ambigüidade e generalidade. Para tratar desses efeitos, a
definição dos requisitos pode ser complementada por modelos tanto gráficos quanto matemáticos
(RUMBAUGH et al., 1991; DELISLE e GARLAN, 1990). Algumas organizações desenvolvem
inclusive suas próprias notações para documentação dos requisitos (VAN LAMSWEERDE,
2000a; CYSNEIROS e LEITE, 2001).
Kotonya e Sommerville (1997) argumentam que, com o objetivo de garantir que toda
informação necessária esteja presente, as organizações devem definir seus próprios padrões de
documentação de requisitos. Um exemplo de padrão aceito internacionalmente é o IEEE/ANSI
830-1998 (IEEE, 1998).
2.4.4 Validação de requisitos
A validação de requisitos é definida como o processo que certifica que o modelo de
requisitos gerado esteja consistente com as necessidades e intenções de clientes e usuários. Essa
visão da atividade de validação retrata um processo contínuo, ocorrendo na maior parte do tempo
em paralelo com as fases de elicitação e especificação (análise, negociação e documentação). De
fato, a validação não é só aplicada ao modelo final de requisitos, mas também a todos os modelos
intermediários gerados ao longo do processo de requisitos.
Validar os requisitos significa confirmar que o documento de requisitos e suas
especificações complementares refletem as reais necessidades dos clientes e usuários finais,
autenticando os artefatos que servirão de base para as fases subseqüentes do processo de
desenvolvimento. Em geral, a validação deve criar os meios necessários para que ocorra um
não é, pois, uma tarefa fácil e pode requerer várias sessões de trabalho até que todos encontrem
não somente pontos de concordância a respeito dos requisitos, mas principalmente visualizem as
implicações futuras de suas decisões. Nesse sentido, a participação de especialistas de domínio
contribui sobremaneira para a orientação de clientes, usuários e desenvolvedores na resolução de
possíveis impasses.
Os elementos de entrada para a validação de requisitos são o documento de requisitos,
diagramas complementares, padrões e conhecimento sobre a organização. Como saída, obtém-se
uma lista de requisitos acordados, ações acordadas e documentação revisada. De fato, enquanto
fases como projeto e implementação possuem o documento de requisitos como fonte para
verificação de seus resultados, a validação de requisitos não possui uma representação similar
que possa ser usada como base. Ou seja, não existe um meio para demonstrar que uma
especificação de requisitos esteja correta em relação a outras representações do sistema
(KOTONYA e SOMMERVILLE, 1997). Contudo, há uma variedade de técnicas que pode ser
aplicada para apoiar o processo de validação:
• Revisões. Provavelmente a técnica mais utilizada para validação de requisitos, revisões envolvem um grupo de pessoas lendo e analisando a documentação de
requisitos à procura de possíveis problemas. A revisão de requisitos constitui-se de
uma reunião formal na qual um engenheiro de requisitos apresenta cada um dos
requisitos para crítica e identificação de inconsistências pelo grupo. As
inconsistências encontradas são registradas para posterior discussão. O grupo de
revisão deve então tomar decisões que se materializam em ações a serem
executadas para corrigir os problemas identificados.
• Prototipação. Se um protótipo foi desenvolvido para fins de elicitação de
requisitos, faz sentido usá-lo posteriormente para a validação desses requisitos.
Porém, protótipos para validação devem ser mais completos e conter requisitos
suficientes para garantir que facilidades projetadas para o sistema estejam de
acordo com o uso prático esperado por seus usuários. Protótipos de elicitação
normalmente apresentam funcionalidades ausentes e podem não contemplar
necessário dar continuidade ao desenvolvimento do protótipo durante a etapa de
validação.
• Testes de Requisitos. Técnicas baseadas em cenário permitem elicitar e analisar requisitos, enquanto facilitam a criação de casos de teste para os cenários
identificados (CYSNEIROS, 2002). A execução dos requisitos implementados
pode ser simulada para demonstrar que todos os requisitos do sistema tenham sido
considerados e estejam de acordo com o esperado. Se dificuldades existem no
sentido de derivar casos de teste para um dado requisito, isso implica que algum
tipo de problema com a definição do requisito pode existir (KOTONYA e
SOMMERVILLE, 1997). O objetivo com os casos de teste, porém, deve ser o de
validar os requisitos e não o sistema.
• Sistemas Especialistas. Segundo Loucopoulos e Karakostas (1995), o processo de
validação poderia se beneficiar de ferramentas automatizadas que possuam
conhecimento de algum aspecto do processo de engenharia de requisitos para o
qual estão capacitadas. Esse aspecto pode ser tanto o conhecimento de um método
(ex. como aplicar a análise estruturada (YOURDON, 1989) para efetuar
engenharia de requisitos) ou o conhecimento sobre um domínio, i.e.,
conhecimento a respeito do domínio para o qual o software deve ser modelado.
Sistemas Especialistas ainda estão restritos ao ambiente acadêmico; contudo, é
esperado um grande impacto com sua incorporação às próximas gerações de
ferramentas CASE.
2.4.5 Gerenciamento de requisitos
As atividades de Documentação e Validação de requisitos devem formar um ciclo ao
longo do qual serão realizadas múltiplas iterações até que a especificação de requisitos seja
aprovada numa validação final sem restrições. Paralelamente a essas atividades, deve-se
desenvolver o gerenciamento de requisitos. Essa atividade consiste em administrar as inevitáveis
mudanças dos requisitos propostos. Tais mudanças surgem, principalmente, quando são alteradas
as prioridades do negócio, quando se identificam erros ou omissões nos requisitos, ou quando
gerenciar mudanças nos requisitos acordados; (ii) gerenciar as relações entre requisitos; (iii)
administrar as dependências entre os documentos de requisitos e outros documentos produzidos
durante o ciclo de vida do software.
Gerenciamento de requisitos é executado por meio da implementação de rastreabilidade.
Gerenciamento e rastreamento de requisitos são reconhecidos como importantes pré-requisitos
para desenvolver software de alta qualidade (POHL, 1996; GOTEL e FINKELSTEIN, 1994;
JARKE, 1998; TORANZO e CASTRO, 1999) e definidos como a habilidade de descrever e
seguir a vida de um requisito, em ambas as direções (POHL, 1996; GOTEL e FINKELSTEIN,
1994; RAMESH, 1998). Rastreamento de requisitos é um fator importante para prover com
integridade uma documentação completa dos requisitos, assim como ajudar no processo de
gerenciamento de mudanças nesses requisitos (TORANZO, 2002).
A área de rastreamento de requisitos situa-se entre duas ilhas: pré e pós-rastreamento,
conectadas pela especificação dos requisitos do sistema. Pré-rastreamento está relacionado a
alguns aspectos da vida do requisito antes da sua inclusão na especificação dos requisitos.
Pós-rastreamento está relacionado a alguns aspectos da vida do requisito após a sua inclusão na
especificação dos requisitos (GOTEL e FINKELSTEIN, 1994). Desse modo, rastreamento de
requisitos associa fonte de informação a requisitos, bem como requisitos a artefatos de design e
vice-versa.
Gerenciar requisitos envolve manipular uma grande quantidade de informação, que deve
ser veiculada entre vários indivíduos ao redor da organização (KOTONYA e SOMMERVILLE,
1997). Ferramentas CASE (ASG, 2001) fornecem suporte automatizado a esse processo,
facilitando o intercâmbio das informações, o armazenamento estruturado dos requisitos coletados
e a publicação dos requisitos analisados via meios corporativos tais como a Internet ou Intranet.
Ferramentas como RequisitePro® (RATIONAL, 2001) e Doors® (TELELOGIC, 2002) já são
uma realidade no ambiente de desenvolvimento das organizações de software e trazem algumas
vantagens ao processo de desenvolvimento, dentre elas a integração com ferramentas
proprietárias existentes e a montagem de matrizes de rastreabilidade a partir do repositório de
2.5 CONSIDERAÇÕES FINAIS
Os últimos 30 anos têm evidenciado um grande esforço por parte das organizações de
software e da comunidade acadêmica no sentido de intensificar a adoção e a melhoria de
processos para uma engenharia de requisitos de alta-qualidade. Embora difícil, essa tarefa
revela-se cada vez mais crítica para o sucesso dos projetos de software, o que vem elevar a importância
das técnicas, conceitos e processos da Engenharia de Requisitos para o perfeito entendimento das
necessidades dos clientes e conseqüente derivação de um produto de software de qualidade.
Neste capítulo foram apresentados os benefícios da aplicação desses mecanismos para
uma correta aquisição, análise, especificação e gerência dos requisitos do sistema. Todavia, a
inserção desses mecanismos no processo de desenvolvimento de sistemas ainda se configura
como uma ciência incompleta. O próximo capítulo apresenta uma abordagem sobre padrões da
Engenharia de Requisitos reportada como resultado de um estudo iniciado no encontro anual do
grupo especial em engenharia de requisitos realizado pela German Informatics Society (GI),
ocorrida em Ulm – Alemanha em 2002. O estudo revela que determinados padrões podem ser a
ponte entre o conhecimento existente na Engenharia de Requisitos e o sucesso de sua aplicação
3 PADRÕES DE ENGENHARIA DE REQUISITOS
3.1 INTRODUÇÃO
A engenharia de requisitos tem sido reconhecida como um fator crítico de sucesso na
execução dos projetos de software. As melhores práticas ou métodos de engenharia de requisitos
têm sido explorados na academia fornecendo soluções para as atividades do processo; todavia,
muitas vezes não é possível aplicá-los devido às restrições e os conflitos do projeto. Além disso,
a engenharia de requisitos depende de características individuais dos projetos, tais como o
tamanho e o tipo, ou ainda das partes interessadas (HAGGE et al., 2006).
Para a implementação bem sucedida do processo de engenharia de requisitos,
profissionais necessitam de conhecimentos metodológicos confiáveis e acessíveis. Os padrões de
Engenharia de Requisitos apresentados neste capítulo abordam a necessidade de conhecimento
consolidado e estruturado. O conhecimento é capturado para refletir e analisar situações
comparáveis (observações) de projetos (casos de estudo), com foco na solução de conflitos de
situações peculiares (LAPPE et al., 2004). Decisões ou ações de sucesso observadas em pelo
menos dois projetos são registradas como padrões (Figura 4).
Figura 4 – Capturando padrões a partir da observação em casos de estudo Fonte: Hagge e Lappe (2006); Lappe et al. (2004), adaptado.
Os padrões de Engenharia de Requisitos (ER) são descritos em um formato que torna o
conteúdo do padrão instrutivo e facilmente acessível. Os padrões contêm pares de problemas e
padrões são obtidos exclusivamente a partir de soluções que possuam comprovação da
experiência em projetos do mundo real.
Este capítulo descreve o conceito e a metodologia para captura do padrão de Engenharia
de Requisitos. Inicialmente, são expostos os conceitos sobre o que é um “padrão”. Em seguida
são apresentados os requisitos, a estrutura e o formato do padrão de ER, além do processo para
sua extração. A última seção encerra o capítulo tecendo as considerações finais sobre a utilização
dos padrões de ER.
3.2 PADRÕES
Etimologicamente a palavra ‘padrão’ tem origem do latin patronus que deriva de pater,
que significa pai. Pela semântica, um patrono (ou pai) deve ser pensado como um modelo de
cidadão, ou seja, para ser imitado (PATTERN, 2008).
Os padrões vêm sendo utilizados em diferentes disciplinas para capturar o conhecimento
de engenharia e prover regras para gerar soluções de sucesso na área (LAPPE et al., 2004). A
idéia original sobre o tema surgiu na engenharia civil em uma série de livros de Christopher
Alexander. Ele observou que o sucesso na etapa de construção de alguns projetos possuía
características comuns em sua estrutura. A partir dessa observação ele desenvolveu ajustes nas
regras dos arquitetos em como elaborar a construção dos projetos (ALEXANDER et al., 1977;
ALEXANDER, 1979).
Mais tarde, o formato do padrão foi estendido para os projetos de software e obteve um
tremendo sucesso na comunidade de engenheiros de software (GAMMA et al., 1995). A partir
dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham
propuseram os primeiros padrões de projeto para a área da ciência da computação. Em um
trabalho para a conferência OOPSLA7, eles apresentaram alguns padrões para a construção de janelas na linguagem Smalltalk8(BECK e CUNNINGHAM, 1987).
Os padrões de projeto ganharam popularidade com o livro Design Patterns: Elements of
Reusable Object-Oriented Software, publicado em 1995. Os autores desse livro são conhecidos
7 OOPSLA - International Conference on Object-Oriented Programming, Systems, Languages, and Applications. 8Smalltalk é uma linguagem de programação orientada a objeto que teve o seu desenvolvimento iniciado no final
como a “Gangue dos Quatro” (Gang of Four) ou simplesmente “GoF”. Posteriormente, vários
outros livros do estilo foram publicados, como Applying UML and Patterns: An Introduction to
Object-Oriented Analysis and Design and Iterative Development, que introduziu um conjunto de
padrões conhecidos como GRASP9 (GAMMA et al., 1995).
A utilização de padrões para transferência do conhecimento se disseminou por outros
domínios, tais como a arquitetura de software, processos de negócio etc. Todavia, Lappe et al.
(2004) reforça que a adoção do formato para descrever padrões varia significativamente
conforme os hábitos particulares de cada comunidade.
Os padrões não são soluções; padrões geram soluções. Quanto maior for o potencial para
a aplicação de um padrão, mais genérico ele será. Embora os padrões específicos sejam úteis, a
definição de um padrão mais amplo possui muitas aplicações diferentes (DEUGO, 1999).
Alexander (1977) define padrão da seguinte maneira:
• Um padrão é uma regra que exprime uma relação entre um certo contexto, um problema e uma solução.
• Cada padrão é uma relação entre um certo contexto, um certo sistema de forças
que ocorre repetidamente nesse contexto, e uma determinada ‘configuração’ que
permite que estas forças se resolvam entre si.
• Um padrão é uma instrução, que demonstra o modo como a ‘configuração’ pode
ser utilizada, repetidas vezes, para resolver o sistema dado de forças, sempre que o
contexto se tornar relevante.
• O padrão é ao mesmo tempo o ‘elemento’ que está no mundo; a forma como criar
esse ‘elemento’; e quando se deve criá-lo. Ele é simultaneamente um processo e o
‘elemento’, ou seja, tanto a descrição do ‘elemento’, como a descrição do processo
que irá gerá-lo.
Embora existam muitos formatos de padrões, o formato mínimo contém essencialmente
(DEUGO,1999; ALEXANDER, 1977):
