UMA ABORDAGEM PARA O REUSO DE REQUISITOS …siaibib01.univali.br/pdf/Rodrigo Cezario da...

RODRIGO CEZARIO DA SILVA

UMA ABORDAGEM PARA O REUSO DE REQUISITOS BASEADA EM PADRÕES E RASTREABILIDADE

São José (SC), agosto de 2011

UNIVERSIDADE DO VALE DO ITAJAÍ

CURSO DE MESTRADO ACADÊMICO EM

COMPUTAÇÃO APLICADA


por

Rodrigo Cezario da Silva

Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Computação Aplicada. Orientadora: Fabiane Barreto Vavassori Benitti, Dra.

São José (SC), agosto de 2011

FOLHA DE APROVAÇÃO

Esta página é reservada para inclusão da folha de assinaturas, a ser disponibilizada pela

Secretaria do Curso para coleta da assinatura no ato da defesa.

Dedicado à Juliane e Julia, amores da minha vida.

“Tenha coragem de seguir o que seu coração e sua intuição dizem. Eles já sabem o que você realmente deseja. Todo resto é secundário.”

(Steve Job).

AGRADECIMENTOS

Agradeço de forma muito carinhosa a minha esposa Juliane, e a minha filha Julia, por me

incentivar e apoiar incondicionalmente, e pela paciência e compreensão nos momentos que estive

ausente.

Agradeço em especial à Profa. Fabiane Barreto Vavassori Benitti, pela orientação, apoio,

compreensão e paciência, sem as quais não seria possível o cumprimento desta etapa. Serei sempre

grato!

Agradeço à Profa. Adriana Gomes Alves que gentilmente se dispôs a auxiliar-me nesta

dissertação, através de revisões e considerações pertinentes nos modelos de correções.

Agradeço à minha amiga Profa. Lucia Galuch pela contribuição na revisão dos dados

estatísticos.

Agradeço aos colegas do laboratório L2S e alunos participantes do experimento, pelo

interesse e comprometimento na realização dos estudos de caso.

Agradeço aos membros da Banca Examinadora, composta pelos Professores Ricardo Pereira

e Silva, Marcello Thiry e Michelle Wangham, que forneceram sugestões e comentários para

melhorar este trabalho.

Agradeço aos profissionais que contribuíram nesta pesquisa, participando das entrevistas e

respondendo aos questionários; suas informações enriqueceram este trabalho.

Por fim, a todos que colaboraram de alguma forma para o sucesso deste trabalho.



Agosto / 2011

Orientadora: Fabiane Barreto Vavassori Benitti, Dra Área de Concentração: Computação Aplicada

Linha de Pesquisa: Engenharia de Software Palavras-chave: Reuso de Requisitos, Padrões de Requisitos, Engenharia de Requisitos.

Número de páginas: 247 RESUMO

O processo de Engenharia de Requisitos é complexo e envolve trabalho desde a captação dos requisitos até a sua documentação e validação. Diversos problemas de projetos de desenvolvimento de software estão relacionados à atividade de elicitação de requisitos. Existem diferentes metodologias e técnicas para realização da tarefa de elicitação de requisitos, mas mesmo assim ainda persistem problemas. Esse trabalho concentra-se nas dificuldades associadas com a comunicação humana ou ao problema de compreensão dos requisitos que é uma parte necessária na elicitação de requisitos. O reuso de requisitos tem sido uma abordagem vista como uma forma de se obter requisitos mais corretos e precisos no processo de Engenharia de Requisitos. Diante desta afirmação, este trabalho propôs uma abordagem de reuso de requisitos dando ênfase nas etapas de elicitação e especificação de requisitos, a qual envolveu técnicas como rastreabilidade, padrões e catálogo de requisitos, sendo apoiada por uma ferramenta computacional. A pesquisa caracterizou-se sob o ponto de vista da natureza como uma pesquisa aplicada, e sob o ponto de vista dos procedimentos técnico enquadra-se como uma pesquisa bibliográfica e experimental. Para tanto, a pesquisa bibliográfica foi realizada de forma sistemática, buscando o estado da arte a cerca de padrões para escrita de requisitos e abordagens de reuso de requisitos. A abordagem de reuso de requisitos passou por três avaliações buscando avaliar a abordagem proposta quanto a eficiência e eficácia em relação a sua não utilização. A primeira avaliação foi realizada de forma controlada em ambiente acadêmico, outra sobre a percepção de uso dos participantes e, por fim, uma avaliação sob o ponto de vista de especialistas na área de engenharia de requisitos. A análise dos resultados das avaliações indicaram que a abordagem apresentou resultados positivos quanto à eficiência e a eficácia em relação a sua não utilização. Neste sentido, têm-se indícios que a abordagem proposta pode auxiliar na elicitação e documentação de requisitos.

AN APPROACH FOR THE REUSE OF REQUIREMENTS BASED ON PATTERNS AND TRACEABILITY


August / 2011

Advisor: Fabiane Barreto Vavassori Benitti, Dra Area of Concentration: Applied Computer Science

Research Line: Software Engineering Keyworks: Requirement Reuse, Software Requirement Patterns, Requirements Engineering.

Number of pages: 247 ABSTRACT

The process of requirements engineering is complex and involves work since the capture of requirements through its documentation and validation. Several problems of software development projects are related to requirements elicitation activity. There are different methodologies and techniques for accomplishing the task of requirements elicitation, however problems remain still. This work focuses on the difficulties associated with human communication or the failure of understanding of the requirements is an essential part of requirements elicitation. The reuse of requirements has been seen as a way to obtain more accurate and precise requirements in the process of requirements engineering. In front of this statement, this paper proposed an approach for the reuse of requirements with emphasis on the steps of elicitation and specification of requirements, which involved techniques such as traceability, standards and requirements catalog, backed by a computational tool. The research was characterized from the point of view of an applied research, and from the point of view of technical procedures is framed as a literature research and experimental. Through this, the literature research was performed systematically, seeking the state of the art about standards for writing requirements and approaches to the reuse of requirements. The approach to the reuse of requirements was analyzed of three assessments attempt to evaluate the proposed approach and the efficiency and effectiveness compared to no application. The first assessment was performed in a controlled manner in an academic environment, one on the perception to the use from the participants and, finally, an evaluation from the point of view of experts in the area of requirements engineering. The analysis of the results for evaluations indicated that the approach demonstrated positive results on the efficiency and effectiveness compared to no application. In this way, there have been indications that the proposed approach is able to assist in the elicitation and documentation requirements.

LISTA DE ILUSTRAÇÕES

Figura 1 - Exemplo de padrão de requisitos apresentado em Toro et al. (1999). ............................. 46 Figura 2 - Catálogo de padrões de requisitos apresentado em Withall (2007). ................................ 46 Figura 3 - Padrão de requisito Registro de Usuário (WITHALL, 2007). ........................................ 48 Figura 4 - Fluxograma das atividades da abordagem de Montabert et al. (2009). ........................... 62 Figura 5 - Generalização do processo de reuso da abordagem de Perednikas (2008). ..................... 69 Figura 6 - Visão geral do processo da abordagem proposta. ........................................................... 77 Figura 7 - Processo retratando a abordagem proposta. ................................................................... 81 Figura 8 - Modelo da estrutura do formulário padrão utilizado pela abordagem. ............................ 85 Figura 9 - Exemplo do padrão Relatório. ....................................................................................... 87 Figura 10 - Catálogo de padrões de requisitos utilizado na abordagem. ......................................... 90 Figura 11 - Exemplos de utilização de um padrão. ......................................................................... 93 Figura 12 - Exemplo de sugestões de reuso a partir da rastreabilidade. .......................................... 94 Figura 13 - Interface de busca e seleção dos padrões. .................................................................... 96 Figura 14 - Interface de “Sugestão de Reuso” baseado no padrão selecionado. .............................. 97 Figura 15 - Interface de "Sugestão de Reuso" baseado na rastreabilidade. ..................................... 98 Figura 16 - Etapas do processo seguido na avaliação da abordagem. ........................................... 103 Figura 17 - Perfil dos participantes. ............................................................................................. 104 Figura 18 - Análise do conhecimento dos participantes. .............................................................. 104 Figura 19 - Gráfico da representação do conhecimento dos grupos. ............................................. 105 Figura 20 - Análise da eficiência. ................................................................................................ 109 Figura 21 - Análise da eficácia. ................................................................................................... 110 Figura 22 - Análise dos mecanismos de reuso. ............................................................................ 111 Figura 23 - Análise comparativa entre os resultados obtidos pelos grupos. .................................. 112 Figura 24 - Boxplots comparando a eficiência dos grupos. .......................................................... 115 Figura 25 - Boxplots comparando a eficácia dos grupos. ............................................................. 115 Figura 26 - Resultado do questionário de percepção do grupo experimental. ............................... 116 Figura 27 - Resultado do questionário de percepção do grupo controle. ....................................... 117 Figura 28 - Indicativo percentual sobre a agilidade na atividade de elicitação e documentação de

requisito utilizando a abordagem. ........................................................................................ 123 Figura 29 - Indicativo percentual da análise em relação a completude e corretude do artefato

produzido. ........................................................................................................................... 124 Figura 30 - Indicativo percentual da análise em relação a ajuda proporcionada pelo emprego dos

padrões/catálogo. ................................................................................................................. 125 Figura 31 - Indicativo percentual da análise em relação ao rendimento proporcionado pela

ferramenta de apoio da ferramenta ....................................................................................... 126 Figura 32 - Gerenciamento da seleção de estudos. ....................................................................... 151 Figura 33 - Relacionamento entre os padrões. ............................................................................. 177 Figura 34 - Casos de uso para o projeto da ferramenta de apoio a abordagem. ............................. 205 Quadro 1 - Estrutura de alguns padrões localizados na literatura.................................................... 42 Quadro 2 - Um exemplo de padrões de requisitos apresentado em Mendez-Bonilla et al. (2008). .. 50 Quadro 3 - Comparativo entre os estudos encontrados. .................................................................. 52 Quadro 4 - Resumo das observações e adequações do experimento piloto. .................................. 101 Quadro 5 - Questões e métrica..................................................................................................... 120 Quadro 6 - Strings de busca no idioma inglês. ............................................................................. 148 Quadro 7 - Strings de busca no idioma português. ....................................................................... 148

Quadro 8 - População, Intervenção, Contexto, Resultado para cada pergunta de pesquisa (KONDA; MANDAVA, 2010). ............................................................................................................ 172

Quadro 9 - Termos de busca. ....................................................................................................... 173 Quadro 10 - Strings de busca. ...................................................................................................... 173 Quadro 11 - Requisitos funcionais. .............................................................................................. 184 Quadro 12 - Requisitos não funcionais. ....................................................................................... 187 Quadro 13 - Requisitos funcionais. .............................................................................................. 190 Quadro 14 - Requisitos não funcionais. ....................................................................................... 195 Quadro 15 - Padrão de interface entre sistemas............................................................................ 226 Quadro 16 - Padrão de interação entre sistemas. .......................................................................... 226 Quadro 17 - Padrão de tecnologia. ............................................................................................... 226 Quadro 18 - Padrão de aderência ao padrão (do inglês comply-with-standard). ........................... 227 Quadro 19 - Padrão de referência a requisitos (do inglês refer-to-requirements). ......................... 227 Quadro 20 - Padrão de documentação. ........................................................................................ 227 Quadro 21 - Padrão de tipo de dados. .......................................................................................... 227 Quadro 22 - Padrão de estrutura de dados. ................................................................................... 227 Quadro 23 - Padrão de identificação. ........................................................................................... 228 Quadro 24 - Padrão de fórmula de cálculo. .................................................................................. 228 Quadro 25 - Padrão de longevidade de dados. ............................................................................. 228 Quadro 26 - Padrão de arquivamento de dados. ........................................................................... 229 Quadro 27 - Padrão de entidade ativa. ......................................................................................... 229 Quadro 28 - Padrão de transação. ................................................................................................ 229 Quadro 29 - Padrão de configuração. ........................................................................................... 230 Quadro 30 - Padrão cronologia. ................................................................................................... 230 Quadro 31 - Padrão de consulta. .................................................................................................. 230 Quadro 32 - Padrão de relatório. .................................................................................................. 231 Quadro 33 - Padrão de acessibilidade. ......................................................................................... 231 Quadro 34 - Padrão de tempo de resposta. ................................................................................... 232 Quadro 35 - Padrão de rendimento (do inglês throughput)........................................................... 232 Quadro 36 - Padrão de capacidade dinâmica................................................................................ 232 Quadro 37 - Padrão de capacidade estática. ................................................................................. 233 Quadro 38 - Padrão de disponibilidade. ....................................................................................... 233 Quadro 39 - Padrão de escalabilidade. ......................................................................................... 233 Quadro 40 - Padrão de extensabilidade. ....................................................................................... 233 Quadro 41 - Padrão de ilimitado (do inglês unparochialness). ..................................................... 234 Quadro 42 - Padrão de múltiplos. (do inglês multiness) ............................................................... 234 Quadro 43 - Padrão de multi-linguagem. ..................................................................................... 234 Quadro 44 - Padrão de instalabilidade. ........................................................................................ 235 Quadro 45 - Padrão de registro de usuário. .................................................................................. 235 Quadro 46 - Padrão de autenticação de usuário............................................................................ 235 Quadro 47 - Padrão de autorização específica. ............................................................................. 235 Quadro 48 - Padrão de autorização configurável.......................................................................... 235 Quadro 49 - Padrão de aprovação. ............................................................................................... 236 Quadro 50 - Padrão de multi-organizacional. ............................................................................... 236 Quadro 51 - Padrão de taxas. ....................................................................................................... 236

LISTA DE TABELAS

Tabela 1 - Problemas com Requisitos ............................................................................................ 13 Tabela 2 - Resultado da análise das ferramentas. ........................................................................... 39 Tabela 3 - Modelo de descrição do padrão de requisito. ................................................................. 58 Tabela 4 - Exemplo da utilização da abordagem de Gotzhein et al., (1998). ................................... 59 Tabela 5 - Matriz de PR-Context. .................................................................................................. 64 Tabela 6 - Especificação do PR1 para Cadastro. ............................................................................ 65 Tabela 7 - Matriz de PR-Usecase. ................................................................................................. 66 Tabela 8 - Nível de distribuição de reuso. ...................................................................................... 67 Tabela 9 - Economia de esforço e razão de reuso. .......................................................................... 68 Tabela 10 - Análise comparativa entre os trabalhos similares. ....................................................... 70 Tabela 11 - Exemplo de sugestão de reuso pela rastreabilidade. .................................................... 93 Tabela 12 - Resultado dos estudos de caso. ................................................................................. 108 Tabela 13 - Análise sobre o percentual de reuso. ......................................................................... 110 Tabela 14 - Classificação dos grupos. .......................................................................................... 112 Tabela 15 - Resultados da classificação (ranks) em relação à eficiência. ...................................... 113 Tabela 16 - Plano de coleta de dados. .......................................................................................... 121 Tabela 17 - Resultado da busca nas fontes utilizando no idioma inglês. ....................................... 153 Tabela 18 - Resultado da busca nas fontes utilizando no idioma português. ................................. 154 Tabela 19 - Matriz de estudo encontrados.................................................................................... 156 Tabela 20 - Estudos descartados na etapa de análise do resumo e conclusões. ............................. 157 Tabela 21 - Template da tabela de extração dos dados dos estudos primários selecionados. ......... 158 Tabela 22 - Extração dos dados do estudo de Franch et al. (2010). .............................................. 159 Tabela 23 - Extração dos dados do estudo de Renault et al. (2009a). ........................................... 160 Tabela 24 - Extração dos dados do estudo de Renault et al. (2009b). ........................................... 162 Tabela 25 - Extração dos dados do estudo de Mendez-Bonilla et al. (2008). ................................ 163 Tabela 26 - Extração dos dados do estudo de Withall (2007). ...................................................... 164 Tabela 27 - Extração dos dados do estudo de Toro et al. (1999). ................................................. 165 Tabela 28 - Estudos obtidos para responder a Q1. ....................................................................... 175 Tabela 29 - Estudos localizados na revisão. ................................................................................. 176 Tabela 30 - Requisitos funcionais. ............................................................................................... 198 Tabela 31 - Requisitos não funcionais. ........................................................................................ 202 Tabela 32 - Matriz de rastreabilidade RF x RNF.......................................................................... 204 Tabela 33 - Planejamento do experimento. .................................................................................. 212

LISTA DE ABREVIATURAS E SIGLAS

CMMI-DEV Capability Maturity Model Integration ERS Especificação de Requisito de Software FODA Feature-Oriented Domain Analysis GQM Goal-Question-Metrics HTML Hypertext Markup Language IEC International Eletrotechnical Commission IEEE Institute of Electrical and Electronics Engineers INCOSE International Council on Systems Engineering ISBN International Standard Book Number IRC Interruption, Reaction, and Comprehension ISO/IEC International Organization for Standardization/ International

Electrotechnical Commission JAD Joint Application Development LINK-UP Leveraging Integrated Notification Knowledge through Usability

Parameters LPS Linha de Produto de Software MCA Mestrado em Computação Aplicada MPS.BR Melhoria de Processo do Software Brasileiro ODM Organization Domain Modeling PDF Portable Document Format PR Primitive Requirement RF Requisito funcional RNF Requisito Não Funcional RSP Requirements Specification RTF Rich Text Format SEI Software Engineering Institute SWEBOK Software Engineering Body of Knowledge SOA Stage-Of-Action-Leve SPICE Software Process Improvement and Capability dEtermination UML Unified Modeling Language UNIVALI Universidade do Vale do Itajaí XML Extensible Markup Language

SUMÁRIO

1 Introdução ......................................................................................... 12 3.1 PROBLEMA DE PESQUISA ........................................................................ 13 3.1.1 Solução Proposta .......................................................................................... 15 3.1.2 Delimitação de Escopo ................................................................................. 18 3.1.3 Justificativa .................................................................................................. 19 3.2 OBJETIVOS ................................................................................................... 20 3.2.1 Objetivo Geral .............................................................................................. 20 3.2.2 Objetivos Específicos ................................................................................... 20 3.3 METODOLOGIA ........................................................................................... 20 3.3.1 Metodologia da Pesquisa.............................................................................. 20 3.3.2 Procedimentos Metodológicos ..................................................................... 23 3.4 ESTRUTURA DA DISSERTAÇÃO .............................................................. 25

2 Fundamentação Teórica ................................................................... 27 2.1 ENGENHARIA DE REQUISITOS ............................................................... 27 2.1.1 Processo de Engenharia de Requisitos ........................................................ 29 2.2 REUSO DE REQUISITOS ............................................................................ 30 2.2.1 Rastreabilidade no contexto de reuso ......................................................... 33 2.2.2 Linha de Produtos de Software no Contexto de Reuso de Requisitos ....... 35 2.2.3 Ferramentas ................................................................................................. 36 2.3 PADRÕES ....................................................................................................... 40 2.3.1 Padrões de Requisitos .................................................................................. 42 2.4 PADRÕES DE REQUISITOS PARA ESCRITA DE REQUISITOS DE SOFTWARE........................................................................................................... 44 2.4.1 Abordagem de Toro et al. (1999) ................................................................. 45 2.4.2 Abordagem de Withall (2007) ..................................................................... 46 2.4.3 Abordagem de Franch et al. (2010), Renault et al. (2009a), Renault et al. (2009b) e Mendez-Bonilla et al. (2008) .................................................................. 49 2.4.4 Comparativo entre as abordagens............................................................... 50 2.5 CONSIDERAÇÕES SOBRE O CAPÍTULO ................................................ 53

3 Estado da Arte ................................................................................... 54 3.1 CRITÉRIOS PARA SELEÇÃO DOS ESTUDOS ........................................ 55 3.2 TRABALHOS RELACIONADOS ................................................................ 55 3.2.1 SMARTRe Requisitos: Escrevendo requisitos reutilizáveis (KEEPENCE et al., 1995) .............................................................................................................. 55 3.2.2 Uma abordagem de especificação de domínio de aeronáutica necessária para alcançar a reutilização (LAM, 1997) ............................................................ 56 3.2.3 Reutilização em engenharia de requisitos: descoberta e aplicação de um padrão de requisito em tempo real (GOTZHEIN et al., 1998) ............................ 57

3.2.4 Suporte a reutilização de requisitos em design de sistema de notificação através da tarefa de modelagem (MONTABERT et al., 2005) e Uma abordagem integrativa para a análise de requisitos: Como modelos de tarefas dão suporte ao reuso em um framework de modelagem centrado no usuário (MONTABERT et al., 2009) .................................................................................................................. 59 3.2.5 Uma abordagem para o desenvolvimento de requisitos de domínio como núcleo principal baseado nos pontos comuns e análise da variabilidade em uma linha de produtos (MOON et al., 2005) ................................................................. 63 3.2.6 Abordagem prática para reuso de requisitos de famílias de produtos de sistemas on-board (MONZON, 2008) ................................................................... 66 3.2.7 Reutilização de requisitos baseado nas previsões das necessidades dos usuários (PEREDNIKAS, 2008) ............................................................................ 68 3.3 CONSIDERAÇÕES SOBRE OS TRABALHOS SIMILARES ................... 69 3.4 CONSIDERAÇÕES DO CAPÍTULO ........................................................... 74

4 Abordagem de Reuso de Requisitos ................................................. 76 4.1 VISÃO GERAL .............................................................................................. 76 4.2 PROCESSO DE REUTILIZAÇÃO DE REQUISITOS ............................... 80 4.3 PADRÃO DE ESCRITA DE REQUISITO DE SOFTWARE ..................... 83 4.4 CATÁLAGO DE PADRÕES DE REQUISITOS ......................................... 88 4.5 REPOSITÓRIO .............................................................................................. 91 4.6 MECANISMOS DE APOIO AO REUSO ..................................................... 92 4.7 FERRAMENTA DE APOIO ......................................................................... 94 4.7.1 Funcionalidades ............................................................................................ 95 4.8 CONSIDERAÇÕES DO CAPÍTULO ........................................................... 98

5 Avaliação da abordagem ..................................................................100 5.1 QUASE-EXPERIMENTO ........................................................................... 100 5.1.1 Planejamento .............................................................................................. 100 5.1.2 Execução do Experimento Piloto ............................................................... 101 5.1.3 Execução ..................................................................................................... 102 5.1.4 Resultados ................................................................................................... 107 5.2 ANÁLISE DE ESPECIALISTAS ................................................................ 119 5.2.1 Planejamento .............................................................................................. 119 5.2.2 Execução ..................................................................................................... 122 5.2.3 Resultados ................................................................................................... 122 5.3 CONSIDERAÇÕES DO CAPÍTULO ......................................................... 126

6 Conclusão ..........................................................................................129 6.1 RESULTADOS ............................................................................................. 131 6.2 TRABALHOS FUTUROS ........................................................................... 133

REFERÊNCIAS....................................................................................135

APÊNDICE A - PROTOCOLO DE MAPEAMENTO SISTEMÁTICO ....................................................................................144

1 OBJETIVO .......................................................................................145

2 PLANEJAMENTO DA REVISÃO .................................................145 2.1 PERGUNTA DE PESQUISA ....................................................................... 145 2.2 ESTRUTURA DA PERGUNTA DE PESQUISA ....................................... 146 2.3 ESTRATÉGIA DE BUSCA ......................................................................... 146 2.4 DEFINIÇÃO DAS STRINGS DE BUSCA .................................................. 148 2.5 CRITÉRIOS DE INCLUSÃO E EXCLUSÃO DE ESTUDOS PRIMÁRIOS 148 2.6 CRITÉRIOS PARA FILTRAGEM DE PESQUISA .................................. 149 2.7 PROCESSO DE SELEÇÃO DE TRABALHOS PRELIMINAR .............. 150 2.8 AVALIAÇÃO DA QUALIDADE DOS ESTUDOS PRIMÁRIOS ............ 151 2.9 EXTRAÇÃO DOS DADOS ......................................................................... 151

3 CONDUÇÃO DA REVISÃO ...........................................................152 3.1 IDENTIFICAR A PESQUISA ..................................................................... 153 3.2 SELEÇÃO DOS ESTUDOS PRIMÁRIOS ................................................. 154 3.3 EXTRAÇÃO E MONITORAÇÃO DOS DADOS ...................................... 157 3.4 EXTRAÇÃO DOS DADOS DOS ESTUDOS SELECIONADOS.............. 158

REFERÊNCIAS....................................................................................166

APÊNDICE B - REVISÃO SISTEMÁTICA DA LITERATURA SOBRE REUSO DE REQUISITOS ....................................................170 3.5 REVISÃO SISTEMÁTICA DA LITERATURA REALIZADA POR KONDA E MANDAVA (2010) ............................................................................ 170 3.5.1 Fase 1 .......................................................................................................... 171 3.5.2 Fase 2 .......................................................................................................... 174 3.5.3 Fase 3 .......................................................................................................... 175 3.5.4 Fase 4 .......................................................................................................... 175

APÊNDICE C - RELACIONAMENTO ENTRE OS PADRÕES ...177

APÊNDICE D - PROPOSTA DE ESTUDO DE CASO 1: LOJA VIRTUAL "LIVRARIA THE BOOKS" ............................................178

APÊNDICE E - PROPOSTA DE ESTUDO DE CASO 2: SISTEMA DE RESERVA ONLINE DE UMA LOCADORA DE VEÍCULOS..181

APÊNDICE F - MODELO DE CORREÇÃO DO ESTUDO DE CASO 1 184

APÊNDICE G - MODELO DE CORREÇÃO DO ESTUDO DE CASO 2 190

APÊNDICE H - PROJETO DA FERRAMENTA DE APOIO ........198 1 REQUISITOS ............................................................................................... 198 1.5 REQUISITOS FUNCIONAIS ..................................................................... 198 1.6 REQUISITOS NÃO FUNCIONAIS ............................................................ 202 1.7 MATRIZ DE RASTREABILIDADE .......................................................... 204 1.8 CASOS DE USO ........................................................................................... 205

APÊNDICE I - PLANEJAMENTO DA AVALIAÇÃO ...................212

APÊNDICE J - TERMO DE CONCORDÂNCIA ............................217

APÊNDICE K - QUESTIONÁRIO DO PERFIL DOS PARTICIPANTES ................................................................................218

APÊNDICE L - QUESTIONÁRIO DE PERCEPÇÃO (GRUPO EXPERIMENTAL) ..............................................................................220

APÊNDICE M - QUESTIONÁRIO DE PERCEPÇÃO (GRUPO DE CONTROLE) 221

APÊNDICE N - RELAÇÃO DE PARTICIPANTES .......................222

APÊNDICE O - QUESTIONÁRIO PARA AVALIAÇÃO COM ESPECIALISTAS .................................................................................223

ANEXO A - Tradução dos padrões de Whitall (2007) ...................226

ANEXO B - Ficha de Cadastro de Livros (Estudo de Caso 1) .........237

ANEXO C - Tabela fornecida pelos Correios para o cálculo do frete (Estudo de Caso 1) ................................................................................238

ANEXO D - Dados da Transação retornados pela operadora de cartão de crédito (Estudo de caso 1 e 2) ..............................................239

ANEXO E - Folder (Estudo de caso 2) ..............................................240

ANEXO F - Tabela de contrato de cobertura de risco (Estudo de caso 2) 241

ANEXO G - Ata de reunião de entrevista (Estudo de caso 2) .......242

12

1 INTRODUÇÃO

Nos últimos anos, as organizações voltadas ao desenvolvimento de software têm procurado

por melhores práticas em engenharia de requisitos (YOUNG, 2004; WIEGERS, 2006;

ROBERTSON; ROBERTSON, 2006; DAVEY; COPE, 2008; TAMAI; KAMATA, 2009; LIU et

al., 2010). Essa busca por novas práticas ocorreram porque as organizações perceberam que o êxito

no projeto está cada vez mais relacionado a um melhor entendimento dos requisitos (WIEGERS,

2006; ROBERTSON; ROBERTSON, 2006).

Nesse sentido, diversos autores ressaltam a importância da engenharia de requisitos e seus

impactos principalmente em relação aos custos do projeto. De acordo com Pressman (2002), a

correção de defeitos de software na fase de projetos eleva o custo de três a seis vezes mais que na

fase de definição de requisitos. Já Boehm e Basili (2001), informam que os custos podem ser

elevados em 100 vezes caso a correção ocorra após a entrega do sistema de software. Robertson e

Robertson (2006) destacam que 60% dos erros em produtos de software são decorrentes de

requisitos incorretos ou incompletos. Pesquisas como a de Davey e Cope (2008), apontam que na

atividade de elicitação de requisitos ocorrem problemas que levam ao insucesso ou abandono de

projetos.

Visando resolver esses problemas, a Engenharia de Requisitos é uma área da Engenharia de

Software que trabalha com a sistematização do tratamento dos requisitos (SWEBOK, 2004), sendo

composta pelas seguintes atividades (WIEGERS, 2006; CHENG; ATLEE, 2007) ou subáreas

(SWEBOK, 2004): elicitação, análise, especificação e validação. A Elicitação de Requisitos tem

como objetivo o descobrimento ou identificação das necessidades dos stakeholders. (WIEGERS,

2006; SOMMERVILLE, 2007). Para a realização dessa atividade diversas técnicas podem ser

empregadas, alguns trabalhos apresentam um comparativo entre estas (DAVEY; COPE, 2008;

ZHANG, 2007) porém, essas pesquisas ainda apontam problemas nessa atividade.

O processo de Engenharia de Requisitos é complexo e envolve muito trabalho desde a

captação dos requisitos até sua documentação. Na literatura, diversas pesquisas (GRISS et al., 1998;

BARBER et al., 1999; KULOOR; EBERLEIN, 2002; FALBO et al., 2007; PEREDNIKAS, 2008)

afirmam que muitos esforços podem ser poupados utilizando abordagens de reuso nesse processo.

Já o uso de padrões é apontado como uma solução emergente para ajudar às organizações a

13

estruturar melhor o seu conhecimento (HAGGE; LAPPE, 2006; RENAULT et al., 2009a). O uso de

padrões ajuda no processo interno de comunicação, pois se trata de uma solução de identificação e

de registro de uma solução empregada, e isso é feito de forma que seja mais fácil a sua localização,

uso ou sua disseminação (CUNHA; HEBERT, 2003).

Diante do exposto, este trabalho apresenta, como contribuição na área de Engenharia de

Requisitos, uma abordagem para o reuso de requisitos. Tal abordagem está embasada na

rastreabilidade entre requisitos, catálogos de requisitos e em padrões, apoiada por uma ferramenta

computacional, com o propósito de obter requisitos mais corretos e precisos.

3.1 PROBLEMA DE PESQUISA

Freitas et al. (2007) relatam que erros produzidos na atividade de elicitação de requisitos

podem ser muito custosos se detectados em um estágio avançado do desenvolvimento. Em

complemento, Gottesdiener (2008), diz que a definição correta dos requisitos no início do

desenvolvimento é um fator crucial para reduzir o risco de falhas e custos associados com defeitos.

A Tabela 1 descreve as fontes de problemas encontrados no desenvolvimento de software

em relação a requisitos. Esses dados são de uma pesquisa realizada em trinta e dois projetos

iniciados e concluídos entre 2003 e 2005 em uma grande empresa de Tokyo por Tsumaki e Tamai

(2006) e nesta foram apontadas vinte e duas diferentes fontes de dificuldade (não ordenadas) em

relação a requisitos.

Tabela 1 - Problemas com Requisitos

Fontes de problemas em relação a requisitos. Requisitos incompletos Condições intestáveis Pouco conhecimento sobre o domínio Limites do sistema mal definidos Pouco conhecimento sobre as necessidades dos usuários

Fontes de informação vultosas e desorganizadas

Requisitos incorretos Pouca colaboração por parte dos usuários Diferentes visões para diferentes usuários Mau entendimento do propósito do sistema Requisitos ambíguos Requisitos soltos Requisitos incompatíveis Requisitos flutuantes Suposições tácitas negligenciadas Intenções abstratas de donos de requisitos Requisitos excessivos Aceitação contínua de requisitos adicionais Condições sinônimas e homônimas Muitos compromissos pela equipe de vendas Considerações de desígnio desnecessário Muitos donos de requisitos

Fonte: Tsumaki e Tamai (2006).

14

De acordo com Davey e Cope (2008), os problemas com requisitos levantados por Tsumaki

e Tamai (2006), são decorrentes de três fatores:

problemas de comunicação humana;

as necessidades das organizações mudam de acordo com o tempo;

o cliente só percebe algumas oportunidades depois que o projeto é iniciado. Segundo

Sommerville (2007), isso acontece porque as pessoas envolvidas desenvolvem uma

compreensão maior do que realmente querem que o software faça.

Esses fatores descritos por Davey e Cope (2008) são semelhantes aos problemas

classificados na fase de elicitação por Christel e Kang (1992). Em seu relatório, elaborado para SEI

intitulado "Questões em Elicitação de Requisitos", eles definem três categorias de problemas na

fase de elicitação: problemas de escopo, problemas de compreensão e problemas de volatilidade

(CHRISTEL; KANG, 1992).

Diversos autores (HOOD et al., 2008; PRESMANN, 2002; YOUNG, 2004) relatam a

dificuldade encontrada na fase de elicitação de requisitos e apontam sempre como vilão o problema

de compreensão na elicitação de requisitos. Diversas técnicas como entrevistas, brainstorming,

cenários, observação e etc., são apontados como métodos aplicados para a identificação dos

requisitos, mas mesmo assim os autores argumentam que é uma tarefa difícil e que não se trata

apenas de anotar as necessidades de seus usuários, a pessoa que executa essa atividade deve ser uma

pessoa preparada e que tenha habilidades natas para conseguir “seduzir” os clientes para realizar sua

tarefa (HOOD et al., 2008).

Os argumentos usados nesse tópico demonstram a complexidade do problema ainda

enfrentado na Engenharia de Requisitos. Tsumaki e Tamai (2006) reforçam o problema ainda

enfrentado nessa área. Assim, diante dos problemas relatados pela literatura e aqui relacionados,

este trabalho pretende contribuir com a área de engenharia de requisitos abordando os seguintes

problemas:

requisitos incompletos;

pouco conhecimento sobre o domínio;

15

pouco conhecimento sobre as necessidades dos usuários;

condições sinônimas e homônimas;

Considerando esses problemas, trabalhos como o de Lucrédio (2009), Lutowski, (2005),

Falbo et al., (2007), Kuloor e Eberlein (2002) apontam o reuso de requisitos como uma solução

consolidada para ajudar a resolver o problema explanado nesse tópico. Porém, esses trabalhos

deixam algumas questões ainda em aberto, que este trabalho pretende responder:

Q1 – A utilização de uma abordagem de reuso de requisitos torna mais eficiente o processo

de elicitação de requisitos que uma abordagem sem a utilização de reuso?

Q2 – A utilização de uma abordagem de reuso de requisitos torna mais eficaz o processo de

elicitação de requisitos que uma abordagem sem a utilização de reuso?

No contexto deste trabalho, a eficiência é calculada como a razão entre o número de

requisitos corretamente descritos e o tempo gasto no processo de elicitação. A eficácia é

considerada como a relação entre o número de requisitos corretamente descritos e número total de

requisitos existentes (conhecidos). Para tanto, são considerados requisitos corretamente descritos, os

requisitos que observarem os critérios quanto à: correto, não ambíguo, completo, consistente,

verificável e rastreável, conforme abordado pela norma IEEE Std 830-1998 (IEEE std 830-1998,

1998), sendo que tal avaliação irá considerar como referência um documento de especificação de

requisitos aprovado por especialista.

Através de uma pesquisa bibliográfica preliminar, percebeu-se a oportunidade de elaborar

uma pesquisa que permita responder as questões aqui formuladas. Além de apresentar uma nova

abordagem de reuso de requisito, a realização de um experimento e uma avaliação conduzida

através do método GQM (Goal-Question-Metrics) buscam responder essas questões que ainda estão

em aberto.

3.1.1 Solução Proposta

A intenção desta pesquisa é propor e avaliar uma abordagem para o reuso de requisitos

apoiada por uma ferramenta computacional. Propõe-se uma abordagem para a Engenharia de

16

Requisitos dando ênfase nas etapas de elicitação e documentação, estando esta abordagem apoiada

em práticas como rastreabilidade entre requisitos, catálogo de requisitos e padrões.

A identificação de um conjunto de requisitos para uma determinada linha de produtos ou

características de produtos é uma tarefa difícil de ser realizada. Porém, o emprego de técnicas de

rastreabilidade pode ajudar a potencializar o reuso de requisitos (DICK, 2002). Nesse sentido, o

emprego da rastreabilidade (de requisitos funcionais com requisitos não funcionais), utilizada pela

abordagem aqui proposta, tem a intenção de sugerir novos requisitos tendo como base requisitos

rastreados que foram usados em outros projetos similares.

Já o Catálogo de Requisitos é um conjunto de padrões de requisitos e estão relacionados de

forma que venha a sugerir requisitos adicionais. Esses padrões têm o objetivo de estabelecer

requisitos com uma maior qualidade de escrita, isso com maior agilidade e menor esforço

(WITHALL, 2007). Em complemento, encontra-se em Oliveira e Spinola (2007), que o uso de

padrões é uma solução que “agiliza” o processo de elicitação de requisitos de software e também

pode aumentar a qualidade dos documentos gerados. No que diz respeito a catálogo de padrões,

neste trabalho foi realizada a identificação e análise de padrões encontrados na literatura para escrita

e categorização de requisitos.

Segundo Hagge e Lappe (2006), padrões de engenharia de requisitos são elaborados para

encapsular as boas práticas disponíveis de engenharia de requisitos, pois os padrões oferecerem uma

base sólida de aprendizado organizacional, o que ajuda equipes com pouca ou nenhuma experiência

em engenharia de requisitos, transferindo o conhecimento para um nível prático. Além disso, para o

emprego de padrões de requisitos não se faz necessária uma adaptação ou reorganização do

processo de software (HAGGE; LAPPE, 2004a).

Cheng e Atlee (2007) também fazem uma reflexão sobre o uso de padrões em uma

abordagem de reuso em seu trabalho, no qual discute o futuro da Engenharia de Software, segundo

as autoras, o uso de padrões ajudaria os profissionais em um contexto de reutilização, isso devido

aos padrões ser estruturas abstratas reutilizáveis e que devem vir acompanhadas de um par

problema/solução e exemplos de sua utilização.

Sobre processos de reutilização, pode-se dizer que estes já se encontram em diversas

atividades no processo de software. Diversas pesquisas (GRISS et al., 1998; BARBER et al., 1999;

17

KULOOR; EBERLEIN, 2002; FALBO et al., 2007) apontam que o reuso não deve se limitar

apenas ao código, seus benefícios devem também se estender aos requisitos, projetos, testes,

especificações e a outros artefatos gerados durante o processo de software. De fato, qualquer

artefato pode ser reutilizado.

O reuso de requisitos na atividade de elicitação não é uma forma “vital” de se descobrir

novos requisitos, mas é uma forma de se obter requisitos indiretamente de outras fontes, não

somente de usuários ou clientes. Essa forma de conseguir requisitos serve como um complemento

para a atividade, melhorando de forma eficiente e eficaz o levantamento de requisitos (ZHANG,

2007).

Wiegers (2006) e Young (2004) recomendam o apoio de ferramentas para automatizar e

gerenciar o processo de Engenharia de Requisitos. Essa automatização pode ser feita desde a

elicitação dos requisitos até a sua gerência. Johnson e Harris (1991) reforçam afirmando que a

reutilização informal é possível, mas que existem muitas vantagens em apoiar-se em uma

ferramenta computacional para realização de um processo de reuso.

Em virtude do cenário exposto neste tópico, este trabalho tem como objetivo elaborar uma

abordagem para o reuso de requisitos, apoiada em ferramenta computacional, visando verificar as

seguintes hipóteses:

H01 (hipótese nula para a pergunta de pesquisa Q1): Não existe diferença quanto à

eficiência do processo de elicitação quando utilizada a abordagem de reuso em relação ao seu não

uso.

HA1 (hipótese alternativa ao H01): A eficiência do processo de elicitação utilizando

abordagem baseada em reuso é maior que quando não utilizada esta abordagem.

H02 (hipótese nula para a pergunta de pesquisa Q2): Não existe diferença quanto à eficácia

do processo de elicitação quando utilizada a abordagem de reuso em relação ao seu não uso.

HA2 (hipótese alternativa ao H02): A eficácia do processo de elicitação utilizando

abordagem baseada em reuso é maior que quando não utilizada esta abordagem.

Na busca por este objetivo, este trabalho apresenta uma abordagem voltada ao reuso de

requisitos de software. A abordagem aqui proposta é apoiada na rastreabilidade entre requisitos,

18

catálogos de requisitos e em padrões. Pretende-se com uso da técnica de rastreabilidade de

requisitos, identificar outros requisitos que foram relacionados em projetos anteriores, conforme

Spanoudkis e Zisman (2005), com o emprego de rastreabilidade de requisitos é possível identificar

e comparar as necessidades dos sistemas novos com sistemas existentes. E com o emprego de

padrões pretende-se atingir o objetivo de obter requisitos com uma maior qualidade de escrita

(HAGGE; LAPPE, 2006; OLIVEIRA; SPINOLA, 2007) e agilizar o processo de elicitação de

requisitos de software (OLIVEIRA; SPINOLA, 2007).

O diferencial da abordagem proposta reside no fato de que não foi encontrado na literatura

um trabalho que reúna as técnicas de rastreabilidade, catálogo de requisito e padrões com o intuito

de potencializar a reutilização de requisitos.

3.1.2 Delimitação de Escopo

Ao verificar o interesse da comunidade de software por pesquisas que voltem seus esforços

em realizar avaliações de eficácias e eficiência entre técnicas de elicitação de requisitos e de

abordagens que propiciem o reuso de requisitos (CHENG; ATLEE, 2007), este trabalho pretende

avaliar de forma empírica a eficiência e eficácia de uma nova abordagem para o reuso de requisitos.

Para isso, pretende-se elaborar uma nova abordagem que potencialize o reuso de requisitos, estando

esta apoiada em práticas como rastreabilidade entre requisitos, catálogo de requisitos e padrões.

Este trabalho pretende fazer uso da rastreabilidade com o propósito de vincular requisitos

entre si. Não serão desenvolvidos mecanismos que trabalhem todo o processo de rastreabilidade

entre requisitos e quaisquer outros artefatos no projeto de software.

Em resumo, está fora do escopo deste trabalho:

as outras atividades da disciplina da Engenharia de Requisitos (análise e negociação

dos requisitos, verificação e validação, e gerência de requisitos);

atividades de manutenção dos artefatos produzidos;

atividade de rastreabilidade entre outros artefatos no projeto de software;

atividades ligadas a exploração de prototipação.

19

3.1.3 Justificativa

A definição correta dos requisitos é um fator crucial para reduzir custos e riscos no projeto

de software (GOTTESDIENER, 2008), pois a falta de um bom trabalho na atividade de elicitação

de requisitos leva ao insucesso ou abandono de projetos (DAVEY; COPE, 2008). Problemas na

elicitação de requisitos estão relacionados a escopo, compreensão e volatilidade (CHISTEL;

KANG, 1992), esses problemas são decorrentes da dificuldade em se extrair ou identificar as

necessidades de seus usuários (HOOD et al., 2008).

Em um evento que discutiu o futuro da Engenharia de Software, o FOSE'07 (Future of

Software Engineering). Cheng e Atlee (2007) fizeram um levantamento do estado atual da arte da

Engenharia de Requisitos e identificaram futuras direções de pesquisas no que diz respeito a

tecnologias que abordam especificação de requisitos, elicitação, modelagem e análise. Diante do

trabalho das autoras, podem-se destacar os seguintes pontos que justificam o presente projeto:

Cheng e Atlee (2007) citam que há poucos trabalhos que relatem comparações de

eficácia entre técnicas de elicitação;

o uso de padrões para escrita de requisitos e abordagens de reuso como hotspots de

pesquisa na Engenharia de Requisitos.

Trabalhos que tratem Padrões são vistos pelas autoras como pesquisas que beneficiam no

melhoramento da qualidade dos artefatos de requisitos produzidos, pois os padrões impõem certo

nível de uniformidade e previsibilidade no resultado da descrição dos requisitos.

Em relação a Reuso de Requisitos, Cheng e Atlee (2007) afirmam que a dificuldade

encontrada nessa área é como facilitar a reutilização dos artefatos de requisitos. Outra dificuldade

relatada pelas autoras é em relação às seções da estrutura dos padrões, segundo elas essas

informações normalmente não são suficientes para facilitar a reutilização do padrão.

Em virtude do exposto, este trabalho se justifica pelo interesse da comunidade em pesquisas

que voltem esforços para abordagens que propiciem o reuso de especificações de requisitos, bem

como avaliações que determinem sua eficiência e eficácia.

20

3.2 OBJETIVOS

Esta seção formaliza os objetivos do trabalho, conforme descrito a seguir.

3.2.1 Objetivo Geral

Desenvolver uma nova abordagem para reuso de requisitos e avaliar de forma empírica a sua

eficiência e a eficácia.

3.2.2 Objetivos Específicos

Os objetivos específicos deste trabalho são:

OE1. Elaborar uma abordagem para o reuso de requisitos, tendo como principais práticas a

rastreabilidade, catálogo e padrões de requisitos;

OE2. Especificar e implementar uma ferramenta que apóie a abordagem proposta;

OE3. Avaliar a eficiência e eficácia da abordagem proposta.

3.3 METODOLOGIA

De modo amplo, pode-se dizer que metodologia é a descrição dos métodos ou

procedimentos que serão adotados na pesquisa (MATTAR, 2008, p. 162). Segundo Mattar (2008,

p.162), a especificação da metodologia é muito importante porque através da metodologia adotada

pode-se saber de antemão os possíveis resultados do trabalho.

Para uma melhor compreensão da metodologia adotada neste projeto, este tópico está

dividido em metodologia da pesquisa e procedimentos metodológicos.

3.3.1 Metodologia da Pesquisa

Por intermédio da metodologia de pesquisa científica, foi desenvolvida uma abordagem

voltada ao reuso de requisitos de software, utilizando-se de técnicas que empreguem rastreabilidade

entre requisitos, catálogos de requisitos e padrões, apoiada por uma ferramenta computacional com

o propósito de obter requisitos mais corretos e precisos.

21

Segundo Gil (1994), pesquisa é definida como o procedimento racional e sistemático que

objetiva responder aos problemas que são propostos. Silva e Menezes (2000, p.19) definem

pesquisa como “de forma bem simples, procurar respostas para indagações propostas”. Wazlawick

(2009, p. 17) colabora ao afirmar que pesquisa em um cunho científico, é a produção de

conhecimento novo. Já Pádua (2000, p. 31) define pesquisa como “toda atividade voltada para a

solução de problemas”.

Portanto, pode-se então afirmar diante dessas definições que pesquisa é um esforço realizado

de forma sistemática com realizações de atividades de busca ou investigação, que vem elaborar um

conhecimento novo em um âmbito de ciência e esse conhecimento irá responder a um problema

proposto.

Para Gil (1994) uma pesquisa é requerida quando:

Não se dispõe de informações no qual se possa responder ao problema.

As informações disponíveis estão em desordem de forma que não se possa ser

adequadamente relacionada ao problema.

Nesse ponto, este trabalho enquadra-se como pesquisa por atender a primeira característica

enumerada por Gil (1994). Através de uma pesquisa na literatura, não se encontrou trabalhos que

abordem / respondam a pergunta de pesquisa apresentada nesse trabalho. Nesse sentido esse

trabalho trará como resultado um conhecimento novo para a comunidade.

Este trabalho, sob o ponto de vista da natureza, pode ser classificado como pesquisa

aplicada. Conforme Silva e Menezes (2000, p.20), uma pesquisa aplicada “objetiva gerar

conhecimentos para aplicação prática dirigida à solução de problemas específicos”. Para Gil (1994,

p. 20), uma pesquisa aplicada é de uma ordem prática, que ocorre do desejo de conhecer e fazer

algo de uma maneira mais eficiente ou eficaz. Sendo assim, este trabalho objetiva gerar

conhecimento sobre o tema para aplicação prática na engenharia de requisitos.

Do ponto de vista da forma de abordagem do problema, este trabalho tem características de

pesquisa quantitativa. Uma pesquisa quantitativa consiste que tudo pode ser quantificável (SILVA;

MENEZES, 2000, p. 20). O trabalho aqui proposto possui essa característica porque os resultados

serão passíveis de uso de técnicas estatísticas.

22

Do ponto de vista dos objetivos, Wazlawick (2009, p. 14) afirma que os estilos de pesquisas

podem ser classificados em três tipos básicos: Pesquisas Formais, Pesquisas Empíricas e Pesquisas

Exploratórias. Segundo Wazlawick (2009, p. 14), as pesquisas formais são aquelas que elaboram

uma teoria ou uma prova formal na qual valide se a teoria é correta. As pesquisas empíricas

correspondem a um tipo de pesquisa em que uma nova abordagem é apresentada e comparada com

outras já existentes. Sua principal ferramenta para testes são os métodos estatísticos, porém esse

tipo de pesquisa não dispensa o embasamento de uma boa teoria, devido à estatística não poder

explicar causas. Já, uma pesquisa exploratória é uma pesquisa na qual os métodos estatísticos não

conseguem demonstrar resultados aceitos pela comunidade, esse tipo de pesquisa consiste em

análises qualitativas. Diante do exposto por Wazlawick (2009), pode-se afirmar que este trabalho é

visto sob o ponto de vista de seus objetivos como uma pesquisa empírica.

Outro enquadramento que pode ser feito em um trabalho de pesquisa é quanto ao método de

abordagem. Utilizando-se do entendimento de Andrade (1999), a metodologia é definida como o

“conjunto de métodos ou caminhos que são percorridos na busca do conhecimento”. Com base

nessa definição, conclui-se que o método científico delineia o raciocino lógico empregado à

investigação científica. Desta forma, considerando o tipo de raciocínio empregado, os métodos de

abordagem são classificados como: dedutivo, indutivo, hipotético-dedutivo e dialético.

Este trabalho sob o ponto de vista dos procedimentos técnico enquadra-se como uma

pesquisa bibliográfica e como pesquisa experimental. Uma revisão bibliográfica não produz

nenhum conhecimento novo (WAZLAWICK, 2009, p.25), mas em contra partida, um estudo

bibliográfico ajuda na redefinição de um problema, obtenção de informação acerca de técnicas de

coleta de dados, obtenção de dados em resposta ao problema formulado e/ou para interpretação de

resultados (GIL, 1994, p. 63-64). Na pesquisa bibliográfica, foram considerados artigos

especializados, livros e sites web relevantes. Em relação à pesquisa experimental, é correto afirmar

que esta é caracterizada pela manipulação direta das variáveis relacionadas com o objeto de estudo.

A manipulação dessas variáveis deve ser feita de forma sistemática no ambiente a ser pesquisado, e

seu resultado é observado para verificar se o resultado obtido condiz com o resultado esperado

(WAZLAWICK, 2009, p.42). A face experimental desta pesquisa visa verificar as hipóteses e

responder as perguntas de pesquisa levantadas neste trabalho.

Observando esse trabalho quanto ao método de abordagem definido, pode-se dizer que se

trata de um trabalho que utiliza o método hipotético-dedutivo, pois hipóteses são formuladas para

23

tentar explicar as dificuldades expressas no problema. A partir das hipóteses formuladas, deduzem-

se consequências que deverão ser testadas ou faseadas procurando evidências empíricas para

derrubá-las (GIL, 1994).

3.3.2 Procedimentos Metodológicos

Procedimento descreve uma seqüência de passos seguidos por um ou vários indivíduos em

um determinado nível em que esses passos ou procedimentos possam ser transmitidos ou utilizados,

por outro indivíduo que não o mesmo que o descreveu (MATTAR, 2008).

Diante do exposto, segue a seqüência do procedimento aqui adotado para atingir aos

objetivos listados na seção 3.2.2 :

ETAPA 1. Estudo bibliográfico: Inicialmente, visando fundamentar o objetivo específico 1,

foi realizado um levantamento bibliográfico visando descrever os principais conceitos relacionados

aos temas da pesquisa a citar: Engenharia de Requisitos, reuso de requisitos, padrões de requisitos,

rastreabilidade e catálogo de requisitos. Nessa revisão, foram considerados artigos especializados,

livros e sites web relevantes.

ETAPA 2: Pesquisa de ferramentas similares: Complementarmente ao objetivo específico 1

e visando fornecer base para objetivo específico 2, foram analisadas ferramentas voltadas ao apoio à

engenharia de requisitos, visando identificar características referentes à: (i) apoio ao reuso; (ii)

utilização de padrões; e (iii) possibilidade de extensão.

ETAPA 3. Catálogo de padrões: elaboração de um catálogo contemplando padrões que

apoiem o reuso de requisitos e que possam ser aplicados através de uma ferramenta automatizada.

Segue lista de passos para essa etapa que tem como foco atender ao objetivo específico 1:

a) identificação e análise de padrões encontrados na literatura para escrita e

categorização de requisitos. Esta atividade foi realizada através de um mapeamento

sistemático da literatura junto a bases de dados, visando identificar artigos, teses,

dissertações e livros que atendam ao seguinte critério de busca ((pattern OR catalog

OR category) AND (“software requirement” OR “requirements engineering” OR

“requirements elicitation”)) na língua inglesa, e ((padrões OR catálogo OR categoria)

AND (“requisito de software” OR “engenharia de requisitos” OR “elicitação de

24

requisitos”)) na língua portuguesa. Foram consideradas nesta etapa, as sugestões de

sistematização para realização da pesquisa bibliográfica feitas por Kitchenham et al.

(2007) e Brereton et al. (2007). O resultado desta etapa é apresentado no Apêndice

A.

b) seleção e/ou adaptação do catálogo para apoiar a abordagem.

ETAPA 4: Estado da arte: identificação e descrição dos estudos correlatos destinados a

descrever abordagens de reuso de requisitos. Como foi encontrada uma revisão sistemática

realizada nesta área (KONDA; MANDAVA, 2010) esta etapa focou em filtrar os resultados e

descrever os estudos correlatos ao presente projeto. O resultado desta etapa é apresentado no

Apêndice B.

ETAPA 5. Elaborar e descrever a abordagem proposta: compreende a atividade que resulta

no atendimento do objetivo específico 1, contemplando o detalhamento da abordagem envolvendo

as práticas de reuso de requisitos, padrões de requisitos, rastreabilidade e catálogo de requisitos.

ETAPA 6. Desenvolvimento da ferramenta: projeto e implementação de uma ferramenta que

automatize a abordagem proposta, contemplando o objetivo específico 2. Nesta etapa, realizaram-se

as seguintes atividades:

a) projeto: compreendeu a descrição dos requisitos funcionais e não funcionais

contemplados pela ferramenta. Além disso, foi realizada a modelagem da ferramenta

proposta utilizando a linguagem de modelagem UML;

b) implementação: atividade destinada a codificação da ferramenta conforme projeto

elaborado;

c) testes: compreende a realização de uma bateria de testes visando identificar se a

ferramenta está apta para avaliação.

ETAPA 7. Avaliação da abordagem: com foco a atender ao objetivo específico 3, esta etapa

compreende a elaboração de estudos de caso em 2 linhas de produtos distintas contemplando o

desenvolvimento por, no mínimo, 4 grupos de alunos da graduação. Os grupos foram divididos da

seguinte maneira: 2 grupos desenvolveram projetos de cada linha, sendo que 1 dos grupos utilizou a

abordagem proposta e o outro grupo não. Para tanto, as seguintes atividades foram elaboradas:

25

a) elaboração de 2 projetos modelos de linhas distintas que serviu como base para o

reuso, tendo-se como opções avaliadas e-commerce de uma livraria virtual e uma

locadora de veículos;

b) elaboração de 2 estudos de casos nas linhas definidas que foram realizados pelos

alunos;

c) elaboração de “projeto de referência” contemplando a solução esperada para os

estudos de casos;

d) planejamento da avaliação;

e) execução dos projetos pelos grupos de alunos e acompanhamento;

f) coleta e análise dos resultados.

3.4 ESTRUTURA DA DISSERTAÇÃO

Esta dissertação está organizada em seis capítulos, estes dispostos de forma a apresentar o

problema de pesquisa, fundamentação teórica, análise dos trabalhos similares, a especificação e

prototipagem da abordagem e planejamento da avaliação do estudo.

O primeiro Capítulo trata da introdução, a qual apresenta o escopo do trabalho, direcionando

ao problema investigado, os objetivos do trabalho e a metodologia utilizada.

O segundo Capítulo apresenta a fundamentação teórica sobre Engenharia de Requisitos,

Reuso de Requisitos, Padrões de Requisitos focando em padrões de requisitos para escrita de

requisitos de software.

O terceiro Capítulo apresenta o estado da arte sobre reuso de especificações de requisitos.

No quarto Capítulo, é realizada uma descrição detalhada da abordagem proposta neste

trabalho, englobando o padrão de requisito adotado, os mecanismos de sugestão para reuso de

especificações de requisitos e a descrição do protótipo da ferramenta de apoio à abordagem. Para

tanto, utilizou-se de diagramas, figuras e descrições textuais para especificação de todos os

elementos e mecanismos envolvidos.

26

No quinto Capítulo, é apresentado o planejamento, execução e resultados dos experimentos

realizados para avaliação da abordagem.

No sexto Capítulo, são tecidas as considerações sobre a pesquisa, como as contribuições e

sugestões de trabalhos futuros.

27

2 FUNDAMENTAÇÃO TEÓRICA

Este capítulo tem o caráter de apresentar a fundamentação teórica a cerca deste trabalho.

Este capítulo é dividido em quatro partes: na primeira parte é descrito aspectos sobre a engenharia

de requisitos, na segunda parte são relacionados assuntos sobre reuso de requisitos. A terceira parte

trata de padrões. Na quarta parte, são descritos os principais aspectos sobre padrões de requisitos

para escrita de requisitos.

2.1 ENGENHARIA DE REQUISITOS

Devido à necessidade de qualidade na produção de um produto de software, o processo de

desenvolvimento de software vem sendo aperfeiçoado ao longo dos anos (GENVIGIR, 2009). Essa

busca por aperfeiçoamento está ocorrendo porque organizações perceberam que o êxito na execução

dos projetos está cada vez mais relacionado a um melhor entendimento dos requisitos (WIEGERS,

2006; ROBERTSON; ROBERTSON, 2006).

Diversos autores destacam a importância da engenharia de requisitos e seus impactos,

principalmente em relação aos custos do projeto e qualidade, ressaltando que os defeitos de

software na fase de projetos são muito mais caros e difíceis de serem resolvidos do que na fase de

definição de requisitos (PRESSMAN, 2002; BOEHM e BASILI, 2001; ROBERTSON;

ROBERTSON, 2006; YOUNG, 2004).

Neste sentido, a engenharia de requisitos trabalha de forma a sistematizar o tratamento dos

requisitos (SWEBOK, 2004). Uma definição para engenharia de requisitos é feita por Cheng e Atlee

(2007), como um processo pelo qual requisitos são determinados. É o processo pelo qual se

descobre os propósitos do sistema, faz-se a identificação dos stakeholders e de suas necessidades,

documenta-se essas necessidades de forma que seja passível de análise, comunicação e que,

posteriormente, possa-se implementá-las (NUSEIBEH; EASTERBROOK, 2000).

No entanto, antes de aprofundar no processo de engenharia de requisitos, faz-se importante

compreender o que são requisitos. Requisito, por sua vez, tem o papel de descrever como o sistema

deverá se comportar, além de prestar informação sobre o domínio da aplicação ou restrições na

operação do sistema (SOMMERVILLE; KOTONYA, 1998), a fim de resolver um problema no

mundo real (SWEBOK, 2004). Os requisitos servem de base para elaboração de cada projeto

28

(HULL et al., 2005; YOUNG; 2004, p.2) e o sucesso do projeto depende do entendimento desses

requisitos (CHENG; ATLEE, 2007). Uma separação por tipos de requisitos pode ser feita de modo

a evitar problemas no processo de engenharia de requisitos (SOMMERVILLE; KOTONYA, 1998).

Os requisitos podem ser divididos em três tipos: requisitos de negócio, que é dirigido por metas ou

objetivos e também descrevem visões estratégicas de negócio, requisitos do usuário, que descrevem

o que o usuário espera do sistema, e requisitos do sistema, que descrevem o que o sistema deve

fazer (GOTTESDIENER, 2008). Essa separação entre diferentes níveis de descrição deve ser feita

para facilitar a comunicação entre os diferentes tipos de leitores (SOMMERVILLE; KOTONYA,

1998).

Os requisitos de sistema são classificados freqüentemente em três tipos: requisitos

funcionais, requisitos não funcionais e requisitos de domínio (SOMMERVILLE; KOTONYA,

1998), definidos da seguinte forma:

Requisitos funcionais: são descrições de funções que o sistema irá fazer; deve ser útil

ao usuário para ajudar na execução de seu trabalho. Qualquer ação ou verbo ativo

são considerados requisitos funcionais, como por exemplo, calcular, inspecionar,

publicar, processar, imprimir, listar e etc. (ROBERTSON; ROBERTSON, 2006)

Requisitos não funcionais: expressam condições de comportamento e/ou restrições

que o software deve satisfazer (CYSNEIROS; LEITE, 1998), ou seja, são descrições

ou atribuições de qualidade que o sistema deve possuir (ROBERTSON;

ROBERTSON, 2006). São exemplos requisitos ligados a segurança, desempenho,

usabilidade, acurácia, portabilidade e etc.

Requisitos do domínio: derivam do domínio da aplicação e refletem características

desse domínio. Podem ser enquadrados como requisitos funcionais ou como

requisitos não funcionais (SOMMERVILLE, 2007). A diferença entre esse tipo de

requisito e os requisitos funcionais e os não funcionais, é que requisitos de domínio

normalmente têm uma existência fora dos limites de qualquer sistema de software

(WIEGERS, 2006). Isso quer dizer que, uma regra de negócio não é propriamente

um requisito de domínio, ela existe independentemente de um sistema

computacional, e muitas vezes ela será aplicada para garantir que o sistema imponha

esta regra. Cabe ressaltar aqui que nem todos os autores citam este tipo de requisito.

29

2.1.1 Processo de Engenharia de Requisitos

Conforme Nuseibeh e Easterbrook (2000), o sucesso de um sistema de software é decorrente

do cumprimento das finalidades para o qual o sistema foi desenvolvido. De um modo amplo, pode-

se dizer que o processo de engenharia de requisitos objetiva a criação e manutenção do documento

de especificação de requisitos (SOMMERVILLE, 2007, p.143). Esse processo ou domínio da

engenharia de requisitos pode ser divido em desenvolvimento de requisitos, que centra as atividades

de identificar e acordar um conjunto de requisitos; e gerenciamento de requisitos, parte responsável

por gerir as alterações do conjunto de requisitos gerado pelas atividades de desenvolvimento de

requisitos (WIEGERS, 2006). Segundo Sommerville (2007, p.143), a engenharia de requisitos pode

ser divida em desenvolvimento de requisitos e gerenciamento de requisitos. O desenvolvimento de

requisitos é dividido em quatro atividades: elicitação1, análise, especificação e validação. E o

gerenciamento de requisitos é composto de três atividades: identificação de requisitos (a

identificação de requisitos aqui não se refere à atividade de elicitação de requisitos, mas sim a

atividade de organizar, como por exemplo: fazer atribuição de identificador único, adequações de

atributos como status, prioridade e urgência), gerenciamento de mudanças de requisitos e

rastreabilidade de requisitos.

Como fruto deste processo é desenvolvido o documento de especificação de requisitos que

dispõe das declarações oficiais as quais os desenvolvedores devem implementar (SOMMERVILLE,

2007, p. 136). É neste ponto em que todas as descrições das funções do sistema, restrições do

projeto, validações apropriadas e outros dados pertinentes aos requisitos são documentados

(PRESSMANN, 2002, p. 267). Sua utilização também é essencial para a elaboração de um contrato

de desenvolvimento do software (SOMMERVILLE, 2007, p. 138). A conclusão da sua revisão é

um marco final do processo de engenharia de requisitos, nas quais todas as atividades do processo

de engenharia de requisitos forma concluídas (VLIET, 2007 p.12).

1Optou-se por utilizar o termo elicitação para a tradução da palavra elicitation da língua inglesa. Pode-se afirmar que “elicitar” e “elicitação” são simples adaptações de palavras inglesas: o verbo (to) elicit pode ser traduzido como: eliciar, fazer sair, trazer à tona, deduzir, concluir, induzir, evocar; e o substantivo elicitation têm como significado: ação de extrair ou fazer surgir; (Dicionário Michaelis, 2000-2009). O termo elicitation é de uso corrente na literatura inglesa sobre o tema de engenharia de requisitos. O vocábulo elicitação está sendo usado com freqüência nas publicações de língua portuguesa na área de engenharia de requisitos (CYSNEIROS, 2001; FREITAS et al., 2007).

30

Dentro deste contexto, o reuso de requisitos surge como uma alternativa para auxiliar na etapa

de elicitação e documentação dos requisitos. Sendo o reuso o foco deste trabalho, a seção seguinte

explana sobre este tema.

2.2 REUSO DE REQUISITOS

A produção de um produto de software deve obedecer a três restrições: normas de qualidade,

tempo de desenvolvimento e os requisitos. Isso quer dizer que um produto de software deve

satisfazer padrões de qualidade rigorosos, deve ser entregue o mais rápido possível e, além disso,

deve satisfazer a um conjunto de necessidades dos usuários definidas nos requisitos de software

(VILLEGAS; LAGUNA, 2001).

Neste sentido, o reuso é visto pela comunidade de software como uma atividade

fundamental em todos os processos relacionados com o desenvolvimento de software (FRANCH et

al., 2010; OLIVEIRA; SPÍNOLA, 2007) e sua utilização deve ser mais ampla, e não só restrita ao

reuso de código (ZAND; SAMADZADEH, 1994; KONDA; MANDAVA, 2010 p.50). Portanto,

uma abordagem de reuso de requisitos de software tende a conduzir a uma melhora substancial na

qualidade do processo de engenharia de requisitos (PEREDNIKAS, 2008), reduzindo o tempo de

construção e aumentando a qualidade do produto desenvolvido (SPANOUDAKIS;

CONSTANTOPOULOS, 1996; MASSONET; van LAMSWEERDE, 1997; CYBULSKI; REED,

2000). Além disso, o reuso de requisitos de software pode ajudar os engenheiros nas atividades de

elicitação, análise, validação e documentação de requisitos e, como consequência, obter

especificações de requisitos de maior qualidade, tanto em conteúdo como em sintaxe

(ROBERTONS; ROBERTONS, 2006). Outro aspecto a ser destacado é que o reuso de

especificações de requisitos leva a uma maior reutilização de outros artefatos como modelos,

código, documentação e planos de testes, assim, estendendo os benefícios que o reuso

proporcionam (KEEPENCE et al., 1995; LÓPEZ et al., 2002).

Entretanto, algumas dificuldades ainda são relatadas em um processo de reuso, tais como:

existência dos artefatos para reutilização; disponibilidade dos artefatos; localização dos artefatos;

entendimento dos artefatos; validade e integração com o projeto (POOLEY; WARREN, 2008).

Observa-se também que muitos estudos vêm tentando resolver problemas de reuso de requisitos

durante a evolução da engenharia de software, mas a eficácia dos métodos propostos ainda não é

satisfatória (PEREDNIKAS, 2008).

31

Entretanto, o sucesso de uma abordagem de reuso é obtido quando se consegue atender as

seguintes questões: (i) gestão comprometida com o processo de reutilização; (ii) modificações dos

processos que não consideravam o reuso;e (iii) quando são abordados os fatores humanos como

parte do processo (MORISIO et al., 2002). Cabe dizer, que essa mesma visão já havia sido descrita

por Card e Comer (1994), no entanto, de uma forma mais superficial, sem uma avaliação como a

realizada por Morisio et al. (2002).

Neste sentido, a definição de uma abordagem que defina mecanismos que possam contornar

dificuldades como as relatadas por Pooley e Warren (2008) e que atenda as considerações de

Morisio et al. (2002) são de extrema importância para que ocorra um reuso efetivo.

Por sua vez, também é enfatizado que para alcançar o reuso em projetos, é necessário

previamente ter uma biblioteca de componentes reutilizáveis, sendo a gestão desta biblioteca um

processo independente do processo de reuso (WAHONO, 2002). Recomenda-se, então, o apoio de

uma ferramenta computacional para automatizar o processo de reuso (WIEGERS, 2006; YOUNG,

2004) e para a gestão de uma biblioteca (WAHONO, 2002).

Cabe ressaltar ainda que algumas investigações como a de Johnson e Harris (1991) e Tracz

(1994) afirmam que a reutilização informal é possível, mas que existem muitas vantagens em

apoiar-se em uma ferramenta computacional para realização de um processo de reuso. Algumas

investigações nesta área revelam que a reutilização deve ser feita formalmente, com isso mantendo

a integridade do componente atingindo os benefícios da reutilização. A utilização do método

“copia/cola” é intuitivo e de fácil implementação, porém, raramente é benéfico, isso porque a

escrita do novo requisito nesta forma consiste em uma nova especificação e, portanto, necessita

passar por um processo de validação, perdendo assim um dos principais benefícios promovidos

pelas abordagens de reuso (KEEPENCE et al., 1995). Além disso, sabe-se também que o método de

“copia/cola”, possui importantes limitações como problemas de inconsistência de informação e falta

de controle de análise de impacto (MOZON, 2008).

Estas afirmações levam a seguinte discussão, comumente associada aos obstáculos à

reutilização de software: a reutilização deve ou não ser sistemática? Qual a diferença de custo e

benefícios proporcionados entre a reutilização sistemática e ad-hoc?

32

Na verdade, essa discussão está muito longe de um consenso. Isso porque se entende que a

reutilização no processo de desenvolvimento de software é algo natural e inerente a ela, isto,

independente da adoção ou não de uma abordagem de reuso. Quanto aos custos, a economia pode

ser observada a longo prazo, ou seja, quando empregada a reutilização sistemática os custos são

mais elevados no seu início, porém, eles são reduzidos com o decorrer do tempo (FRAKES;

ISODA, 1994). No entanto, alguns estudos estimam que para a recuperação do investimento um

componente deve ser reutilizado mais de 13 vezes (FAVARO, 1991).

De fato, independentemente do nível de reutilização, a concepção de uma abordagem de

reutilização de sucesso deve abordar mecanismos que facilitem a localização, customização

(adaptação) e gestão dos artefatos (ZAND; SAMADZADEH, 1994). Além disso, uma abordagem

de reuso deve dar resposta: (i) o que é uma unidade reutilizável? (ii) de que forma essas unidades

podem ser armazenadas e mantidas juntas em um repositório? (ZAND; SAMADZADEH, 1994)

Por sua vez, reutilização baseada na experiência pode ser usada para identificar necessidades

que uma solução deve satisfazer (WAHONO, 2002). Neste sentido, padrões provêem uma

reutilização de alto nível que pode ser implementada em muitas linguagens e plataformas

(OLIVEIRA, 2009 p.76). De modo amplo, o reuso de padrões é feito através da identificação de um

conjunto de padrões que servirão de núcleo para elaboração da análise do sistema. Os padrões são

selecionados pelo analista pela relevância à aplicação e são adaptados ao seu contexto (WAHONO,

2002).

Sendo assim, os padrões de requisitos são vistos pela comunidade como a abordagem que

mais apoia a reutilização (FRANCH et al., 2010). Segundo Fredj e Roudiès (1999), padrões

constituem uma solução eficiente para reutilização por três razões:

a) o par problema/solução serve de orientação e motivação para que os projetistas

procurem resolver determinado problema;

b) o tamanho reduzido de um padrão é de melhor usabilidade, bem como sua

compreensão, seleção e adaptação;

c) a generalidade de um padrão aumenta largamente o seu campo de aplicação.

A Seção 2.3.1 apresenta mais detalhes sobre padrões de requisitos.

33

Outra forma de reutilização de requisitos é através da rastreabilidade entre requisitos (DICK,

2002; von KNETHEN et al., 2002). A rastreabilidade, além do seu foco principal que é de apoiar a

análise das implicações e da integração das mudanças que ocorrem no processo de software,

também serve de apoio ao processo de reutilização dos artefatos (DICK, 2002; SPANOUDAKIS;

ZISMAN, 2005).

Outra abordagem de reutilização de requisitos promovida pela rastreabilidade é a reciclagem

de requisitos. Entretanto, em muitas vezes essa abordagem é realizada de forma ad-hoc, o que não é

recomendável, isso porque, a realização desta forma é muito demorada e propensa a erros. A

literatura relata que os maiores benefícios utilizando essa abordagem são alcançados utilizando-a de

uma forma sistemática (von KNETHEN et al., 2002). Na seção 2.2.1 são apresentadas alguns das

abordagens de reuso de requisito baseado nos vínculos de rastrabilidade.

Por fim, observa-se que o reuso possui muito potencial de utilização em linha de produtos de

software. Este paradigma serve como guia para o desenvolvimento de software baseado na

construção de artefatos reutilizáveis (desenvolvimento para reutilização) e na construção de novas

aplicações a partir desses artefatos (desenvolvimento com reutilização) (FERNANDES, 2009). Na

seção 2.2.2 são apresentados os principais conceitos sobre linha de produtos de software.

2.2.1 Rastreabilidade no contexto de reuso

A rastreabilidade é uma das atividades da gerência de requisitos (VLIET, 2007, p.236), mas

também é uma atividade que apóia várias atividades no processo de desenvolvimento de software.

Seu emprego visa a melhoria de qualidade na obtenção de sistemas de software (SPANOUDAKIS;

ZISMAN, 2005; GENVIGIR, 2009).

Conforme Spanoudakis e Zisman (2005), além de servir de base nas análises relatadas por

Dick (2002), a rastreabilidade também pode ser usada para análise em processo de reutilização dos

componentes de sistema de software e na identificação e comparação das necessidades de sistemas

novos com sistemas já existentes. Outro aspecto relatado pelos autores é da possibilidade de utilizar

a rastreabilidade para permitir que os usuários tenham uma melhor compreensão das

funcionalidades do sistema.

34

Alguns trabalhos como de Dick (2002), Constantopoulos et al. (1995) e von Knethen et al.

(2002), apresentam técnicas de rastreabilidade com o intuito de apoiar o reuso em algum momento

no ciclo do desenvolvimento. No trabalho de Constantopoulos et al. (1995), são empregadas

relações de dependência de rastreabilidade chamadas pelos autores de “relação de

correspondência”, associando especificação de requisitos com os modelos de design e os modelos

de design com o código fonte. Seguindo essas relações, o engenheiro de software conseguiria

localizar artefatos reutilizáveis. Estas relações são estabelecidas em um contexto de frames, em que

os grupos de artefatos para uma linha de produtos são declarados de forma manual. Nesta

abordagem, a reutilização é alcançada através da avaliação da similaridade do frame com os

requisitos para os novos sistemas.

O trabalho de von Knethen et al. (2002), apresenta uma abordagem que consiste na

reciclagem de requisitos2. Naturalmente, os documentos de especificação de requisitos têm muitas

semelhanças, aproveitando desta característica a reciclagem é muito utilizada por aproveitar pontos

de variabilidade entre os projetos. Com este tipo de abordagem, os desenvolvedores buscam poupar

esforços, porém, é freqüentemente realizada de forma ad-hoc. Esse tipo de abordagem realizada de

forma não sistemática é muito demorada de ser realizada e está propensa a erros. Os problemas para

identificação das necessidades que potencialmente poderiam ser reutilizadas são: a variação das

estruturas dos documentos de requisitos; e as relações de dependência que não são explícitas (von

KNETHEN et al., 2002). Na proposta de von Knethen et al. (2002), esses problemas são

contornados com o uso de templates na especificação de requisitos para que o texto seja expresso de

forma estruturada e a utilização de um modelo de rastreabilidade para tornar explícitas as relações

de dependência entre requisitos. Em complemento, Dahlstedt e Persson (2005, p.107), afirmam que

utilizando das informações de rastreabilidade, pode-se claramente apoiar a reciclagem de requisitos.

Em Dick (2002), é apresentado melhoria no processo de desenvolvimento através de

rastreabilidade com relação de “satisfatibilidade”. Essa abordagem é uma forma de capturar o

argumento de satisfação. O uso da abordagem fornece maneiras de representar de forma alternativa

um conjunto de ideias nas quais não estão explícitas quando se faz o link entre os requisitos de

2 Reciclagem de requisitos consiste na atividade de identificar requisitos de sistemas existentes em documentos de especificação de requisitos e inseri-los em um novo documento de especificações de requisitos de um produto semelhante (von KNETHEN et al., 2002).

35

usuário e os requisitos de sistema. Isso permite que além da análise de impacto, cobertura e

derivação, outras análises mais profundas possam ser realizadas. Neste trabalho, também é

abordado como essa estrutura pode ser aplicada na gestão de requisitos para uma família de

produtos, fornecendo uma maneira de representar de forma alternativa um conjunto de ideias de

requisitos. Além disso, pode ser usado para representar a variância nos requisitos de sistema por

diferentes configurações de uma gama de produtos.

2.2.2 Linha de Produtos de Software no Contexto de Reuso de Requisitos

Linha de Produto de Software (LPS), também chamada de família de produtos na literatura,

objetiva reduzir o esforço de engenharia aplicada para produzir uma coleção de sistemas similares

por intermédio da capitalização sobre as semelhanças entre os sistemas e gerenciar formalmente a

variação entre os sistemas. Para Clements e Northrop (2002), uma LPS trata de um conjunto de

sistemas intensivos de software os quais compartilham um conjunto comum de características as

quais satisfaçam as necessidades de um determinado domínio (segmento do mercado ou missão),

esses desenvolvidos a partir de um conjunto comum de ativos de uma forma prescrita. A ideia

inicial de linha de produtos foi apresentada por Parnas em 1976, que objetivava reduzir o custo de

manutenção e desenvolvimento do software. No conceito inicial apresentado por Parnas (1976) era

levada em consideração apenas a variabilidade de requisitos não funcionais entre os produtos.

Porém, o termo Linha de Produto de Software (LPS) foi introduzido no início da década de 90, após

a descrição do método FODA (Feature-Oriented Domain Analysis) proposto por Kang et al., 1990

(FERNANDES, 2009).

Conforme Krueger (2000), uma LPS objetiva reduzir o esforço de engenharia aplicada para

produzir uma coleção de sistemas similares por intermédio da capitalização sobre as semelhanças

entre os sistemas e gerenciar formalmente as variações entre eles. Para Clements e Northrop (2002),

uma LPS trata de um conjunto de sistemas intensivos de software os quais compartilham um

conjunto comum de características que satisfazem as necessidades de um determinado domínio

(segmento do mercado ou missão), esses desenvolvidos a partir de um conjunto comum de ativos de

uma forma prescrita.

Assim, um dos principais aspectos sobre um LPS é o fato de construir produtos de software

a partir de ativos comuns, os quais são moldados de acordo com regras definidas pela arquitetura.

Desta forma, o conceito de variabilidade é um aspecto chave para a abordagem de LPS, pois

36

permite especificar os pontos nos quais os produtos se assemelham ou diferem entre si, portanto,

aumentando o reuso de software (BECKER, 2003).

Vale ressaltar que a engenharia de LPS conta com uma distinção fundamental entre

desenvolvimento para reutilização (engenharia de domínio) e desenvolvimento com reutilização

(engenharia de aplicação) (VAN DER LINDEN et al., 2007). Sendo que a preocupação dos

requisitos é tratada na atividade de domínio de engenharia de requisito, a qual corresponde a uma

das atividades da engenharia de domínio. Na atividade de domínio de engenharia de requisito é

utilizado o guia de produtos e tem como objetivo analisar exaustivamente os requisitos para

diversos produtos na LPS. Nesta atividade são capturados os requisitos e identificados os pontos

comuns e de variabilidade para construção de um modelo de variabilidade inicial que será utilizado

nas próximas etapas.

Segundo Van Der Linden et al. (2007), em uma LPS, os requisitos são considerados um

importante artefato que são muitas vezes documentados de acordo com sua comunalidade e análise

de variabilidade. A análise das variações e similaridades dos requisitos tem como objetivo capturar

os requisitos comuns (ou seja, requisitos da linha de produtos inteira) e variáveis (ou seja, as

características específicas que não constam em todos os membros da linha de produto) das

aplicações do domínio. A reutilização em uma LPS ocorre com o uso dos ativos fundamentais (do

inglês core asset). Neste sentido, o escopo é delimitado de forma a maximizar a reutilização dos

ativos fundamentais.

2.2.3 Ferramentas

Hoje em dia, existe uma grande quantidade de ferramentas comerciais que visam apoiar a

engenharia de requisitos. Segundo Robertson e Robertson (2006), as ferramentas de automação

podem ser utilizadas na execução de diversas tarefas, tais como: rastreabilidade de requisitos,

ligação dos resultados de testes de requisitos, gerenciamento de mudanças, análise semântica e

outras. Segundo Hoffmann et al. (2004), a seleção de uma ferramenta é um assunto importante e

sensível, sendo que sua seleção depende de vários fatores como: domínio do produto, tamanho do

projeto e da organização, o montante da reutilização e da maturidade do processo.

International Council on Systems Engineering (INCOSE) mantém desde a década de 90

avaliações das principais ferramentas de gerenciamento de requisitos, fornecendo uma lista dos

37

recursos dessas ferramentas, permitindo a comparação. No entanto, cabe observar, que as

especificações das ferramentas são de preenchimento pelos próprios fornecedores através de um

formulário com perguntas padrão e revisadas pelo grupo (GOTEL; MÄDER, 2009).

Em INCOSE (2011), constam 34 ferramentas destinadas à área de requisitos, assim, partiu-

se desta listagem de ferramentas, utilizando como critério de seleção para análise quais ofereciam

algum tipo de suporte à reutilização de especificações de requisito. Como resultado, selecionou-se 4

ferramentas para análise. A seguir, são descritas as ferramentas selecionadas.

A ferramenta Contour (JAMAS SOFTWARE, 2010) é uma aplicação disponibilizada para a

plataforma web desenvolvida pela Jamas Software para o gerenciamento dos requisitos em grandes

projetos de desenvolvimento. Segundo o fornecedor, os principais benefícios que a ferramenta

proporciona é a captura das necessidades do cliente, controle de comunicação no projeto e controle

de mudanças. A partir da análise da ferramenta, percebeu-se que a mesma não possui um método de

reuso de requisitos de forma sistemática conforme relatado na literatura, a ferramenta apenas

permite realizar uma cópia de um projeto existente como forma de reuso. A versão utilizada para

análise foi a 2.9.

A ferramenta inteGREAT Enterprise 2010 desenvolvida pela Edevtech Software (2010) é

uma suite de ferramentas que dão suporte a cada fase da engenharia de requisitos. Segundo o

fornecedor, a suite oferece integração com diversos produtos como o Visual Studio Team System,

SharePoint, Word, Excel, Visio, Project e Expression Blend com Sketchflow, e ainda inclui dados de

teste, relatórios e estatísticas. O módulo que trata do gerenciamento dos requisitos é chamado de

inteGREAT Requirement Studio. Analisando a ferramenta, observou-se que o reuso é relacionado a

um requisito (que pode conter diversas regras de negócio) ou a regras de negócio (que

correspondem a um item de um requisito). A reutilização pode assumir dois valores distintos,

sendo:

Contêm: corresponde a um item copiado sem nenhuma referência com o requisito ou

regra de negócio de origem (corresponde ao método de “copia/cola”);

Referem-se: refere-se a um requisito ou regra de um projeto origem.

A versão utilizada no quadro comparativo da INCOSE (2011) é a 4.7.

38

A ferramenta MKS Integrity (MKS INC., 2010) da MKS Inc, é uma ferramenta que apóia

todas as atividades da engenharia de requisitos. Segundo o fornecedor, a ferramenta oferece

reutilização e persistência de requisitos, o que permite ao grupo de requisitos a associação e reuso

de requisitos em um cenário paralelo de desenvolvimento. A partir da análise da ferramenta,

constatou-se que o método de reuso de requisitos consiste na seleção de requisitos de outros

projetos para um novo. Nessa seleção, o requisito reusado no novo projeto mantém referência ao

projeto antigo. Essa referência pode ser de três tipos:

compartilhado: Os requisitos marcados como “compartilhado” no novo projeto

mantém um vínculo de referência com o antigo projeto, quando o requisito “pai”

sofre algum tipo de modificação a mesma será propagada ao novo requisito reusado.

reusado: Quando marcado como “reusado” o novo requisito mantém um vínculo com

o requisito “pai” do antigo projeto, porém as alterações feitas no requisito “pai” não

serão transmitidas ao requisito “filho”.

do autor: Nesse tipo de referência os requisitos reusados não manterão nenhum tipo

de vínculo com o requisito “pai”. Esse tipo de referência assemelha-se ao método

“copia/cola”.

Na análise da ferramenta MKS Integrity (MKS INC., 2010) utilizou-se a versão 2009.

A última ferramenta analisada foi a IRQA (VISURE SOLUCTIONS, 2010) desenvolvida

pela empresa Visure Soluctions. Segundo o fornecedor, a ferramenta MKS Integrity faz parte de

uma plataforma integrada de produtos para o desenvolvimento de software. O foco da ferramenta é

abordar problemas comuns dos clientes com o gerenciamento de requisitos. A partir da análise da

ferramenta, observou-se que a forma de reuso dos requisitos pode ser feita de acordo com as

informações contidas em cada grupo de elementos. Essas informações assumem os seguintes

valores:

compartilhado: Os elementos são compartilhados em diferentes projetos. O objetivo

é permitir a todos os usuários de forma colaborativa a construção de uma solução. A

permissão dos usuários é total sobre cada elemento e suas modificações são

propagadas para todos os projetos que os utilizam.

39

modo de leitura: Os elementos são compartilhados para todos os projetos, mas com

permissão restrita para somente poder reutilizar de outros projetos sem opção de

modificação.

copiar e manter ligação: Os elementos são importados de outros projetos. Esses

elementos podem ser adaptados e atualizados. Estes também podem ter atributos e

podem ser rastreados para outros elementos.

modo cópia: Os elementos são importados de outros projetos e perdem a ligação com

o original.

Na análise da ferramenta IRQA (VISURE SOLUCTIONS, 2010) utilizou-se a versão v4.

Considerando a análise realizada nas ferramentas, a Tabela 2 demonstra um comparativo

contemplando os seguintes critérios: (i) forma de reuso – descreve as possibilidades disponíveis na

ferramenta para reutilizar um requisito; (ii) sugestão de reuso – descreve os mecanismos disponíveis

para identificar um requisito para reuso; (iii) utilização de padrões – verifica se há algum suporte

ao uso de padrões de requisitos; e (iv) possibilidade de extensão – verifica se existe a possibilidade

de estender as funcionalidades da ferramenta.

Tabela 2 - Resultado da análise das ferramentas.

Ferramenta Forma de reuso3 Sugestão de reuso Utilização de padrões

Possibilidade de extensão

Contour CC Não oferece Não Não inteGREAT Requirement Studio CC/CL Não oferece Não Não MKS Integrity CC/CL/C Não oferece Não Não IRQA CC/CL/C/ML Não oferece Não Não

Em síntese, pode-se afirmar que existem diversas ferramentas com o objetivo de apoiar o

reuso de requisitos. Das ferramentas observadas, percebe-se que em todas elas o método de

copiar/cola está presente. No entanto, muito autores não concordam que este seja um método

efetivo de reuso (KEEPENCE et al., 1995; AKERS, 2008; MOZON, 2008), assim, para ser um

3 CC – Funcionalidade de “Copiar e Colar”: nenhum vínculo entre os requisitos é mantido. CL – Funcionalidade de “Copiar e Link”: a ferramenta mantém um vínculo com o requisito original, mas o novo requisito pode ser alterado. C – Funcionalidade de “Compartilhar”: alterações no requisito original são propagadas para os projetos que o reutilizaram. ML – Funcionalidade de “Modo Leitura”: requisito compartilhado para todos os projetos, porém, as alterações no requisito original não são permitidas.

40

método real de reuso, o mesmo deve proporcionar pelo menos um ponteiro para a origem do

conteúdo (AKERS, 2008). Constata-se, ainda, que as ferramentas não apresentam recursos que

auxiliam a identificação de requisitos com potencial para reuso. Ainda, observa-se que nenhuma

ferramenta utiliza padrões para orientar a escrita dos requisitos. Por fim, destaca-se que nenhuma

das ferramentas pesquisadas possibilita o desenvolvimento de novas funcionalidades pela

comunidade para ampliação os recursos da ferramenta.

2.3 PADRÕES

Na maioria dos casos, padrão é um instrumento eficaz para reutilizar o conhecimento

adquirido em desenvolvimento de software. Sua utilização é afirmada como eficaz para resolver

problemas inesperados ou acidentais, isso porque trata de conhecimentos baseados em experiências

reais (TSUMAKI, 2004).

Segundo Wahono (2002), o termo atual da palavra padrão é derivado dos trabalhos

publicados para arquitetura por Christopher Alexander. Nesses trabalhos de Christopher Alexander,

são apresentados padrões para arquitetura e urbanismo, os quais são aplicáveis a muitas outras

disciplinas, incluindo desenvolvimento de software. A popularização de padrões de software

aconteceu com o trabalho realizado por Gamma et al. (1995), com a coleção de padrões para

desenvolvimento orientado a objetos (TSUMAKI, 2004; WAHONO, 2002).

Segundo Alexander et al. (1977 apud GAMMA et al. 1995, p.12), “Cada padrão descreve

um problema que ocorre repetidamente no nosso ambiente e então descreve o núcleo da solução

para esse problema, de tal forma que você pode usar esta solução um milhão de vezes, sem nunca

fazê-lo da mesma maneira duas vezes”. Uma definição com o mesmo cerne, apresentada por

Alexander et al. (1977), é encontrada em Hagge e Lappe (2004b), que define padrões como uma

forma de capturar o conhecimento bem sucedido de soluções de engenharia em um formato

comprovado por intercâmbio de experiências práticas de projetos, de modo a torná-lo aplicável,

confiável e relevante. Cabe também dizer que um padrão é uma solução que foi descoberta e já tem

sido testada por algum tempo sob condições variáveis (SALINGAROS, 2000).

Conforme Gamma et al. (1995, p.12), a mesma ideia apresentada por Alexander et al. (1977)

pode ser utilizada em padrões para desenvolvimento orientado a objetos, já que o núcleo dos dois

tipos de padrões é uma solução para um problema em um determinado contexto. Por sua vez, o uso

41

de padrões foi estendido para outras áreas da computação, podendo ser classificado em categorias

mais específicas como padrões de análise, padrões de negócios, padrões organizacionais e padrões

de requisitos. Os padrões de requisitos, por sua vez, são aplicados em dois contextos diferentes:

especificação de padrões para problemas recorrentes na engenharia de requisitos e padrões para

criação de especificações de requisitos (HAGGE; LAPPE, 2004a). Essas classificações para

padrões são geralmente feitas de acordo com a sua contribuição ao ciclo de vida de uma aplicação

(FREDJ; ROUDIÈS, 1999).

Para um melhor entendimento, ressalta-se que o mecanismo proposto por Alexander et al.

(1977) para realizar o seu novo modelo foi a linguagem de padrão (GABRIEL, 1996 p.46). No

entendimento de Gabriel (1996, p.46), a linguagem de padrão é um conjunto de padrões que são

usados por um processo para gerar novos artefatos. Em uma linguagem de padrões, cada padrão

define subproblemas no qual o padrão irá resolver, assim, a solução de um problema grande é um

conjunto de padrões aninhados (GABRIEL, 1996 p.46). Winn e Calder (2002, p.63) reforçam o

conceito de linguagem de padrões afirmando que um “padrão é parte de uma linguagem”, cada

padrão está ligado a outros padrões, os quais fazem parte de uma rede de padrões inter-

relacionados.

Outro conceito que é apresentado em linguagem de padrões é quanto a sua estrutura. Os

padrões são documentados de forma textual, nos quais geralmente são organizados em seções ou

componentes, o que define um template ou formato do padrão (MESZAROS; DOBLE, 1996).

Conforme Tsumaki (2004), diversos formatos ou templates de padrões estão disponíveis na

literatura, entre os mais citados encontra-se o formato de padrão proposto por Coplien (1994) que

reflete os elementos básicos encontrados no formato de Alexander, os quais correspondem: nome

do padrão, contexto, problema, forças, solução, racionalização e resultante de contexto. O Quadro 1

exemplifica mais alguns dos formatos de padrões encontrados na literatura quanto à estrutura.

42

Quadro 1 - Estrutura de alguns padrões localizados na literatura. (HAGGE; LAPPE, 2005)

(MESZAROS; DOBLE, 1996)

(ALEXANDER et al., 1977 apud FREDJ; ROUDIÈS, 1999)

(TORO et al., 1999)

(MENDEZ-BONILLA et al., 2008)

Objetivo Contexto Problema Solução Áreas aplicadas Conseqüências Exemplos Experiência

Nome do padrão Problema Solução Contexto Forças

Nome Contexto Problema Solução Exemplos

Id Descrição do nome Versão Autor Fonte Propósito Descrição Dados específicos Intervalo de tempo Importância Urgência Comentários

Objetivo do padrão Descrição do padrão Parte fixa Extensão part1 Extensão part2 Parâmetros Classificação

2.3.1 Padrões de Requisitos

Normalmente, a linguagem natural é usada para fazer as especificações de requisitos, isso

porque é a única linguagem que é comum para todos os stakeholders. Porém, o uso da linguagem

natural é um problema reconhecido e o uso de uma notação mais formal muitas vezes faz o

entendimento das especificações serem impossíveis de serem entendidas (TORO et al., 1999). Neste

sentido, padrões vêm a apoiar a atividade de elicitação e escrita de requisitos de software (TORO et

al., 1999; WITHALL, 2007; MENDEZ-BONILLA et al., 2008; RENAULT et al., 2009a;

RENAULT et al., 2009b; FRANCH et al., 2010).

Franch et al. (2010) define padrões de requisitos de software como um artefato que pode ser

utilizado durante a atividade de elicitação de requisitos e, segundo Tsumaki (2004), a sua utilização

cria bons artefatos de software ou engenharia. Os padrões estabelecem boas práticas disponíveis

para engenharia de requisitos, visando à utilização do conhecimento existente que foi bem-sucedido

em diferentes tipos de processo de engenharia de requisitos para melhoria do acesso a esse

conhecimento ou experiência. Sua utilização é indicada aos profissionais de pequenas e médias

empresas, que tenham pouca ou nenhuma experiência em engenharia de requisitos (HAGGE;

LAPPE, 2006).

Segundo Withall (2007), no desenvolvimento de sistema é normal encontrar requisitos que

são de natureza similar ou que apareça com freqüência na maioria dos sistemas. A construção dos

padrões é realizada a partir da observação de requisitos similares já utilizados na construção de

43

vários projetos de software. Quando essa similaridade é identificada, um estudo pode ser realizado

para verificar se há um padrão de forma a generalizar (MENDEZ-BONILLA et al., 2008).

Segundo Hagge e Lappe (2006), padrões de engenharia de requisitos são elaborados para

encapsular as boas práticas disponíveis de engenharia de requisitos, pois os padrões oferecerem uma

base sólida de aprendizado organizacional, o que ajuda equipes com pouca ou nenhuma experiência

em engenharia de requisitos, transferindo o conhecimento para um nível prático. Além disso, para o

emprego de padrões de requisitos não se faz necessária uma adaptação ou reorganização do

processo de software (HAGGE; LAPPE, 2004a). Porém, a utilização de um método para apoiar o

uso de padrões contribui na redução do tempo na realização da atividade de elicitação de requisitos

e reduz erros durante a sua condução (RENAULT et al., 2009a; MENDEZ-BONILLA et al., 2008;

WITHALL, 2007; TORO et al., 1999). Além destes benefícios relatados pela utilização de padrões

de requisitos, alguns outros são encontrados na literatura:

facilidade na condução da atividade de elicitação e escrita dos requisitos (TORO et

al., 1999);

benefícios em outras atividades do processo de engenharia de requisitos como a

documentação e validação de requisitos (FRANCH et al., 2010);

promove a consistência entre os requisitos (WITHALL, 2007);

simplicidade e formalismo (WAHONO, 2002);

qualidade dos requisitos (TSUMAKI, 2004; MENDEZ-BONILLA et al., 2008);

flexibilidade na utilização (isso porque não é necessária a aplicação de um método na

sua globalidade) (FREDJ; ROUDIÈS, 1999).

Em contrapartida, alguns problemas também foram localizados na literatura. Tsumaki

(2004) destaca os seguintes problemas: dificuldade de busca e reuso de padrões e compreensão da

relação entre os padrões. Conforme Tsumaki (2004), é difícil encontrar um padrão adequado em

uma coleção de padrões porque um padrão pode ser efetivo para uma determinada situação e em

outra não.

44

Como possíveis soluções para os problemas relatados por Tsumaki (2004), destaca-se o

emprego de um método para aplicação do catálogo de padrões como solução para localização mais

“fácil” dos padrões (RENAULT et al., 2009a). A sinalização de dependência entre os padrões

também ajuda a determinar a ordem de aplicação (RENAULT et al., 2009b). Já Withall (2007),

destaca que um catálogo de padrões promove a consistência entre os requisitos. O emprego de

templates ajuda na escrita e descrição dos padrões (TORO et al., 1999). Outra orientação quanto a

padrões é feita por Mendez-Bonilla et al. (2008), que sugere uma classificação dos padrões para

uma seleção mais fácil. Por sua vez, Hagge et al. (2005) contribuem em afirmar que um repositório

de padrões permite a filtragem de padrões para engenharia de requisitos para serem utilizados em

condições e situações específicas do projeto.

2.4 PADRÕES DE REQUISITOS PARA ESCRITA DE REQUISITOS DE SOFTWARE

Padrões de requisitos propõem soluções genéricas e reutilizáveis para escrita de requisitos

(FRANCH et al., 2010; WITHALL, 2007; WAHONO, 2002; TORO et al., 1999; FREDJ;

ROUDIÈS, 1999), ou para problemas recorrentes na engenharia de requisitos (HAGGE; LAPPE,

2004a). A partir daqui, padrões de requisito serão referenciados a padrões que objetivam a criação

de especificações de requisitos, para adequação ao contexto deste trabalho. Sendo assim, padrões de

requisitos fornecem orientações de como escrever os requisitos, sugerindo informações, ajudando

com alertas e sugestões que devem ser consideradas. Também ajuda a poupar tempo, por não ser

necessária a escrita do requisito a partir do zero, fornecendo um ponto de partida, uma estrutura

para sua construção. Outro fato é de que sua utilização normalmente aumenta a qualidade no

processo de desenvolvimento de software (WITHALL, 2007). E é vista pela comunidade como a

abordagem que mais dá apoio a reutilização diante das demais (FRANCH et al., 2010). O

levantamento do estado da arte referente a padrões de requisito foi realizado através de um

mapeamento sistemático utilizando-se das orientações feitas por Kitchenham et al., (2007) e

Brereton et al. (2007), cujo detalhamento encontra-se no Apêndice A.

As subseções seguintes tratam da discussão dos dados extraídos dos estudos selecionados na

condução deste mapeamento sistemático. Utilizando-se de um mapeamento sistemático foi possível

documentar e conhecer, de maneira imparcial, o estado da arte de métodos e técnicas na Engenharia

de Requisitos que utilizam de padrões para escrita de requisitos. Neste mapeamento sistemático da

45

literatura, foi possível a localização de seis estudos os quais vieram a contribuir para responder a

seguinte pergunta de pesquisa: Quais os padrões para a escrita de requisitos de software? Os

principais resultados obtidos foi quanto à identificação de padrões para escritas de requisitos de

sistemas, templates para formalização da estrutura dos padrões e classificações para agrupamentos

dos padrões em catálogos.

2.4.1 Abordagem de Toro et al. (1999)

No estudo de Toro et al. (1999), são apresentados templates de requisitos que podem

melhorar a atividade de elicitação dos requisitos e de sua expressão. Para isso, o autor descreve dois

tipos de padrões: padrão lingüístico, que se refere às frases que são normalmente utilizadas nas

descrições dos requisitos em linguagem natural, as quais os autores realizaram parametrização e

integração em um template; o outro tipo é o padrão de requisitos, estes são templates de requisitos

genéricos que podem ser reutilizados com algumas adaptações durante a atividade de elicitação de

requisitos.

Segundo Toro et al. (1999), a utilização de templates de requisitos e padrões ajudam na

atividade de elicitação e expressão dos requisitos de sistema, isso porque estes estruturam as

informações dos requisitos de uma forma fixa. Com isso, o analista é auxiliado a encontrar as

informações que faltam para preencher os requisitos, os quais podem ser facilmente tratados por

uma ferramenta computacional, promovendo a sua reutilização. Como resultado, é afirmado pelos

autores, que o preenchimento dos espaços em branco dos formulários dos templates facilita e agiliza

a atividade de elicitação de requisitos, sendo que a reutilização dos templates pode ser feita diversas

vezes, desde que tenha sido identificado e/ou adaptado para um projeto específico. Segundo os

autores, esta abordagem já foi aplicada com sucesso em mais de 40 práticas acadêmicas e em dois

projetos reais. Na sua prática em projetos reais, uma das organizações obteve melhorias da

comunicação com os stakeholders. Um exemplo da utilização de um dos templates é ilustrado na

Figura 1, que trata da especificação de um requisito não funcional.

46

RNF-3 Sistema Operacional Versão 1.0 (Jan, 15, 1999) Autor: A. Durán (University of Seville) Fonte: M. Toro (Super Video Shop) Descrição: O sistema deve funcionar no âmbito do Sistema Operacional Linux Importância: Vital Urgência: Imediatamente Comentários: Verifique diferentes versões de Linux compatíveis

Figura 1 - Exemplo de padrão de requisitos apresentado em Toro et al. (1999).

2.4.2 Abordagem de Withall (2007)

No estudo de Withall (2007), são apresentados trinta e sete padrões de requisitos que foram

organizados em oito domínios, conforme ilustrado na Figura 3. Os domínios classificados por

Withall (2007) possuem padrões que objetivam atender as funcionalidades de seu domínio em

específico, porém, alguns padrões poderão compartilhar e integrar informação conforme pode ser

visto com a sinalização de setas entre alguns padrões na Figura 3. Segundo Withall (2007), juntos

podem representar mais da metade de um conjunto de especificação típicas de requisitos de um

sistema comercial. Segundo o autor, o emprego de padrões de requisitos fornece orientações sobre

como fazer a especificação (escrita) dos tipos mais comuns de requisitos, tornando a tarefa de

escrita mais fácil e rápida de ser realizada e melhorando a qualidade desses requisitos.

Figura 2 - Catálogo de padrões de requisitos apresentado em Withall (2007).

47

Neste estudo, Withall (2007) introduz a noção de padrões de requisitos para a escrita de

requisitos, esse esforço extra, permite especificar os requisitos de uma forma mais consistente, e

permite descrever como cada requisito deve ser usado ou definido. Segundo Withall (2007), os

padrões de requisitos fornecem orientações de como escrever os requisitos, sugerindo informações,

ajudando com alertas e sugestões que devem ser consideradas. Também ajuda a poupar tempo, por

não ser necessária a escrita dos requisitos a partir do zero, fornecendo um ponto de partida, uma

estrutura para sua construção. Padrões de requisitos também são vistos como um fator de qualidade

no processo de desenvolvimento de software.

Os padrões que compõem o catálogo de Withall (2007) foram identificados a partir de estudo

da vida real. No estudo apresentado pelo autor, mais de 400 exemplos de escrita de requisitos são

apresentados. Segundo o autor, muitos podem ser aplicados sem nenhuma alteração a quaisquer

sistema, e os demais servem de ponto de partida para que possa ser adequada a necessidade dos

usuários.

Um exemplo que demonstra a utilização poderia ser a especificação de um requisito de

software que trate o processo para o registro de usuário, sendo necessário informar o nome do

usuário, endereço de e-mail, data de nascimento, número do documento de identificação, endereço e

senha de acesso. O padrão de requisito a ser utilizado para a especificação deste requisito é

chamado de “Registro de Usuário”, conforme ilustrado na Figura 3.

Padrão de requisito Registro de Usuário Detalhes básicos: Padrões relacionados: autenticação de usuário, autorização de usuário, estrutura de dados. Frequência antecipada: um ou dois requisitos. Classificação do requisito: funcional: sim; afeta banco de dados: sim. Aplicabilidade: Use o padrão de requisitos “registro de usuário” para especificar como os novos usuários são registrados (criados no sistema), com ênfase em capturar os detalhes através do qual um usuário pode depois ser autenticado (log-in). Discussão: Usuários são especiais. Eles são pessoas e dirigem a maior parte do que acontece em um típico sistema comercial, por isso é fundamental saber o grau de confiança que cada usuário será enquadrado. O registro do usuário, então, é mais importante do que outra atividade de manutenção de dados. O principal objetivo do registro de usuário é gravar informação suficiente para facilitar a autenticação (log-in). Templates:

Resumo Definição Auto-registro <<classe usuário>> Uma pessoa deve ser capaz de se registrar como um

<<classe usuário>>, por <<descrição do processo de registro>>. Devem ser solicitados os seguintes dados pessoais:

<<detalhe do usuário 1>> <<detalhe do usuário 2>>

48

... Registro de <<classe usuário>> Será possível registrar uma pessoa como um <<classe

usuário>>, por <<descrição do processo de registro>>. As seguintes informações devem ser inscritas sobre eles:

<<detalhe do usuário 1>> <<detalhe do usuário 2>>

... Exemplos:

Resumo Definição Registro de Cliente Será possível registrar uma pessoa como um Cliente,

através do web site. As seguintes informações devem ser inscritas sobre eles:

id de usuário; senha (a ser digitada duas vezes) nome; endereço; endereço de e-mail; telefone de contato; data de nascimento; preferências de linguagem;

Requisitos extras: Um requisito de registro de usuário pode ser acompanhado por vários tipos de obrigações, a maioria das quais relacionadas com a proteção permanente e manutenção das informações inicialmente fornecidas no momento da inscrição do usuário. Considere o seguinte:

1. Formato da senha: que critérios devem satisfazer uma senha para ser aceitável? 1. Alteração da senha: como e quando? 2. Registro de usuário: os usuários podem ser criados, também deve ser possível removê-los? 3. Proteção dos dados do usuário: como podemos proteger as informações pessoais e privadas das pessoas?

Existem leis de proteção de dados que devemos respeitar? 4. Boas práticas de segurança: existem passos para incentivar a proteção das informações do usuário? Existem

práticas especialmente ruins que queremos evitar? 5. Processos especiais para novos usuários: há mais a ser dito sobre o processo de registro do usuário? Existem

situações que surgem como novos usuários (por exemplo, como informar sua senha inicial)? 6. Acesso inicial: quem vai ser capaz de usar o sistema quando é instalado pela primeira vez?

Considerações para desenvolvimento: A gama de temas abordados neste padrão de requisitos torna claro que há muito em que pensar. O melhor conselho é simplesmente levar a sério o registro de usuário. Recomenda-se cuidado ao manipular dados com valores secretos, como a senha de usuário. Considerações para teste: A função de registro de usuário é basicamente uma função de entrada de dados e deve ser testado como tal. Teste a entrada e validação de todos os valores. Teste se a validação não é realizada apenas em dispositivos não confiáveis, a citar o computador de um usuário remoto. Teste se os valores considerados secretos são tratados de forma adequada e não são exibidos pelo sistema em relatórios e consultas. Testes de que um processo de registro de usuário é seguro não podem ser feitos exclusivamente por meio do sistema, é uma atividade especializada (como discutido no padrão de exigência de autenticação do usuário).

Figura 3 - Padrão de requisito Registro de Usuário (WITHALL, 2007).

Para efeito de simplificação alguns elementos guias do padrão foram retirados do exemplo

ilustrado na Figura 3, estes elementos são: conteúdo (expressa informações sobre os elementos que

deverão ser adaptados no template do padrão), exemplo de escrita dos requisitos extras (trata de

ilustrar exemplos para cada requisito extra identificado ao padrão).

49

A partir da análise do padrão selecionado, alguns outros requisitos podem ser sugeridos com

possibilidades de reuso. Estes requisitos podem ser oriundos do relacionamento dos padrões, como

por exemplo: requisitos que descrevam o processo de autenticação de usuário, requisitos que

descrevam o controle de acesso, e requisitos que descrevam a estrutura de dados. Outra forma de

reuso proporcionado pelo padrão é referente os requisitos sugeridos como “requisitos extras ao

padrão”, como por exemplo: formato da senha do cliente, mudança de senha, expiração da senha do

usuário, bloqueio de usuário inativo, entre outros.

2.4.3 Abordagem de Franch et al. (2010), Renault et al. (2009a), Renault et al. (2009b) e Mendez-Bonilla et al. (2008)

Nos estudos realizados pelo grupo, é apresentada uma versão inicial do catálogo de padrão de

requisitos em Mendez-Bonilla et al. (2008), a sua evolução e a apresentação do método de sua

utilização intitulado PABRE em Renault et al. (2009a) e Renault et al. (2009b). Já no estudo

descrito em Franch et al. (2010), consta a apresentação de um metamodelo para padrões de

requisitos de software que é composto de três conceitos: 1) a estrutura de um padrão de requisitos

de software; 2) o relacionamento entre esses padrões; e 3) a classificação para agrupá-los.

De forma geral, os estudos apresentam uma proposta de haver padrões de requisitos que

poderiam ser aplicados em diferentes projetos, a intenção é obter a especificação de requisitos mais

unificada, padronizada e útil. O catálogo de padrões de requisitos dos autores é endereçado a

requisitos do tipo não funcionais e não técnicos, pois segundo os autores, padrões de requisitos para

escrita de requisitos funcionais seriam mais adequados para uso em projetos de domínio específico,

já padrões de requisitos para escrita de requisitos não funcionais e não técnicos poderiam ser

adequados mais facilmente a quase todos os tipos de domínio de aplicação.

A construção dos padrões é realizada a partir da observação de requisitos similares já

utilizados na construção de vários projetos de software. Quando essa similaridade é identificada, os

autores realizam um estudo para verificar se há um padrão de forma a generalizar. O objetivo é a

geração de um catálogo de padrões de requisitos, então, após a identificação de um padrão o mesmo

é adicionado a esse catálogo. Para organizar os padrões em um catálogo, os autores utilizaram a

norma ISO/IEC 9126-1. Segundo os autores, uma classificação ajuda os analistas a localizarem

mais facilmente um padrão para o seu uso. O catálogo é proposto de forma aberta, evoluindo a

partir de experiências adquiridas em novos projetos. Em um ciclo de vida dos padrões, os novos

50

padrões serão adicionados a partir de novas necessidades e desejos dos stakeholders e estes serão

avaliados a cada utilização do catálogo. Neste estudo, também é apresentada a estrutura para escrita

dos padrões identificados pelos autores. O Quadro 2 mostra um exemplo de sua utilização, bem

como ilustra a estrutura de padrões de requisitos desenvolvida pelos autores.

Quadro 2 - Um exemplo de padrões de requisitos apresentado em Mendez-Bonilla et al. (2008). Padrão de requisito Alerta de falha

Objetivo satisfazer as necessidades dos clientes de ter um sistema que forneça alertas quando ocorrem falhas de sistema Formulário de Requisito Alertas heterogêneos de falha

Parte Fixa Template O sistema deve provocar diferentes tipos de alertas,

dependendo do tipo de falha Restrição da parte estendida

multiciplicidade(Alertas para os tipos de falhas) = 0..*

Parte estendida

Template O sistema deve gerar alertas %alertas% em caso de %falhas% falhas

Parâmetro Métrica

Alertas: conjunto não vazio de tipos de alerta

Alertas: Set(TiposdeAlertas) TiposdeAlertas: Domínio dos possíveis tipos de alertas

Falhas: conjunto não vazio de tipos de falhas

Falhas: Set(TiposdeFalhas) TiposdeFalhas: Domínio dos possíveis tipos de falhas

Formulário de Requisito Alertas homogêneo de falha

Parte Fixa Template O sistema deve acionar um alerta em caso de falha. Restrição da parte estendida

multiciplicidade (TiposdeAlertas) = 0..1 emulticiplicidade (TiposdeFalhas) = 0..1

Parte estendida Tipos de Alerta

Template A solução deve disparar alertas %alertas% em caso de falha

Parâmetro Métrica

Alertas: conjunto não vazio de tipos de alerta

Alertas: Set(TiposdeAlertas) TiposdeAlertas: Domínio dos possíveis tipos de alertas

Parte estendida Tipos de falhas

Templates O sistema deve gerar alertas em caso de %falhas% falhas

Parâmetro

Falhas: conjunto não vazio de tipos de falhas

Falhas: Set(TiposdeFalhas) TiposdeFalhas: Domínio dos possíveis tipos de falhas

No processo PABRE, descrito pelos autores, os padrões são selecionados em um catálogo e

convertidos para as necessidades reais que irão compor o documento de especificação de requisitos

do projeto. Segundo os autores, o método objetiva facilitar a atividade de elicitação de requisitos

utilizando uma proposta de padrões de requisitos.

2.4.4 Comparativo entre as abordagens

Os trabalhos apresentados diferem em suas abordagens. Assim, alguns aspectos foram

estabelecidos para permitir a comparação entre os padrões:

51

Templates para escrita de requisitos: observa se o estudo apresenta um (ou mais)

template para orientar a escrita do padrão e analisa qual o escopo do template, se está

limitado a escrita do requisito ou contempla também outros dados para

gerenciamento dos requisitos.

Base para o padrão: descreve o método (origem) utilizado para obter o padrão

proposto.

Relacionamento entre os padrões: um padrão pode se referir a outros padrões por

diversas razões, assim, este aspecto observa se o padrão proposto é composto ou se

prevê relacionamento entre diferentes padrões.

Categorias de padrões: uma classificação dos padrões em categorias permite

demonstrar um pouco sobre a natureza do requisito que se pretende obter com a

utilização do padrão de requisito, além de ser uma forma de facilitar a seleção dos

padrões de requisitos adequados ao seu objetivo. Assim, este aspecto observa se o

estudo propõe/envolve algum tipo de catálogo ou categorização para os padrões

propostos.

Existência de metamodelos: Um metamodelo é um modelo para modelos

(AMATRIAIN, 2004 p.36) podendo ajudar a entender conceitos sobre os padrões de

requisitos de software ou orientar a estruturação de novos padrões. Portanto, este

aspecto analisa se o estudo propõe um metamodelo de seu(s) padrão(ões).

Ferramenta: a utilização de padrões de escrita de requisitos pode ser facilitada a

partir da utilização de uma ferramenta, portanto, este aspecto analisa se o padrão

proposto foi incorporado em alguma ferramenta computacional.

Aplicação do padrão: observa as evidências de aplicação dos padrões em projetos

de software.

O Quadro 3 mostra um comparativo das características entre os trabalhos selecionados neste

mapeamento sistemático.

52

Quadro 3 - Comparativo entre os estudos encontrados. Toro et al. (1999) Withall (2007) Franch et al. (2010) Template Sim (Figura 1)

Engloba além do padrão de redação do requisito, campos para gerenciamento dos requisitos.

Sim O padrão é descrito a partir da definição de 9 campos. Os templates apresentados compreendem apenas a redação do requisito, sem prever informações complementares.

Sim (Quadro 2) O template envolve apenas a escrita do requisito, sem prever campos para informações complementares.

Base para construção do padrão

Padrões propostos a partir da análise de 2 outros estudos (de outros autores).

Padrões identificados a partir do estudo das necessidades em projetos reais.

Padrões generalizados a partir da análise de 7 documentos de especificação de requisitos de projetos finalizados (Média de 70 requisitos não funcionais em cada documento).

Relacionamento entre padrões

Não aborda. Aborda (conforme Figura 2). Aborda, mas não explicitamente.

Categorias de padrões

- Requisitos funcionais (CRUD). - Requisitos não funcionais (sem determinar categorias).

- Requisitos funcionais - Requisitos não funcionais (com padrões por categorias, conforme Figura 2)

- Requisitos não funcionais (extensão da ISO/IEC 9126-1).

Metamodelo Não apresenta Não apresenta Apresenta Ferramenta Há um protótipo descrito em

Toro et al. (1999). Há uma ferramenta descrita no website do autor.4

O desenvolvimento de uma ferramenta é proposto como passo futuro.

Aplicação Mais de 40 projetos acadêmicos e em 2 projetos reais.

Apresenta exemplos de mais de 400 requisitos empregando os padrões.

Validação em 2 projetos reais.

Diante do exposto, percebe-se que padrões de requisitos de software são artefatos que

podem ser utilizados durante a atividade de elicitação de requisitos, no qual a literatura afirma que

trazem um possível impacto positivo na atividade de elicitação, documentação e análise dos

requisitos. Sua utilização é confirmada como uma dos principais métodos de apoio para uma

abordagem de reuso de requisitos (FRANCH et al., 2010; WITHALL, 2007; WAHONO, 2002;

TORO et al., 1999; FREDJ; ROUDIÈS, 1999). Neste sentido, a reutilização é realizada a partir

padrões de requisitos, que são modelos genéricos de requisitos, nos quais são encontrados diversas

vezes durante a atividade de elicitação de requisitos, e que são reutilizados com ou sem nenhuma

adaptação (TORO et al., 1999; WITHALL, 2007; FRANCH et al., 2010).

4 http://www.withallyourequire.com/reqtssoftware.html

53

2.5 CONSIDERAÇÕES SOBRE O CAPÍTULO

Neste Capítulo, foram abordados aspectos gerais de engenharia de requisitos, bem como seu

processo e atividades. Foram abordados também os principais aspectos sobre a prática da atividade

de rastreabilidade e a descrição dos aspectos que envolvem o documento de especificação de

requisitos. Foram apresentados os conceitos de reuso de requisitos, padrões de requisitos e algumas

técnicas para elicitação de requisitos. Além disso, foram abordados os esforços na utilização de

padrões de requisitos e algumas ferramentas existentes para o reuso de especificações de requisitos.

Com o término deste capítulo, se encerra o embasamento teórico necessário para a

compreensão da abordagem proposta. O Capítulo a seguir, aborda o “estado da arte” sobre métodos

de reuso de requisitos.

54

3 ESTADO DA ARTE

Este capítulo tem a finalidade de apresentar o estado da arte sobre reuso de requisitos de

software. Para tanto, utilizou-se de uma revisão sistemática da literatura como instrumento de

localização dos trabalhos selecionados para compor este capítulo. Todos os passos da execução e

benefícios que uma revisão sistemática ou mapeamento sistemático tende a oferecer estão descritos

nas seções iniciais do Apêndice A.

Segundo Brereton et al. (2006), um crescente número de estudos empíricos estão sendo

realizados com uma maior freqüência em engenharia de software, devido a isso, é necessário a

adoção de uma abordagem sistemática para se conseguir apresentar uma síntese equilibrada e

objetiva de evidência de pesquisas para um determinado tópico. O uso de uma revisão sistemática é

mais indicado que uma revisão informal, isso porque, uma revisão informal é caracterizada por ter

pouca abrangência, não é passível de repetição, pouco confiável e dependente dos revisores

(MAFRA; TRAVASSOS, 2006, p.10).

Neste sentido, como primeiro passo buscou-se trabalhos de revisões já executadas por outros

pesquisadores. A busca por trabalhos de revisão sistemática na web (fonte: Google) foi realizada

utilizando os termos “revisão sistemática” and “reuso” em português e “systematic review” and

“reuse” em inglês. Como resultado na busca pelos termos na língua portuguesa nenhum estudo foi

encontrado, no entanto, na busca utilizando os termos na língua inglesa dois estudos foram

localizados. Os estudos localizados foram os de Jamwal (2010) e Konda e Mandava (2010).

O estudo de Jamwal (2010) foi descartado por não apresentar pesquisas que abordem reuso

de requisitos, na revisão o autor objetiva explicar os benefícios do reuso de software, os problemas

de reutilização, descrever os tipos de componentes reutilizáveis, processos para reutilização e

desafios e problemas durante a reutilização de software. Já o trabalho de Konda e Mandava (2010),

apresenta o estado da arte de reuso de software no geral, mas com subsídios suficientes para atender

ao propósito deste capítulo - apresentar as pesquisas focadas no reuso de requisitos. Desta forma, a

partir da análise do trabalho de Konda e Mandava (2010), foram selecionados os trabalhos

correlatos apresentados neste capítulo. O Apêndice B apresenta o processo seguido no trabalho de

Konda e Mandava (2010). Na Seção 3.1 são descritos os critérios para seleção dos trabalhos para

compor a seção 3.2 com o detalhamento dos estudos selecionados.

55

3.1 CRITÉRIOS PARA SELEÇÃO DOS ESTUDOS

Como ponto de corte para selecionar os estudos denominados de “trabalhos relacionados”

foram utilizados os seguintes critérios sobre os estudos localizados na revisão sistemática de Konda

e Mandava (2010) que abordam reuso de requisitos de software:

1. Estudos que apresentem informações suficientes para reproduzir/aplicar a

abordagem, e/ou;

2. Estudos que apresentem alguma forma de avaliação da abordagem.

Utilizando-se destes critérios 9 estudos foram selecionados, sendo que os estudos de

Antonellis e Vandoni (1993), Lam (1997), Gotzhein et al. (1998), Monzon (2008) e Perednikas

(2008) satisfazem ao critério 1. E que os estudos de Keepence et al. (1995), Montabert et al. (2005)

e Moon et al. (2005) satisfazem ao critério 2 e o estudo de Montabert et al., (2009) enquadra-se nos

dois critérios. No entanto, foi descartado o trabalho de Antonellis e Vandoni (1993), mesmo sendo

um trabalho de interesse para composição deste capítulo, pois o autor desta dissertação não obteve

acesso a base de dados na qual se encontra o estudo e não houve um retorno do contato realizado

com os autores do trabalho.

3.2 TRABALHOS RELACIONADOS

Esta seção apresenta os trabalhos relacionados a técnicas ou métodos que apóiam o reuso de

requisitos de software de uma maneira geral, selecionados após análise em uma recente publicação

da revisão sistemática da literatura sobre reuso de software de Konda e Mandava (2010).

3.2.1 SMARTRe Requisitos: Escrevendo requisitos reutilizáveis (KEEPENCE et al., 1995)

Neste estudo, os autores descrevem um guia para ajudar a maximizar o nível de reuso de

requisitos. Este guia consiste em passos como categorização dos requisitos em não reusáveis,

diretamente reusáveis ou baseado em parâmetros. Como passo seguinte, os autores indicam uma

posterior análise nos requisitos não reutilizáveis, a fim de remover referências específicas e

uniformização dos termos, e a divisão de especificações genéricas em mais específicas. O estudo foi

avaliado com um estudo de caso que verificou os requisitos em dois projetos na especificação de

56

um sistema de planejamento de missões para uma missão científica. Como resultado, os autores

relatam que o estudo de caso revelou que os ganhos com a reutilização são significativos e

justificam o esforço adicional para aumentar os níveis de reutilização atual.

3.2.2 Uma abordagem de especificação de domínio de aeronáutica necessária para alcançar a reutilização (LAM, 1997)

Este estudo descreve o esforço feito para promover a reutilização de especificações de

requisitos na indústria aeronáutica. A abordagem consiste em duas fases principais: análise de

domínio e engenharia de domínio.

Na fase de análise de domínio (fase em que se faz a identificação de artefatos reutilizáveis

no domínio), o autor utilizou um método de análise de domínio já existente o ODM (STARS,

1995), com algumas adaptações para ser utilizado com o foco na reutilização de requisitos. Nesta

fase os autores executam as seguintes atividades para o entendimento do domínio:

a) definição das fronteiras do domínio;

b) abstração a partir de exemplos e identificação de questões fundamentais sobre o

domínio;

c) fundamentação dos requisitos; e

d) combinação do conhecimento em um quadro coerente.

Ainda nesta etapa os autores executam mais algumas atividades de modo a reconhecer e

capturar o conhecimento de requisitos reutilizável a partir do domínio. Essas atividades são:

a) formulação de requisitos genéricos;

b) formulação de uma lista de fator externo e fator interno. (Uma lista de fator externo

relaciona os tipos para conhecimento para fora de um fator de uma formulação de

requisitos genéricos, o inverso é considerado para fator interno);

c) escolha de um conjunto de requisitos;

57

d) antecipar mudança e seu impacto sobre os requisitos (estratégia usada para evitar

suposições explícitas sobre a tecnologia, isso para garantir que todos os requisitos

genéricos gerados pelo engenheiro de software irão ser válidos para todos os típicos

sistemas de partida atuais e futuros);

e) uso sensato com julgamento de como lidar com o resultado de uma abstração de

requisito;

f) saída da análise de domínio; e

g) resumo do exercício de análise de domínio.

A partir deste ponto o autor discute como trabalhar na fase de engenharia de domínio. Para

apoiar esta fase é apresentada uma ferramenta chamada COMPASS. A ferramenta automatiza as

atividades de preenchimento dos requisitos genéricos. O objetivo desta ferramenta é construir

requisitos recuperados de uma biblioteca de requisitos genéricos reusáveis, os quais possam ser

instanciados com as informações fornecidas nos formulários, e colocados em uma biblioteca do

projeto. A ferramenta foi avaliada como um framework para avaliação de kit de especificação de

domínio, e também passou por uma avaliação pelo ponto de vista dos engenheiros.

3.2.3 Reutilização em engenharia de requisitos: descoberta e aplicação de um padrão de requisito em tempo real (GOTZHEIN et al., 1998)

Este trabalho trata de uma abordagem de reutilização de especificação de requisitos de

sistema formal com base em padrões de requisitos. O objetivo da abordagem é de produzir um

documento de especificação de requisitos formal derivado de descrição em linguagem natural. Este

trabalho é baseado em um pool de padrões de requisitos e em especificação de requisitos de usuário

em linguagem natural. Para descrever os padrões de requisitos os autores utilizam um template

composto por nome do padrão, intenção do padrão, definição e propriedades semânticas, esse

modelo é apresentado na Tabela 3.

58

Tabela 3 - Modelo de descrição do padrão de requisito.

Nome Nome do padrão de requisito. Intenção Uma descrição informal do tipo de requisito dirigido por esse padrão. Exemplo Um exemplo para a o domínio da aplicação ilustra o propósito para o

padrão de requisito. Definição O padrão é descrito tanto formalmente, através de uma técnica formal

de descrição adequada, e em linguagem natural. A descrição formal é a base para as etapas posteriores de desenvolvimento, finalmente conduzindo à especificação de requisitos (seleção do padrão, adaptação e composição). A descrição em linguagem natural servirá a tradução de padrões instanciados da especificação formal de requisitos em requisitos informal de linguagem natural de especificação de requisitos. Além disso, a descrição fornece algumas informações sobre possíveis instâncias.

Propriedades semânticas Propriedades que tenham sido formalmente comprovadas a partir do padrão. Ao instanciar essas propriedades da mesma forma como o padrão de requisitos, as provas também podem ser reutilizadas.

A utilização da abordagem consiste no seguimento de três passos:

Primeiro passo: Padrões de requisitos são selecionados de um pool de padrões a partir de

informações fornecidas pelo modelo (ver Tabela 3), como definição, intenção e propriedades

semânticas.

Segundo passo: Os padrões selecionados são adaptados pela instanciação adequada. O

mesmo tipo de adaptação é aplicado às propriedades semânticas. Neste passo é possível formalizar

a razão sobre os requisitos individualmente.

Terceiro passo: Os padrões são compostos para produzir a especificação de requisitos. A

composição pode ser suportada pelos operadores adequados.

Uma observação feita por Gotzhein et al. (1998), diz que o grau de reutilização irá depender

da especificação de requisitos de usuário em linguagem natural e do conteúdo do pool de padrões,

isso porque, o conjunto de padrões de requisitos deve evoluir com o passar do tempo, fazendo com

que reduza o esforço na especificação de requisitos.

No trabalho de Gotzhein et al. (1998) é apresentado um exemplo de uma especificação

formal de um controlador de temperatura, esse exemplo é ilustrado na Tabela 4. Mais detalhes sobre

a simbologia utilizada no exemplo pode ser obtido em Gotzhein et al. (1998).

59

Tabela 4 - Exemplo da utilização da abordagem de Gotzhein et al., (1998).

Nome LazyReaction(p, q, T1, T2, T3) Intenção Aplicável se uma reação não é imediata, mas contém algum atraso. Exemplo

A sala está em uso (romUsed) se uma das condições for verdadeira:

Durante as últimas unidades de tempo T1, uma pessoa tenha ficado continuamente na sala.

Já houve um intervalo de tempo de comprimento T1 + T2 tal que uma pessoa tem ficado continuamente na sala, e uma vez que este tem sido o caso para a última hora, os períodos enquanto a sala estava vazia não era maior ou igual a T3.

Definição O predicado p é válido se uma das seguintes afirmações for verdadeira:

Durante as últimas unidades de tempo T1, q tem sido continuamente verdadeiro;

Já houve um intervalo de tempo de comprimento T1 + T2 tal que q tenha ficado continuamente na sala, e desde que este tenha sido o último caso ocorrido, os períodos enquanto q era falso e que não era maior ou igual a T3.

Propriedades semânticas

No entanto, nessa abordagem, nenhuma forma de avaliação ou ferramenta para sua

automatização ou apoio foi apresentada para este trabalho.

3.2.4 Suporte a reutilização de requisitos em design de sistema de notificação através da tarefa de modelagem (MONTABERT et al., 2005) e Uma abordagem integrativa para a análise de requisitos: Como modelos de tarefas dão suporte ao reuso em um framework de modelagem centrado no usuário (MONTABERT et al., 2009)

O trabalho de Montabert et al. (2005) apresenta um processo e instanciação de análise

hierárquica de tarefa, para ajudar os projetistas a identificar os aspectos mais importantes com o

foco na modelagem, e para apoiar a reutilização de conhecimento entre projetos. Neste sentido, os

60

autores utilizam reivindicações5 (do inglês claims) para integrar requisito dentro de modelos de

análise hierárquica de tarefa, com isso criando um modelo de tarefa para visualização de requisitos

que contém os requisitos de sistemas. Para isso, os autores apresentam uma ferramenta para

desenvolvimento dos requisitos baseado em LINK-UP6, o qual foi avaliado por um estudo de

usabilidade.

Os principais atributos da abordagem de análise de requisitos é uma forte dependência do

envolvimento do usuário, desambiguação, validação de requisitos através de uma estrutura,

formalismo e reutilização extensiva do conhecimento. Esta abordagem é apoiada por uma

ferramenta computacional baseado em LINK-UP, mas antes da sua utilização é necessário a

condução de investigações preliminares as quais são necessárias para estabelecer um conceito raiz,

também se faz necessário um estudo prévio das práticas de trabalhos em seu ambiente natural. A

Figura 4 ilustra os passos de execução da abordagem na ferramenta, esses passos consistem em:

Primeiro passo é estabelecer o cenário do problema. Esse cenário é estabelecido a

partir de estudos das práticas atuais dos usuários dentro do domínio do problema.

Segundo passo é estabelecer o cenário de atividade. Aqui o projetista descreve os

usuários e a sua interação com o sistema previsto.

Terceiro passo permite a criação do sistema de nível de valor de IRC (interruption,

reaction, and comprehension) para o modelo de design. Neste passo a ferramenta

apresenta uma interface que ajuda ao projetista obter estimativas precisas para o

valor de IRC. Essa interface funciona como um assistente que solicita resposta

para perguntas sobre comportamento de notificações do sistema, expectativas de

um típico usuário e benefícios resultantes da notificação, ou se o projetista quiser

pode-se informar os IRC manualmente. 5 Reivindicações tratam de uma declaração que descreve uma característica do projeto com seus benefícios e pontos fracos associados. A implementação de uma biblioteca de reivindicações facilita um processo de reutilização, isso porque, captura o conhecimento reutilizável de design em design baseado em cenários (MONTABERT et al., 2005). 6 LINK-UP (Leveraging Integrated Notification Knowledge through Usability Parameters) da tradução literal “aproveitamento do conhecimento de notificação integrada através de parâmetros de usabilidade”, consiste em uma suite de design baseado na Web para permitir um melhor apoio na concepção dos sistemas de notificação, promovendo a reutilização de conhecimento de modelagem centrada no usuário por meio de um framework de modelagem (MONTABERT, 2006 p.31).

61

Quarto passo é um módulo do sistema no qual todos os modelos de tarefa estão

disponíveis para seleção do projetista. A seleção é feita de forma a melhor

representar a desagregação dos componentes do sistema de nível de IRC por

estágio de ação da interação de notificação para o sistema alvo. Alternativa nesse

passo é a criação de um novo modelo de tarefa, quando dada à inexistência de um

modelo que contemple o novo sistema. Aqui o sistema irá exibir todas as

subtarefas genéricas aplicáveis para cada fase da ação, os fatores psicológicos

intervindo nas equações de IRC são estimados utilizando uma escala de cinco

pontos, e com base nesses fatores associados com cada etapa da ação, a ferramenta

calcula os valores do nível SOA (stage-of-action-level) do IRC para o modelo.

Neste ponto o novo modelo pode ser incorporado ao repositório de conhecimento e

pode ser reutilizado.

O quinto passo procede logo após a seleção de um modelo de tarefa generalizado.

Neste passo o sistema permite aos projetistas indicar o nível da subtarefa de seu

modelo de tarefas. Então o projetista seleciona as tarefas genéricas disponíveis que

são aplicáveis e introduz em um cenário que descreve a relação subtarefa com os

usuários em sua tarefa principal. Após a seleção, a ferramenta gera para cada fase

de ação do nível recomendado os valores de SOA IRC que caracterizam o objetivo

de cada subtarefa.

No sexto e último passo o sistema apresenta ao projetista recomendação de

reivindicações associadas a um modelo de tarefa reutilizada. Aqui o projetista pode

procurar por outra reivindicação adicional relevante, e associar reivindicações para

um correspondente estágio ação, a fim de criar uma modalidade de requisitos de

notificação para o sistema alvo. Essas alterações são armazenadas em um

repositório de conhecimento para fornecer a base para a estrutura de recomendação

de reivindicações.

62

Figura 4 - Fluxograma das atividades da abordagem de Montabert et al. (2009).

A abordagem foi avaliada por dois estudos, o primeiro que examinava a viabilidade da

ferramenta, verificando se um projetista iniciante consegue desempenhar sua atividade de análise

com o apoio da ferramenta e outro estudo avaliava os benefícios atingidos com a ferramenta em

relação à atividade de especificação de requisitos. Como resultado, o autor confirma que a

capacidade de projetistas iniciantes em compreender as atividades envolvidas com o processo de

modelagem é satisfatória e que a abordagem também serve como um catalisador de reutilização.

Além desses resultados, o autor também afirma que o estudo revelou potenciais benefícios de

aprendizagem associados às práticas de engenharia de requisitos.

63

3.2.5 Uma abordagem para o desenvolvimento de requisitos de domínio como núcleo principal baseado nos pontos comuns e análise da variabilidade em uma linha de produtos (MOON et al., 2005)

Neste trabalho, os autores apresentam uma abordagem de desenvolvimento de requisitos de

domínio utilizando da uniformização e variabilidade em um domínio. Esta abordagem trata de um

método que sistematicamente desenvolve o núcleo principal de requisitos em uma análise de

domínio para aumentar o reuso no contexto de abordagens de linha de produtos. Também é

apresentada pelos autores uma ferramenta para gestão do método. Esta abordagem consiste em

quatro etapas principais:

Primeira etapa: Nesta etapa, é realizada uma definição prévia do escopo dos requisitos de

domínio. Essa especificação deve ser realizada para que os desenvolvedores possam identificar e

especificar os requisitos de domínio de uma forma coerente e precisa.

Segunda etapa: Esta etapa, consiste na identificação dos requisitos de domínio usando PRs

(Primitive Requirement7). Após acordado sobre o escopo dos requisitos de domínio, os sistemas

legados são analisados para extrair os requisitos de domínio comuns a eles. Segundos os autores, ao

considerar os requisitos comuns de sistemas legados, um conjunto de requisitos semelhantes com

variações podem ser identificados. Neste passo o conceito de PR é utilizado como uma unidade dos

requisitos identificados. A Tabela 5 ilustra uma matriz de PR-Context que é usada para

identificação e refinamento dos requisitos de domínio usando PRs, a matriz consiste de informações

de um repositório de domínio de empresas jornalísticas, sendo que todos os PRs identificados estão

listados em linhas e os sistemas construídos a partir do domínio são organizados em colunas. O

preenchimento da matriz com "O" na interseção da PRs e sistemas indica que o PR é encontrado no

sistema, já um "X" indica que o sistema não tem o PR. Segundo os autores, os PRs para um

determinado domínio podem ser identificados através da análise de requisitos funcionais para

sistemas legados em um domínio.

O refinamento da matriz de PR-Context pode ser feita através da realização de dois tipos de

generalizações:

7 Primitive Requirement é um termo definido por Moon et al. (2005) que é usado como um bloco de construção para um refinamento mais complexo de uma conjunto de semântica no qual um requisito possa ser decomposto.

64

Generalização de PR: Esse tipo de generalização verifica dois ou mais PRs com

funcionalidades semelhantes que possam ser generalizados para um PR, essa

generalização é alcançada com a abstração das diferenças na variabilidade. O

objetivo desta generalização é de se obter PR mais gerais, o que ajuda na

identificação de funcionalidades comuns entres os sistemas e aumenta a sua

reutilização. Um exemplo deste tipo de generalização é visto na Tabela 5, onde o

PR7 é comum em mais de um sistema, mais a forma de sua execução é um pouco

diferenciada, refinando-se para PR71 e PR72.

Generalização de contexto: Neste tipo de generalização dois ou mais sistemas

legados compostos por PRs podem ser generalizados em um único “contexto”,

reduzindo-se o tamanho da matriz. Na Tabela 5 esta generalização pode ser

visualizada pela coluna com o título BS1(2), na qual foram agrupadas duas

empresas, MBC e KBS, que têm o mesmo conjunto de PRs. Destaca-se que o

número 2 entre parênteses logo após o nome do novo grupo refere-se à quantidade de

sistemas generalizados por este contexto.

Tabela 5 - Matriz de PR-Context. PR CV

Propriedade / Razão

BS1(2) YTN ET Times Chosun Daily

PR1 Login C / 100% O O O O PR2 Logout C / 100% O O O O PR3 Cadastro C / 100% O O O O PR4 Modificar informações do membro C / 100% O O O O PR5 Adicionar um artigo para um scrapbook

P / 40% X X O O

PR6 Procurar por uma scrapbook P / 20% X X O X PR7 Transmitir um artigo C / 100% O O O O PR71 por e-mail O X O O PR72 por telefone celular X O O O PR8 Escrever uma opinião C / 60% O X X O ... ... ... ... ... ...

Após as generalizações é realizado o preenchimento da coluna “CV Propriedade/Razão” na

matriz (ver Tabela 5), que consiste na razão comum para cada PR. Essa razão indica o quanto o PR

é utilizado no domínio e é definido como a relação entre o número de sistemas com o PR para o

número total de sistemas relacionados na matriz. Sendo assim, esta propriedade é determinada por

sua relação de semelhança, isso denota se o PR é ou não comumente utilizado em diversos sistemas.

65

Terceira etapa: É realizado um refinamento dos requisitos de domínios com o PR. Aqui

todos os PRs são detalhados individualmente como uma forma de especificação em relação a

aspectos estruturais e comportamentais, é onde as variabilidades são explicitamente especificadas.

Nesta etapa também são identificadas e especificadas as restrições entre os requisitos de domínio,

restrições como dependência, generalização e alternativas. A Tabela 6 ilustra este refinamento, bem

como as demais especificações.

Tabela 6 - Especificação do PR1 para Cadastro. PR PR1. Cadastrar Descrição Variabilidade

Tipo Cardinalidade Variantes Comportamento PRelemento

PR1a. O sistema verifica o nome verdadeiro do cliente

Computação externa

[0..1] Serviço de verificação do nome verdadeiro

PR1b. Cliente informa MemberBasicData

PR1c. Sistema verifica por disponibilidade para dados de cliente ID e senha

PR1d. Cliente entra com dados de endereço e código postal

Computação externa

[1] Serviço de busca por entrada manual de endereço

PR1e. Cliente informa MemberSupplementaryData

dado

PR1f. Cliente paga taxa de adesão, quando ele/ela escolhe um membro carregado.

Controle [1...n] Pagamento com cartão de crédito Pagamento com cheque Pagamento com telefone celular Pagamento com certificado de presente Pagamento com cupom Pagamento com transferência bancária

Estático PRelement

MemberSupplementaryData Dados [1..n] Ocupado Renda Educação Juros

Quarta etapa: Nesta etapa, desenvolve-se um modelo de domínio denominado usecase, o

qual é construído para representar um nível maior de abstração para os requisitos de domínio. A

Tabela 7 ilustra uma matriz de PR-Usecase que é gerada nesta etapa. Segundo os autores na matriz

de PR-Usecase os casos de uso identificados inicialmente são refeitos e categorizados, visando com

este procedimento a produção e identificação de requisitos de domínio mais reutilizáveis.

66

Tabela 7 - Matriz de PR-Usecase. PR CV Propriedade /

Razão AutenticaçãoUsuário Cadastro BuscaNotícia

PR1 Login C/100% O PR2 Logout C/100% O PR3 Cadastro C/100% O PR4 Alteração dos dados de um membro C/100% O PR5 Adicionar um artigo para o scrapbook

P/40% O

PR6 Busca no scrapbook P/20% O PR7 Transmitir um artigo C/100% O PR8 Buscar uma notícia C/100% O PR9 Mostrar uma notícia C/100% O PR10 Modificar uma opinião P/42.8% O PR11 Apagar uma opinião P/42.8% O PR12 Administrar pagamentos C/100% O O

Para avaliação do estudo, os autores apresentam um estudo de caso realizado em um sistema

de web para agências de viagem. Neste estudo de caso, os autores apresentam uma ferramenta

CASE chamada de DREAM (Domain REquirements Asset Manager - Administração de ativos de

requisitos de domínio), essa ferramenta apóia tanto a fase de definição dos requisitos de domínio,

como a fase de engenharia de aplicação, nas quais os domínios de sistemas são produzidos. Como

resultado do estudo de caso, os gerentes de projeto e desenvolvedores envolvidos no projeto

afirmam que a abordagem foi muito útil para identificação e especificação dos requisitos de

sistemas, alcançando uma redução de esforço no desenvolvimento.

3.2.6 Abordagem prática para reuso de requisitos de famílias de produtos de sistemas on-board (MONZON, 2008)

Esta abordagem apresenta uma experiência adquirida na especificação de requisito dentro de

uma família de produtos em sistemas de bordo de aviões militares para missões táticas.

Antes de iniciar a descrição da abordagem proposta por Monzon (2008), faz-se necessária a

apresentação do conceito de derivação de requisitos e o de reutilização de requisitos fortes e fracos.

Segundo Monzon (2008), requisitos de derivação são aqueles requisitos que não possuem um

vínculo direto de rastreabilidade com os requisitos de um nível superior. Esse tipo de requisito deve

existir para garantir que os requisitos impostos são viáveis. A reutilização forte é aquela que em um

contexto de família de produtos os requisitos reusados são considerados a evoluir de forma

síncrona. As mudanças nesse tipo de requisito tendem a afetar todo o conjunto de projetos de

família de produtos, portanto, deve ser aprovada por todos os gerentes de projeto. A reutilização

67

fraca é aquela em que as especificações de requisitos que são copiados de outras fontes para um

novo projeto podem evoluir separadamente da fonte. A diferença entre o método de “copiar/colar” e

de reutilização fraca de requisito é que na reutilização fraca de requisitos os requisitos especificados

permanecem ligados a fontes, mesmo que ocorram mudanças separadamente.

A abordagem consiste na identificação das árvores de rastreabilidade de outros projetos

relacionados com os requisitos que serão aplicáveis a um novo requisito. Estes requisitos

identificados são marcados como “requisito pai” em uma família, e cada especificação de um novo

projeto que herdar esses requisitos serão acompanhados de onde vieram, e em casos em de

reutilização forte também manterão uma sincronização de mudança. Para sistematizar a abordagem

o autor apresenta uma ferramenta chamada de MIA. Esta ferramenta auxilia no controle das

marcações dos requisitos comuns para uma família de produtos e permitir a reutilização forte e

fraca de requisitos. A Tabela 8 mostra o nível de distribuição para a abordagem de reuso

apresentada por Monzon (2008), o qual identifica o percentual de requisitos derivados e não

derivados em combinação com os tipos de reuso.

Tabela 8 - Nível de distribuição de reuso. Reutilização forte Reutilização fraca Não reutilizável Requisitos derivados 40% 30% 30% Requisitos não derivados 20% 30% 50%

Segundo Monzon (2008), os requisitos derivados devem ser estáveis, isso porque são eles

que estão mais relacionados com a solução proposta. Por esta razão, o modelo de reuso de requisitos

proposto se preocupa em atingir um alto nível de reutilização deste tipo de requisito. Já os requisitos

não derivados terão o grau de reaproveitamento menor por depender da seleção de característica de

um produto em uma família de produto de software. A Tabela 9 ilustra a simulação do uso da

abordagem mostrando o esforço poupado e a razão de reuso. Como resultado Monzon (2008)

afirma que a utilização da abordagem de reuso em um projeto padrão dentro de uma família de

produto tende a obter uma economia global de cerca de 61% na produção de todo o conjunto de

documentos de especificação de requisitos.

68

Tabela 9 - Economia de esforço e razão de reuso. N° de

documentos Esforço Nominal

(M-M) Esforço com Reuso

(M-M) Razão de reuso

Requisitos contratuais 1 2 1,0 50% Requisitos de sistema de alto nível - Hardware

1 2 1,2 58%

Requisitos de sistema de baixo nível - Hardware

14 28 17,4 62%

Requisitos de sistema de alto nível - Software

1 2 1,2 62%

Requisitos de sistema de baixo nível - Software

14 28 17,4 62%

Total 31 62 38,1 61%

No entanto, nessa abordagem, nenhuma forma de avaliação foi apresentada para este

trabalho.

3.2.7 Reutilização de requisitos baseado nas previsões das necessidades dos usuários (PEREDNIKAS, 2008)

Esta abordagem propõe a reutilização de especificações de requisitos baseado na ideia de

previsão das necessidades do usuário. Para isso o autor descreve uma abordagem como ilustra a

Figura 5. O autor propõe um processo de reuso baseado no conhecimento factual sobre a origem

dos requisitos. Neste sentido o autor utiliza lista de tarefas, as fontes das necessidades (usuários),

restrições ambientes e ferramentas utilizadas no processo de execução dessas tarefas. Segundo

Perednikas (2008), as necessidades para fontes de requisitos estão previstos em função da

similaridade de seus estados, a qual pode ser estimada fazendo o cálculo da percentagem de

elementos correspondentes entre os conjuntos que descrevem estes estados. Na abordagem o

processo de elicitação de requisitos inicia a partir de uma seleção sistemática de um RSP

(Requirements Specifications) de uma lista de RSP previstos, já os requisitos que não puderam ser

identificados nesta etapa serão especificados usando uma abordagem tradicional.

69

Figura 5 - Generalização do processo de reuso da abordagem de Perednikas (2008).

No entanto, nessa abordagem, nenhuma ferramenta ou avaliação são apresentadas para

apoiar e validar a abordagem.

3.3 CONSIDERAÇÕES SOBRE OS TRABALHOS SIMILARES

O objetivo desta seção é reunir e comparar todos os trabalhos apresentados fazendo uma

análise sobre as principais características presentes nas abordagens buscando pontuar a contribuição

e diferencial da abordagem proposta.

Para tanto, alguns critérios de comparação foram estipulados, entendendo-se que estes

pontos resumem as principais características das abordagens analisadas:

1. quanto ao escopo de reuso: entende-se que reuso de requisitos é um tema amplo.

Assim, dentro deste tema amplo, qual é o problema específico que o estudo pretende

resolve?

70

2. quanto às características da abordagem analisada: com este critério deseja-se

identificar e classificar o tipo de método ou técnica utilizada para apoiar o reuso;

3. quanto ao apoio de algum tipo de ferramenta computacional: verifica se a

abordagem é provida do apoio de uma ferramenta computacional.

4. quanto à utilização de repositório para armazenamento do conhecimento de

requisitos de software: um repositório é uma estrutura de base de dados que

armazena a coleção de elementos para reuso, além de promover mecanismos que

permitam a recuperação eficiente desses elementos. Este critério identifica a

existência de um repositório na arquitetura da abordagem. Entende-se que uma

abordagem que objetiva o reuso de requisitos deve ser baseada num repositório, a

não adoção de um repositório para o armazenamento do conhecimento o qual se

pretende reutilizar coloca em dúvida a sua efetividade, abrindo espaço para perguntas

como, por exemplo: Onde e como se encontra o conhecimento que se pretende

reutilizar? Como é feita a busca neste repositório em cada caso? A busca é

realiazada de forma manual?

5. quanto ao método de avaliação da abordagem (tipo de avaliação): concordando

com as colocações de Basili (2007), os estudo empíricos apresentam um papel

importante na evolução da engenharia de software, contribuindo na construção de

um corpo de conhecimento em engenharia de software, apoiado em observações e

evidências empíricas. Assim, este critério observa o método de avaliação ao qual a

abordagem foi submetida.

A análise encontra-se sumarizada na Tabela 10. Desta forma, é possível observar com mais

transparência as contribuições e limitações de cada abordagem em relação as característica

levantadas.

Tabela 10 - Análise comparativa entre os trabalhos similares. Estudo Escopo Abordagem Ferramenta Repositório Avaliação (KEEPENCE et al., 1995)

Linha de produto (setor de planejamento de missões espaciais)

Método de classificação dos requisitos em componentes reutilizáveis

Não Não

Estudo de caso

(LAM, 1997) Linha de Reuso de requisitos Sim Sim Framework

71

produtos (setor aeronáutico)

abstratos a partir de formulários genéricos baseado em coleção de requisitos

Baseada em formulário (desenvolvido em Visual Basic) para instanciação de requisitos genéricos

Armazena uma biblioteca de requisitos genéricos (Banco de dados Ms-Access) Busca realizada de forma manual, no entanto, é auxiliada pela ferramenta de apoio, através da instanciação de requisitos com base nas informações fornecida nos formulários.

de avaliação

(GOTZHEIN et al., 1998)

Reuso em sistemas de tempo de real

Padrões de requisitos não triviais para sistemas de tempo real

Não Sim Armazena os padrões de requisito (baseado em template). A busca é realizada de forma manual em sistemas de arquivos, sem nenhum auxílio computacional.

Nenhuma

(MONTABERT et al., 2005) (MONTABERT et al., 2009)

Reuso de requisitos de usabilidade

Análise hierárquica de tarefas + reivindicações

Sim Ferramenta baseada em LINK-UP8

Sim Repositório de reivindicações (claims) Os requisitos são recomendados com base nas reivindicações associadas a um modelo de tarefa. A busca por outras reivindicações adicionais é auxiliada pela ferramenta de apoio.

Estudo de usabilidade (2005) Estudo de viabilidade (2009)

(MOON et al., 2005)

Linha de Produtos (setor

Uniformização e variabilidade de requisitos

Sim Suporte para

Sim Armazena o núcleo

Estudo de caso

8 Consiste em uma ferramenta de suporte baseada na web que auxilia projetistas sobre questões-chaves relacionadas ao comportamento de uma interface.

72

jonalístico; e, sistemas de web para companhias de viagens)

gestão dos pontos comuns e variabilidade dos requisitos de domínio

de ativos. A lista de requisitos é criada automaticamente a partir dos requisitos primários (RP)selecionados na matriz de RP-contexto baseado em um meta-modelo.

(MONZON, 2008)

Linha de Produtos (setor aeronáutico)

Rastreabilidade + Derivação de requisitos

Sim Plugin para uma ferramenta comercial (Doors) para prover reuso de requisitos em família de produto

Sim Repositório da ferramenta comercial. A lista de requisito para reuso é apresentada pelo conjunto relacionado pela árvore de rastreabilidade do projeto da linha de produto.

Nenhuma

(PEREDNIKAS, 2008)

Reuso baseado em análise de domínio. Contexto específico não identificado.

Previsão de necessidade do usuário baseado em análise de tarefas + análise baseada na experiência de especialista

Não Não Nenhuma

ABORDAGEM PROPOSTA

Reuso de requisitos de sistemas de informação

Templates baseados em padrões de requisitos + catálogo de padrões + rastreabilidade

Sim Ferramenta web que potencializa o reuso a partir de sugestões

Sim Armazena requisitos descritos conforme padrões. Busca realizada de forma manual. No entanto, é auxiliada pela ferramenta de apoio, através das sugestões de reuso baseadas nos mecanismos de apoio ao reuso.

Estudo de caso (avaliação quase-experimental) Avaliação de percepção de uso da ferramenta/ abordagem Avaliação de especialista (método GQM)

A abordagem de Keepence et al. (1995) apresenta heurísticas que auxiliam na generalização

de requisitos para o reuso (por exemplo, sugerindo remoção de referências específicas; derivando

termos comuns; dividindo especificações genéricas) e classificação dos requisitos em um contexto

73

de reutilização (não reusável, diretamente reusável ou reutilizável por parametrização). Até o

momento desta pesquisa, não foram localizados uma ferramenta e repositório que apóiem a

abordagem.

A proposta da abordagem de Lam (1997) permite a especificação de requisitos a partir de

formulários genéricos que fornecem um ponto de partida para escrita do requisito. No entanto, os

campos dos formulários não apresentam de forma explícita informações que auxiliem na sua

escolha. Além disso, a escolha de um formulário para especificação do requisito é guiada pela

seleção de um componente exibido em uma lista de componentes reutilizáveis (um componente

reutilizável encapusula requisitos genéricos estreitamente relacionados) exigindo que o analista

conheça plenamente o componente para sua reutilização.

A abordagem de Gotzhein et al.(1998) objetiva estruturar o conhecimento na especificação

de requisitos para sistemas formais utilizando padrões de requisitos os quais são armazenados em

um pool de padrões. No entanto, esta abordagem não conta com apoio de uma ferramenta

computacional para auxiliar na seleção e adaptação nas instanciações dos padrões. Entende-se que a

falta de uma ferramenta de apoio minimize as vantagens promovidas pelo reuso (como por

exemplo: busca, seleção e entendimento dos artefatos reutilizáveis).

Os trabalhos de Montabert et al., (2005;2009) e de Perednikas (2008) são baseados em

métodos de análise hierárquica de tarefas. O trabalho de Montabert et al., (2005;2009) se concentra

em reuso de requisitos de usabilidade, onde se instancia um modelo de tarefas capaz de promover a

reutilização de conjuntos de reivendicações, fundamentos e todo os componentes do projeto. A

abordagem de Perednikas (2008) é baseada na suposição de que os problemas e necessidades dos

usuários são semelhantes em muitos casos. Assim, a abordagem de Perednikas (2008) utilizada lista

de tarefas associadas a fontes de requisitos (usuários), sendo que os usuários selecionados na etapa

inicial do processo proposto pela abordagem selecionam as especificações de requisito apropriadas

da lista. No entanto, é observado alguns pontos críticos nestas duas abordagens por ser baseada em

um método de análise hierárquico de tarefa. Observa-se que sua aplicação fica limitada diante de

grandes quantidades de dados. Isso pode ocorrer porque logo se tornam complicada e difícil de

acompanhar a anotação, e também não é possível à modelagem de tarefas que ocorrem em paralelo

(PREECE et al., 2002, p. 253). Além disso, na abordagem de Montabert et al., (2005; 2009) o

formato de declarações das reividicações (claims) associadas aos benefícios (upsides) e fraquesas

(downsides) não abordam a especificação de requisitos de forma trivial, provalmente devido ao seu

74

escopo de especificações de requisitos para projetos de notificação ao usuário. Em relação à

abordagem de Perednikas (2008) outros desafios ainda estão relacionados à: (i) falta de apoio de

uma ferramenta computacional para realiza os cálculos dos graus de incerteza (princípio chave de

abordagem); (ii) especificação do repositório (não é descrito pelo autor como o conhecimento é

armazado e recuperado .

Cabe destacar ainda que os trabalhos de Lam (1997), Moon et al. (2005) e Monzon (2008)

consideram a reutilização de requisitos em uma linha de produtos de software. Neste sentido, essas

abordagens em sua maioria dependem do conhecimento e experiência de especialistas no domínio

para adquirir manualmente a comunalidade (o que é semelhante no domínio) e variabilidades (o que

é variável no domínio) do domínio modelado. Além disso, as abordagens de linha de produto de

software produzem uma considerável mudança no processo de desenvolvimento (von Knethen et

al., 2002).

Outro aspecto que pode ser destacado refere-se a forma de avaliação, a qual em muitas

pesquisas não foi realizada. Quando realizada, a forma também varia bastante, destacando-se a

avaliação através de estudo de caso.

3.4 CONSIDERAÇÕES DO CAPÍTULO

Este Capítulo apresenta o estado da arte sobre abordagens para o reuso de requisitos de

software. Para tanto, utilizou-se de uma revisão sistemática da literatura como instrumento de

localização dos trabalhos selecionados para compor este capítulo. Os trabalhos selecionados

demonstram o esforço realizado pela comunidade de engenharia de software em reutilizar

especificações de requisitos de software.

Em síntese, pode-se afirmar que existem diversas abordagens com o objetivo de apoiar o

reuso de requisitos. Observa-se que o grande foco dos estudos de reutilização de requisitos provém

da engenharia de linha de produtos (KEEPENCE et al., 1995; LAM, 1997; MOON et al., 2005;

MONZON, 2008) ou possui um escopo bem específico como é o caso de Montabert et al., (2005;

2009) que foca apenas em requisitos de usabilidade ou de Gotzhein et al., (1998) que se refere

apenas a requisitos não triviais para sistemas de tempo real. As abordagens empregam métodos

distintos, como classificação, padrões, análise de tarefas associada a reinvindicações, derivação e

rastreabilidade. A abordagem proposta nesta dissertação reúne alguns dos métodos utilizados e os

75

emprega visando apresentar automaticamente sugestões de requisitos para reuso, sem restringir a

um domínio específico. Em relação ao escopo dos trabalhos, as abordagens relacionadas ao

paradigma de linha de produtos (KEEPENCE et al., 1995; LAM, 1997; MOON et al., 2005;

MONZON, 2008) realizam a reutilização de toda a especificação de um produto variante do

domínio, destacando-se a análise de domínio no setor de aeronáutica. Também foram relacionados

estudos com preocupação na especificação de requisitos para sistemas de tempo reais (GOTZHEIN

et al., 1998) e especificações de requisitos de usabilidade em sistemas (MONTABERT et al.,

2005;2009) ou atrealados as atividades de um domínio (PEREDNIKAS, 2008). Em contra partida, a

abordagem aqui proposta proporciona a reutilização unitária de cada artefato, ou seja, cada

especificação de requisito é independente de um domínio e pode ser reutilizado onde o analista

julgar ser conviniente.

Outro aspecto que pode ser destacado, refere-se à forma de avaliação – que não foi realizada

em muitas pesquisas. Quando realizada, a forma também varia bastante, destacando-se a avaliação

através de estudo de caso.

No próximo Capítulo, é descrita em detalhes a abordagem proposta neste trabalho.

76

4 ABORDAGEM DE REUSO DE REQUISITOS

Considerando o que foi apresentado e discutido nos Capítulos 2 e 3, apresenta-se neste

Capítulo a proposta de uma nova abordagem para apoiar a reutilização de requisitos. A partir do

estudo das abordagens existentes (analisados no Capítulo 3), percebeu-se que não há uma

abordagem de reuso de requisitos que forneça automaticamente sugestões de requisitos

reutilizáveis. Além disso, a junção de diferentes técnicas empregadas nas pesquisas pode dar origem

a uma nova abordagem.

Na Seção 4.1, é abordada uma visão geral da abordagem. Na Seção 4.2, são apresentados os

passos do processo proposto para adoção da abordagem. Os padrões de requisitos adotados são

apresentados na Seção 4.3. O catálogo de padrões é detalhado na Seção 4.4. A Seção 4.5 apresenta

o repositório utilizado na arquitetura da abordagem. Os mecanismos de sugestão de reuso são

definidos na Seção 4.6. Por fim, na Seção 4.7 é apresentada a ferramenta de apoio a abordagem.

4.1 VISÃO GERAL

Com a finalidade de criar uma abordagem que apoiasse a reutilização de requisitos e que

pudesse prover ao Engenheiro de Software uma forma de ajudá-lo na atividade de elicitação de

requisitos, a abordagem proposta foi concebida fundamentada em três pilares: (i) padrões de escritas

de requisitos (TORO et al., 1999; WITHALL, 2007); (ii) catálogo de padrões (WITHALL, 2007;

RENAULT et al., 2009a) e; (iii) rastreabilidade (von KNETHEN et al., 2002; DICK, 2002).

De modo amplo, os principais objetivos da abordagem de reuso de requisitos são:

1. Alavancar a atividade de elicitação de requisitos com a captura de requisitos mais

completos;

2. Ajudar o Engenheiro de Software com sugestões de requisitos, auxiliando na

obtenção de um conjunto de requisitos mais completo (contemplando as

funcionalidades do sistema em desenvolvimento);

3. Aumentar a compreensão da informação contida no requisito;

77

4. Reusar o conhecimento sobre o atual contexto do domínio para ajudar tanto o

Engenheiro de Software como o Usuário do sistema a identificar possíveis

característica ainda não percebidas;

5. Prover mecanismos para encontrar requisitos utilizados em outros projetos do

mesmo contexto, como forma de se obter requisitos indiretamente;

6. Aumentar a qualidade de escrita dos requisitos identificados;

7. Aumentar a qualidade do documento de especificação de requisitos gerado pela fase

de engenharia de requisitos;

8. Diminuir o esforço na condução da atividade de elicitação de requisitos.

Para alcançar estes objetivos, a abordagem aqui proposta utiliza-se de diversos elementos,

elencados na Figura 6.

Figura 6 - Visão geral do processo da abordagem proposta.

Importante considerar as definições/objetivos dos elementos adotados no contexto desta

abordagem:

Usuários: compatilhando da mesma definição de Wiegers (2006), um usuário é

“qualquer pessoa ativamente envolvida no projeto, ou que pode influenciar o seu

78

resultado”. Assim, o principal papel do usuário é de especificar as característica ou

necessidades.

Necessidades: corresponde ao desejo do usuário, sendo assim, a necessidade ou

característica esperada do sistema. A partir da necessidade são elaborados os requisitos

de usuário. Para identificar as necessidades e os requisitos de usuário recomenda-se a

utilização de algum método de elicitação de requisito.

Requisito de usuário: um requisito de usuário é uma declaração de alto nível de uma

necessidade do usuário. Posteriormente, estas definições de alto nível são refinadas em

um ou vários requisitos de sistema. Então, os requisitos de usuários para a abordagem

correspondem ao insumo para elaboração dos requisitos de sistema.

Requisito de sistema: concordando com o entendimento de Sommerville e Kotonya

(1998), requisito de sistema descreve como o sistema deverá se comportar, além de

informar sobre o domínio da aplicação ou restrições na operação do sistema.

Padrões de requisito: no contexto deste trabalho os padrões de requisitos tem o papel de

apoiar a abordagem estruturando e generalizando o conhecimento de escrita de um

determinado tipo de requisito. O emprego de padrões também é fundamental para

fornecer as sugestões de reuso. A Seção 4.3 apresenta em detalhes o padrão adotado.

Catálogo de padrões: o seu papel é de servir como guia para seleção dos padrões através

do agrupamento dos padrões por objetivo. Mais informações sobre o catálogo de padrões

utilizado na abordagem são apresentadas na Seção 4.4.

Repositório: local de armazenagem do conhecimento a ser reutilizado.

Requisito reutilizável: um requisito reutilizável é aquele que já foi analisado, revisado e

validado pelos interessados. Um requisito pode ser reutilizado quando o projeto no qual

ele foi elaborado inicialmente estiver marcado como compartilhado para reutilização.

Rastreabilidade: nesta abordagem a rastreabilidade é utilizada como uma forma de

identificar e comparar as necessidades dos sistemas novos com sistemas existentes e

sugerir novos requisitos, baseando-se em projetos armazenados no repositório. Cabe

79

salientar que, a rastreabilidade entre requisitos de usuários e de sistema, como também, a

rastreabilidade entre requisitos funcionais e não funcionais deve ser cumprida para

prover esse mecanismo de reuso. Essa prática também é uma recomendação para um

bom processo de engenharia de requisitos em diversos modelos (STD 830-1998, 1998

p.4; YOUNG, 2006).

Documento de Especificações de Requisitos de Software (ERS): este documento dispõe

das declarações dos envolvidos (usuários) as quais devem ser implementadas

(SOMMERVILLE, 2007, p. 136). A seção principal do documento consiste no conjunto

de requisitos funcionais ou não funcionais e restrições derivadas dos requisitos de

usuário.

Esta abordagem observa o modelo de reutilização de software proposto por Krueger (1992)

que consiste em:

a) Abstração: característica essencial presente em todas as abordagens de reuso

(KRUEGER, 1992), trata da unidade para o reuso e o nível de abstração. Nesta

abordagem, a unidade de reuso é um requisito de sistema e o nível de abstração é

contemplado pelo emprego de padrões de requisito.

b) Seleção: método utilizado para reutilizar uma unidade de reuso. Na abordagem proposta

a reutilização deverá ocorrer a partir de sugestões, obtidas a partir do emprego de um

catálogo de requisitos e da rastreabilidade entre requisitos.

c) Adaptação: a adaptação é realizada em artefatos semelhantes que foram fundidos

(generalizados) em um único artefato, assim, gerando um artefato genérico, no qual

são instanciados e adaptados para reuso através de parâmetros. Na abordagem, a

adaptação é realizada a partir da instanciação de um padrão de requisito. Cabe dizer

que a adaptação é guiada por alguns elementos do padrão selecionado como, por

exemplo, templates e exemplos; e

d) Integração: relaciona como os componentes reutilizados serão integrados a um novo

projeto. Aqui, a integração é proporcionada pelo apoio de uma ferramenta

computacional, sendo os requisitos reutilizados integrados ao documento de

especificação de requisitos.

80

4.2 PROCESSO DE REUTILIZAÇÃO DE REQUISITOS

Nesta seção, são apresentados os passos seguidos para a utilização da abordagem proposta.

Como estes conceitos (padrões de requisitos, catálogo de padrões e rastreabilidade) se relacionam

de forma a viabilizar o reuso? A Figura 7 apresenta o processo proposto demonstrando as

possibilidades de reuso e os mecanismos de sugestão de requisitos para reutilização.

Inicialmente, é importante considerar que o processo exposto deve ser realizado de forma

iterativa, ou seja, os requisitos de sistema devem ser adquiridos e especificados em vários ciclos até

que todos os requisitos do projeto estejam relacionados, gerando ao final deste processo o artefato

de documento de especificação de requisitos.

Sendo assim, o primeiro passo consiste na elicitação e especificação dos requisitos de usuário.

A elicitação dos requisitos de usuário pode ser executada utilizando qualquer técnica convencional.

A abordagem não faz nenhuma restrição à escolha e utilização das técnicas de elicitação

disponíveis. Algumas técnicas para realizar esta atividade são apresentadas por Zhang (2007).

81

act Processo Geral

Informar requisitos deusuário

Adicionar maisrequisi tos

Uti lizar padrão?

Av aliar utilização dopadrão

Realizar busca nocatálogo de padrões

Sugestão de Reuso?

Definir requisito desistema a partir de

template

Definir requisito desistema

Verificar sugestões dereuso por padrão

Reusar?

Incorporar requisito aodocumento deespecificação

Definir modo de reuso

Tipo de reuso?

Adaptar requisitoreutilizado

Verificar sugestões dereuso por rastreabilidade

Reusar?

Verificar pornecessidades pendentesno escopo

Requisi tos escri tos a parti r deste passo não servirão de sugestão para o reuso.

Incluir requisito norepositório

[Não]

[Sim][Não]

[Não]

[Sim]

[Não]

[Sim]

[Não]

[Sim]

[Sim]

["Copiar" ou"Copiar_e_manter_l igação"]

[Comparti lhado]

[Sim]

[Não]

Figura 7 - Processo retratando a abordagem proposta.

Posteriormente, os requisitos de usuários são “transformados” em requisitos de sistema –

elementos que poderão ser reutilizados na abordagem proposta. Neste passo, pode-se optar por

utilizar ou não padrões para a definição dos requisitos de sistema, sendo que a não utilização leva ao

processo tradicional sem reuso. Ou seja, na abordagem proposta as sugestões de reuso ocorrerão a

partir da utilização de padrões.

82

Desta forma, o analista deve buscar no catálogo de padrões um padrão que se adéque a sua

necessidade. Observa-se que nesta etapa, o catálogo de padrões tem o papel fundamental de guia e

facilitar a escolha de um padrão. A seleção de um padrão também é orientada por alguns elementos

que compõem o padrão, alguns exemplos desses elementos que fornecem essa orientação são:

objetivo, contexto, problema, forças e exemplos (detalhes na seção 4.3).

Assim, ao identificar o padrão, o analista pode criar um novo requisito a partir do template

proposto pelo padrão ou verificar as sugestões de reuso – neste caso, as sugestões ocorrem a partir

de requisitos de outros projetos compartilhados e que foram escritos com base no mesmo padrão

selecionado pelo analista.

Depois de selecionado o padrão, o mesmo é utilizado para definir o requisito de sistema a

partir do template oferecido pelo padrão. A definição do requisito a partir de um padrão consiste no

preenchimento de lacunas em um formulário de uma estrutura fixa, que expressa o requisito de

sistema. Como resultado, o analista obtém uma especificação de requisito que será incorporado ao

documento de especificação de requisito. Destaca-se que este requisito especificado na estrutura do

padrão poderá servir como ativo reutilizável em outros projetos (desde que o projeto deste “ativo

reutilizável” esteja compartilhado).

Por outro lado, uma vez que é identificado algum requisito para reutilização, deve-se optar

pelo modo de reuso:

a) Compartilhado: esse tipo de referência vincula o novo requisito com o requisito do

projeto original (no qual o requisito foi especificado inicialmente). Quando o requisito de

origem sofrer qualquer tipo de modificação a mesma será propagada aos requisitos

vinculados. Desta forma, este modo de reuso faz a reutilização da especificação de

requisito na sua totalidade, sendo vedada a adaptação do conteúdo do novo requisito.

b) Copiar e manter ligação: neste tipo de referência a especificação do requisito de origem é

copiada para o novo projeto mantendo o vínculo de referência ao requisito de origem, no

entanto, permitindo a adaptação do conteúdo do novo requisito. O objetivo deste modo de

reuso é manter o vínculo com o requisito original viabilizando uma comparação entre as

especificações, para que se possa aceitar ou não a propagação das alterações do requisito

original para o novo requisito.

83

c) Copiar: neste tipo de referência a especificação do requisito de origem é copiada sem

manter nenhum tipo de vínculo de referência, sendo também possível a adaptação de seu

conteúdo.

Como pode ser observado, somente o modo de reuso “compartilhado” não permite a

adaptação do conteúdo (edição do requisito reutilizado), sendo que os demais modos não aplicam

nenhuma restrição. Porém, é conveniente ressaltar que a adaptação de um requisito reutilizado

conduz a perda dos benefícios promovidos pelo reuso.

Como próximo passo após a reutilização, a especificação do novo requisito é adicionada ao

documento de especificação. A partir da reutilização de um requisito, independentemente do tipo de

referência escolhida, é sugerido um novo conjunto de requisitos para reuso a partir dos vínculos de

rastreabilidade do requisito de origem. E, neste caso, o analista optando por reutilizar um requisito,

o procedimento é o mesmo já descrito – devendo optar um dos modos de reuso previstos.

No final deste ciclo, o analista poderá selecionar um novo requisito de usuário, ou o mesmo

se for o caso, para a especificação de outro requisito de sistema. Após a especificação de todos os

requisitos de sistema, o analista obtém um documento de ERS completo do projeto. Recomenda-se

que com este artefato faça-se uma validação dos requisitos junto aos stakeholders, e que todo o

processo de engenharia de requisitos seja mantido incluindo o gerenciamento de requisitos.

É mister ressaltar que existe a necessidade de realização de uma atividade de rastreabilidade

entre requisitos, pois, este é um dos pilares da abordagem. Entende-se que a sua falta, traria uma

redução considerável de sugestões de requisitos para reutilização.

Esta seção apresentou o processo de reutilização de requisito no qual consiste a abordagem. A

seção a seguir apresenta o padrão adotado pela abordagem.

4.3 PADRÃO DE ESCRITA DE REQUISITO DE SOFTWARE

Esta seção tem o objetivo de apresentar o “formulário padrão” para a escrita dos padrões que

irão compor o catálogo de padrões da abordagem aqui proposta.

Conforme apresentado na Seção 2.4, um padrão de requisito é um artefato que pode ser

utilizado durante a atividade de elicitação de requisitos (FRANCH et al., 2010), cuja a utilização

84

promove a criação de bons artefatos de software ou engenharia (TSUMAKI, 2004). Visando

potencializar o reuso de requisitos, considerou-se importante haver um padrão que oriente a escrita

(redação) do requisito.

Neste sentido, a partir do mapeamento sistemático visando identificar os padrões para escrita

de requisitos disponíveis na literatura (descritos na seção 2.4), optou-se pelos padrões propostos por

Withall (2007), por serem considerados mais completos e detalhados, além de abranger padrões

para requisitos tanto funcionais como não funcionais.

Convém ressaltar que o objetivo dos padrões na abordagem é de estruturar o conhecimento

capturado para que ele possa ser armazenado e recuperado de um repositório. Além disso, os

padrões devem prover orientações para a escrita e seleção do requisito.

Ainda, para fortalecer e facilitar o emprego dos padrões, estes foram adaptados em uma nova

estrutura seguindo as orientações de Meszaros e Doble (1996) conforme retratado pela Figura 8 e,

portanto, para cada padrão foi definido:

- Nome do padrão: um nome pelo qual o padrão possa ser identificado, devendo

servir como referência do problema/solução (MESZAROS; DOBLE, 1996) e deve

também representar o contexto do padrão (WITHALL, 2007).

- Objetivo: este elemento deve indicar o objetivo do requisito em resolver um

problema. O objetivo é semelhante à força e tem de indicar o alvo individual

(TSUMAKI, 2004).

- Contexto: descreve uma situação no âmbito do projeto em que os problemas

ocorrem (WITHALL, 2007). Também tem o papel de revelar a importância relativa

das forças (MESZAROS; DOBLE, 1996).

- Problema: o campo problema serve para lembrar o leitor do problema que estão

tentando resolver. Segundo Tsumaki (2004), o problema tem várias causas, por isso

uma descrição do problema é composta por duas partes: a descrição geral do

problema e as causas do problema.

- Forças: este elemento fornece informações que devem ser consideradas ao escolher

uma solução para um problema.

85

- Template: o template serve como ponto de partida para a escrita de um requisito,

também pode ser visto como o elemento “solução” que é normalmente encontrado

em uma linguagem de padrões. O conteúdo deste elemento é uma adaptação do que

foi apresentado em Withall (2007). O que difere a sua utilização entre esta

abordagem e a de Withall (2007), é que nesta abordagem ele está fortalecido por

uma estrutura que ajuda na seleção e orientação de como utilizá-lo.

- Exemplos: este elemento tem a finalidade de orientar com um ou mais exemplos a

utilização do padrão para especificação do requisito. Os exemplos utilizados partem

do preenchimento do elemento template.

ID - <id> <nome do padrão> Objetivo <objetivo do requisito> Contexto <contexto em que se apresenta o padrão> Problema <problema cujo padrão irá abordar> Forças <forças que atuam> Resumo <texto utilizando poucas palavras para resumir o requisito> Template <template correspondente ao padrão selecionado> Exemplos <exemplo de escrita do requisito utilizando o padrão>

Figura 8 - Modelo da estrutura do formulário padrão utilizado pela abordagem.

Para um melhor entendimento, a Figura 9 apresenta o padrão “Relatório” em seu formato

completo.

Nome: Relatório

Objetivo: Use o padrão de requisitos de relatório para definir um relatório que mostra as informações especificadas para o usuário.

Contexto: Um relatório é uma forma de apresentar informações muito parecida com uma consulta, de fato, então devemos começar por explicar a distinção. Uma consulta foi algo que você olhou na tela e um relatório trata de alguma coisa que você imprimiu em papel. Nada mais que isso. No entanto, a rolagem nos permite manipular grandes quantidades de informações na tela, e os relatórios são vistos cada vez mais na tela em vez de serem impressos. Esta é uma tendência que devemos incentivar, para reduzir o uso de papel, o desgaste das impressoras, o tempo de espera para impressão, e os riscos de segurança dos documentos de cair nas mãos erradas.

Quando você precisa mostrar alguma informação a um usuário, deve-se decidir se irá especificá-o como uma pesquisa ou como um relatório. Tomem a decisão sobre uma base racional sólida, e não de forma arbitrária, apenas porque alguém tinha um ou outro em mente. Os fatores a considerar são:

Fator 1: Quanta informação deve ser mostrada? Se for um único item (tais como detalhes de um cliente), uma consulta é mais adequada, se é uma quantidade ilimitada de informações, um relatório é preferível. Além disso, se você precisa mostrar muitas colunas de informações, um relatório poderia ser melhor.

Fator 2: Deseja interatividade? Os relatórios são passivos (pelo menos usando a tecnologia atual). Se quisermos ser capazes de mudar o que nós estamos olhando ou para navegar em outros lugares (como clicando sobre as coisas), devemos usar uma consulta. E se precisar de informações que sejam atualizáveis automaticamente na própria na tela, optar por uma consulta é o recomendável.

86

Fator 3: Quantas vezes você precisa de uma cópia? Se for impresso com frequência opte por um relatório.

Fator 4: Quantas pessoas precisam ver isso? Você pode executar um relatório, enviá-lo para outras pessoas, quando se trata de informações confidenciais, neste caso uma consulta é menos confiável. Você também pode enviar um relatório para alguém que não tem acesso online ao seu sistema.

Fator 5: Você precisa ser capaz de salvar os resultados? Um relatório é mais passível de ser armazenado que uma consulta, no entanto, isso depende em parte da natureza da infraestrutura básica da interface do usuário. (Por exemplo, uma consulta exibida em uma página HTML pode ser salva.).

Fator 6: De onde a informação vem? Se não for de um banco de dados, um software gerador de relatório pode não ser capaz de lê-lo.

Fator 7: O quanto a informação é volátil? Se os dados mudam com frequência, uma cópia de um relatório vai se tornar rapidamente desatualizado, assim, tornando-se obsoleto.

Fator 8: Uma consulta ou um relatório, o que é mais barato de implementar? Normalmente, um relatório é a opção mais barata, isso ocorre porque ele geralmente é um produto gerado por uma ferramenta de design de relatório, o que facilita a criação de um novo relatório.

Se você receber respostas conflitantes a estas perguntas, considere a especificação tanto de uma consulta quanto de um relatório para a mesma informação.

Os relatórios necessários para sistemas quase sempre são especificados de forma inadequada, sem considerar os fatores citados anteriormente. A descoberta de funcionalides (necessidades) que são pertinentes ao sistema são difíceis de serem capturadas, então não é surpresa que haja pouco entusiasmo para realização desta tarefa. Com a mudança regular do ponto de vista de negócio, os relatórios de gestão, vendas, marketing e de outras áreas remotas de operações do dia-a-dia, frequentemente tornam-se voláteis. Então, não é possível capturar todos os requisitos de uma única vez. Mas, é recomendável buscar o máximo possível para obter-se uma ideia razoável do número de relatórios necessários. Uma maneira de fazer isto é examinando o seguinte:

1. As pessoas que possam estar interessadas em receber relatórios: este poderia ser um grupo muito mais amplo que aqueles que realmente usam o sistema: as pessoas do finançeiro, auditores, a gestão em todos os níveis, administradores de sistemas, gerentes de projeto (para as estatísticas de erros e de desempenho do sistema) e pessoas dos recursos humanos. Poderia incluir pessoas de fora da organização, tais como o governo e a indústria, clientes, agentes, fornecedores e outros parceiros de negócios. Pergunte a si mesmo quem pode ter um interesse legítimo em algum aspecto do que se passa no seu sistema.

2. As atividades necessárias para manter o negócio funcionando: para fins de relatórios, não se preocupe com as atividades tradicionais sobre o dia-a-dia, porque elas nunca podem ser negligenciadas. Preste atenção especial às atividades operacionais que envolvem a tomada de decisões, porque todas estas decisões são baseadas em informações de modo a tentar identificar qual a informação necessária e de que forma seria mais eficaz para isso.

3. As estratosferas estratégicas: que tipo de informações estatísticas predominantemente ajudaria as pessoas envolvidas no direcionamento do negócio (principalmente da alta administração e vendas e marketing)? É importante ter uma boa compreensão das expectativas das pessoas a este nível, porque a escala e a complexidade dos relatórios para que elas possam ter um impacto significativo sobre a dimensão global do sistema. Além disso, o processamento necessário para gerar tais relatórios poderia ser tão intenso que ele terá um impacto significativo no desempenho global do sistema; se um sistema de relatórios em separado for necessário para evitar isso, precisamos identificar isso o mais cedo possível e prever as implicações nos requisitos.

Não é aceitável escrever um requisito que abrange vários relatórios, especialmente se ele é aberto. Algo como "um conjunto completo de relatórios financeiros" ou "todos os relatórios exigidos pelo órgão regulador do governo" são na melhor das hipóteses uma dica que muita coisa está faltando e são inúteis como requisitos. Se os relatórios específicos não podem ser fixados, digamos assim, em texto informal, não é um requisito.

Preste atenção especial às ocasiões em que o relatório é especialmente importante (por exemplo os que devem ser gerados nos fins de meses, trimestres, exercício corrente ou exercícios anteriores). Não cometa o erro de fazer somente os relatórios do dia-a-dia corretamente e negligenciar relatórios frequentes de tarefas. Fique atento ao especificar necessidades “óbvias” de uma forma superficial, isso pode levar a relatórios que são de difícil controle na prática, os quais impõem carga extra de trabalho para os usuários durante suas atividades. Além disso, a tentativa de adicionar esses relatórios pouco antes deles serem necessários pode levar a descoberta de outras omissões subjacente ao sistema que não podem ser corrigidas a tempo.

Ao investigar porque o relatório é necessário, você irá reunir muitas informações valiosas sobre quem deve recebê-los, quantas vezes, quantas cópias, quanto tempo eles devem ser retidos, e assim por diante. Este trabalho não faz parte do requisito, porque eles são aspectos passíveis de mudanças e você deve exigir um sistema no qual eles possam ser alterados a qualquer momento. No entanto, guarde essas informações para usá-las na hora de realizar as configurações iniciais do sistema. Decisões concretas sobre a produção e distribuição de relatórios devem ser feitas no período que antecede a instalação do sistema, estes sendo mais oportunos de serem tomados na etapa de teste do sistema. Se possível, permita que os usuários experimentem o sistema na etapa de teste, para que eles possam familiarizar-se com ele. Eles podem refinar o relatório e decidir sobre questões operacionais naquele momento.

Algumas organizações imprimem relatórios regularmente para arquivamento físico ou para cópias eletrônicas para que possam ser consultados mais

87

tarde como um último recurso. Isto sugere que o sistema em si não é adequado e confiável. Projetando sistemas melhores diminuiria esse papel para os relatórios, de forma que reduziria a necessidade deste tipo de relatórios. Desta forma, se você estiver especificando um sistema substituto, mantenha os olhos abertos para este tipo de relatório.

Problema: Como especificar um requisito para definir um relatório?

Forças:

Definição dos aspectos sobre relatórios; A intenção de negócio do relatório; As informações que serão exibidas no relatório; Critérios para seleção; Detalhes referentes à execução (automática ou manual); Níveis de totalização; e etc.

Template:

Resumo Definição Relatório <<nome do relatório>>

Deve haver um relatório que mostre <<informações a serem exibidas>> <<critério de seleção>> ordenadas por <<sequência de ordenação>>. O objetivo deste relatório é a <<intenção do negócio>>.

Para cada <<nome do tipo de item>>, o relatório deve mostrar o seguinte: <<nome do valor 1 >>. <<nome do valor 2 >>. …

(Os itens a serem exibidos podem ser especificados por enquadrar em qualquer dos seguintes critérios de seleção: <<critério de seleção 1 >>. <<critério de seleção 2 >>. …)

Os totais devem ser mostrados para <<níveis de totalização>>. (Uma nova página deve ser iniciada por <<níveis de páginas>>)

(O relatório destina-se a ser executado automaticamente <<detalhe da execução automática>>)

Exemplos:

Resumo Definição Relatório cambial Deve haver um relatório que mostre todos os negócios feitos no câmbio de um período selecionado ordenadas por data

de processamento. O objetivo deste relatório é a movimentação do câmbio de um determinado período.

Para cada moeda estrangeira, o relatório deve mostrar o seguinte: Tipo do negócio; Montante do negócio (incluindo a moeda); Data e hora; Taxa de câmbio; Nome da organização com o qual a operação foi realizada.

Os itens a serem exibidos podem ser especificados por enquadrar em qualquer dos seguintes critérios de seleção: Período selecionado.

Os totais devem ser mostrados para cada organização.

Figura 9 - Exemplo do padrão Relatório. Fonte: Adaptado de Withall (2007).

Esta seção apresentou o “formulário padrão” proposto pela abordagem para a escrita dos

padrões de requisitos. A seção a seguir apresenta o catálogo de padrões que apóia a abordagem

proposta.

88

4.4 CATÁLAGO DE PADRÕES DE REQUISITOS

O problema tratado pelo catálogo de padrões envolve soluções que objetivam facilitar a

localização e seleção de um determinado padrão (MENDEZ-BONILLA et al., 2008) permitindo

demonstrar um pouco mais sobre a natureza dos padrões (WITHALL, 2007).

De fato, um catálogo de padrões é uma coleção de padrões que estão relacionados, a sua

utilização pode ser feita individualmente ou em conjunto para resolver um problema (WINN;

CALDER, 2002; WITHALL, 2007; FRANCH et al., 2010).

Pode-se dizer que a instanciação de padrão cria um elemento que irá comportar uma parte do

projeto de software, no entanto, um projeto completo incluirá muitas instâncias de diversos padrões,

estes compostos de várias maneiras. Assim, cada novo elemento do projeto será o resultado da

instância de um padrão apropriado selecionado de um catálogo.

Neste sentido, um catálogo foi desenvolvido contemplando os 37 padrões propostos por

Withall (2007), organizados em 6 domínios distintos, conforme retratado pela Figura 10

(procurando conciliar os domínios propostos por Withall (2007) e a norma IEEE Std 830-1998

(1998)), sendo eles: Lógicos de base de dados, Interfaces externas, Atributos do sistema,

Funcionais, Restrições de projeto e Desempenho.

Além disso, vale observa-se que catálago foi adaptado de Withall (2007) utilizando todos os

padrões nele retratado. No entanto, foram feita adaptações no sentido de facilitar a sua seleção e

entendimento. As modificações foram feitas na estrutura do padrão adicionando os elementos

“forças” e “problema”. As orientações das seções “detalhes básicos”, “aplicação” e “discussão” dos

padrões de Withall (2007) foram redistribuídas nos elementos “objetivo” e “contexto” na estrutura

proposta de padrões pela abordagem aqui apresentada.

Cabe ressaltar que o relacionamento indicado no catálogo corresponde ao relacionamento

entre os padrões, não sendo entre os domínios. Sendo assim, o relacionamento entre os padrões visa

fornecer orientações de padrões adicionais de forma a complementar um requisito. Essa orientação

é necessária porque em muitas situações, um padrão de requisito não é suficiente para orientar em

tudo o que é necessário para a declaração do requisito (WITHALL, 2007).

89

O catálogo completo com os padrões pode ser visualizado no site do projeto9. O

relacionamento entre os padrões está detalhado no Apêndice C, e o detalhamento de cada padrão

focando somente no campo template (devido à limitação de espaço) está descrito no Anexo A.

9 http://www.studiodesigner.com.br/mestrado/sers/catalogo

90

Figura 10 - Catálogo de padrões de requisitos utilizado na abordagem.

91

4.5 REPOSITÓRIO

Conforme relatado em Marinho et al. (2003) e Hagge et al. (2005b), um repositório de

padrões permite o armazenamento de boas práticas de engenharia de requisitos e promove

mecanismos para facilitar a busca e aplicação desses padrões. Quanto ao acesso, deve ser garantido

a todos os desenvolvedores ligados ao repositório, proporcionando métodos para pesquisa e

manutenção, objetivando o seu reuso (PFAFFENSELLER et al., 2001).

Neste sentido, o repositório (considerando o contexto da abordagem proposta) armazena

dados relacionados a:

Projetos: contempla informações referentes a todos os projetos, armazenando informações

como, por exemplo, nome do projeto, descrição, nome da empresa, nome do responsável

pelo projeto, data de criação e interessados;

Usuários: corresponde tanto a informações relacionadas aos analistas dos projetos, quanto

aos interessados (envolvidos), armazenando dados como, por exemplo, nome, perfil,

email e senha;

Requisitos: envolve todos os tipos de requisitos abordados, a citar: (i) requisitos de

usuário; (ii) requisitos de sistema, contemplando requisitos funcionais e não funcionais.

Importante, considerar que, caso o requisito seja descrito a partir de um padrão, este deve

ser identificado. Assim, contemplando dados como a descrição breve e detalhada do

requisito, usuário que especificou o requisito, tipo do requisito, importância, urgência e

versão;

Padrões: corresponde a informações dos padrões de requisitos, armazenando informações

como, por exemplo, nome do padrão, objetivo do padrão, contexto, problema, forças,

exemplos e categoria do padrão. Observar-se que os padrões estão relacionados a uma

categoria ao qual ele se aplica (a citar: lógicos de base de dados, interfaces externas,

atributos do sistema, funcionais, restrições de projeto e desempenho), conforme descrito

na seção 4.4.

Rastreabilidade: envolve todas as informações de rastreabilidade entre os requisitos. A

rastreabilidade será promovida entre os requisitos funcionais e requisitos não funcionais.

92

4.6 MECANISMOS DE APOIO AO REUSO

A abordagem proposta neste trabalho prevê dois mecanismos de apoio à reutilização de

requisitos, sendo: padrões de requisitos e rastreabilidade.

Como primeiro mecanismo, destaca-se as sugestões de reuso a partir da seleção do padrão.

Ou seja, quando o analista seleciona um padrão para utilização, buscam-se sugestões de

especificações de requisitos de projetos anteriores que utilizaram o padrão selecionado. Por

exemplo, o analista seleciona o padrão de requisito de documentação para especificar um requisito,

em seguida, é possível resgatar do repositório especificações de requisitos de outros projetos que

fizeram uso deste padrão.

A partir da reutilização de um requisito (por sugestão de reuso a partir do padrão de requisito

selecionado), o segundo mecanismo de apoio fornece sugestões de reuso a partir do elo de

rastreabilidade. Assim, a técnica de rastreabilidade é utilizada nesta abordagem como um

mecanismo de apoio a reutilização de especificações de requisitos. O objetivo é aumentar o grau de

reutilização utilizando a rastreabilidade entre requisitos como uma forma de identificar outros

requisitos para um sistema novo a partir de sugestões de requisitos localizados pela rastreabilidade

entre requisitos em projetos anteriores. Cabe aqui mencionar, que as sugestões de reuso baseadas na

rastreabilidade só são possíveis a partir de um requisito já previamente reutilizado. Isso quer dizer,

que não é possível localizar outros requisitos pelo vínculo de rastreabilidade sem uma seleção de

um requisito sugestionado pela escolha de um padrão de requisito.

Para um melhor entendimento, observe o exemplo retratado na Tabela 11. O requisito

funcional RF02 está vinculado aos requisitos não funcionais RNF03, RNF06 e RNF09 pela

rastreabilidade de RF x RNF. No mecanismo de reuso a partir da rastreabilidade, se o RF02 for

selecionado para reutilização ou adaptação em um novo projeto, os requisitos não funcionais a este

relacionados serão sugeridos como requisitos com probabilidade de reuso neste novo projeto.

93

Tabela 11 - Exemplo de sugestão de reuso pela rastreabilidade.

RN

F01

RN

F02

RN

F03

RN

F04

RN

F05

RN

F06

RN

F07

RN

F08

RN

F09

RN

F10

...

...

RN

Fn

RF01 x RF02 x x x RF03 x x ... RFn x x x

Observa-se que para registro dos elos de rastreabilidade serão somente considerados

relacionamentos do tipo de dependência, os quais indicam que requisitos dependem uns dos outros

por restrições de recursos, competência ou compatibilidade (SPANOUDAKIS; ZISMAN, 2005).

Visando exemplificar a dinâmica dos mecanismos de reuso da abordagem, supõe-se que seja

necessário definir um requisito que especifica o cálculo do valor do frete para o envio de

mercadoria. Empregando a abordagem, o analista realiza busca no catálogo para selecionar o padrão

adequado para escrita, neste caso, o padrão “Fórmula de Cálculo” (conforme ilustrado na Figura

11A).

Neste momento, o analista pode optar por utilizar o padrão como ponto de partida para escrita

do requisito ou selecionar algum dos requisitos sugeridos a partir do padrão selecionado, devendo

ao final o requisito deve ser definido como consta na Figura 11B.

Resumo Definição Determinação do <<nome do valor>>

<<descrição do valor>> deve ser determinado da seguinte forma:

1. <<descrição do passo 1>> 2. <<descrição do passo 2>> 3. ...

(<<limitações de aplicabilidade>>) (<<referência>>) (Por exemplo, <<exemplo>>)

A

Resumo Definição Determinação do valor do frete

O frete deve ser determinado da seguinte forma: 1. calcula-se o valor do peso total da compra; 2. calcula-se o valor total da compra (valor

declarado); 3. com base no peso total calculado,

seleciona-se o valor correspondente “peso/destino” na tabela de preços do sedex fornecida pelos correios.

Limite máximo para declaração de valor: R$ 10.000,00. Referência do cálculo: tabela de valores do sedex. Por exemplo, peso total da compra é de 1kg, o valor da compra é de R$ 450,00, o destino é interior de Goiás. Para esta compra o valor do frete é de R$ 30,80.

B

Figura 11 - Exemplos de utilização de um padrão.

94

Caso o analista opte por selecionar uma opção sugerida para reuso (que utiliza o padrão

“Fórmula de Cálculo” e tem relação com frete), então os mecanismos de apoio ao reuso baseado no

vínculo de rastreabilidade poderá sugerir requisitos como os relacionados na Figura 12.

Resumo Definição Tipo de dados para peso de mercadoria

O peso da mercadoria, que são utilizados para cálculo do frete, deve ser do tipo double.

Tempo de resposta para as transações

Cada função de atendimento ao cliente (buscas, carrinho de compras, cálculo do frete, cadastro de cliente, e etc) deve ter um tempo de resposta não superior a 4 segundos, a partir da correta entrada de dados (quando se utiliza configuração mínima exigida pelo sistema). Este valor é baseado em indicativos de testes anedóticos que os usuários começam a perder a paciência logo após esse tempo.

Figura 12 - Exemplo de sugestões de reuso a partir da rastreabilidade.

4.7 FERRAMENTA DE APOIO

Diversos autores (YOUNG, 2004; WIEGERS, 2006) recomendam o apoio de ferramentas

para automatizar e gerenciar o processo de Engenharia de Requisitos. Neste ponto, destaca-se que o

apoio automatizado ao processo proposto, na forma de uma ferramenta computacional, é essencial

para viabilizar a implantação da abordagem.

De fato, a reutilização informal é possível, mas existem muitas vantagens em apoiar-se em

uma ferramenta computacional para realização de um processo de reuso (JOHNSON; HARRIS,

1991), pois uma ferramenta computacional disponibiliza mecanismos que facilitam o acesso,

identificação, seleção e entendimento do elemento reutilizável armazenado no repositório. No

entanto, há poucas ferramentas disponíveis atualmente que suportem o reuso de requisitos e, dentre

as existentes (conforme analisado na Seção 2.2.3 ), na maioria dos casos, o reuso ocorre a partir da

identificação do requisito a ser reutilizado pelo próprio usuário, sem nenhuma abordagem de apoio

a esta busca. Estudos atuais como o de Alves et al. (2010), indicam a necessidade de

desenvolvimento de ferramentas de apoio para linha de produtos de software, apontando carência de

soluções automatizadas para análise de requisitos de natureza textual. Além disso, técnicas para

recuperação, adaptação e consolidação de requisitos reutilizáveis têm recebido pouca atenção em

comparação a reutilização de software (LAMSWEERDE, 2000).

Assim, a ferramenta SERS (Sistema para Especificação de Requisitos de Software) é uma

ferramenta destinada a apoiar a elicitação e documentação de requisitos de software implementando

a abordagem aqui descrita.

95

4.7.1 Funcionalidades

De maneira geral, as principais funcionalidades da ferramenta podem ser divididas em 2

grupos:

Funcionalidades básicas – inerentes a qualquer ferramenta da área de requisitos de

software, a citar: (a) cadastro de usuário; (b) cadastro de projeto; (c) cadastro de

interessados; (d) cadastro das seções do documento de especificação de requisitos; (e)

cadastro de requisito de usuário; (f) cadastro de requisito de sistema; (g) rastreabilidade

entre requisitos; e (h) impressão do documento de especificação de requisitos.

Funcionalidades de apoio ao reuso – constituem o diferencial da ferramenta: (a) busca,

seleção e aplicação de padrões de requisito; (b) sugestão de requisitos para reuso baseado

em um padrão de requisito; e (c) sugestão de requisitos para reuso baseado nos vínculos

de rastreabilidade.

Focando nas funcionalidades que promovem o mecanismo de reuso da ferramenta, a Figura

13a ilustra a busca por um padrão (que pode ser feito por palavra-chave, selecionando uma

categoria ou por tipo de requisito) – o resultado da busca está retratado na Figura 13b. Ao escolher

um padrão, é apresentado ao usuário um detalhamento do mesmo (contemplando objetivo,

problema, contexto, forças, exemplo de utilização e template), permitindo ao usuário selecionar o

padrão para uso (Figura 13c). Caso o usuário já conheça o padrão, a seleção pode ser realizada a

partir da lista da Figura 13b.

96

Figura 13 - Interface de busca e seleção dos padrões.

Uma vez selecionado um padrão, o sistema apresenta a tela para cadastro de requisitos de

sistema, apresentando no campo de descrição o template do padrão selecionado (Figura 14a). Nesta

mesma interface, havendo requisitos para reusar, é apresentado o alerta ao usuário (Figura 14b).

Acessando a aba “Sugestões de reuso” o usuário encontra uma lista de requisitos de sistemas

(Figura 14c) que podem ser selecionados para: (i) reutilização compartilhada; (ii) copiar e manter

ligação; e (iii) copiar (os comportamentos previstos em cada caso estão descritos na seção 4.2)

97

Figura 14 - Interface de “Sugestão de Reuso” baseado no padrão selecionado.

Esse mecanismo faz sugestões de requisitos baseado nos requisitos especificados a partir do

padrão selecionado pelo usuário. Por exemplo, o usuário seleciona o padrão de requisito de

documentação, a partir daí, é possível resgatar do repositório especificações de requisitos de outros

projetos que fizeram uso deste mesmo padrão.

Por fim, quando um requisito é reutilizado o mesmo é inserido automaticamente na lista de

requisitos de sistema do projeto atual (Figura 15a). No entanto, se o requisito reutilizado possui

algum vínculo (rastreabilidade) no projeto original, estes requisitos vinculados também serão

sugeridos, consistindo assim em outro mecanismo para apoio ao reuso (conforme alerta ilustrado na

Figura 15b), exibindo mais uma lista de requisitos candidatos ao reuso (Figura 15c). Por exemplo, o

usuário reutiliza um requisito que trata do “registro de pagamento de locação”, a partir daí, é

possível sugerir os requisitos vinculados a este, como “taxa de atraso na devolução da locação”,

“verificação de permissões de acesso”, “tempo de resposta”, “acessibilidade”, dentre outros.

Neste sentido, a ferramenta SERS tem um papel muito importante na abordagem, pois,

oferece interfaces para busca, seleção e aplicação dos padrões de requisitos. Como também, auxilia

com interfaces de sinalização das sugestões de reuso, tanto nas baseadas nos padrões como nas de

vínculos de rastreabilidade.

98

Uma limitação presente na primeira versão desta ferramenta está relacionada às sugestões de

rastreabilidade. Como pode ser observado na Figura 15c as sugestões de reuso partem de um RF

para RNF. Em uma próxima versão pretende-se implementar a possibilidade de relacionamento

entre requisitos independentemente do enquadramento do requisito (funcional ou não funcional).

Com esta melhoria, espera-se a ampliação das sugestões de requisitos. Outra limitação refere-se a

possibilidade de manutenção dos padrões, os quais são fixos na versão atual da ferramenta. No

entanto, espera-se disponibilizar opções de personalização e adição de padrões para uso individual,

como também, espaços como Web Wiki ou fóruns para discussão de possíveis padrões para agregar

ao catálogo.

Figura 15 - Interface de "Sugestão de Reuso" baseado na rastreabilidade.

Esta seção apresentou a ferramenta de apoio à abordagem, mais detalhes sobre o projeto da

ferramenta são apresentados no Apêndice H. Uma avaliação da percepção de uso da ferramenta foi

realizada e seus resultados são discutidos na seção 5.1.4.2.


Neste capítulo foi apresentada a abordagem de reuso de requisitos visando apoiar a atividade

de elicitação e especificação de requisitos. A abordagem está fundamentada em três pilares, estes

sendo: padrões de requisito, catálogo de padrões e rastreabilidade. Esta abordagem de reuso de

99

requisitos utiliza dois mecanismos de sugestões de reuso de requisitos: (i) na seleção do padrão,

onde as sugestões partem de requisitos que foram especificados utilizando um padrão selecionado, e

(ii) pelo vínculo de rastreabilidade, em que as sugestões emergem dos requisitos rastreados dos

requisitos já reutilizados.

A aplicação desta abordagem de reuso tem como objetivo auxiliar o analista na etapa de

elicitação de requisitos através de sugestões de requisitos que possivelmente ajudariam a identificar

outros requisitos relacionados a partir do histórico de projetos similares. Este aspecto contribui

evitando esquecimento de funcionalides e apoiando o analista com pouco conhecimento sobre o

domínio. Além disso, também auxilia na condução da especificação do requisito (escrita) utilizando

templates fornecidos a partir de padrões de requisitos.

Os padrões de requisitos são oriundos do catálogo proposto por Withall (2007), este adotado

por ser considerado mais completo e detalhado (conforme resultado de um mapeamento sistemático

realizado para este fim). No entanto, o catálogo de Withall (2007) foi reclassificado procurando

conciliar os seus domínios com as observações da norma IEEE Std 830-1998 (1998). Além disso,

os padrões foram organizados dentro de uma estrutura com o objetivo de facilitar a sua busca e

seleção.

Também foi apresentado um processo para reutilização de requisitos, composto por atividades

que devem ser realizadas de forma iterativa para o desenvolvimento do documento de especificação

de requisitos. Este processo descreve como se relacionam os conceitos envolvidos e como é

viabilizado o reuso. Além disso, também foi apresentada a estrutura do repositório utilizado pela

abordagem para armazenamento do conhecimento.

E por fim, é apresentada a ferramenta baseada em web denomida SERS que presta apoio a

abordagem aqui proposta, implementando as funcionalidades básicas de uma ferramenta da área de

engenharia de requisitos e as funcionalides de apoio ao reuso.

No próximo capítulo são apresentados os estudos executados para avaliar a aplicação da

abordagem aqui proposta.

100

5 AVALIAÇÃO DA ABORDAGEM

Este capítulo apresenta o detalhamento das avaliações realizadas da abordagem, bem como

os resultados obtidos. A primeira trata de um quase-experimento que foi realizado no meio

acadêmico visando verificar e coletar dados para análise quantitativa da abordagem. Aproveitou-se

a oportunidade e também foi realizada uma avaliação da ferramenta de apoio. Assim, através da

proposta de desenvolvimento de estudos de caso, buscou-se identificar se a abordagem atingiu o

objetivo proposto de tornar mais eficiente e eficaz a atividade de elicitação de requisitos de

software.

Além dessas avaliações, este capítulo também apresenta uma avaliação qualitativa guiada

pelo método GQM (Goal-Question-Metrics) (BASILI et al., 1994), sob o ponto de vista de

especialistas, com o objetivo de se obter mais indicadores da viabilidade de aplicação da

abordagem.

Neste sentido, este capítulo tem o caráter de detalhar o planejamento, condução e análise dos

resultados das avaliações realizadas da abordagem proposta no capítulo 4 .

5.1 QUASE-EXPERIMENTO

Em relação aos seus objetivos, a avaliação visou verificar se a abordagem de reuso proposta

realmente torna mais eficiente e eficaz a atividade de elicitação de requisitos, em relação à execução

desta atividade sem o apoio da abordagem. Trata-se de um quase experimento por não utilizar uma

distribuição aleatória dos participantes.

5.1.1 Planejamento

O planejamento completo do quase-experimento foi realizado adaptando-se uma instância do

framework desenvolvido por Kochanski (2009), que se encontra no Apêndice I. No entanto, esta

seção apresenta algumas informações relevantes para o entendimento do quase-experimento.

Cabe salientar que o planejamento do quase-experimento prevê o envolvimento de dois

grupos (controle e experimental), sendo que ambos realizaram atividades envolvendo a elicitação e

documentação de requisitos a partir de 2 estudos de caso distintos.

101

O primeiro estudo de caso é apresentado no Apêndice D e trata de um projeto de loja virtual

para uma livraria. O segundo estudo de caso é apresentado no Apêndice E descrevendo um projeto

de uma locadora de veículos. O modelo de correção para o primeiro estudo de caso encontra-se no

Apêndice F e para o segundo estudo a correção é orientada pelo modelo retratado no Apêndice G.

Convém ressaltar que os modelos de correções foram revisados por um professor de Engenharia de

Software (este não participante do estudo).

Ressalta-se também que para viabilizar o reuso se faz necessária a existência de projetos

compartilhados. Assim, foram cadastrados projetos (e compartilhados) de domínios semelhantes aos

estudos de caso propostos, estes sendo oriundos de trabalhos de conclusão de curso (TCC) e

propostas de estudos de caso de cursos relacionados à área de computação (disponíveis em FALBO,

2011; FGSYS, 2010; MAGALHÃES et al., 2008).

5.1.2 Execução do Experimento Piloto

Antes de realizar a experimentação, optou-se em conduzir um experimento piloto com o

objetivo de identificar possíveis problemas os quais viessem a prejudicar a avaliação. Esse

experimento foi realizado com dois acadêmicos do curso de Ciência da Computação, ambos

colaboradores do laboratório L2S da UNIVALI. Os participantes apresentam o mesmo perfil, como

programadores com pelos menos 3 anos de experiência e conhecimento sobre as atividades e etapas

da engenharia de requisitos. O cenário de utilização foi o mesmo empregado ao grupo experimental,

sendo ministrada uma aula sobre os assuntos inerentes a abordagem e aplicação do estudo de caso

para elaboração do documento de especificação de requisitos utilizando a ferramenta de apoio. O

experimento foi realizado no laboratório de informática da UNIVALI, tendo um tempo total de 3

horas na sua execução.

Em resumo, o Quadro 4 apresenta em um âmbito geral as dificuldades observadas e as

adequações realizadas.

Quadro 4 - Resumo das observações e adequações do experimento piloto.

Dificuldade encontrada Adequação realizada

Problema de desempenho da ferramenta. Optou-se pela instalação da ferramenta de apoio em pelo menos dois servidores na rede local. Essa medida foi tomada porque em testes realizados na ferramenta fora da universidade, a ferramenta apresentou um desempenho

102

satisfatório e suficiente. Cabe dizer que houve contato com o administrador da rede na ocasião, sendo confirmada a suspeita de que havia problemas com acesso a rede externa (internet) nos dias precedentes ao experimento.

Um dos participantes não tinha uma visão clara sobre a diferença entre requisito de usuário e requisito de sistema (houve necessidade de explicação adicional ao conteúdo ministrado antes do experimento).

Foram feitas adequações nos slides de revisão no tópico de engenharia de requisitos, dando foco em mais exemplos didáticos.

Tamanho do estudo de caso: talvez os participantes não consigam realizá-lo por completo.

Foi realizada uma redução do escopo dos estudos de caso propostos, porém vale enfatizar que ambos passaram por nova revisão para verificar possíveis inconsistências.

Dificuldade na seleção do padrão mais adequado para aplicação em um requisito (provavelmente ocorrido em virtude do pouco conteúdo ministrado sobre os padrões).

Foi feita adequação do conteúdo apresentado nos slides sobre padrões, optando pela adição de mais exemplos demonstrativos de sua aplicação.

Alguns artefatos do conjunto de dados do repositório de conhecimento para reuso apresentavam erros de escrita.

Foi realizada uma revisão ortográfica no texto dos artefatos destinados para a base de reuso visando corrigir erros.

5.1.3 Execução

Participaram do quase-experimento 24 acadêmicos da disciplina de Engenharia de Software,

do 5º período do curso de graduação em Ciências da Computação da Univali/Campus de Itajaí,

vinculados às aulas e atividades referentes ao conteúdo de Engenharia de Requisitos ministrado na

disciplina.

Para a realização do quase-experimento, optou-se em dividi-lo em duas etapas, conforme

processo exposto na Figura 16. Antes da primeira etapa, foi ministrada uma aula introdutória (3hs)

sobre engenharia de requisitos, abordando as etapas básicas do processo (elicitação, análise,

documentação e validação), bem como definição de requisitos e tipos (de usuário e de sistema –

funcional e não funcional) uma semana antes do experimento.

No dia da realização do quase-experimento, inicialmente foi explicado a todos os

participantes os objetivos e a importância do experimento e a sua livre participação, e, a partir daí,

deu-se início a primeira etapa. Como primeiro passo, todos os participantes participaram de uma

aula sobre os padrões de requisitos e uma revisão superficial sobre especificação de requisitos,

103

sendo essa revisão aplicada como apoio necessário identificado pelo experimento piloto. Logo após,

foi apresentada a todos os participantes a ferramenta de apoio à abordagem em seu modo

standard10.

Figura 16 - Etapas do processo seguido na avaliação da abordagem.

Após este momento, os participantes assinaram o termo de concordância do Apêndice J e

preencheram o questionário de perfil do Apêndice K. Em um próximo momento foi realizado o

sorteio para divisão dos participantes em grupos e equipes. O sorteio foi realizado com cada

participante retirando um papel que estabelecia identificadores como A1, A2, A3, B1, B2 e B3.

Havia dois papéis de cada identificador (formando a dupla), sendo que os identificadores “A”

compuseram o grupo experimental e o identificador “B” o grupo de controle. Assim, obteve-se seis

equipes de dois participantes para cada grupo.

Quanto ao perfil dos participantes em relação a sua atuação profissional (conforme retratada

pela Figura 17), percebe-se que o maior número é composto por programadores, com um percentual

de 36%. Em seguida, são participantes com experiência na área de suporte com 24%, os indivíduos 10 Standard aqui refere-se as funcionalidades básicas da ferramenta de apoio, ou seja, foram suprimidas as funcionalidades de seleção/aplicação dos padrões e todos os mecanismo de sugestão de reuso.

104

com nenhuma experiência somam 20%, analistas e outros com percentual de 8% e testadores com

percentual de 4%.

Figura 17 - Perfil dos participantes.

A Figura 18 retrata a análise sobre o conhecimento dos participantes em relação ao

conhecimento em engenharia de requisitos obtida a partir do questionário de perfil dos participantes

(disponível no Apêndice K). Para responder a esta questão (questão 4 do Apêndice K) os

participantes deveriam apontar um valor de 0 a 6 para mensurar seu conhecimento atual em

engenharia de requisitos, sendo 0 para “nenhum”, 1 para “Tenho pouco conhecimento do assunto”,

2 para “Conheço o básico”, 3 para “Aplico na prática como dependência de outros”, 4 para “Aplico

na prática sem dependência de outros”, 5 para “Tenho bastante conhecimento do assunto” e 6 para

“Sei tudo sobre o assunto”. Aqui nota-se que o conhecimento dos participantes do grupo

experimental é muito próximo do grupo de controle.

0

0,5

1

1,5

2

2,5

3

3,5

Grupo Experimental Grupo Controle

Nív

el d

e co

nhec

imen

to

Análise sobre o conhecimento atual dos participantes em Engenharia de Requisitos

Figura 18 - Análise do conhecimento dos participantes.

105

O gráfico boxplots ilustrado na Figura 19 apresenta mais detalhes da representação da

distribuição dos grupos em relação ao nível de conhecimento em engenharia de requisitos (referente

à questão 4 do Apêndice K). Este gráfico proporciona a comparação dos grupos e ao mesmo tempo

as medidas de centralidade (média/mediana) e de dispersão (desvio padrão/variância). Percebe-se

que os valores da mediana, primeiro e terceiro quartil, são os mesmos em ambos os grupos, assim,

mesmo havendo participantes no limite superior e inferior do grupo de controle não existem

discrepância, sendo que os mesmos estão dentro dos limites. Contudo, foi realizado um teste não

paramétrico Chi-Square com auxilio da ferramenta SPSS (SPSS, 2011) para verificar se o nível de

conhecimento em engenharia de requisito entre os grupos apresentava diferença. Por sua vez, o

resultado do teste demonstrou que os grupos de participantes não apresentavam diferença

significativa em relação ao seu conhecimento em engenharia de requisitos (p = 0,530). Optou-se por

este teste por se basear na comparação da frequência observada na amostra com as frequências

esperadas (ESTEVES; SOUZA, 2007, p.67).

Figura 19 - Gráfico da representação do conhecimento dos grupos.

Na segunda parte do quase-experimento, o grupo B (controle) foi deslocado para outro

laboratório com a supervisão de outro pesquisador, o grupo A (experimental) continuou no mesmo

laboratório e recebeu mais um tratamento, sendo que 25 minutos foram gastos na apresentação das

106

demais funcionalidades da ferramenta e explanações sobre os mecanismos de reuso. O tempo médio

para realização do experimento em ambos os grupos foi de aproximadamente 110 minutos.

Seguindo a sequência planejada para o quase-experimento, os participantes receberam um

estudo de caso no qual deveriam localizar requisitos funcionais e não funcionais. A quantidade de

estudos de caso foi distribuída de forma equânime entre os grupos, ou seja, 3 grupos dos 6

utilizaram o estudo de caso do projeto de e-commerce e os outros 3 grupos utilizaram o estudo de

caso da locadora de veículos, isso em cada grupo (experimental e controle), assim, totalizando 12

projetos.

Sendo assim, o próximo passo da experimentação foi gerar a especificação de requisitos

para o estudo de caso com o auxílio da ferramenta de apoio. No caso do grupo de controle, a

aplicação dos templates dos padrões foi realizada de forma ad-hoc, ou seja, foi disponibilizado um

link11 para que o catálogo dos padrões pudesse ser consultado para sua utilização (tal procedimento

teve como objetivo comparar apenas os benefícios do reuso, sem considerar o benefício do uso dos

padrões). Já os participantes do grupo experimental utilizaram todas as funcionalidades da

ferramenta, beneficiando-se das sugestões de reuso de requisitos de projetos já previamente

cadastrados no repositório da ferramenta.

Depois da realização da atividade proposta nos estudos de caso, os participantes responderam

um questionário de percepção (disponível no Apêndice L o questionário do grupo experimental e no

Apêndice M o aplicado no grupo de controle). O objetivo foi capturar a opinião dos participantes

referente à utilização da ferramenta e alguns aspectos da abordagem, indicando (em alguns casos)

aspectos positivos e/ou melhorias na ferramenta.

Depois de finalizado o quase-experimento, os dados coletados foram tabulados para permitir a

realização das análises e testes para verificação das hipóteses formuladas pela pesquisa. A Seção

5.1.4 apresenta os resultados obtidos nesta avaliação.

11 http://www.studiodesigner.com.br/mestrado/sers/catalogo/

107

5.1.4 Resultados

A partir do quase-experimento realizado foi possível mensurar, de forma preliminar, qual a

contribuição da abordagem e da ferramenta na área da Engenharia de Requisitos. Assim, obtendo

uma resposta às seguintes perguntas de pesquisa:

Q1 – A utilização da abordagem proposta para reuso de requisitos torna mais eficiente o

processo de elicitação de requisitos em relação ao não emprego da abordagem?

Q2 – A utilização da abordagem proposta para reuso de requisitos torna mais eficaz o

processo de elicitação de requisitos que uma abordagem sem a utilização de reuso?

Ou seja, buscou-se avaliar se a abordagem de reuso proposta realmente torna mais eficiente e

eficaz a atividade de elicitação de requisitos em relação à execução desta atividade sem o apoio da

abordagem. Para tanto, foram formuladas as seguintes hipóteses:


eficiência12 do processo de elicitação quando utilizada a abordagem de reuso em relação

ao seu não uso.

HA1 (hipótese alternativa ao H01): A eficiência do processo de elicitação utilizando

abordagem baseada em reuso é maior em relação a não utilização da abordagem.


eficácia13 do processo de elicitação quando utilizada a abordagem de reuso em relação ao

seu não uso.

HA2 (hipótese alternativa ao H02): A eficácia do processo de elicitação utilizando

abordagem baseada em reuso é maior em relação a não utilização da abordagem.

12 a eficiência foi calculada como a razão entre o número de requisitos corretamente descritos e o tempo gasto na execução na atividade de elicitação de requisitos. 13 A eficácia da abordagem é medida como a relação entre o número de requisitos corretamente descritos e o número total de requisitos existentes.

108

Nesse sentido, os resultados foram obtidos partindo de 3 aspectos: (i) o tempo gasto por cada

grupo buscando identificar requisitos; (ii) o resultado do estudo de caso de cada grupo (obtido

diretamente do repositório da ferramenta); e (iii) questionário de percepção.

A seguir é apresentado o detalhamento dos resultados obtidos deste estudo, incluindo a

avaliação da abordagem e avaliação da percepção de uso da ferramenta de apoio.

5.1.4.1 Avaliação da Abordagem

Depois de realizadas as experimentações e todos os dados coletados, os mesmos foram

tabulados de forma a permitir a realização das análises para comprovar ou refutar as hipóteses de

pesquisa. O modelo de correção para o estudo de caso 1 (livraria online) previa um total de 18

requisitos, sendo 9 requisitos funcionais e 9 requisitos não funcionais. Para o modelo de correção do

estudo de caso 2 (locadora de veículos) estavam previstos um total de 22 requisitos, sendo 15

requisitos funcionais e 7 requisitos não funcionais. A Tabela 12 sintetiza os resultados,

considerando os grupos A experimental e B de controle.

Tabela 12 - Resultado dos estudos de caso. Grupo Q.Enc1 Q.Esp2 Q.Reuso3 Tempo Eficiência Eficácia

ESTUDO DE CASO 1 A1 8 9 1 100 0,080 0,444 A4 7 9 4 99 0,070 0,388 A6 4 5 2 101 0,039 0,222 B3 5 24 - 105 0,047 0,277 B4 2 10 - 105 0,019 0,111 B5 2 5 - 105 0,019 0,111

ESTUDO DE CASO 2 A2 7 10 7 110 0,063 0,318 A3 6 9 4 102 0,058 0,272 A5 7 20 4 94 0,074 0,318 B1 4 10 - 105 0,038 0,181 B2 0 11 - 105 0 0 B6 4 6 - 105 0,038 0,181

(1)Q.Enc é a quantidade de requisitos encontrada; (2) Q.Esp é a quantidade de requisitos especificados em relação ao documento modelo; e (3) Q.Reuso é a quantidade de requisitos reutilizados.

Em relação os resultados do estudo de caso 1, observa-se que somente 1 grupo (B3), não

apoiado pela abordagem, obteve um resultado maior em relação à eficiência e eficácia, sendo este

somente superior ao grupo (A6). Mesmo assim, cabe ressalta que o grupo B3 especificou 24

requisitos (número muito superior em relação aos outros grupos) para obter um acerto de apenas 5

requisitos.

109

Analisando os resultados do grupo B3 em relação aos requisitos especificados que não foram

considerados como corretos, pode-se afirmar que a grande maioria se tratava de especificações em

não conformidade com o modelo de correção, a citar: “envio de dados de cartão de crédito via

post”, “campo de CEP”. Também foram realizadas especificações que se utilizaram de padrões

inadequados para a especificação, por exemplo: especificação do requisito “cálculo do frete”

utilizando o padrão de requisito “Transação” em vez de ser utilizado o padrão de requisito “Fórmula

de cálculo”. Um grande percentual das especificações consideradas erradas foi referente a

especificações que não utilizaram um padrão (aspecto exigido em ambos os grupos) ou requisitos

repetidos (situações sinônimas ou homônimas), por exemplo, “busca de produto” e “busca de

produtos com informações parciais”.

Na análise dos resultados do estudo de caso 2, fica evidente que os grupos apoiados pela

abordagem obtiveram resultados superiores, tanto na eficiência quanto na eficácia da atividade. A

Figura 20 (análise de eficiência) e Figura 21 (análise de eficácia) ajudam a ilustrar as observações

em relação aos dois grupos.

0,08

0,038

0,063

0

0,058

0,047

0,07

0,019

0,074

0,019

0,039 0,038

00,010,020,030,040,050,060,070,080,09

Grupo A (experimental) Grupo B (controle)

Efic

iênc

ia c

alcu

lada

Comparativo da eficiência da abordagem

Figura 20 - Análise da eficiência.

110

0,444

0,181

0,318

0

0,272 0,277

0,388

0,111

0,318

0,222

0,0500,1000,1500,2000,2500,3000,3500,4000,4500,500

Efic

ácia

calc

ulad

a

Comparativo da eficácia da abordagem

Figura 21 - Análise da eficácia.

A Tabela 13 apresenta os dados dos projetos que contaram com as sugestões de reuso da

abordagem, nela é apresentado o percentual de requisitos reutilizados (“% Reuso” QR. RF + QR.

RNF) em relação ao total de requisitos encontrados (Q. ERF + Q. ERNF). Percebe-se, aqui, que em

dois grupos (A4 e A6) a taxa de reutilização foi de pelo menos 50% em relação aos requisitos

encontrados no estudo de caso 1, sendo a média de 46,82% de reutilização nesses projetos. Já

quanto ao reuso no estudo de caso 2, um grupo (A2) conseguiu atingir 100% de reutilização, sendo

a média de 74,60% de reutilização.

Outro aspecto que pode ser analisado é quanto à quantidade de reuso por categoria de

requisito. Observa-se que a quantidade de requisitos funcionais reutilizados foi sempre maior,

exceto no grupo A5 (que são iguais em ambas as categorias). Este fato destoa de algumas pesquisas

que afirmam serem requisitos não funcionais mais propícios para o reuso (FRANCH et al., 2010).

Tabela 13 - Análise sobre o percentual de reuso. Grupo Q. ERF1 Q. ERNF2 QR. RF3 QR. RNF4 % Reuso5

ESTUDO DE CASO 1 A1 2 1 1 0 33,33% A4 3 4 3 1 57,14% A6 2 2 2 0 50%

ESTUDO DE CASO 2 A2 5 2 5 2 100% A3 4 2 3 1 66,66% A5 5 2 2 2 57,14%

(1)Q.ERF é a quantidade de requisitos funcionais encontrados; (2) Q.ERNF corresponde à quantidade de requisitos não funcionais encontrados; (3) QR.RF é a quantidade de requisitos funcionais reutilizados; (4) QR.RNF a quantidade de requisitos não funcionais reutilizada; e (5) o percentual de reutilização total no projeto.

111

Cabe, ainda, analisar os mecanismos de apoio ao reuso (apresentados na Figura 22). Esta

análise considera as sugestões provenientes dos padrões de requisitos (no momento da seleção de

um padrão) e as sugestões a partir da rastreabilidade (sendo realizada após a reutilização de um

requisito).

0

1

2

3

4

5

A1 A2 A3 A4 A5 A6

Tota

l de

requ

isito

s reu

tiliz

ados

Grupos

Reuso a partir dos diferentes mecanismos

Padrões Rastreabilidade

Figura 22 - Análise dos mecanismos de reuso.

Os resultados demonstram que a maioria das aceitações de reuso foi promovida pelas

sugestões baseada nos padrões, aspecto já esperado, uma vez que as sugestões por rastreabilidade

são decorrentes da reutilização a partir do uso de um padrão. No entanto, destacam-se os grupos A4

e A5, os quais encontraram maior benefício a partir das sugestões de rastreabilidade. Estes dados

indicam que ambos os mecanismos de apoio favoreceram ao reuso.

Por fim, a Figura 23 apresenta o resultado comparativo entre os dois grupos em relação à

eficiência de eficácia. A média aritmética da eficiência do grupo A foi de 0,064 e do grupo B foi de

0,026. Quanto à eficácia, o grupo A apresentou o resultado de 0,327 e o grupo B de 0,143.

112

00,05

0,10,15

0,20,25

0,30,35

Eficiência Eficácia

0,064

0,327

0,026

0,143

Comparativo da eficiência e eficácia dos grupos

Grupo Experimental Grupo Controle

Figura 23 - Análise comparativa entre os resultados obtidos pelos grupos.

Com base nos resultados apresentados na Figura 23 têm-se indicativos de que a abordagem

trouxe eficiência e eficácia ao processo de elicitação e documentação de requisitos. O resultado com

o apoio da abordagem se mostrou 40,62% superior em relação à eficiência no grupo experimental e

apresentou uma eficácia de 43,73% maior em relação a sua condução sem o emprego da

abordagem.

No entanto, se faz necessária uma análise estatística para aceitar ou rejeitar as hipóteses com

base nos elementos amostrais para confirmar esses resultados. Neste sentido, a Tabela 14 apresenta

os dados dos resultados para análise da eficiência e eficácia classificadas para aplicação do teste

estatístico de Mann-Whitney. Observa-se que o uso de um teste não paramétrico é mais apropriado

porque a amostra não segue uma distribuição normal.

Tabela 14 - Classificação14 dos grupos.

Classificação dos Grupos Classificação quanto a Eficiência Classificação quanto a Eficácia

Sequência Grupo Classificação Eficiência Sequência Grupo Classificação Eficácia 1 B 1,00 0 1 B 1,00 0 2 B 2,50 0,019 2 B 2,50 0,111 3 B 2,50 0,019 3 B 2,50 0,111

14 A classificação é iniciada em 1 para o menor resultado, no entanto, havendo dois ou mais resultados iguais, a classificação é obtida através do cálculo da média do valor correspondente a sua sequência que essas observações teriam se não fossem iguais.

113

4 B 4,50 0,038 4 B 4,50 0,181 5 B 4,50 0,038 5 B 4,50 0,181 6 A 6,00 0,039 6 A 6,00 0,222 7 B 7,00 0,047 7 A 7,00 0,272 8 A 8,00 0,058 8 B 8,00 0,277 9 A 9,00 0,063 9 A 9,50 0,318 10 A 10,00 0,070 10 A 9,50 0,318 11 A 11,00 0,074 11 A 11,00 0,388 12 A 12,00 0,080 12 A 12,00 0,444

A partir dos resultados obtidos pela classificação, o próximo passo foi a realização do

cálculo das médias e a somatória dos ranks conforme retratado pela Tabela 15. Observa-se que a

somatória dos ranks (ou valor do R) é calculada a partir da soma das ordens para cada uma das duas

amostras conforme (1).

1

111

n

jjrR e

2

122

n

jjrR

(1)

onde R1 = somatória do rank do grupo A, R2 = somatória do rank do grupo B, n1 = tamanho

da amostra do grupo A e n2 = tamanho da amostra do grupo B, j = valor da sequência atual, r1j =

valor da classificação atual de j em relação ao grupo A e r2j = valor da classificação atual de j em

relação ao grupo B.

O campo “média do rank” da Tabela 15 corresponde a média da classificação atribuída a um

grupo. Por ele já é possível supor que o grupo A é superior na eficiência e na eficácia em relação ao

grupo B.

Tabela 15 - Resultados da classificação (ranks) em relação à eficiência.

Ranks Eficiência Eficácia

Grupo N Média Somatório Grupo N Média Somatório A 6 9,33 56 A 6 9,17 55 B 6 3,67 22 B 6 3,83 23

O calculo do U crítico da estatística de Mann-Whitney (U) é realizado conforme (2).

114

222

212

111

211

2)1(

2)1(

RnnnnU

RnnnnU

(2)

onde U = valor do U crítico, n1 = tamanho da amostra do grupo A, n2 = tamanho da amostra

do grupo B, R1 = somatória do rank do grupo A e R2 = somatória do rank do grupo B.

A estatística do teste é dada por (3).

U = min(U1,U2) (3)

onde U = valor mínimo entre o valor de U1 e U2, U1 = valor do U crítico do grupo A e U2 =

valor do U crítico do grupo B.

Ao escolher o menor resultado de U para eficiência obteve-se o valor 1. Em relação à

eficácia o menor resultado de U foi 2. Assim, seguindo o teste estatístico, o valor de intersecção

entre n1 = 6 e n2 = 6 com α = 0.05 tem-se o valor de Uc = 5 e com α = 0.01 tem o valor de Uc = 2.

Como base nestes resultados pode-se rejeitar as hipóteses H01 (Não existe diferença quanto à

eficiência do processo de elicitação quando utilizada a abordagem de reuso em relação ao seu não

uso) e H02 (Não existe diferença quanto à eficácia do processo de elicitação quando utilizada a

abordagem de reuso em relação ao seu não uso).

Posto isto, pode-se afirmar ao nível de significância de 5% e 1% que a abordagem proposta

auxilia na atividade de elicitação e especificação de requisitos, tornando-a mais eficiente e eficaz.

Outra análise que reforça esses resultados é retratada pelos boxplots a seguir que comparam

o grupo experimental com o grupo de controle em relação à eficiência e a eficácia. Ao analisar a

Figura 24, pode-se observar que o boxplots do grupo experimental está acima do terceiro quartil do

grupo de controle. Este resultado significa que o grupo experimental foi mais eficiente que o grupo

de controle.

115

Figura 24 - Boxplots comparando a eficiência dos grupos.

A comparação oferecida pelo boxplots ilustrado na Figura 25 representa que o grupo

experimental obteve um resultado mais eficaz que o grupo de controle. Também se percebe que a

maioria dos grupos enquadrados como experimental estão acima de sua própria média. Também é

possível identificar a discrepância do resultado de um dos grupos enquadrado como controle.

Figura 25 - Boxplots comparando a eficácia dos grupos.

Desta maneira, em termos das questões de pesquisa propostas neste trabalho:

Q1 – A utilização da abordagem proposta para reuso de requisitos torna mais

eficiente o processo de elicitação de requisitos em relação ao não emprego da

abordagem?

116

Q2 – A utilização da abordagem proposta para reuso de requisitos torna mais eficaz

o processo de elicitação de requisitos que uma abordagem sem a utilização de reuso?

Os resultados apresentados indicam que a utilização da abordagem contribui na atividade de

elicitação de requisitos, tornando-a mais eficiente e eficaz comparando-a a não utilização da

abordagem.

5.1.4.2 Avaliação da Percepção de Uso da Ferramenta

Através do questionário de percepção respondido ao final do experimento, os participantes

relataram suas impressões a respeito da ferramenta SERS. Para tal utilizou-se a escala de Likert

(FERGUSON, 1941) de 5 pontos para indicar o grau de concordância dos participantes no

experimento. A Figura 26 apresenta os resultados dos questionários dos participantes do grupo

experimental.

0

5

10

15

Concordo totalmente

Concordo parcialmente

Indiferente Não concordo particialmente

Não concordo totalmente

Análise da percepção do grupo experimental

A ferramenta apresentou funcionalidades adequadas para documentação de requisitos.

A ferramenta foi fácil de utilizar.

O reuso de requisitos contribuiu significativamente na elicitação (identificação) dos requisitos.

O uso dos padrões auxiliou na escrita dos requisitos.

Utilizaria a ferramenta na minha prática profissional

Figura 26 - Resultado do questionário de percepção do grupo experimental.

O resultado dos questionários dos participantes do grupo de controle é ilustrado pela Figura

27. Observa-se que a questão que trata o reuso de requisitos foi suprimida devido a não utilização

deste recurso pelo grupo de controle.

117

0

2

4

6

8

Concordo totalmente


Indiferente Não concordo particialmente


Análise da percepção do grupo controle


A ferramenta foi fácil de utilizar.


Utilizaria a ferramenta na minha prática profissional

Figura 27 - Resultado do questionário de percepção do grupo controle.

Percebe-se, aqui, com base nos resultados apresentados sobre análise dos questionários

(retratado pelas Figura 26 e Figura 27) que para ambos os grupos os aspectos que tratam da

ferramenta (funcionalidades, facilidade de uso e adoção da ferramenta) são positivos. Quanto à

utilização dos padrões para escrita de requisitos foi observado que no grupo em que não tinha o

apoio da ferramenta houve uma variação significativa entre as opiniões, porém dentro de um grau

de concordância na sua utilização. O grupo A confirma que a utilização dos padrões auxilia na

escrita dos requisitos. Como também o reuso de requisitos contribuiu na identificação de requisitos.

Ainda na avaliação de percepção foram elaboradas 3 questões para considerações sobre

aspectos relacionados à atividade, ferramenta e padrões, sendo: (i) aspectos positivos da atividade;

(ii) aspectos a serem melhorados na atividade; e (iii) impressões sobre as opções de sugestão de

reuso.

Os resultados envolvendo a primeira questão foram observados por todos participantes como

uma ferramenta fácil e intuitiva de usar. Em relação à segunda questão, poucos participantes do

grupo experimental fizeram recomendações, sendo as recomendações recebidas relativas a aspectos

de melhoria na interface. Já os participantes do grupo de controle fizeram recomendações no

sentido de integrar a busca e aplicação dos padrões na ferramenta (já disponível na versão do grupo

experimental). Quanto à terceira questão, aplicada somente aos participantes do grupo experimental,

obteve-se como resultado que todos concordam que os mecanismos de reuso fizeram sugestões que

118

em algum momento auxiliaram a encontrar requisitos os quais puderam ser reutilizados. Também

houve relatos que as sugestões ajudaram a diminuir o tempo na execução da atividade. Como

sugestões de melhoria nesta funcionalidade houve contribuições no sentido de melhorar a interface

de busca nas sugestões de reuso realizadas pela ferramenta.

5.1.4.3 Avaliação da Validade

Contudo, a execução do quase-experimento para avaliar a abordagem e verificar a

viabilidade da ferramenta possui ameaças à validade. É mister ressaltar que ao diminuir uma

ameaça pode-se conduzir ao aumento de outras. Neste sentido, as ameaças à validade consideradas

neste estudo são:

Validade de conclusão: o problema identificado foi em relação ao tamanho pequeno da

amostra e homogeneidade. Em relação ao tamanho, é certo afirmar que os resultados obtidos são

considerados apenas indícios e não resultados conclusivos. Em relação à homogeneidade, foi

aplicado um questionário para avaliar os grupos para controlar esta ameaça.

Validade interna: duas ameaças foram identificadas: (1) os participantes não estarem

interessados pelo estudo realizado, e não colaborarem com uma efetiva participação; (2) o fato de a

abordagem envolver certo grau de dificuldade na utilização/seleção dos padrões de requisitos pode

gerar fadiga nos participantes pelo esforço empregado, diminuindo o empenho e comprometimento

dos mesmos. Em relação à questão (1) a ação tomada foi motivar os participantes na realização das

atividades do experimento demonstrando a importância do experimento em ambiente acadêmico,

bem como a atividade foi pontuada na disciplina. Em relação a questão (2) foi ministrada uma aula

sobre padrões de requisitos, reforçando a ação tomada na questão (1);

Validade externa: três ameaças foram identificadas: (1) os participantes serem alunos de

graduação; (2) estudo realizado em ambiente acadêmico e; (3) participantes de determinado grupo

terem conhecimentos prévios. Em relação às questões (1) e (2) existem relatos na literatura que

estudantes apresentam habilidades similares a profissionais menos experimentes (CAVER et al.,

2003). Em relação à (3) os participantes foram avaliados através do questionário de perfil dos

participantes levando em consideração o seu conhecimento sobre a engenharia de requisito

(capturado pela questão 4 do Apêndice K), sendo que o teste não paramétrico Chi-Square

119

demonstrou que não havia diferenças significativas entre os grupos (conforme destacado na seção

5.1.3 ).

5.2 ANÁLISE DE ESPECIALISTAS

Apesar dos resultados apresentados apontarem que a abordagem proposta torna a atividade de

elicitação de requisitos mais eficiente e eficaz comparando-a a sua não utilização, tem-se uma forte

ameaça a estes resultados - os participantes não possuíam um grau de experiência desejável para

prática da atividade de elicitação de requisitos.

Por outro lado, entende-se que a reprodução de um experimento fora do ambiente acadêmico

não seria viável, isso porque, a utilização da abordagem é impactante no processo de

desenvolvimento das empresas, assim, dificultando encontrar empresas dispostas a

“experimentarem” a abordagem. Portanto, optou-se por uma avaliação qualitativa com especialistas

no sentido de obter uma avaliação da abordagem sob o ponto de vista de profissionais ligados a área

de engenharia de requisitos.

Desta maneira, a avaliação aplicada com especialistas tem por base o método GQM - Goal-

Question-Metrics (BASILI et al., 1994), assim, as seções a seguir detalham o planejamento,

execução e resultados desta avaliação.

5.2.1 Planejamento

Como passo inicial de uma avaliação utilizando o método GQM (BASILI et al., 1994), deve-

se identificar os objetivos da avaliação, e em seguida elaborar as questões com base nesses

objetivos. O método orienta que cada questão deve possuir pelo menos uma medida relacionada

para avaliação do dado coletado, como também se deve definir como os dados serão coletados,

quem irá fazer a coleta e quando ela será realizada.

Neste sentido, o Quadro 5 apresenta o objetivo da medição, as questões e as métricas adotadas

para a avaliação.

120

Quadro 5 - Questões e métrica. Objetivo

Avaliar uma abordagem de reuso de requisitos em relação à eficiência e eficácia sob o ponto de vista de especialistas experientes em engenharia de requisitos no contexto de especificação e documentação de requisitos de software.

Questões Métricas H1 Q1. Qual a sua impressão subjetiva sobre o percentual na agilidade na atividade de elicitação e documentação de requisito quando da utilização da abordagem, comparado com a não utilização desta?

MQ1.1. Impressão subjetiva do percentual de variação do tempo com o emprego da abordagem comparando a não utilização.

H2 Q2. O artefato de software (documento de especificação de requisitos) produzido com a abordagem é mais completo e correto do que aquele produzido em outra abordagem?

MQ2.1. Grau de concordância em relação a completude e corretude do documento com a utilização da abordagem comparando com a não utilização. (Entendendo por completude como a quantidade de requisitos corretamente identificados e corretude como a quantidade de requisitos corretamente descritos)

MQ2.2. Impressão subjetiva do percentual de variação da completude do documento com a utilização da abordagem comparando com a não utilização. (Entendendo por completude como a quantidade de requisitos corretamente identificados)

MQ2.3. Impressão subjetiva do percentual de variação da corretude do documento com a utilização da abordagem comparando com a não utilização. (Entendendo por corretude como a quantidade de requisitos corretamente descritos)

MQ2.4. Lista de itens não atendidos no artefato produzido.

Geral Q3. A utilização dos padrões/catálogo ajudou a guiar a escrita dos requisitos?

MQ3.1. Grau de concordância subjetiva do conteúdo dos padrões adotado pela abordagem.

MQ3.2. Grau de concordância subjetiva da facilidade em encontrar um padrão adequado no catálogo disponibilizado.

MQ3.3. Lista das dificuldades encontradas com a utilização dos padrões.

Q4. As sugestões de reuso foram adequadas? MQ4.1. Grau de concordância subjetiva das sugestões associadas ao padrão.

MQ4.2. Grau de concordância subjetiva das sugestões associadas a rastreabilidade.

MQ4.3. Lista das dificuldades encontradas com as sugestões de reuso.

Q5. A ferramenta de apoio proporcionou algum rendimento na execução da atividade?

MQ5.1. Grau de concordância subjetiva sobre os benefícios proporcionados pela ferramenta.

MQ5.2. Impressão subjetiva sobre os benefícios proporcionados pela ferramenta.

MQ5.3. Lista de dificuldade encontrada com o uso da ferramenta.

A partir das perguntas e métricas enunciadas para alcançar o objetivo desta avaliação,

apresenta-se na Tabela 16 o plano de coleta de dados. O plano de coleta de dados relaciona a

121

métrica utilizada com a forma em que estes são coletados e quem será responsável em fornecer os

dados.

Tabela 16 - Plano de coleta de dados. Métrica Como coletar? Quem fornece? MQ1.1. Impressão subjetiva do percentual de variação do tempo com o emprego da abordagem comparando a não utilização.

Questionário – Questão 1 Especialista em engenharia de requisitos

MQ2.1. Grau de concordância em relação a completude e corretude do documento com a utilização da abordagem comparando com a não utilização. (Entendendo por completude como a quantidade de requisitos corretamente identificados e corretude como a quantidade de requisitos corretamente descritos)


MQ2.2. Impressão subjetiva do percentual de variação da completude do documento com a utilização da abordagem comparando com a não utilização. (Entendendo por completude como a quantidade de requisitos corretamente identificados)


MQ2.3. Impressão subjetiva do percentual de variação da corretude do documento com a utilização da abordagem comparando com a não utilização. (Entendendo por corretude como a quantidade de requisitos corretamente descritos).


MQ2.4. Lista de itens não atendidos no artefato produzido. Questionário – Questão 2 Especialista em engenharia de requisitos

MQ3.1. Grau de concordância subjetiva do conteúdo dos padrões adotado pela abordagem.


MQ3.2. Grau de concordância subjetiva da facilidade em encontrar um padrão adequado no catálogo disponibilizado.


MQ3.3. Lista das dificuldades encontradas com a utilização dos padrões.


MQ4.1. Grau de concordância subjetiva das sugestões associadas ao padrão.


MQ4.2. Grau de concordância subjetiva das sugestões associadas a rastreabilidade.


MQ4.3. Lista das dificuldades encontradas com as sugestões de reuso.


MQ5.1. Grau de concordância subjetiva sobre os benefícios proporcionados pela ferramenta.


MQ5.2. Impressão subjetiva sobre os benefícios proporcionados pela ferramenta.


MQ5.3. Lista de dificuldade encontrada com o uso da ferramenta.


Como próximo passo, foi criado um questionário para a identificação do perfil do especialista

(retratado pelo Apêndice O) seguida pelas perguntas direcionadas à obtenção das medidas desejadas

e elencadas no GQM.

122

5.2.2 Execução

A pesquisa contou com a participação de 6 (seis) especialistas ligados a área de engenharia de

requisitos. Os participantes foram previamente convidados a colaborar com a pesquisa através de

convite enviado através de email, nesta etapa foram convidados 8 especialistas. Após a confirmação

do interesse em colaborar com a pesquisa por parte do participante, iniciou-se o agendamento para

aplicação da avaliação individualmente com cada um. Assim, a avaliação foi realizada na primeira

quinzena de julho (11/07/2011 a 20/07/2011).

A condução das avaliações foi realizada na presença do autor desta pesquisa, auxiliando o

participante com informações para condução da atividade proposta e, sanando possíveis dúvidas. De

modo geral, a avaliação consistiu na realização de 3 etapas. A primeira etapa tratava da

apresentação da proposta da abordagem e explanação sobre o catálogo de padrões e utilização da

ferramenta de apoio. Na segunda etapa, os participantes realizaram um estudo de caso (utilizou-se

os mesmos aplicados na experimentação descrita anteriormente) utilizando a ferramenta de apoio.

Cabe mencionar aqui que não foi exigida a conclusão do estudo de caso, mas que foi aplicado até o

ponto em que o participante julgasse necessário para o entendimento de todos os elementos e

mecanismos propostos pela abordagem. Como terceira e última etapa os participantes responderam

o questionário para avaliação (retratado pelo Apêndice O).

A partir daí, os dados coletados através do questionário foram tabulados e categorizados para

uma posterior análise. Cabe salientar que a interpretação dos dados foi realizada em sua maioria de

forma qualitativa através da análise do conteúdo dos questionários obtidos em avaliações

individuais.

5.2.3 Resultados

Após a análise dos dados observa-se que todos os participantes da avaliação afirmaram

possuirem experiência na área de engenharia de requisitos, sendo que o tempo de experiência na

elaboração de documentos de especificações de requisitos varia de 3 a 7 anos.

Em relação a primeira questão, a Figura 28 apresenta a impressão subjetiva dos especialistas

em relação ao percentual de agilidade (ganho de tempo) que a abordagem proporcionou em

comparação a sua não utilização.

123

0 0

1

4

1

0

1

2

3

4

5

6

Nenhum 1% - 25% 26% - 50% 51% - 75% 76% - 100%

Q1. Qual a sua impressão subjetiva sobre o percentual de agilidade (ganho de tempo) que a atividade de elicitação e documentação de requisitos obtêm quando da

utilização da abordagem, comparado com a não utilização desta?

Figura 28 - Indicativo percentual sobre a agilidade na atividade de elicitação e documentação de requisito utilizando a abordagem.

Percebe-se aqui, que a maior parte dos especialistas (66,66%) considerou que a abordagem

proporcionou um ganho de tempo entre 51% a 75% nas atividades de elicitação e documentação

dos requisitos.

A segunda questão buscou avaliar a percepção dos especialistas em relação ao artefato

produzido pela abordagem, o documento de especificação de requisitos. Assim, buscou-se avaliar o

percentual de variação da corretude15 e completude16 do documento comparado com a sua não

utilização. A Figura 29 retrata o resultado da análise sobre o indicativo percentual em relação a

completude e corretude do documento produzido pela abordagem.

15 Entende-se por corretude como a quantidade de requisitos corretamente descritos. 16 Entende-se por completude como a quantidade de requisitos corretamente identificados.

124

1 12 2

1 12 2

0123456

Nenhum 1% - 25% 26% - 50% 51% - 75% 76% - 100%

Q2. Em relação ao artefato de software “Documento de especificação de requisitos” produzido com a abordagem, qual a sua impressão subjetiva sobre o percentual de

melhoria da abordagem em relação à completude e corretude?

Completude Corretude

Figura 29 - Indicativo percentual da análise em relação a completude e corretude do artefato produzido.

Observa-se que a maior parte dos especialistas considerou que o artefato produzido

(documento de especificação de requisito) tem um percentual maior de completude e corretude de

melhoria do que a sua produção de forma ad-hoc. Com essa questão, também se buscou verificar os

itens não atendidos na elaboração do artefato produzido, assim, os analistas deveriam analisar e

relacionar os itens que ainda não estivesse em conformidade com um “bom documento de

especificação de requisitos”. Cabe salientar aqui que as orientações na produção do documento de

especificação de requisitos (em relação às seções do documento e os aspectos em relação as

característica de um bom documento, podendo citar: ambiguidade, consistência, classificação em

importância e/ou estabilidade, verificável, rastreável e etc.) deveria seguir a especificação orientada

pela norma IEEE Std 830-1998 (1998), e essa observação foi relatada a todos os especialistas. Neste

aspecto, esperava-se que os especialistas que assinalaram sua percepção em relação a completude e

corretudo do artefato produzido menor que “76% - 100%” justificassem a sua escolha e relatassem

o que ainda falta ser atendido, no entato, não houve nenhuma observação.

A terceira questão buscou verificar com os especialistas aspectos relacionados a utilização

dos padrões/catálogo de requisitos. A Figura 30 ilustra o resultado do indicativo de percentual de

ajuda que os padrões e o catálogo proporcionaram na escrita dos requisitos em consideração o

emprego dos padrões adotados pela abordagem.

125

1 1

4

0

1

2

3

4

5

6

Nenhum 1% - 25% 26% - 50% 51% - 75% 76% - 100%

Q3. Em relação a utilização dos padrões/catálogo de requisitos, qual a sua impressão subjetiva sobre o percentual de ajuda na escrita dos requisitos quando considerado o

emprego dos padrões adotados pela abordagem?

Figura 30 - Indicativo percentual da análise em relação a ajuda proporcionada pelo emprego dos padrões/catálogo.

Pode-se destacar aqui que a maior parte dos especialistas (66,66%) considerou que o

padrões/catálogo ajudou na elaboração da escrita dos requisitos. Nesta questão os especialistas

também puderam opinar sobre a seguir afirmação: “Você considera que foi fácil localizar um

padrão adequado no catálogo disponibilizado?”. Assim, 4 especialistas afirmaram concordar

totalmente com a afirmação, e 2 especialistas concordaram parcialmente. Em complemento a esta

questão também se buscou dos especialistas observações sobre as dificuldades encontradas com a

utilização dos padrões. Neste sentido, os 2 especialistas que concordaram parcialmente com a

afirmação apresentada anteriormente realizaram comentários como: “Sem o conhecimento do

catálogo fica um pouco complicado encontrar o padrão desejado” e “Sugestionamento com base em

experiências anteriores, recomendação de usabilidade: acrescentar dicas”. De fato, para a utilização

dos padrões faz-se necessária um treinamento ou estudo prévio para a sua compreensão, no entanto,

a maioria dos especialistas concordou que o agrupamento dos padrões por objetivo ou domínios

distintos dispostos pela abordagem proporcionou certo grau de facilidade na sua localização.

A quarta questão desta avaliação tinha o objetivo de avaliar se as sugestões de reuso foram

adequadas. Neste sentido, os especialistas puderam opinar em relação a duas afirmações: “Você

concorda que as sugestões associadas aos padrões foram adequadas?” e “Você concorda que as

sugestões associadas à rastreabilidade foram adequadas?”. Aqui, todos os especialistas afirmaram

concordar totalmente com ambas as afirmações. Também se oportunizou nesta questão as

observações dos especialistas em relação às dificuldades encontradas com as sugestões de reuso, no

entanto, nenhuma observação foi realizada.

126

A quinta e última questão visou verificar se a ferramenta de apoio proporcionou algum

rendimento na execução da atividade. Aqui os especialistas puderam opinar em relação a seguinte

afirmação: “A ferramenta de apoio proporcionou algum benefício na execução da atividade de

elicitação e documentação de requisitos?”. Como resultado, 5 especialistas afirmaram concordar

totamente com a afirmação e 1 afirmou concorda parcialmente. Conforme retratado na Figura 31,

também se verificou nesta questão a impressão subjetiva sob o rendimento proporcionado com o

apoio da ferramenta na execução da atividade.

1

3

2

0

1

2

3

4

5

6

Nenhum 1% - 25% 26% - 50% 51% - 75% 76% - 100%

Q5. Em relação a ferramenta de apoio, qual a sua impressão subjetiva sobre o percentual de ajuda que a ferramenta proporcionou?

Figura 31 - Indicativo percentual da análise em relação ao rendimento proporcionado pela ferramenta de apoio da ferramenta

Nota-se que a maioria dos especialistas considerou que a ferramenta proporcionou um apoio

entre 51% - 75% (sendo esta a opinião de 50% dos especialistas) de rendimento superior na

execução das atividades em relação a sua não utilização. Buscou-se saber também nesta questão se

existiram dificuldades na utilização da ferramenta, sendo que a única observação retratava:

“Acredito que uns poucos ajustes de usabilidade deixaria a ferramenta muitíssimo interessante”.

De acordo com os dados coletados, pode-se verificar, de modo geral, que também se tem

indicativos que a abordagem proposta auxilia na atividade de elicitação e especificação de

requisitos na percepção de especialista na área de engenharia de requisitos.


Neste capítulo foi apresentada a descrição de 3 avalições executadas para avaliar a abordagem

aqui proposta. A primeira avaliação trata de um quase experimento que foi realizado em ambiente

127

acadêmico no sentido de medir a eficiência e eficácia da abordagem da atividade de elicitação e

especificação de requisitos, em relação à execução destas atividades sem o apoio da abordagem. Foi

também realizada uma análise estatística sobre os dados coletados no sentido de aceitar ou rejeitar

as hipóteses formuladas para esta pesquisa. Neste momento, utilizou-se o teste não paramétrico de

Mann-Whitney por se tratar da comparação de dois grupos com amostras independentes e com

variável de mensuração ordinal (MARÔCO, 2011, p.219). Os resultados desta primeira avaliação

apresentaram indicativos que a utilização da abordagem torna as atividades de elicitação e

especificação de requisitos mais eficiente e eficaz em relação a sua condução sem o apoio da

abordagem.

Por sua vez, após a realização do quase experimento foi aplicada uma segunda avaliação com

os participantes no sentido de avaliar a percepção de uso da ferramenta de apoio. Nesta avaliação

foi utilizada a escala de Likert (FERGUSON, 1941) de 5 pontos para indicar o grau de

concordância dos participantes em relação às questões exploradas pela avaliação. O resultado da

avaliação mostrou que os participantes do grupo experimental (que utilizaram a ferramenta em sua

versão completa) avaliaram de forma positiva a ferramenta em relação a suas funcionalides e

consideraram que os padrões de requisitos e as sugestões de reuso auxiliaram na elaboração do

documento de especificação de requisitos. Por outro lado, os participantes do grupo de controle (que

não tiveram disponíveis as funcionalidades ligadas à seleção e aplicação dos padrões e as sugestões

de reuso) relacionaram observações no sentido de melhorar a ferramenta com implementação de

funcionalides no sentido de facilitar a busca e aplicação dos padrões de requisitos.

A terceira avaliação foi realizada na tentativa de reduzir o viés que surge a partir da análise da

abordagem em um ambiente acadêmico, onde os participantes provavelmente não possuam um grau

de experiência desejável para a prática na indústria. Neste sentido, optou-se em realizar uma

avaliação junto a especialistas na área de engenharia de requisitos com objetivo de se obter mais

indicadores da viabilidade de aplicação da abordagem. É importante ressaltar que esta avaliação tem

um caráter mais exploratório, sendo que alguns pontos precisam ser melhorados para que se possa

obter resultados mais confiáveis. Nesta avaliação foi utilizado o método GQM (BASILI et al.,

1994), obtendo-se uma avaliação da abordagem sob o ponto de vista de profissionais ligados a área

de engenharia de requisitos. De acordo com os resultados obtidos nesta avaliação, pode-se afirmar

que se têm indicativos que a abordagem auxilia na atividade de elicitação e especificação de

requisitos segundo sob o ponto de vista de especialistas.

128

O estudo descrito neste capítulo foi um primeiro passo no sentido de avaliar a abordagem

proposta neste trabalho. O resultado das avaliações indicaram que a abordagem proposta (apoiada

pela ferramenta) auxiliou na atividade de elicitação e especificação de requisitos. No entanto, os

resultados desse estudo são limitados em diferentes aspectos, restringindo a sua generalização.

Sendo assim, se entende que seria necessária a aplicação de mais estudos de caso e experimentos

para uma avaliação mais conclusiva. E por fim, as limitações exposta ao longo do trabalho,

associadas a outros pontos a serem investigados, apresentam a perspectiva de realização de outros

trabalhos, inclusive focando outros aspectos relacionados à abordagem de linha de produtos de

software.

129

6 CONCLUSÃO

É de amplo conhecimento da comunidade de engenharia de software que o processo de

Engenharia de Requisitos é repleto de dificuldades na etapa de elicitação e especificação dos

requisitos de sistema. Dificuldades essas que normalmente estão ligadas a requisitos especificados

de forma incompleta, ou com pouco conhecimento sobre o domínio no qual ele se aplica, ou

relacionadas ao pouco conhecimento sobre as reais necessidades dos usuários, além de

especificações que tratam condições sinômimas ou homônimas. Essas dificuldades tornam-se uma

barreira para o sucesso de um projeto, isso porque, o sucesso de um sistema de software é

decorrente do cumprimento das finalidades para o qual o sistema foi desenvolvido. Assim, o não

entendimento pleno das necessidades de seus usuários é denotado como um dos maiores causadores

do insucesso de projetos de software.

Por sua vez, diversos autores ressaltam a importância da engenharia de requisitos e seus

impactos, principalmente, em relação aos custos e sucesso dos projetos. Neste cenário, o reuso de

artefatos de requisitos é visto por diversos pesquisadores como uma alternativa para ajudar nas

atividades de engenharia de requisitos, a fim de diminuir ou eliminar o impacto causado pelas

dificuldades destacadas anteriormente. De forma geral, a adoção de uma abordagem de reuso de

requisitos proporciona redução no tempo de construção e aumenta a qualidade do produto

desenvolvido, assim, conduzindo a uma melhora na qualidade do processo de engenharia de

requisitos. No entanto, considerando as abordagens encontradas na literatura poucas realizam uma

avaliação para verificar a sua eficiência e eficácia.

Neste sentido este trabalho propôs uma abordagem de reuso de requisitos e buscou verificar

se esta abordagem tornaria mais eficiente e eficaz o processo de elicitação e especificação de

requisitos. A abordagem está fundamentada em três pilares: (i) padrões de escrita de requisitos para

a estruturação do conhecimento auxiliando no reuso; (ii) catálogo de padrões provendo mecanismo

para facilitar a seleção de um padrão; e (iii) rastreabilidade para sugerir novos requisitos a partir de

um requisito reutilizado. Com estes elementos explorou-se a possibilidade de fornecer

automaticamente sugestões de requisitos para reutilização, aspecto este não explorado pelas

abordagens existentes.

130

Destaca-se ainda que a abordagem proposta neste trabalho buscou facilitar e potencializar a

reutilização de requisitos, apoiando-se em técnicas já consolidadas na literatura e na indústria. Outra

contribuição deste trabalho está nos resultados obtidos através de duas avaliações.

A primeira avaliação foi realizada no meio acadêmico com 24 participantes divididos em

duplas, com o objetivo de verificar a eficiência e eficácia da abordagem em relação a condução das

atividades de elicitação e especificação de requisitos de forma tradicional (sem a abordagem de

reuso disponível). Comparando-se o resultado do grupo de controle com o grupo experimental,

constatou-se que 11 entre 12 estudos de caso avaliados foram mais eficientes e eficazes utilizando a

abordagem de reuso.

A segunda avaliação foi realizada como o objetivo de corroborar o resultado da primeira

avaliação, assim, utilizando o método GQM foram coletados dados para análise sob o ponto de vista

de especialistas na área de engenharia de requisitos em relação à eficiência e eficácia da abordagem.

O resultado de ambas as avaliações indicaram que a abordagem proposta auxiliou na

atividade de elicitação e especificação de requisitos. De fato, os resultados da primeira avaliação em

um experimento controlado indicaram que a eficiência e eficácia da abordagem foram superiores no

grupo experimental em relação ao grupo de controle. No entanto, cabe destacar que o quase-

experimento foi restrito a 2h de execução, assim, não se pode afirmar que os resultados

permaneçam com o uso mais prolongado (sistemático) da abordagem. Salienta-se também que a

eficiência medida é relacionada a 2 pessoas em ambos os grupos, embora não relacionada aqui

como “esforço” a sua medição também pode ser realizada na razão homens-hora. Outro aspecto que

merece destaque é quanto ao repositório para reuso, entende-se que os desafios na utilização inicial

da abordagem sejam maiores, isso porque ainda não se detem uma repositório de artefatos para

reutilização formada, aspecto este também presente na maioria das outras abordagens de reuso.

Cabe ainda ressaltar que os padrões armazenados (e utilizados na experimentação) são

provenientes do catálogo de Withall (2007) em sua versão completa (sem excluir nenhum padrão).

No entanto, encoraja-se investigações em busca de outros padrões de forma a complementar este

catálogo. Guias de como descobrir/reconhecer um padrão de requisito é abordado em Withall

(2007), Renault et al., (2009b) e Gotzhein et al., (1998). Outro aspecto observado é que mesmo

havendo um template como ponto de partida para especificação de um requisito, pode-se encontrar

131

outras soluções (templates) para adicionar ao padrão como forma de complementá-lo. Este é outro

aspecto presente nesta abordagem e não identificada nas demais.

Por fim, pode-se afirmar que todos os objetivos específicos delineados para este trabalho

foram alcançados. No entanto, é pertinente salientar que os resultados obtidos nesta pesquisa não

são definitivos, sendo estes passíveis de serem aprimorados e revistos.

6.1 RESULTADOS

Neste trabalho são discutidas propostas para contribuir com a atividade de elicitação e

especificação de requisitos. Após estudos e pesquisas na área, foi definido o objetivo geral de

desenvolver uma abordagem para reuso de requisitos e avaliar de forma empírica a sua eficiência e

a eficácia. Com este objetivo foram identificados os seguintes resultados obtidos ao longo do

processo de desenvolvimento desta pesquisa:

#1: um mapeamento sistemático da literatura que teve o objetivo identificar, analisar e avaliar

pesquisas voltadas para o conhecimento de padrões de escrita de requisitos na disciplina de

engenharia de requisitos, com a intenção de conhecer o estado da arte referente a padrões de escrita

de requisitos. É importante destacar que o mapeamento pode permitir a descoberta de evidências

identificadadas em um alto nível de granularidade sobre escrita de requisito utilizando padrões,

como também serviu de ponto de partidade para direcionar o foco em futuros mapeamentos ou

revisões sistemáticas. Além disso, também permite identificar áreas para estudos primários que

ainda necessitam de investigações.

#2: apresentação de uma estrutura para comportar os padrões de requisitos adotados. A

apresentação de uma estrutura pode favorecer a adoção e utilização dos padrões, segundo Cheng e

Atlee (2007) os mesmos carecem de uma apresentação (estrutura) que forneça informações

suficientes para facilitar a sua reutilização. No entanto, percebe-se a necessidade de pesquisa para

identificar quais informações são realmente relevantes ao analista para propiciar o entendimento de

um padrão de requisito.

#3: elaboração do catálogo de padrões procurando conciliar os domínios propostos por

Withall (2007) e a norma IEEE Std 830-1998 (1998). Entende-se que a taxonomia utilizada pela

132

norma IEEE Std 830-1998 (1998) é a mais próxima da vivência do analista, sendo assim, seria mais

fácil a localização de um padrão que estivesse em um domínio conhecido.

#4: análise comparativa das abordagens de reuso de requisitos realizada a partir da revisão

sistemática do Konda e Mandava (2010). A análise comparativa abre caminho para a discussão

sobre as abordagens, permitindo extrair semelhanças e divergências existentes entre os estudos

analisados.

#5: descrição de um novo processo de reutilização baseados nos conceitos adotados pela

abordagem (padrões de requisitos, catálogo de padrões e rastreabilidade). Esta é a principal

contribuição do trabalho, apresentando uma abordagem nova de forma a contribuir com a

comunidade.

#6: desenvolvimento de uma ferramenta de apoio à abordagem proposta. A partir da pesquisa

do estado da arte (capítulo 3 e seção 2.2.3), percebeu-se que existe uma carência de ferramentas que

apoiem a reutilização de requisitos. Assim, este trabalho contribuiu como uma solução nesta área.

#7: resultados de uma avaliação realizada através experimento controlado (avaliação

empírica) verificando a eficiência e eficácia da abordagem proposta em relação a sua não utilização.

#8: resultados de uma avaliação da percepção do uso da ferramenta de apoio.

#9: resultados de uma avaliação sob o ponto de vista de especialista em relação à eficiência e

a eficácia da abordagem.

Conforme enfatizado por Travassos et al., (2002), somente a experimentação pode verificar as

teorias e explorar os fatores críticos dando a luz ao fenômeno novo dando espaço para que as teorias

possam ser formuladas e corrigidas. Em complemento Basili (2007) argumenta que as

experimentações podem ser consideradas uma pequena contriuição para a tapeçaria do

conhecimento, ou seja, ajudam a formar o corpo de conhecimento. Neste sentido, de apresentar um

corpo novo de conhecimento e dando abertura para que as teorias possam ser formuladas e/ou

corrigidas que os resultados #7, #8 e #9 pontuam.

133

6.2 TRABALHOS FUTUROS

Como recomendações e sugestões de trabalhos para evoluir a presente pesquisa se pode

destacar:

Desenvolvimento das recomendações realizadas pelos participantes do primeiro

experimento e dos especialistas em relação à ferramenta de apoio, a grande maioria

tratando de aspectos relacionados à usabilidade.

Análise e desenvolvimento de outros padrões a fim de complementar o catálogo com mais

possibilidades. Outro ponto interessante também é a adição de mais templates (soluções

em forma de como fazer, ou ponto de partida para escrita de requisitos) para os padrões

atuais existentes no catálogo.

Outra sugestão é o desenvolvimento de um plugin que implemente a abordagem em uma

ferramenta já existente, com por exemplo: Eclipse, DOORS, RequisitePro, Enterprise

Architect, etc.

Sugere-se o desenvolvimento de um terceiro mecanismo de apoio ao reuso, implementado

através da associação entre os padrões, estes já previstos no catálogo de padrões.

Propor a reutilização em nível de produto, em que o produto é detentor de um ou vários

projetos.

Desenvolvimento de funcionalidades para fornecer o uso de métricas de suporte a

estimativas. Por exemplo, relacionando-se cada requisito do repositório com seus dados

históricos, permitiria o cálculo do esforço de programação, prazos e custos, auxiliando

com informações para a estimativas de tamanho, produtividade e alocação de pessoas.

Desenvolvimento de um guia em formato de heurísticas para fornecer orientações para o

levantamento e escrita de requisitos de usuário.

Moderação na inclusão de requisitos no repositório, para verificar o conteúdo dos

requisitos que serão compartilhados para reuso.

Desenvolvimento de funcionalidades ligadas à prototipação de telas.

134

Por fim, sugere-se realizar novos experimentos visando verificar a eficiência e a eficácia

da abordagem proposta em empresas de desenvolvimento de software.

135

REFERÊNCIAS

AKERS, D., Real Reuse for Requirements, Issue of Methods & Tools, Spring, 2008. Disponível em: < http://www.methodsandtools.com/PDF/mt200801.pdf>. Acessado em julho de 2010.

ALEXANDER, C., ISHIKAWA, S., SILVERSTEIN, M., JACOBSON, M., FIKSDAHL-KING, I., ANGEL. S. A Pattern Language. Oxford University Press, New York, 1977

ALVES, V., Niu, N., ALVES, C. and VALENÇA, G. Requirements engineering for software product lines: A systematic literature review, IST, Volume: 52, Issue: 8, August, 2010, pp. 806-820, Elsevier, 2010

AMATRIAIN, X. An Object-Oriented Metamodel for Digital Signal Processing with a focus on Audio and Music, Universitat Pompeu Fabra, Departament de Tecnologia. Tesi de doutorado em informática e comunicação digital. 2004

ANDRADE, M. M. Introdução à metodologia do trabalho científico. 4 ed., São Paulo: Atlas, 1999

ANTONELLIS, V. D., VANDONI, L. Temporal Aspects in Reuse of Requirement Specifications, Advanced information Systems Engineering. F. B. C. Rolland, and C. Cauvet. London, Springer-Verlag. Volume 685: pp: 504-520, 1993

BARBER, K.S. GRASER, T.J. JERNIGAN, S.R. SILVA, J. The Systems Engineering Process Activities (SEPA) - supportingearly requirements analysis and integration prior to implementationdesign. In Australian Journal of Information Systems (AJIS)---Special Issue on Requirements Engineering 7 (1), 75-97, 1999

BASILI, V. The Role of Controlled Experiments in Software Engineering Research, Lecture Notes in Computer Science, 2007, Volume 4336, Empirical Software Engineering Issues. Critical Assessment and Future Directions, Pages 33-37, Springer-Verlag Berlin Heidelberg, 2007

BASILI, V., CALDIERA, G., ROMBACH, H. D. Goal Question Metric Approach, Encyclopedia of Software Engineering, pp. 528-532, John Wiley & Sons, Inc., 1994

BECKER, M., Towards a general model of variability in product families. In: Proceedings of the 1st Workshop on Software Variability Management, pp. 19-27, Groningen, The Netherlands, 2003

BRERETON, P., KITCHENHAM, B. A., BUDGEN, D., TURNER, M., KHALIL, M. Lessons from applying the systematic literature review process within the software engineering domain, Journal of Systems and Software 80, 2007

BOEHM, B., BASILI, V. R.. Software Defect Reduction Top 10 List, IEEE Computer. 34(1); Los Alamitos, CA: IEEE Computer Society; 2001, doi:10.1109/2.962984

CARD, D., COMER, E. Why do So Many Reuse Programs Fail?, IEEE Software, Vol. 11, No. 05, September/October, 1994, pp. 114-115

136

CHENG, B. H. C., ATLEE, J. M. Research Directions in Requirements Engineering, International Conference on Software Engineering 2007 Future of Software Engineering, IEEE Computer Society Washington, DC, USA, 2007, ISBN:0-7695-2829-5

CHRISTEL, M. G., KANG, K. C. Issues in Requirements Elicitation, Technical Report Software Engineering Institute CMU/SEI-92-TR-12.7, September 1992. Disponível em:http://www.sei.cmu.edu/pub/documents/92.reports/pdf/tr12.92.pdf. Acessado outubro de 2009.

CLEMENTS, P., NORTHROP, L., Software Product Lines: Practices and Patterns, Addison-Wesley, 2002

CONSTANTOPOULOS, P., JARKE, M., MYLOPOULOS, J., VASSILIOU, Y. The Software Information Base: A Server for Reuse, In. The VLDB Journal — The International Journal on Very Large Data Bases, Springer-Verlag New York, 1995

COPLIEN, J. O. A Development Process Generative Pattern Language, Proceedings of PLoP/94, Monticello, 1994

CUNHA, G. E., HERBERT, J. S. Proposta de Padrões de Software para a Reutilização Sistemática em Sistemas de Software Orientados a Objetos, SugarloafPlop 2003 Conference, 2003

CYBULSKI, J. L., REED, K. Requirements Classification and Reuse: Crossing Domain Boundaries. In Conference on Software Reuse, ICSR'2000, (Vienna, Austria, 2000), 190-210, 2000

CYSNEIROS, L. M., LEITE, J. C. S. P. Utilizando Requisitos Não Funcionais para Análise de Modelos Orientados a Dados, Anais do WER98 - Workshop em Engenharia de Requisitos, Maringá-PR, Brasil, Outubro 12, 1998, pp 149-158. Disponível em: <http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER98/cysneiros.pdf>. Acessado junho de 2010

DAHLSTEDT, A., G., PERSSON, A. Requirements Interdependencies: State of the Art and Future Challenges. In AURUM, A., WOHLIN, C. Engineering and Managing Software Requirements, Springer: Germany, 2005, p.95-116

DAVEY, B; COPE, C. Requirements Elicitation – What’s Missing?, Issues in Informing Science and Information Technology, vol.5, 2008

DICK, J. Rich Traceability, Proceedings of the 1st International Workshop on Traceability in Emerging Forms of Software Engineering, Edinburgh, Scotland, 2002

EDEVTECH, inteGREAT Requirement Studio, 2010, Disponível em: <www.edevtech.com>, Acessado em: Outubro de 2010.

ESTEVES, E., SOUZA, C. Apontamento de Análise de dados e Planeamento de Experiências, 2007. Disponível em: http://w3.ualg.pt/~eesteves/docs/TestesQualidadeAjustamento.pdf. Acessado em julho de 2011.

FALBO, R. A. Documento de Requisitos - Vídeo Locadora Passatempo, 2011. Diponível em http://www.inf.ufes.br/~falbo/files/DocumentoRequisitos-v2.1.pdf. Acessado em 19 de março de 2011

137

FALBO, R. A., MARTINS, A. F., SEGRINI, B. M., BAIÔCO, G., DAL MORO, R., NARDI, J. C. Um Processo de Engenharia de Requisitos Baseado em Reutilização de Ontologias e Padrões de Análise. VI Jornadas Iberoamericanas de Ingenieería del Software e Ingeniería del Conocimiento, Lima - Perú, 2007

FAVARO, J. What price Reusability? A Case Study, Proceedings of the first international symposium on Environments and tools for Ada, California, United States, Vol. 11, No. 03, April, 1991, pp. 115-124.

FERGUSON, L. W. A Study of the Likert Technique of Attitude Scale Construction, Journal of Social Psychology 13, pp: 51-57, 1941

FERNANDES, P. C. C. Ubifex: Uma Abordagem Para Modelagem De Características De Linha De Produtos De Software Sensíveis Ao Contexto, COPPE/UFRJ - Mestrado em Engenharia de Sistemas e Computação, 2009

FGSYS, Documento de Requisitos (Sistema de Automação Comercial - Controle de Fábrica), 2010. Disponível em http://files.hilaiaproject.webnode.com.br/200000010-3f59b40547/Requisitos%20vers%C3%A3o%201.pdf. Acessado em 21 de março de 2011

FRAKES, W. B., ISODA, S. Success Factors of Systematic Reuse, IEEE Software, September 1994, pp. 14-19

FRANCH, X., PALOMARES, C., QUER, C., RENAULT, S., LAZZER, F. A Metalmodel for Software Requirement Patterns*, REFSQ 2010, Springer-Verlag: Berlin, p.85-90, 2010

FREDJ, M., ROUDIÈS, O. A Pattern Based Approach for Requirements Engineering, Proceedings of the 10th International Workshop on Database & Expert Systems Applications, 1999

FREITAS, D. P.; BORGES, M. R. S., ARAÚJO, R. M. Colaboração e Negociação na Elicitação de Requisitos, In IDEAS - Workshop Iberoamericano de Ingenieria de Requisitos y Ambientes de software, Venezuela - Maio 2007, Disponível em: http://kuainasi.ciens.ucv.ve/ideas07/documentos/articulos_ideas/Articulo74.pdf, Acessado outubro de 2009

GABRIEL, R. P. Patterns of Software - Tales from the software community, Oxford University Press, New York, 1996

GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J. Design Patterns: Elements of Reusable Object-Oriented Software. Boston: Addison-Wesley, 1995.

GENVIGIR, E. C. Um modelo para rastreabilidade de requisitos de software baseado em generalização de elos e atributos, São Jose dos Campos - SP, INPE, Tese de dourado em computação aplicada, 2009

GIL, A. C. Como elaborar projetos de pesquisa. 3. ed. São Paulo: Atlas. 1994

GOTEL, O., MÄDER, P. How to Select a Requirements Management Tool: Initial Steps, 17th IEEE International Requirements Engineering Conference, 2009

138

GOTTESDIENER, E. Good Practices for Developing User Requirements, Crosstalk - The Journal of Defense Software Engineering, March, 2008

GOTZHEIN, R., KRONENBURG, M., PEPER, C. Reuse in requirements engineering: Discovery and application of a real-time requirement pattern, 5th International Symposium on Formal Techniques in Real-Time and Fault-Tolerant Systems (FTRTFT’98), Lecture Notes in Computer Science 1486, Springer pp: 65–74, 1998

GRISS, M. L., FAVARO, J. D'ALESSANDRO, M. Integrating Feature Modeling with the RSEB, IEEE Computer Society, Washington, DC, USA, 1998, ISBN:0-8186-8377-5

HAGGE, L., LAPPE, K. Patterns for the RE Process, Proceedings of the 12th IEEE International Requirements Engineering Conference (RE’04), 2004a

HAGGE, L., LAPPE, K. Report from the Working Group on Requirements Engineering Patterns, Softwaretechnik-Trends 24, 2004b.

HAGGE, L., LAPPE, K., SCHMIDT, T. REPARE: The Requirements Engineering Patterns Repository, 13th IEEE International Conference on Requirements Engineering (RE’05), 2005

HAGGE, L., LAPPE, K. Using Requirements Engineering (RE) Patterns for Organizational Learning, Journal of Universal Knowledge Management, vol. 1, no. 2 (2006), 137-148, 2006

HOFFMANN, M., KÜHN, N., WEBER, M., BITTNER, M. Requirements for Requirements Management Tools, Proceedings in 12th IEEE International Requirements Engineering Conference, 2004

HOOD, C., WIEDEMANN, S., FICHTINGER, S., PAUTZ, U. Requirements Management: The Interface Between Requirements Development and All Other Systems Engineering Processes. Springer-Verlag Berlin Heidelberg, 2008. ISBN 978-3-540-47689-4

HULL, E., JACKSON, K., DICK, J. Requirements Engineering, Secound Edition, Springer London Berlin Heidelberg, 2005, ISBN 1-85233-879-2

IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, Nova Iorque: IEEE, 1998. ISBN 0-7381-0332-2

INCONSE, International Council On Systems Engineering, Tools survey: requirements management (RM) tools. Seattle, WA, USA, 2011. Disponível em: <http://www.incose.org/ProductsPubs/products/rmsurvey.aspx>, Acessado junho de 2011.

JAMAS SOFTWARE, Contour v2.9, 2010, Disponível em: <http://www.jamabackstage.com>, Acessado em: outro de 2010

JAMWAL, D., Software Reuse: A Systematic review, Proceedings of the 4th National Conference; INDIACom-2010 Computing For Nation Development, February 25 – 26, 2010

JOHNSON, W. L., HARRIS, D. R. Sharing and Reuse of Requirements Knowledge, Proc. KBSE-91, IEEE Press, Los Alamitos, CA; 1991, pp. 57-66

139

KANG, K. C.; COHEN, S. G.; HESS, J. A.; NOVAK, W. E. & PETERSON, A. S. Feature-Oriented Domain Analysis (FODA) Feasibility Study, Technical report, Carnegie-Mellon University Software Engineering Institute, 1990

KITCHENHAM, B.; CHARTERS, S. Guidelines for performing systematic literature reviews in software engineering. Technical Report EBSE 2007‐001, Keele University and Durham University Joint Report, 2007.

KEEPENCE, B., MANNION, M., SMITH, S. SMARTRe requirements: writing reusable requirements, Systems Engineering of Computer Based Systems, Proceedings of the 1995 International Symposium and Workshop on: pp: 27-34, 1995

KOCHANSKI, D. Um framework para apoiar a construção de experimentos na avaliação empírica de jogos educacionais, 2009. Dissertação (Mestrado em Computação Aplicada) – Curso de Mestrado Acadêmico em Computação Aplicada, Universidade do Vale do Itajaí - Univali, São José – Santa Catarina, 2009.

KONDA, B. M., MANDAVA, K. K. A Systematic Mapping Study on Software Reuse, University essay from Blekinge Tekniska Högskola/COM - Master Thesis Software Engineering, 2010

KOTONYA, G., SOMMERVILLE, I. Requirements Engineering: Process and Techniques. Editora John Wiley and Sons. 1998.

KRUEGER, C. W. Software Product Line Reuse in Practice, Proceedings. 3rd IEEE Symposium on Application-Specific Systems and Software Engineering Technology, 2000

KULOOR, C., EBERLEIN, A. Requirements Engineering for Software Product Lines, Calgary, Alberta, Canada; The University of Calgary; In Proceedings of the 15th International Conference on Software & Systems Engineering and their Applications (ICSSEA’02), Paris, France, 2002

LAM, W. Achieving requirements reuse: a domain-specific approach from avionics, Journal of Systems and Software Volume 38(Issue 3): p: 197-209, 1997

LAMSWEERDE, A. Requirements Engineering in the Year 00: A Research Perspective, 22th

International Conference on Software Engineering, 2000

LIU, L., LI, T., PENG, F. Why Requirements Engineering Fails: A Survey Report from China, Requirements Engineering Conference (RE), 2010 18th IEEE International, 2010

LÓPEZ, O., LAGUNA, M. A., GARCÍA, F. J. Metamodeling for Requirements Reuse, Anais do. WER02 - Workshop em Engenharia de Requisitos, Valencia, Spain, 2002

LUCRÉDIO, D. Uma abordagem orientada a modelos para reutilização de Software, USP - São Carlos – SP, Tese de Doutorado, 2009

LUTOWSKI, R. Software requirements: encapsulation, quality, and reuse. Boca Raton, Fl: Aurebach Publications, 2005

140

MAFRA, S. N,; TRAVASSOS, G. H. Estudos Primários e Secundários Apoiando a Busca por Evidências em Engenharia de Software. Relatório Técnico Rt-Es-687/06, Programa De Engenharia De Sistemas E Computação (Pesc), Coppe/Ufrj, 2006.

MAGALHÃES, H. J., TAMAGI, W. D., BELLO, A. R. Especificação de Requisitos e Modelagem (Sistema de apoio à empresa de produtos impermeabilizantes), Unioeste – Universidade Estadual do Oeste do Paraná, 2008. Disponível em http://200.201.81.50/~victor/projetos/ProjetosProcessoII2009/DocumentacaoFinalAlanHudsonWilliam/PES2.pdf. Acessado em 19 de março de 2011

MARÔCO, J. Análise Estatística com o SPSS Statistics, 5a edição, Editora ReportNumber, 2011. Disponível em: http://analisestatistica.no.sapo.pt/downloads/Ponto_7_2.pdf . Acessado em julho de 2011.

MARINHO, F., SANTOS, M., PINTO, R. N., ANDRADE, R. Uma Proposta de um Repositório de Padrões de Software Integrado ao RUP, SugarloafPLoP 2003, 2003

MASSONET, P., van LAMSWEERDE, A. Analogical Reuse of Requirements Frameworks, Proceedings of the Third IEEE International Symposium on Requirements Engineering, 1997

MATTAR, J. Metodologia Científica na era da Informática, 3 ed., ver. e atual. São Paulo: Saraiva, 2008

MENDEZ-BONILLA, O., F., X., QUER, C. Requirements Patterns for COTS Systems, Seventh International Conference on Composition-Based Software Systems, 2008

MESZAROS, G., DOBLE, J. MetaPatterns: A Pattern Language for Pattern Writing, In 3rd Pattern Languages of Programming conference, 1996

MKS, MKS Integrity 2009, 2010, Disponível em: <www.mks.com>, Acessado em: Outubro de 2010.

MONTABERT, C., BUSSERT, D., GIFFORD, S. S., CHEWAR, C. M., MCCRICKARD, S. Supporting Requirements Reuse in Notification Systems Design through Task Modeling, Proc. 11th International Conference on Human-Computer Interaction (HCII ‘05), 2005

MONTABERT, C. Supporting Requirements Reuse in a User-centric Design Framework through Task Modeling and Critical Parameters, Faculty of Virginia Polytechnic Institute and State University, Blacksburg - Virginia, Dissertação de mestrado, 2006

MONTABERT, C., MCCRICKARD, D. S., WINCHESTER, W. W., PÉREZ-QUIÑONES, M. A. An integrative approach to requirements analysis: How task models support requirements reuse in a user-centric design framework, Elsevier. Volume 21: pp: 304-315, 2009

MONZON, A. A Practical Approach to Requirements Reuse in Product Families of On-Board Systems, In Proceedings of the 2008 16th IEEE international Requirements Engineering Conference. Washington, DC, IEEE Computer Society: pp: 223-228, 2008

141

MOON, M., YEOM, K., SEOK CHAE, H. An Approach to Developing Domain Requirements as a Core Asset Based on Commonality and Variability Analysis in a Product Line, Software Engineering, IEEE Transactions on, IEEE Computer Society. Volume 31: pp: 551- 569, 2005

MORISION, M., EZRAN, M., TULLY, C. Success and Failure Factors in Software Reuse, IEEE Transactions on Software Engineering, 2002

NUSEIBEH, B., EASTERBROOK, S. Requirements Engineering: A Roadmap, Proceedings of International Conference on Software Engineering (ICSE-2000), Limerick, Ireland : ACM Press, 2000

OLIVEIRA, K., SPINOLA, M. POREI: Patterns-Oriented Requirements Elicitation Integrated Proposta de um Metamodelo Orientado à Padrão para Integração do Processo de Eliciação de Requisitos, SugarLoafPLoP'2007 - 6 Latin America Conference on Pattern Languages of Programming, Pernambuco, 2007

PÁDUA, E. M. Marchesini de. Metodologia da pesquisa: Abordagem teórica-prática, 13 ed., ver. e amp., Campinas, SP: Papirus, 2000

PARNAS, D. On the Design and Development of Program Families, IEEE Transactions on Software Engineering, v. SE-2, n. 1 (March), pp. 1-9, 1976

PEREDNIKAS, E. Requirements Reuse Based on Forecast of User Needs, International Conference 20th EURO Mini Conference “Continuous Optimization and Knowledge-Based Technologies” (EurOPT-2008). Neringa, LITHUANIA: pp: 450–455, 2008

PFANFESELLER, M., PFANFESELLER, M., KROTH, E. Uma ferramenta de apoio ao desenvolvimento de software baseado em componentes, XV Simpósio Brasileiro de Engenharia de Software, Sessão de Ferramentas, Rio de Janeiro - RJ, 2001

POOLEY, R., WARREN, C. Reuse Through Requirements Traceability, in: Proc. ICSEA 2008, October 26-31, Sliema, Malta, 2008

PREECE, J., ROGES, Y., SHARP, H. Design de Interação – Além da interação homem-computador, John Wiley & Sons, 2002

PRESSMAN, Roger S. Engenharia de software, 5ª edição. MacGraw-Hill, 2002.

RENAULT, S., MÉNDEZ-BONILLA, Ó., FRANCH, X., QUER, C. A Pattern-based Method for Building Requirements Documents in call-for-tender Processes, International Journal of Computer Science and Applications, Vol. 6, No. 5, pp 175-202, 2009a

RENAULT, S., MÉNDEZ-BONILLA, Ó., FRANCH, X., QUER, C. PABRE: Pattern-Based Requirements Elicitation, Third International Conference on Research Challenges in Information Science, RCIS 2009, 2009b

ROBERTSON, S. ROBERTSON, J. Mastering the Requirements Process, Second Edition. Addision Wesley Professional, Março 17, 2006

142

STARS, Organisation Domain Modelling Guidebook STARS-VC-A023/011/00, March 1995, 1995

SALINGAROS, N. A. The Structure of Pattern Languages, Published in arq -- Architectural Research Quarterly volume 4 (2000) pages 149-161, Cambridge University Press, 2000

SILVA, E. L; MENEZES, E. M. Metodologia de pesquisa e elaboração de dissertação. 3 ed., rev. e atual., Florianópolis: UFSC, 2001

SOMMERVILLE, Ian. Engenharia de software, 8ª edição. São Paulo: Pearson Addison Wesley, 2007.

SPANOUDAKIS, G., CONSTANTOPOULOS, P. Analogical Reuse of Requirements Specifications: A Computational Model, Applied Artificial Intelligence, Volume 10, 1996

SPANOUDAKIS, G., ZISMAN, A., Software Traceability: A Roadmap. Advances in Software Engineering and Knowdledge Engineering, Vol. 3: Recent Advances,(ed) S.K Chang, World Scientific Publishing, ISBN:981-256-273-7, Agosto de 2005

SPSS, SPSS Statistics version 17.0, release 17.0.0 (Aug 23, 2008) for Windows. Chicago, SPSS Inc., 2011

SWEBOK. Guide to the Software Engineering Body of Knowlegment, IEEE Computer Society, 2004. Disponível em http://www.computer.org/portal/web/swebok/htmlformat. Acesso em outubro de 2009.

TAMAI, T., KAMATA, M. L. Impact of Requirements Quality on Project Success or Failure, Design Requirements Engineering: A Ten-Year Perspective, Lecture Notes in Business Information Processing, 14, 258-275, 2009

TORO, A. D., BERNÁRDEZ, B., RUÍZ, A., TORO, M. A Requirements Elicitation Approach Based in Templates and Patterns, In Proceedings 2nd Workshop on Requirements Engineering (WER’99), 1999

TRACZ, W. Software Reuse Myths Revisited, Proceeding ICSE '94 Proceedings of the 16th international conference on Software engineering, IEEE Computer Society Press Los Alamitos, CA, USA, 1994

TRAVASSOS, G. H., GUROV, D., AMARAL, E. A. G. Introdução a Engenharia de Software Experimental, Relatório Técnico – RT-ES-590/02, Programa de Engenharia de Sistemas de Computação COOPE/UFRJ, 2002

TSUMAKI, T. Requirements Engineering Pattern Structure. APSEC'04, 2004

TSUMAKI, T., TAMAI, T., Framework for matching requirements elicitation techniques to project characteristics. 505-519, 2006.

VAN DER LINDEN, F., SCHMID, K., ROMMES, E., Software product lines in action: the best industrial practice in product line engineering, Springer-Verlag New York, 2007, ISBN:3540714367

143

VILLEGAS, O. L., LAGUNA, M. A. Requirements Reuse for Software Development, Proceedings of the RE'01 Doctoral Workshop - Fifth IEEE International Symposium on Requirements Engineering, Toronto - Canada, 2001

VLIET, H. V. Software Engineering: Principles and Practice, Wiley, 2007

VON KNETHEN, A. PAECH, B., KIEDAISCH, F., HOUDEK, F. Systematic Requirements Recycling through Abstraction and Traceability, Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02), 2002

VISURE SOLUTIONS, IRQA v4, 2010, Disponível em: <www.visuresolutions.com>, Acessado em: Outubro de 2010.

WAHONO, R. S. On the Requirements Pattern of Software Engineering, Proceedings of Temu Ilmiah XI 2002, 2002

WAZLAWICK, Raul Sidney; Metodologia de Pesquisa para Ciência da Computação, Rio de Janeiro: Elsevier, 2009

WIEGERS, K. E. More About Software Requirements: Thorny Issues and Practical Advice, Microsoft Press, ISBN:0735622671, 2006

WINN, T., CALDER, P. Is This a Pattern?, IEEE Computer Society Press, CA-USA, 2002 p.59-66

WITHALL, S. Software Requirement Patterns, Washington: Microsoft Press, 2007.

YOUNG, R. R. The Requirements Engineering Handbook. Artech House, 2004

YOUNG, R. R. Twelve Requirements Basics for Project Sucess. CROSSTALK The Journal of Defense Software Engineering, 2006 - www.stsc.hill.af.mil, 2006

ZAND, M. K., SAMADZADEH, M. H. Software reuse issues and perspectives, Potentials, IEEE , vol.13, no.3, pp.15-19, Aug/Sep 1994, 1994

ZHANG, Z; Effective Requirements Development - A Comparison of Requirements Elicitation techniques, SQM2007 conference, 2007

144

APÊNDICE A - PROTOCOLO DE MAPEAMENTO SISTEMÁTICO

Normalmente, a primeira atividade em um processo de pesquisa é a atividade de revisão da

literatura. Esta atividade visa coletar todo o conhecimento prévio existente em cerca de um assunto.

Porém, esta atividade é comumente realizada de forma ad-hoc, sem um protocolo de revisão pré-

estabelecido para a sua condução (MAFRA; TRAVASSOS, 2006). A realização desta atividade

sem um sistematização pode levar uma pesquisa a obter resultados poucos abrangentes, aumentando

a possibilidade de resultados tendenciosos. Mafra e Travassos (2006, p.10) contribuem em afirmar,

o uso de uma revisão sistemática é mais indicado que uma revisão informal, isso porque, uma

revisão informal é caracterizada por ser:

Pouca abrangência - não existe um planejamento ou estratégia prévia para a busca e

seleção dos estudos nas fontes de dados;

Não é passível de repetição - por não apresentar nenhum protocolo de revisão, a sua

reprodução não é passível de ser realizada;

Pouco confiável - como os resultados não são documentados, a verificação de acordo

com os resultados não é possível de auditagem;

Dependente dos revisores - sem a possibilidade de auditagem, as revisões são

dependentes dos que a conduziram, o que tende a aumenta o viés de seus resultados.

Neste sentido, a revisão sistemática da literatura é uma forma de avaliar e interpretar todas

as pesquisas acerca de um assunto (KITCHENHAM et al., 2007). O mapeamento sistemático é uma

forma de estudo secundária que utiliza uma metodologia rigorosa, confiável e que possibilita

auditagem. A sua utilização é feita com meio de identificar, avaliar e interpretar todas as pesquisas

disponíveis relevantes para obtenção de subsídios para responder uma determinada questão de

pesquisa, ou área temática, ou fenômeno de interesse, evitando viés e que permite certo grau de

reprodução por outros pesquisadores. A sua reprodução deve de ser passível, já que uma revisão

sistemática da literatura deve de produzir um protocolo de busca (KITCHENHAM et al., 2007). A

revisão sistemática também é uma forma de apresentar uma síntese dos trabalhos como prova de

145

investigação referente a um tema de pesquisa (BRERETON et al., 2007). Esta revisão sistemática

seguirá a estrutura de agrupamento das atividades conforme Brereton et al. (2007).

Sendo assim, este apêndice tem o caráter de apresentar o protocolo de uma mapeamento

sistemático da literatura realizada neste projeto, seguindo as etapas proposta por Kitchenham et al.,

(2007). A revisão sistemática é uma forma de avaliar e interpretar todas as pesquisas acerca de um

assunto (KITCHENHAM et al., 2007). O mapeamento sistemático é uma forma de apresentar uma

síntese dos trabalhos como prova de investigação referente a um tema de pesquisa (BRERETON et

al., 2007).

1 OBJETIVO

Este mapeamento sistemático tem como objetivo identificar, analisar e avaliar pesquisas

voltadas para o conhecimento de padrões de escrita de requisitos na disciplina de Engenharia de

Requisitos. A intenção é de conhecer, de maneira imparcial, o estado da arte referente a padrões de

escrita de requisitos para Engenharia de Requisitos.

2 PLANEJAMENTO DA REVISÃO

O planejamento deste estudo segue conforme o modelo de protocolo descrito por

Kitchenham et al., (2007).

A revisão do protocolo deu-se junto a um especialista na área, e sua execução foi realizada

pelo próprio autor, devido a não haver outra pessoa no qual pudesse delegar esta atividade. As

demais atividades do planejamento da revisão estão detalhadas nos próximos tópicos.

2.1 PERGUNTA DE PESQUISA

Este trabalho pretender encontrar estudos nos quais possam ajudar a responder a seguinte

pergunta de pesquisa:

Questão de Pesquisa: Quais os padrões para a escrita de requisitos de software?

146

2.2 ESTRUTURA DA PERGUNTA DE PESQUISA

Segundo Kitchenham et al. (2007), os seguintes critérios devem de ser respondidos para

enquadrar as questões de pesquisa de Engenharia de Software para a orientação da seleção dos

estudos primários:

População: esta pesquisa explora é a de publicações em engenharia de software com o foco

em engenharia de requisitos.

Intervenção: pretende-se encontrar catálogos, padrões ou categorias de padrões para escrita

de requisitos de software.

Comparação: nenhuma comparação será realizada.

Resultados: entende-se que o autor poderá ter subsídios para elaboração de um catálogo de

padrões para escrita de requisitos de software.

Contexto: comunidade de Engenharia de Software.

Desenho do experimento: nenhum método estatístico será aplicado.

Controle: checklists e inspeção ad-hoc.

Aplicação: projetos de desenvolvimento de software na atividade de elicitação de requisitos.

2.3 ESTRATÉGIA DE BUSCA

Segundo Kitchenham et al. (2007), é necessário determinar e seguir uma estratégia de

pesquisa. Essa estratégia consiste em identificar revisões sistemáticas existentes, elaboração das

strings de buscas, verificação experimental das strings de buscas, e consulta de especialistas na

áreas.

Como estratégia de busca, foi realizada uma busca por revisões sistemáticas na web (fonte:

Google) pelo termo “revisão sistemática” and “padrões de requisitos” em português e “systematic

review” and “requirements pattern”, o qual resultou em nenhum registro encontrado para ambas as

buscas. Após essa busca, foram identificadas e analisadas as possíveis fontes de busca em base de

147

dados eletrônica, seleção dos idiomas nos quais seriam criados as strings de buscas, e as palavras

chaves para as strings de busca. A descrição desses dados está listada a seguir:

Fontes: A busca será feita em bases de dados eletrônicas como:

ACM Digital library (<http://portal.acm.org/>);

IEEExplore (<http://ieeexplore.ieee.org>);

SpringerLink (<http://www.springerlink.com>);

ScienceDirect (<http://www.sciencedirect.com >);

Citesser library (<http://citeseerx.ist.psu.edu/>);

Google scholar (<http://scholar.google.com/>);

BDTD – Biblioteca Digital Brasileira de Teses e Dissertações

(<http://bdtd.ibict.br>);

Domínio Público (<http://www.dominiopublico.gov.br>);

Banco de Teses e Dissertações da UFRGS (<http://www.lume.ufrgs.br>);

Banco de Teses e Dissertações da USP (<http://www.teses.usp.br>);

Biblioteca Digital de Teses e Dissertações – UFSCar

(<http://200.136.241.56/htdocs/tedeSimplificado/>);

Biblioteca Digital de Teses e Dissertações – UFRJ (<http://www.minerva.ufrj.br/>);

Biblioteca Digital da Sociedade Brasileira de Computação (SBC) –

(<http://www.sbc.org.br/bibliotecadigital/>);

Algumas bases de dados eletrônicas como Inspec e El Compendex foram descartas devido à

restrição ao acesso destas bases.

148

Idioma: A busca inicia-se pela preferência em trabalhos na língua inglesa, por se tratar de

uma língua universalmente aceita para trabalhos científicos e por ter conhecimento de que os

trabalhos mais atuais encontram-se na língua inglesa. Posteriormente trabalhos em língua

portuguesa.

Palavras chaves: “pattern”, “catalog”, “category”, “software requirement”, “requirements

engineering” e “requirements elicitation” (em inglês), “padrões”, “catálogo”, “categoria”,

“requisitos de software”, “engenharia de requisitos” e “elicitação de requisitos” (em português).

2.4 DEFINIÇÃO DAS STRINGS DE BUSCA

Segundo Kitchenham et al. (2007), é necessário determinar e seguir uma estratégia de

pesquisa. Essa estratégia consiste em identificar revisões sistemáticas existentes, elaboração das

strings de buscas, verificação experimental das strings de buscas, e consulta de especialistas na

áreas. O Quadro 6 e Quadro 7 ilustram as strings de buscas elaboradas para utilização nas bases de

dados eletrônicas já relatadas anteriormente.

Quadro 6 - Strings de busca no idioma inglês.

((pattern OR catalog OR category) AND (“software requirement” OR “requirements

engineering” OR “requirements elicitation”))

Quadro 7 - Strings de busca no idioma português.

((padrões OR catálogo OR categoria) AND (“requisito de software” OR “engenharia de

requisitos” OR “elicitação de requisitos”))

2.5 CRITÉRIOS DE INCLUSÃO E EXCLUSÃO DE ESTUDOS PRIMÁRIOS

Serão aceitos trabalhos que façam discussões que ajudem a responder a pergunta de pesquisa

referenciada neste trabalho, especificamente:

149

estudos que apresentam padrões para escrita dos requisitos de forma a permitir a sua

aplicação, ou seja, estudos que expõem o padrão de forma detalhada viabilizando sua

utilização;

estudos que evidenciassem a aplicação do padrão proposto em projetos reais ou

acadêmicos.

Consequentemente, considerou-se como critérios de exclusão:

estudos em que o padrão proposto não abordava aspectos relacionados com a forma

de escrita/documentação de requisitos de software;

estudos nos quais o padrão não era apresentado detalhadamente, inviabilizando sua

aplicação;

estudos que não evidenciavam a aplicação do padrão, seja no meio acadêmico, seja

na indústria.

2.6 CRITÉRIOS PARA FILTRAGEM DE PESQUISA

A lista de critérios adotados para filtragem das pesquisas encontradas pelas strings

informadas anteriormente contempla:

fonte onde o estudo foi encontrado;

análise do título do trabalho;

análise do resumo;

análise do trabalho;

relevância e abrangência do estudo;

150

2.7 PROCESSO DE SELEÇÃO DE TRABALHOS PRELIMINAR

O processo de seleção preliminar dos trabalhos será feitos através da utilização das strings

ou palavras-chaves e sinônimos identificados, nas quais serão submetidas às máquinas de buscas

relatadas anteriormente.

Será efetuada a leitura do resumo dos trabalhos encontrados. Os trabalhos que atendam aos

critérios descritos anteriormente, ou que seja identificada alguma relevância, serão separados para

uma leitura detalhada posteriormente.

Os trabalhos selecionados para a execução do processo de seleção dos estudos primários

serão avaliados utilizando-se critérios de qualidade estabelecidos detalhados na seção 2.8. Os

trabalhos que contemplarem os critérios de qualidade serão incluídos no processo de extração dos

dados.

Os trabalhos selecionados serão armazenados em um diretório, nos quais os arquivos serão

nomeados utilizando primeiramente o ano da publicação e o título do documento. No entender do

autor, essa é uma forma eficiente de armazenamento e posterior localização dos documentos. Ainda,

se utilizou a ferramenta Mendeley Desktop (2008) para o gerenciamento dos estudos. A Figura 32

ilustra parte da seleção de estudos com algumas informações extraídas.

151

Figura 32 - Gerenciamento da seleção de estudos.

2.8 AVALIAÇÃO DA QUALIDADE DOS ESTUDOS PRIMÁRIOS

Serão considerados estudos de qualidade os estudos nos quais os autores apresentem de

forma detalhada o padrão, de forma a viabilizar a sua aplicação, além de descrições de como utilizar

o padrão proposto. Outro critério de qualidade em que os estudos devem se adequar é quanto à

descrição dos resultados alcançados pelos pesquisadores.

Outros critérios de qualidade já estão implícitos na seleção das bases de dados eletrônicas.

Normalmente as pesquisas publicadas nessas bases são passadas por um rigoroso critério de revisão

por pesquisadores que exercem intenso trabalho na comunidade. Exemplo desses critérios de

qualidade implícitos pode ser: revisão externa, coerência, completude, imparcialidade, dentre

outros.

2.9 EXTRAÇÃO DOS DADOS

Para os trabalhos selecionados no processo de extração dos dados serão extraídas as

seguintes informações:

data de publicação;

título do trabalho;

152

local da publicação;

pesquisadores autores do trabalho;

descrição do padrão;

descrição da pesquisa realizada;

resultado da pesquisa;

comentários adicionais;

Como resultado da extração dos resultados, será elaborado um relatório sobre as principais

conclusões e análise dos trabalhos selecionados. Os trabalhos que forem considerados adequados à

proposta do projeto de dissertação, serão separados e utilizados no projeto de pesquisa com o

objetivo de contribuir com a elaboração de um catálogo de padrões para apoiar a atividade de

elicitação de requisitos.

A sumarização do resultado do relatório poderá ser expressa tanto em sínteses discursivas

quanto quadros tabulados. Nenhuma meta-análise será realizada.

3 CONDUÇÃO DA REVISÃO

Segundo Kitchenham et al. (2007), com o protocolo acordado, pode-se iniciar a condução da

revisão.

Este mapeamento sistemático foi realizado no mês de junho a agosto de 2010 com o intuito

de cumprir uma atividade da disciplina de estudo dirigido, mas ajudou a encontrar alguns estudos

que contribuíram de forma significativa na condução do trabalho de pesquisa do autor. A busca por

trabalhos para mapear o estado da arte dos debates a respeito de padrões de escrita de requisitos, já

foi realizada durante alguns meses, mas essa busca ainda não era sistematizada. A condução

realizou-se utilizando as strings definidas anteriormente neste documento e procedeu de suas

utilizações nas buscas das bases de dados eletrônicas que também estão relacionadas anteriormente.

A seção a seguir trata de apresentar as etapas seguidas na condução do mapeamento sistemático.

153

3.1 IDENTIFICAR A PESQUISA

A pesquisa nas bases de dados foi realizada no mês de junho e julho de 2010. As Tabela 17

e Tabela 18, relacionam fonte de dados, a string formatada para a base e a quantidade de estudos

localizados. Optou-se o uso da string de busca, na busca pelo título dos trabalhos. Isso devido ao

resultado de um busca por todos os campos retornarem muitos trabalhos não relacionados ao tema,

o que comprometeria a pesquisa por não dispor de tempo hábil para analisar todos os trabalhos.

Nenhum problema ocorreu na execução das strings nos motores de busca das base de dados

eletrônicas. O campo “String de busca formatada” da Tabela 17 e Tabela 18 ilustra a string

formatada utilizada na busca.

Tabela 17 - Resultado da busca nas fontes utilizando no idioma inglês. Base de dados consultada String de busca formatada Estudos encontrados IEEEXplorer (("Document Title":pattern OR "Document Title":catalog

OR "Document Title":category) AND ("Document Title":"software requirement" OR "Document Title":"Requirements Engineering" OR "Document Title":"Requirements Elicitation"))

A pesquisa retornou 9 resultados

ACM ((Title:pattern or Title:catalog or Title:category) and (Title:"software requirement" or Title:"Requirements Engineering" or Title:"Requirements Elicitation"))


SpringerLink ((ti:(pattern) OR ti:(catalog) OR ti:(category)) AND (ti:("software requirement") OR ti:("Requirements Engineering") OR ti:("Requirements Elicitation")))


Science Direct ((title(pattern) or title(catalog) or title(category)) and (title("software requirement") or title("Requirements Engineering") or title("Requirements Elicitation")))

A pesquisa retornou 1 resultado

Google Scholar ((notítulo:pattern OR notítulo:catalog OR notítulo:category) AND (notítulo:"software requirement" OR notítulo:"requirements engineering"))


CiteSeer ((title:pattern OR title:catalog OR title:category) AND (title:"software requirement" OR title:"requirements engineering") OR title:"Requirements Elicitation")


154

Tabela 18 - Resultado da busca nas fontes utilizando no idioma português. Base de dados consultada String de busca formatada Estudos encontrados BDTD – Biblioteca Digital Brasileira de Teses e Dissertações

((titulo:padrões OR titulo:catálogo OR titulo:categoria) AND (titulo:"requisitos de software" OR titulo:"engenharia de requisitos" OR titulo:" elicitação de requisitos"))))

A pesquisa não retornou nenhum resultado

Domínio Publico ((padrões OR catálogo OR categoria) AND ("requisitos de software" OR "engenharia de requisitos" OR "elicitação de requisitos"))


Banco de Teses e Dissertações da UFRGS

((padrões OR catálogo OR categoria) AND ("requisitos de software" OR "engenharia de requisitos" OR "elicitação de requisitos"))))


Google Scholar ((notítulo:padrões OR notítulo:catálogo OR notítulo:categoria) AND (notítulo:"requisitos de software" OR notítulo:"engenharia de requisitos" OR notítulo:" elicitação de requisitos"))


Banco de Teses e Dissertações da USP

((padrões OR catálogo OR categoria) AND ("requisitos de software" OR "engenharia de requisitos" OR "elicitação de requisitos"))


Biblioteca Digital de Teses e Dissertações – Bco/UFSCar

((padrões OR catálogo OR categoria) AND ("requisitos de software" OR "engenharia de requisitos" OR "elicitação de requisitos"))

A pesquisa retornou 1 resultado

Biblioteca Digital de Teses e Dissertações - UFRJ

( ( WTI = ( padrões ) OR WTI = ( catálogo ) OR WTI = ( categoria ) ) AND ( WTI = ( Requisitos de software ) OR WTI = ( Engenharia de Requisitos ) OR WTI = ( Elicitação de Requisitos ) ) )


Biblioteca digital da SBC ((padrões OR catálogo OR categoria) AND ("requisitos de software" OR "engenharia de requisitos" OR "elicitação de requisitos"))


3.2 SELEÇÃO DOS ESTUDOS PRIMÁRIOS

O processo de seleção deu-se conforme relacionado na sessão 3 no qual resultou na

localização de 54 estudos. Alguns desses 54 estudos se repetiam em outras bases o que resultou

então em 34 estudos únicos. Todos os trabalhos que retornaram nas buscas foram verificados antes

de fazer um descarte ou inclusão no protocolo. A Tabela 19 ilustra os estudos encontrados em uma

matriz. O critério de verificação quanto à fonte foi aplicado sob os estudos, nesta etapa nenhum

descarte foi necessário, pois todos os estudos eram provenientes de fontes confiáveis. No processo

de análise do título 17 trabalhos foram descartados, estes trabalhos são os de Silva et al. (2003),

Compagna et al. (2008), Maiden e Bright (1996), Issa e Al-ali (2010), Hatebur et al. (2007), Maiden

e Hare (1998), Sikkel et al. (2000), Zlatev et al. (2005), Hermoye et al. (2008), Merrick e Barrow

(2004), Pavan et al. (2003), Kozima et al. (2005) e Watahiki e Saeki (2001), Gaska (1999), Hagge

et al. (2006), Xuan et al. (2009), Hironori et al. (2006). Neste passo a quantidade de estudos foi

reduzida para 17 estudos, com os estudos que restaram após a análise do título, foi realizada uma

leitura em seu resumo e nos trabalhos que apresentavam relevância também foi realizada a leitura

155

da conclusão, a exceção foi o estudo de Ang (2007) o qual não possuía o texto completo disponível

na base de dados. Como resultado desta etapa de análise do resumo e das conclusões foi descartado

12 estudos, cujos estão relacionados na Tabela 20 que também descreve o motivo pelo qual o

estudo foi descartado. No final desta etapa 4 estudos foram selecionados para fazer parte da revisão

sistemática. Foram selecionados os estudos de Franch et al. (2010), Withall (2007), Toro et al.

(1999) e Renault et al. (2009b). Esta etapa foi realizada guiando-se nas orientações apresentadas por

Kitchenham et al., (2007), o qual orienta a proceder de forma cuidadosa e imparcial a seleção dos

estudos, evitando resultados com algum tipo de viés.

Na análise do estudo de Franch et al. (2010), constatou-se que é um estudo que vinha sendo

realizado há alguns anos e veio a ser necessário a inclusão manual de mais dois estudo relacionados

ao grupo de pesquisa no qual participam os autores. Esses estudos são de Mendez-Bonilla et al.

(2008) e Renault et al. (2009a). Essa inclusão justifica-se pelo fato que esses dois estudos são

complemento e evolução do catálogo apresentado inicialmente em Mendez-Bonilla et al. (2008) e

identificado nesta revisão sistemática nos estudos apresentado em Franch et al. (2010) e Renault et

al. (2009b).

156

Tabela 19 - Matriz de estudo encontrados17.

Base de dados Estudos

IEEE

Xpl

orer

AC

M

Sprin

gerL

ink

Scin

ce D

irect

Goo

gle

Scho

lar (

ING

)

Cite

Seer

Goo

gle

Scho

lar (

POR

)

Bco

/UFS

Car

(ISAZADEH et al., 1995) X (MAIDEN; BRIGHT, 1996) X X (GASKA; GAUSE, 1998) X X (MAIDEN; HARE, 1998) X X (GOTZHEIN et al., 1998) X XX XX (FREDJ; ROUDIÈS, 1999) X X (HATEBUR et al., 2007) X X X (SIKKEL et al., 2000) X (WAHONO, 2002) X (PAVAN, et al., 2003) X (TSUMAKI, 2004) X X X (MERRICK; BARROW, 2004) X (HAGGE et al., 2006) X (ZLATEV et al., 2005) X X (HAGGE et al., 2005) X (HAGGE; LAPPE, 2005) X X (HAGGE; LAPPE, 2006) X (GRAF, 2007) X (FALBO et al., 2007) X (HERMOYE et al., 2008) X (COMPAGNA et al., 2008) X X (ISSA; AL-ALI, 2010) X X (FRANCH et al., 2010) X (TOLEDO, 2008) X X (WITHALL, 2007) X (ANG, 2007) X (SILVA et al., 2003) X (XUAN et al., 2009) X (GASKA, 1999) X (RENAULT et al., 2009) X X (TORO et al., 1999) XX (HIRONORI et al., 2006) X (KOZIMA et al., 2005) XX (WATAHIKI; SAEKI, 2001) X

17 As colunas com XX representa que o mesmo estudo foi encontrado em duplicidade na base de dados.

157

Tabela 20 - Estudos descartados na etapa de análise do resumo e conclusões.

Estudo Motivo do descarte (FARBO et al., 2007) Os padrões relatados pelos autores são referentes a padrões de análise. (FREDJ; ROUDIÈS, 1999) O estudo dos autores não trata de escrita de padrões, mais sim de como conduzir a

atividade de elicitação de requisitos. (GASKA; GAUSE, 1998) O estudo avalia as práticas comuns em uma disciplina da engenharia de requisitos.

A abordagem procura soluções de problemas no processo de engenharia de requisitos em outras disciplinas. Faz uso de padrões para descrever como proceder na condução do processo de engenharia de requisitos utilizando-se de um framework de boas práticas de engenharia de requisitos. Os autores mapeiam os objetivos e questões sobre o processo de ER, utiliza-se de exemplos genéricos sobre esses objetivos e questões e relaciona com uma fase da engenharia de requisitos.

(GRAF, 2007) O objetivo do estudo é de promover uma abordagem para engenharia na qual consistiu em uso de repositório de padrões para padrões de interação. Padrões de interação são soluções para problemas de especificação de design de interface de usuário, que se utiliza com conceito inicial de padrões promovidos por Gamma et al. (1995) (GRAF, 2007).

(GOTZHEIN et al., 1998) O objetivo do estudo é de descobrir padrões interessantes de requisitos não triviais em tempo real e sua posterior aplicação. Os autores utilizam padrões para especificação de requisitos de linguagem formal para aplicações de tempo real.

(ISAZADEH et al., 1995) O estudo trata de padrões comportamentais. Esses padrões fornecem uma base semântica para apresentação de uma arquitetura de software e configuração de um ponto de vista comportamental (ISAZADEH et al., 1995).

(TOLEDO, 2008) O estudo dos autores não trata de escrita de padrões, mais sim de como as atividades do processo de engenharia de requisitos.

(WAHONO, 2002) Objetivo é demonstrar o esforço da comunidade em utilizar o paradigma de padrões de requisitos aplicados na engenharia de requisitos. Porém, o mesmo não pode ser incluso neste protocolo devido a não atender a um dos critérios de qualidade, no qual se refere à apresentação de padrões que possam ser aplicados e descrição de como utilizar o padrão apresentado pelo estudo.

(HAGGE; LAPPE, 2005) O estudo apresenta quatro padrões para as atividades básicas de engenharia de requisitos. Os padrões apresentados pelos autores têm um foco de demonstrar como realizar algumas das atividades do processo de engenharia de requisitos.

(HAGGE; LAPPE, 2006) Esse estudo apresenta padrões para aprendizagem organizacional e melhoria do processo de engenharia de requisitos.

(TSUMAKI, 2004) O estudo realizado pelo autor propõe uma estrutura adequada para padrões de engenharia de requisitos.

(HAGGE et al., 2005) O estudo trata sobre um repositório de padrões de engenharia de requisitos. Nenhuma referência sobre a escrita é relatada neste estudo. Contudo este estudo poderá servir de base teórica para descrição da abordagem no qual se irá formular.

3.3 EXTRAÇÃO E MONITORAÇÃO DOS DADOS

A ferramenta Mendeley Desktop (2008) proporcionou uma grande auxilio nesta etapa. Com

o a auxílio da ferramenta pode-se identificar trabalhos repetidos, organizar referências, priorizar

leituras, recuperar documentos, adicionar comentários e revisões.

158

A Tabela 21 ilustra um template para sintetizar os dados extraídos dos trabalhos

selecionados para formar os estudos primários deste protocolo de revisão sistemática. Após esse

passo, os resultados poderão finalmente ser publicados.

Tabela 21 - Template da tabela de extração dos dados dos estudos primários selecionados.

Data de Publicação Ano/mês/dia Local Título

Autores

Descrição do padrão

Descrição da avaliação do padrão Resultado da pesquisa Comentários adicionais

3.4 EXTRAÇÃO DOS DADOS DOS ESTUDOS SELECIONADOS

As tabelas apresentadas nesta seção são referentes aos dados extraídos dos estudos

selecionados na condução de uma revisão sistemática.

159

Tabela 22 - Extração dos dados do estudo de Franch et al. (2010).

Data de Publicação 2010/mês/dia Local REFSQ 2010, Springer-Verlag: Berlin

Título A Metamodel for Software Requirement Patterns Autores FRANCH, X., PALOMARES, C., QUER, C., RENAULT, S., LAZZER, F. Descrição do padrão Neste estudo é apresentado o meta-modelo para padrões de requisitos. Este meta-modelo para padrões de requisitos que é composto de três conceitos: 1) estrutura padrões de requisitos; 2) os relacionamentos entre os padrões; 3) os critérios de classificação para agrupá-los; O estudo apresenta uma solução para apoiar os analistas de sistemas sem experiência em engenharia de requisitos para lidar com atividades de análise de requisitos e design. Para tanto, os autores criaram um catálogo com 29 padrões de requisitos não funcionais. Segundo os autores, padrões de requisitos sob requisitos não funcionais são menos sensíveis as mudanças no domínio do problema. Descrição da avaliação do padrão No experimento realizado pelos autores os padrões de requisitos trouxeram uma grande percentagem de reutilização de requisitos não funcionais na especificação de requisitos. A pesquisa foi realizadas em 7 propostas de projetos reais. Resultado da pesquisa Os argumentos deste estudo são os mesmos apresentados em Renault et al. (2009a). Comentários adicionais Este estudo é a evolução de dois outros estudos publicados pelos autores, esse estudo passou por processo de avaliação seguindo critério de uma empresa privada. É apresentada uma estrutura para criação e escrita dos padrões, no qual também é encontrado no trabalho do grupo em Mendez-Bonilla et al. (2008). O processo de utilização da abordagem dos autores está descrita no estudo Renault et al. (2009a). Uma visão futura vislumbrada pelos autores é de aplicar o estudo em outros contextos e adequar de forma que contemple os requisitos funcionais também. E outra visão futura dos autores é de converter o meta-modelo atual em um meta-modelo de padrões de linguagem.

160

Tabela 23 - Extração dos dados do estudo de Renault et al. (2009a).

Data de Publicação 2009/mês/dia Local International Journal of Computer Science and Applications

Título A Pattern-based Method for Building Requirements Documents in Call-for-tender Processes. Autores RENAULT, S., MÉNDEZ-BONILLA, Ó., FRANCH, X., QUER, C. Descrição do padrão Este estudo apresenta um método intitulado PABRE, que constitui na aplicação de um catálogo de padrões de requisitos em um contexto de desenvolvimento de software de prateleira. Neste estudo é especificado o processo pelo qual é criado um documento de especificação de requisitos utilizando-se de padrões de requisitos de software. O estudo trata do método para utilização de um catálogo de padrões de requisitos. O catálogo apresentado neste estudo é uma evolução do que foi apresentado em Mendez-Bonilla et al. (2008). As seguintes etapas foi seguidas pelos autores para a elaboração do catálogo:

1) Consolidação dos livros de requisitos existentes; (70 requisitos não funcionais foram identificados de 7 livros de requisitos)

2) Análise dos requisitos não funcionais; 3) Definição da estrutura para padrão; (aqui os autores articularam um formulário para um meta-modelo) 4) Construção do catálogo; (os requisitos foram formalizados em um catálogo usando a estrutura de padrão. A

primeira versão do catalogo contava com 48 padrões de requisitos não funcionais e foi validado com um caso de estudo, esse processo é relatado por outro trabalho do grupo em Renault et al. (2009). Após uma nova analise por experts utilizando-se de uma diferente perspective, reformularam o catalogo excluindo redundâncias e padrões que não tinha uma clara justificativa para sua existência e inclinou-se para mesclar alguns padrões para criar novos utilizando da mesma estrutura. Com essa nova análise o resultado foi um catálogo com 29 padrões de requisitos não funcionais.

O formulário para a escrita do padrão de Renault et al. (2009a), é estruturada da seguinte forma: Padrão de meta-dados – é um conjunto de atributos que define os meta-dados sobre o modelo em si; Formulário do padrão – é uma forma de permite que modelo possa declarar um padrão de várias formas. Parte fixa – é uma declaração abstrata, que afirma o que o sistema deve de atingir como meta para o padrão. Extensões – é onde comporta informações extras sobre a parte fixa, já que a parte fixa é de uma forma abstrata. Pode ser usada para reescrever a parte fixa ou restringi-la Texto do formulário – cada parte fixa e prolongada de um padrão é especificada por um texto do formulário. Utilizam-se frases curtas e escritas em linguagem natural no qual pode incluir um ou mais parâmetros que indicam as partes que podem variar em diferentes projetos. Quando um padrão é selecionado os parâmetros são substituídos por valores e cada parâmetro é vinculado a uma métrica e opcionalmente terá uma condição de correção. As métricas podem assumir valores inteiros, real, booleanos ou listas enumeradas. Texto da questão – também é associado a cada correção ou parte estendida. Corresponde a uma reescrita do texto em forma de interrogativa e é utilizado para saber se um produto satisfaz os requisitos estabelecidos pela parte fixa ou a parte estendida. Dependência – “padrões de requisitos não vivem isolados”. Os autores sustem que os padrões podem ser relacionados em um catalogo. Dois tipos de dependência foram identificados pelos autores: dependência entre padrões e dependência entre parâmetros. Esquema de classificação – para uma melhor compreensão e ajudar na seleção dos padrões na atividade de elicitação de requisitos, os autores utilizaram a norma ISSO 9126-1 e a abordagem Volere proposta por Robertson e Robertson (1999) e experimentação empírica, para a elaboração de seu esquema de classificação dos padrões. Segundo os autores o motivo de utilizar vários esquemas de classificação é de melhorar a utilização e portabilidade do repositório. Descrição da avaliação do padrão A avaliação foi realizada em dois estudos de caso. O primeiro trata de um projeto de uma biblioteca digital, neste projeto mais de 90% dos requisitos não funcionais foram obtidos do catálogo. O segundo estudo de caso é realizado em um projeto de um sistema de gestão de relacionamento com o cliente, neste estudo de caso os autores relatam que a experiência ajudou na verificação da integridade dos padrões relacionados no novo catálogo e confirmou a necessidade de ter uma ferramenta que apóie a abordagem.

161

Resultado da pesquisa Com resultado os autores conseguir obter uma evolução do catálogo, no primeiro estudo de caso os autores utilizaram um catálogo com 48 padrões de requisitos, após o estudo conseguiu-se refinar o catálogo, passando a compor 32 requisitos. Após a conclusão do segundo estudo de caso, confirmou-se a necessidade de uma ferramenta para apoiar a abordagem. Como resultado final os autores concluem que a abordagem trouxe uma redução no tempo na atividade de elicitação de requisitos e os requisitos que vieram a compor o documento de especificação de requisitos são de “maior qualidade”. Nenhum critério para mensuração de qualidade é descrita pelos autores. Comentários adicionais O catálogo é baseado no trabalho feito em Mendez-Bonilla et al. (2008), porem em ambos os trabalhos o conteúdo dos catálogos não é apresentado, os autores consideram com um conteúdo independente e que o objetivo deste estudo é de apresentar o método. Em contato com os autores, obteve-se o catálogo completo em sua última versão disponível em <http://www.upc.edu/gessi/PABRE>. Este trabalho foi incluído manualmente na revisão sistemática por se tratar de uma pesquisa realizada anteriormente por Franch et al. (2010), no qual relata o processo seguido anteriormente na pesquisa realizada em 2010.

162

Tabela 24 - Extração dos dados do estudo de Renault et al. (2009b).

Data de Publicação 2009/mês/dia Local Third International Conference on Research Challenges in Information Science

Título PABRE: Pattern-Based Requirements Elicitation Autores RENAULT, S., MÉNDEZ-BONILLA, Ó., FRANCH, X., QUER, C. Descrição do padrão O estudo apresenta o método PABRE, que objetiva facilitar a atividade de elicitação de requisitos utilizando uma proposta de padrões de requisitos. Descrição da avaliação do padrão Segundos os autores, a utilização do método poupa o tempo da atividade de elicitação de requisitos e reduz erro durante a condução da atividade. O método consiste na utilização de um catálogo de padrões de requisitos, no qual é aplicado à seleção particular do projeto, convertendo em necessidades reais. Os argumentos deste estudo são os mesmos apresentados em Renault et al. (2009a). Resultado da pesquisa Os argumentos deste estudo são os mesmos apresentados em Renault et al. (2009a). Comentários adicionais Este estudo tratar de uma pesquisa realizada anteriormente por Franch et al. (2010), no qual relata o processo seguido anteriormente na pesquisa realizada em 2010.

163

Tabela 25 - Extração dos dados do estudo de Mendez-Bonilla et al. (2008).

Data de Publicação 2008/mês/dia Local Seventh International Conference on Composition-Based Software Systems

Título Requirements Patterns for COTS Systems Autores MENDEZ-BONILLA, O., FRANCH, X., QUER, C. Descrição do padrão O processo no qual a proposta descreve consiste na identificação de padrões e sua instanciação do projeto concreto, o que gera a especificação dos requisitos do sistema e base para o documento de especificação de requisitos. A construção dos padrões é realizada a partir da observação de requisitos similares já utilizados na construção de vários projetos de software. Quando essa similaridade é identificada, os autores realizam um estudo para verificar se há um padrão de forma a generalizar. O objetivo é a geração de um catálogo de padrões de requisitos, então após a identificação de um padrão o mesmo é adicionado a esse catálogo. Para tanto, os autores utilizam a seguinte estrutura para a descrição dos padrões: Objetivo do padrão: Esse campo conduz o analista de sistema na seleção do padrão Descrição do padrão: Texto que descreve ou resume o padrão Parte fixa: Consiste em uma frase que expressa o padrão em si, o objetivo geral e sua identificação. Extensões: É o corpo técnico do padrão. Estas extensões são opcionais, também podem ser expressas em padrões, mais os autores julgam que é melhor mantê-los juntos já que essas extensões expressam um mesmo objetivo para um projeto COTS. Parâmetros: os parâmetros são conjunto de valores específicos que são assumidos durante a aplicação de um modelo de projeto. Uma métrica é definida para cada parâmetro para indicar claramente a semântica do parâmetro. Descrição da avaliação do padrão Nenhuma avaliação é relatada pelos autores, esta fica como trabalho futuro. Porem é afirmado pelos autores que os padrões de requisitos obtidos foram identificados em análise de projetos acabados, e posteriormente testados em projetos nos quais consistiam na seleção de padrões do catálogo em projetos de sistemas COTS. Resultado da pesquisa Catálogo de padrões de requisitos não funcionais baseados em requisitos analisados de projetos anteriores. Este classificado utilizando-se da norma ISO/IEC 9126-1. Comentários adicionais O trabalho dos autores é uma forma de ajudar o analista de sistema a coletar os requisitos de sistema. O trabalho apresenta uma proposta para uso de padrões de requisitos que possa ser aplicados em diferentes projetos. Segundo os autores, padrões de requisitos ajudam os analistas de requisitos há reduzir o tempo na atividade de elicitação de requisitos, devido a não ter a necessidade de iniciar a atividade do zero. O processo no qual a proposta descreve consiste na identificação de padrões e sua instanciação do projeto concreto, o que gera a especificação dos requisitos do sistema e base para o documento de especificação de requisitos. Para a elaboração do catálogo os autores fizeram análise de projetos de software e perceberam que os requisitos não funcionais e não técnicos podem ser reutilizados com pequenas variações independentemente de domínio do sistema. Segundo os autores, os requisitos funcionais não têm essa flexibilidade, a reutilização desses requisitos dá-se em domínio semelhantes de projetos. O catálogo de padrões requisitos dos autores é endereçado a requisitos do tipo não funcionais e não técnicos. O argumento utilizado é de que padrões de requisitos para requisitos não funcionais e não técnicos são de maior utilizada em projetos do que padrões específicos e seriam mais adequados para uso em projetos de domínios específicos. O catálogo é proposto de forma aberta, no qual evolua e cresça a partir de experiências adquiridas em novos projetos. Em um ciclo de vida dos padrões, os novos padrões serão adicionados a partir de novas necessidades e desejos dos stakeholders, e estes serão avaliados a cada utilização do catálogo. Este trabalho foi incluído manualmente na revisão sistemática por se tratar de uma pesquisa realizada anteriormente por Franch et al. (2010), no qual relata o processo seguido anteriormente na pesquisa realizada em 2010.

164

Tabela 26 - Extração dos dados do estudo de Withall (2007).

Data de Publicação 2007/mês/dia Local Microsoft Press

Título Software Requirement Patterns. Autores WITHALL, S. Descrição do padrão O estudo fundamenta um catálogo de padrões de requisitos composto por 37 padrões em oito domínios, que juntos podem representar mais da metade de um conjunto de especificações típicas de requisitos de um sistema comercial. Descrição da avaliação do padrão Os padrões foram identificados a partir de estudos em projetos reais. No estudo apresentado pelo autor, mais de 400 exemplos de escrita de requisitos são apresentados. Segundo o autor, muitos podem ser aplicados sem nenhuma alteração a qualquer tipo de sistema, e os demais servem de ponto de partida para que possa ser adequada a necessidade dos usuários. Resultado da pesquisa Compilação de um catálogo com 37 padrões de requisitos. Comentários adicionais Segundo Withall (2007), padrão de requisitos consiste é uma abordagem para a especificação de um determinado tipo de requisito. Seu emprego fornece orientações sobre como fazer a especificação (escrita) dos tipos mais comuns de requisitos. Isso torna a tarefa de escrita mais fácil e rápida de ser realizada e melhora a qualidade desses requisitos. Para o autor, no desenvolvimento de sistema é normal encontrar requisitos que são de natureza similar ou que apareça com freqüência na maioria dos sistemas. Conforme o autor, a introdução de noção de padrões de requisitos para a escrita de requisitos, é um esforço extra que permite especificar os requisitos de uma forma mais consistente, e que permite descrever a forma de como cada requisitos deve ser usados ou definido. Segundo o autor, os padrões de requisitos fornecem orientações de como escrever os requisitos, sugerindo informações, ajudando com alertas e sugestões que devem de ser consideradas. Também ajuda a poupar tempo, por não ser necessária a escrita do requisito a partir do zero, fornecendo um ponto de partida, uma estrutura para sua construção. Padrões de requisitos também são visto como um fator de qualidade no processo de desenvolvimento de software. No caso dos padrões de requisitos, vêem a promover a consistência entre os requisitos do mesmo tipo.

165

Tabela 27 - Extração dos dados do estudo de Toro et al. (1999).

Data de Publicação 1999/mês/dia Local Proceedings 2nd Workshop on Requirements Engineering (WER’99)

Título A Requirements Elicitation Approach Based in Templates and Patterns Autores TORO, A. D., BERNÁRDEZ, B., RUÍZ, A., TORO, M. Descrição do padrão Neste estudo é apresentado templates de requisitos que podem melhorar a atividade elicitação dos requisitos e de sua expressão. Para isso o autor descreve dois tipos de padrões: padrão lingüístico, que se refere às frases que são normalmente utilizadas nas descrições de linguagem natura dos requisitos, no qual os autores fazem sua parametrização e integração em um template; o outro tipo é o padrão de requisitos, estes são templates de requisitos genéricos que podem ser reutilizados com algumas adaptações durante a atividade de elicitação de requisitos. Descrição da avaliação do padrão Os autores relação sucesso em mais de 40 práticas acadêmicas e utilização em dois projetos reais. Segundo os autores, uma das organizações obteve melhorias da comunicação com os stakeholders. Resultado da pesquisa É apresentado templates e padrões de requisitos que auxiliam na extração e expressão dos requisitos de sistema, com o objetivo de manter os benefícios do uso da linguagem natural para um melhor entendimento dos requisitos por todos os stakeholders. Comentários adicionais Segundo os autores, normalmente a linguagem natural é usada para fazer as especificações de requisitos, isso porque é a única linguagem que é comum para todos os stakeholders. O uso da linguagem natural é um problema reconhecido na literatura, mais o uso de uma notação mais formal muitas vezes faz o entendimento das especificações serem impossíveis de serem entendidas. Para isso, os autores afirmam que o uso de templates para requisitos ajudam a expressar os requisitos, isso estrutura as informações dos requisitos de uma forma fixa. Com isso o analista é auxiliado a encontrar as informações que falta para preencher os requisitos, e os requisitos podem ser facilmente tratados em uma ferramenta computacional e é promovida a reutilização. Também é confirmado pelos autores que o preenchimento dos espaços em branco facilita e agiliza a atividade. E que a reutilização dos templates pode ser feitas diversas vezes, desde que tenha sido identificado e/ou adaptado para um projeto específico.

166

REFERÊNCIAS

AMATRIAIN, X. An Object-Oriented Metamodel for Digital Signal Processing with a focus on Audio and Music, Universitat Pompeu Fabra, Departament de Tecnologia. Tesi de doutorado em informática e comunicação digital. 2004

ANG, A. Improving the quality of knowledge representation for requirements engineering through natural language requirements patterns, SEA '07: Proceedings of the 11th IASTED International Conference on Software Engineering and Applications, ACTA Press, 2007. Disponível em: http://www.actapress.com/Abstract.aspx?paperId=32045. Acessado em junho de 2010.

BARBER, K.S. GRASER, T.J. JERNIGAN, S.R. SILVA, J. The Systems Engineering Process Activities (SEPA) - supportingearly requirements analysis and integration prior to implementationdesign. Australian Journal of Information Systems (AJIS)---Special Issue on Requirements Engineering 7 (1), 75-97, 1999

BRERETON, P., KITCHENHAM, B. A., BUDGEN, D., TURNER, M., KHALIL, M. Lessons from applying the systematic literature review process within the software engineering domain, Journal of Systems and Software 80, 2007

CARVER, J., JACCHERI, L., MORASCA, S., SHULL, F. Issues in Using Students in Empirical Studies in Software Engineering Education, Proceedings of the 9th International Symposium on Software Metrics (METRICS’03), pp. 239 – 249, Sydney, Australia.

COMPAGNA, L., KHOURY, P. E., KRAUSOVÁ, A., MASSACCI, F., ZANNONE, N. How to integrate legal requirements into a requirements engineering methodology for the development of security and privacy patterns, Artificial Intelligence and Law, Netherlands: Springer, 2008

FALBO, R. A., MARTINS, A. F., SEGRINI, B. M., BAIÔCO, G., DAL MORO, R., NARDI, J. C. Um Processo de Engenharia de Requisitos Baseado em Reutilização de Ontologias e Padrões de Análise. VI Jornadas Iberoamericanas de Ingenieería del Software e Ingeniería del Conocimiento, Lima - Perú, 2007

FRANCH, X., PALOMARES, C., QUER, C., RENAULT, S., LAZZER, F. A Metalmodel for Software Requirement Patterns*, REFSQ 2010, Springer-Verlag: Berlin, 2010, p.85-90

FREDJ, M., ROUDIÈS, O. A Pattern Based Approach for Requirements Engineering, Proceedings of the 10th International Workshop on Database & Expert Systems Applications, 1999

GASKA, M. T. Cross-discipline identification of a unified set of requirements engineering process patterns, 1999. Tese de doutorado na State University of New York at Binghamton

GASKA, M. T., GAUSE, D. C. An Approach for Cross-Discipline Requirements Engineering Process Patterns, ICRE 1998, 1998

167

GOTZHEIN, R., KRONENBURG, M., PEPER, C. Reuse in Requirements Engineering Discovery and Application of a Real Time Requirement Pattern*, FTRTFT'1998, 1998

GRAF, C. A Requirements Engineering Perspective to Repositories for Interaction Patterns, EuroPLoP 2007 Focus Group on Pattern Repositories, 2007

HAGGE, L., HOUDEK, F., LAPPE, K., PAECH, B. Using Patterns for Sharing Requirements Engineering Process Rationales, Rationale Management in Software Engineering, pp. 409-427. Heidelberg: Springer-Verlag, 2006

HAGGE, L., LAPPE, K. Sharing Requirements Engineering Experience Using Patterns, IEEE Software, Jan/Feb 2005, 2005a, p.24-31

HAGGE, L., LAPPE, K. Using Requirements Engineering (RE) Patterns for Organizational Learning, Journal of Universal Knowledge Management, vol. 1, no. 2 (2006), 2006, p.137-148

HAGGE, L., LAPPE, K., SCHMIDT, T. REPARE: The Requirements Engineering Patterns Repository, 13th IEEE International Conference on Requirements Engineering (RE’05), 2005b

HATEBUR, D., HEISEL, M., SCHMMIDT, H. A Pattern System for Security Requirements Engineering, Second International Conference on Availability, Reliability and Security, p.356-365, April 10-13, 2007 , 2007

HERMOYE, L. A., LAMSWEERDE, A., PERRY, D. E. Attack Patterns for Security Requirements Engineering, 2008. Disponível em: http://www.ece.utexas.edu/~perry/work/papers/060908-LH-threats.pdf. Acessado em junho de 2010.

HIRONORI, W., ATSUTO, K., YOSHIAKI, F. A Pattern Language for Requirements Elicitation in System Development, in IPSJ Winter Workshop 2006, Kamogawa - Japan, 2006

ISAZADEH, A., MACEWEN, G. H., MALTON, A. Behavioral patterns for software requirement engineering, Proceedings of the 1995 conference of the Centre for Advanced Studies on Collaborative research, Toronto, Ontario: Canada, 1995

ISSA, A. A., AL-ALI, A. Use Case Patterns Driven Requirements Engineering, Computer Research and Development (ICCRD), 2010 Second International Conference on Digital Object Identifier, 2010

KITCHENHAM, B.; CHARTERS, S. Guidelines for performing systematic literature reviews in software engineering, Technical Report EBSE 2007‐001, Keele University and Durham University Joint Report, 2007.

KOZIMA, A., KIGUCHI, T., YAEGASHI, R., KINOSHITA, D., HAYASHI, Y., HASHIURA, H., KOMIYA, S. A System To Guide Interview-Driven Requirements Elicitation Work: Domain -- Specific Navigation Using The Transition Pattern Of Topics, Journal of Integrated Design & Process Science, 2005

168

MAFRA, S. N., TRAVASSOS, G. H. Estudos primários e secundários a busca por evidência em engenharia de Software, Relatório Técnico RT - ES 689/06, Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ, 2006

MAIDEN, N. A. M., BRIGHT, B. P. Recurrent Communication Patterns in Requirements Engineering Meetings, WET ICE, Stanford, California Pohl, 1996

MAIDEN, N. A. M., HARE, M. Problem domain categories in requirements engineering, Int. J. Human-Computer Studies (1998) 49, 281-304, 1998

MENDELY DESKTOP, Mendeley Desktop Research Networks Beta 0.9, 2008, Disponível em: http://www.mendeley.com/, Acessado em novembro de 2009

MENDEZ-BONILLA, O., F., X., QUER, C. Requirements Patterns for COTS Systems, Seventh International Conference on Composition-Based Software Systems, 2008

MERRICK, P., BARROW, P. Testing a Requirements Pattern Language through Reverse Engineering, INCOSE Conference, Toulouse: França, 2004

PAVAN, P., MAIDEN, N. A. M., ZHU, X. Towards a Systems Engineering Pattern Language: Applying i* to Model Requirements-Architecture Patterns, ICSE 2003: Portland, Oregon, USA - Workshop on Software Requirements to Architectures (STRAW), 2003

RENAULT, S., MÉNDEZ-BONILLA, Ó., FRANCH, X., QUER, C. A Pattern-based Method for Building Requirements Documents in call-for-tender Processes, International Journal of Computer Science and Applications, Vol. 6, No. 5, pp 175-202, 2009a

RENAULT, S., MÉNDEZ-BONILLA, Ó., FRANCH, X., QUER, C. PABRE: Pattern-Based Requirements Elicitation, Third International Conference on Research Challenges in Information Science, RCIS 2009, 2009b

SIKKEL, K., WIERINGA, R., ENGMANN, R. A Case Base for Requirements Engineering: Problem Categories and Solution Techniques, Sixth International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ'00), 2000

SILVA, O., GARCIA, A., LUCENA, C. The Reflective Blackboard Pattern: Architecting Large Multi-agent Systems, Lecture Notes in Computer Science, Berlin: Springer-Verlag, 2003

TOLEDO, D. E. F. Um Processo Ágil de Engenharia de Requisitos com Apoio de Padrões de Software, 2008. Dissertação de Mestrado em Ciência da Computação da Universidade Federal de São Carlos

TORO, A. D., BERNÁRDEZ, B., RUÍZ, A., TORO, M. A Requirements Elicitation Approach Based in Templates and Patterns, In Proceedings 2nd Workshop on Requirements Engineering (WER’99), 1999

TSUMAKI, T. Requirements Engineering Pattern Structure. APSEC'04, 2004

XUAN, H., BIN, L., YICHEN, W. Application of software requirement error pattern based on ontology, Beijing : China, 2009

169

WAHONO, R. S. On the Requirements Pattern of Software Engineering, Temu Ilmiah XI 2002, 2002

WATAHIKI, K., SAEKI, M. Scenario Evolution in Requirements Elicitation Processes: Scenario Pattern and Framework Approach, Proceedings of the 4th International Workshop on Principles of Software Evolution, Vienna - Austria, 2001

WITHALL, Stephen. Software Requirement Patterns. Washington: Microsoft Press, 2007.

ZLATEV, Z., DANEVA, M., WIERINGA, R. Multi-Perspective Requirements Engineering for Networked Business Systems: A Framework for Pattern Composition, WER 2005, Porto:Portugal, 2005.

170

APÊNDICE B - REVISÃO SISTEMÁTICA DA LITERATURA SOBRE REUSO DE REQUISITOS

Este documento apresenta o resumo de uma revisão sistemática da literatura sobre reuso de

ativos de software. Esta revisão teve o papel de demonstrar o estado da arte sobre a reutilização de

requisito no processo de desenvolvimento de software.

3.5 REVISÃO SISTEMÁTICA DA LITERATURA REALIZADA POR KONDA E MANDAVA (2010)

A revisão sistemática da literatura realizada por Konda e Mandava (2010) teve como

objetivo:

Identificar os ativos reutilizáveis que não sejam de codificação;

Identificar métodos/abordagens apresentadas na literatura sobre reuso de ativos;

Identificar métricas e modelos utilizados para avaliar o valor da reutilização;

Identificar métodos para a manutenção de software reutilizável.

Para tanto, foram elaboradas as seguintes perguntas de pesquisa:

Q1 – Quais são os outros ativos além da codificação que tem sido mencionados na literatura

como reutilizável?

Q1.1 – Quais são os métodos ou abordagens de reutilização desses ativos?

Q1.2 – Qual é o status de avaliação desses ativos?

Q1.3 – Quais são os ativos em foco?

Q2 – Quais são as métricas e modelos que tem sido propostas para medir a reutilização e

para avaliar o seu valor?

Q2.1 – Qual é o status de avaliação desses ativos?

Q2.2 – Quais são as áreas de foco?

171

Q3 – Que abordagens têm sido propostas para a manutenção de software reutilizável?

Q3.1 – Qual é o status de avaliação?

Q3.2 – Quais são as áreas de foco?

Neste sentido, Konda e Mandava (2010) elaboraram uma estratégia de busca que consistia

em 4 fases, essas fases são detalhadas nas próximas seções.

No entanto, como o foco deste capítulo é apresentar o estado da arte de pesquisas que

apóiem o reuso de requisitos, somente foram consideradas as etapas da revisão sistemática de

Konda e Mandava (2010) que visem responder a Q1 ora apresentada.

3.5.1 Fase 1

Nesta fase foram executadas buscas por via eletrônica e por citações de pesquisa. Aqui os

autores procuram fazer a identificação dos termos de pesquisa e formular as questões de pesquisa.

Neste momento, as bases de dados eletrônicas utilizadas durante o estudo de mapeamento

sistemático foram: IEEE Xplorer, Inspec + Compendex, ACM Digital, Elsevier e Springer.

Contudo, os autores utilizaram o Google Scholar para realização de busca das citações de pesquisa e

na amostragem Snowball18. Também é relatado que alguns estudos encontrados durante a

amostragem snowball são provenientes do banco de dados Citeseer. O período estipulado pelos

autores para compor esta revisão sistemática é de estudos publicados até o primeiro semestre de

2009, sem nenhum limite mínimo.

Para a elaboração dos termos de pesquisa, os autores relatam que utilizaram termos

derivados da população, da intervenção, do resultado e do contexto. O Quadro 8 relaciona esses

valores utilizados pelos autores nesta etapa.

18 Snowball é uma abordagem para estudo de população oculta. Entende-se com oculto uma população de trabalho de pesquisa que não são encontrados quando executado um processo de pesquisa (KONDA; MANDAVA, 2010 p. 9)

172

Quadro 8 - População, Intervenção, Contexto, Resultado para cada pergunta de pesquisa (KONDA; MANDAVA, 2010).

População Intervenção Contexto Resultado

Q1 Reuso de Software Revisão de ativos reutilizáveis

Acadêmico Reuso de ativos

Q1.1 Reuso de Software Métodos para ativos reutilizáveis

Acadêmico Métodos

Q1.2 Reuso de Software Avaliação de status para ativos

Acadêmico Gráfico representando o percentual de avaliações.

Q1.3 Reuso de Software Foco em ativos Acadêmico Gráfico mostrando a contribuição das pesquisas por ano para cada ativo

Q2 Reuso de Software Avaliando o valor da reutilização

Acadêmico Reuso de métricas e modelos

Q2.1 Reuso de Software Avaliação de status para o valor de reutilização

Acadêmico Gráfico representando o percentual de avaliações.

Q2.2 Reuso de Software As áreas em foco para o valor de reutilização

Acadêmico Gráfico mostrando quanto ao valor da contribuição do estudo em categorias (métrica de reutilização e modelos) por ano.

Q3 Reuso de Software Manutenção de software reutilizável

Acadêmico Métodos/Modelos/Métricas/Pesquisas

Q3.1 Reuso de Software Avaliação de status para manutenção de software reutilizável

Acadêmico Gráfico representando o percentual de validação

Q3.2 Reuso de Software As áreas em foco para a manutenção de software reutilizável

Acadêmico Gráfico mostrando a contribuição da pesquisa para cada categoria de manutenção por ano

Após esta etapa Konda e Mandava (2010) iniciaram o processo de pesquisa que foi realizada

usando os termos 1, 4, 5, 6, 20, 21, 22 e 24 relacionados no Quadro 9. Segundos os autores desta

revisão sistemática, a utilização desta estratégia não foi suficiente para encontrar os estudos

necessários para responder as perguntas de pesquisa. Então, para encontrar outros ativos que

possam ser reutilizados, Konda e Mandava (2010) realizaram um estudo de mapeamento

sistemático, no qual foram localizados 14 tipos de ativos além da codificação que podem ser

reutilizados. Além da codificação, os demais ativos reutilizáveis são:

1. Algoritmos 2. Arquitetura 3. Dados 4. Designs 5. Documentação 6. Templates para estimativa 7. Interface humana 8. Conhecimento 9. Modelos 10. Módulos 11. Planos

173

12. Requisitos 13. Contratos de serviço 14. Casos de Teste

Quadro 9 - Termos de busca.

Termos de busca

1. Ativos 2. Algoritmos 3. Arquitetura 4. Artefatos 5. Aspectos 6. Componentes 7. Dados 8. Designs 9. Documento 10. Estimativas 11. HCI 12. Interfaces homem-computador 13. Interface humana

14. Conhecimento 15. Ciclo de vida 16. Modelos 17. Módulos 18. Planos 19. Requisitos 20. Reutilizável 21. Reutilização 22. Reutilizados 23. Contratos de serviços 24. Software 25. Teste

A fim de obterem mais estudos sobre cada ativo reutilizável, utilizaram os termos de busca

referidos no Quadro 9 como termos de busca para construção das strings de busca. As strings de

buscas utilizadas para localizar os estudos estão ilustradas no Quadro 10.

Quadro 10 - Strings de busca.

Strings de Busca

1. asset AND reuse OR reusable AND software 2. Lifecycle AND reuse AND software 3. software AND reusable AND aspects 4. software AND reusable AND artifacts 5. software AND reusable AND components 6. {Reusable OR reuse} AND Data 7. {Reusable OR reuse} AND Documentation 8. {Reusable OR reuse} AND Estimates(Templets) 9. {Reusable OR reuse} AND plans(project plans) 10. {Reusable OR reuse} AND {Test cases OR Test designs} 11. {Reusable OR reuse} AND Service contracts 12. {Reusable OR reuse} AND Algorithms 13. {Reusable OR reuse} AND Designs 14. {HCI} AND {software AND reus*} AND {asset OR artifact OR component} 15. Knowledge AND {software AND reus*} AND {asset OR artifact OR component} 16. Requirements AND {software AND reus*} AND {asset OR artifact OR component} 17. Architecture AND {software AND reus*} AND {asset OR artifact OR component} 18. Human Interface AND {software AND reus*} AND {asset OR artifact OR component} 19. Human computer Interface AND {software AND reus*} AND {asset OR artifact OR component} 20. Models AND {software AND reus*} AND {asset OR artifact OR component} 21. Modules AND {software AND reus*} AND {asset OR artifact OR component}

Na próxima etapa os artigos são obtidos por meio da execução dos critérios de inclusão e

exclusão, que consiste a Fase 2. Esta etapa está descrita na próxima seção.

174

3.5.2 Fase 2

Nesta fase colocou-se em prática a execução dos critérios de inclusão e exclusão dos estudos

encontrados. Os critérios básicos de inclusão dos estudos necessários para responder a questão de

pesquisa foram:

1. Artigos cujo tema coincide com a área do tema.

2. Artigos cujo abstract coincidisse com a área do tema.

3. Somente artigos não redundantes.

A aplicação dos critérios básicos reduziu o numero de 191.241 estudos encontrados na fase

1 para 2.299 estudos. Após esta etapa, Konda e Mandava (2010, p.9) aplicaram os critérios de

inclusão e exclusão. Os critérios de inclusão consistiam em:

1. O artigo deve ser revisado.

2. O artigo deve estar com o texto disponível na íntegra.

3. O artigo deve de incidir sobre o reuso de software.

4. O artigo deve ser na área tema do valor dos ativos ou a manutenção em reutilização

de software.

5. O artigo deve ser revisão da literatura, revisão sistemática, estudo de mapeamento

sistemático, estudo de caso, experimento ou relato de experiência, pesquisa ou

estudo comparativo.

6. O artigo deve ser incluído, se propõe um modelo, uma métrica, uma abordagem ou

um método.

7. O artigo deve ser incluído se trata da extensão de modelo existente.

8. O artigo deve ser incluído se trata da validação de modelos já existentes ou de uma

proposta de um novo modelo.

Já os critérios de exclusão utilizados por Konda e Mandava (2010, p.9) consistiam em:

175

1. Os artigos que não estiverem em conformidade com os critérios de inclusão devem

ser excluídos.

2. Alguns artigos que mencionam a gestão de manutenção também devem ser

excluídos. Segundo Konda e Mandava (2010), o nome gestão de reuso de software

pode se referir a armazenamento e recuperação de ativos reutilizáveis, que não está

relacionado ao trabalho proposto pela revisão e, portanto, devem ser excluídos.

3. Artigos que não estejam escritos na língua inglesa devem ser excluídos.

3.5.3 Fase 3

Esta fase consistiu na análise dos resultados obtidos no estudo de mapeamento sistemático,

incidindo principalmente sobre o estado de validação dos estudos, as áreas de foco do estudo e

mudanças nas tendências da pesquisa. Nesta etapa os autores relatam que houve um desvio das

orientações de Kitchenham, e que neste passo aplicou-se a abordagem chamada de Snowball para

estudo de população oculta. Como resultado obteve-se os seguintes dados conforme ilustra a Tabela

28.

Tabela 28 - Estudos obtidos para responder a Q1. Número de hits Critério básico de

inclusão Detalhado critérios de inclusão / exclusão

Abordagem Snowball

Google Scholar - - - 21 ACM 17761 24 13 - Inspec 36673 108 12 - IEEE 244 36 19 - Elsevier 12469 42 5 - Springer 68892 363 9 - Total 136039 573 58 21

3.5.4 Fase 4

Esta fase consistiu na análise dos estudos provenientes das outras três fases. A Tabela 29

demonstra a quantidade de estudos localizados na revisão sistemática para cada respectivo ativo

reutilizável.

176

Tabela 29 - Estudos localizados na revisão. Ativos reutilizáveis Quant. de estudos Algoritmos 1 Arquitetura 11 Dados 5 Designs 10 Documentação 9 Templates para estimativa 2 Interface humana 5 Conhecimento 7 Modelos 1 Módulos 4 Planos 7 Requisitos 19 Contratos de serviço 2 Caso de teste 10

Como síntese da análise apresentada por Konda e Mandava (2010), pode-se destacar que a

maioria dos estudos localizados sobre reutilização de ativos é dedicada a reuso de requisitos de

software. Dos 19 estudos sobre reuso de requisitos somente 4 passaram por algum tipo de avaliação,

e 4 tratavam de discussões sobre reuso de um modo geral, e 1 estudo tratava de uma revisão da

literatura. Em análise aos estudos, percebeu-se que no início da década de 90 iniciou-se o interesse

da comunidade em investigações de reuso de ativos, esse interesse manteve-se em alta até o fim

dessa mesma década. Observou-se também que alguns estudos foram apresentados entre 2001 e

2006, e a partir de 2007 a comunidade voltou a apresentar investigações sobre reuso.

177

APÊNDICE C - RELACIONAMENTO ENTRE OS PADRÕES

Figura 33 - Relacionamento entre os padrões.

178

APÊNDICE D - PROPOSTA DE ESTUDO DE CASO 1: LOJA VIRTUAL "LIVRARIA THE BOOKS"

A livraria The Books é uma livraria com sede na capital catarinense e conhecida como a loja

que tem os melhores livros didáticos para crianças a partir de 1 ano. Além de oferecer livros

didáticos, a livraria The Books também oferece em sua loja uma ampla e diversificada gama de

títulos de origem nacional e internacional, como também CD’s e DVD’s, mas com menor

intensidade.

Hoje a livraria pretende ampliar seus negócios, disponibilizando para seus clientes o serviço

de venda pela internet, por intermédio de uma loja virtual. Nesta loja virtual, os proprietários

gostariam de efetuar vendas dos seus produtos já disponíveis em sua loja física, como também a

realização de pré-venda de produtos, como já realiza os seus concorrentes. Outra preocupação dos

proprietários é de prover pagamento de seus produtos por intermédio de vendas com cartão de

crédito.

Em sua loja física, a livraria oferece a disposição dos livros por seções, por exemplo:

romance, autoajuda, literatura estrangeira, literatura infanto-juvenil, religiosos, entre outros. Essa

mesma disposição é exigida pelos proprietários para o site. As informações necessárias para

gerenciar os livros da livraria estão na ficha de cadastro do livro, em anexo (Anexo B). Na busca

por um livro, o mesmo pode ser encontrado pelo título da obra, autor, editora e ISBN, para isso com

apenas parte da informação já poderia ser possível a sua localização.

Após a busca e seleção dos produtos na loja virtual é necessário o cálculo do frete para o seu

envio. Atualmente, a forma de envio dos produtos é feita pelo serviço de Sedex oferecido pelas

empresas de Correios. Para isso, a empresa utiliza uma tabela com os pesos, localidades e valores

do frete para as encomendas, conforme anexo (Anexo C).

Na finalização do pedido, devem ser calculados o valor da compra do cliente, mais o valor

do frete para o pedido. O sistema deve apresentar todas essas informações e solicitar a autenticação

do usuário que está realizando a compra. Nesta versão da loja virtual, o cliente poderá optar por

pagamento à vista (boleto, transferência bancária e cartão de débito) ou a prazo com cartão de

crédito.

179

Para a autenticação do cliente, o mesmo poderá ser feito através do endereço de email e

senha cadastrados em sua primeira compra. Para o cadastro do cliente são necessários os seguintes

dados: nome, data de nascimento, número do documento, endereço, endereço de e-mail e senha para

acesso. Uma opção para realizar a recuperação de senha perdida também se faz necessária,

enviando-a para o endereço de e-mail cadastrado pelo cliente.

Após o pagamento, deseja-se que o sistema registre um comprovante da transação, contendo

o nome do cliente, documento, data e hora que foi efetuado o encerramento da compra, descrição

dos produtos comprados e suas respectivas quantidades, descrição do cálculo do frete e dados da

transação com a operadora de cartão. Os dados da transação estão descritos no documento em anexo

(Anexo D) disponibilizado pela operadora de cartão de crédito.

Ressalta-se que a loja virtual deve ser compatível com os dois navegadores de internet

líderes do mercado (Internet Explorer e Mozzila Firefox). Como se trata de um serviço on-line,

torna-se necessário estabelecer um tempo de resposta razoável, e utilizar-se de uma interface leve e

amigável obedecendo as recomendações de ergonomia feita pela ErgoList disponível em <

http://www.labiutil.inf.ufsc.br/ergolist/ >.

Para o gerenciamento da loja virtual, é necessário um módulo de administração, o qual deve

ser restringido por meio de senha de acesso. Deseja-se neste módulo de administração a execução

das seguintes funções:

Controle sobre o envio dos pedidos. Deseja-se adicionar informações sobre o

processo de envio dos pedidos, como, por exemplo: data de despacho do pedido,

informações para rastreamento do pedido através do número de objeto no site dos

Correios e data prevista para a entrega;

Neste módulo alguns relatórios e consultas são desejáveis:

Lista de pedidos de clientes que ainda estão pendentes de envio, contendo o nome

do cliente, data da compra, forma de envio selecionada, dados da localidade para a

entrega e a descrição e quantidade dos itens comprados;

Resumo de vendas por período. As informações exibidas devem ser agrupadas e totalizadas

por dia, semana, mês e ano. Para cada agrupamento, o relatório deve conter o nome do

180

cliente, descrição dos produtos comprados e respectivas quantidades, valor do frete,

desconto promovido e total geral da compra. Este permite a exibição de informações sobre

estatísticas de venda.

181

APÊNDICE E - PROPOSTA DE ESTUDO DE CASO 2: SISTEMA DE RESERVA ONLINE DE UMA LOCADORA DE VEÍCULOS

A empresa Alugo Carros é uma locadora de veículos que oferece uma grande variedade de

carros de acordo com as necessidades de seus clientes. A empresa Alugo Carros é conhecida no

mercado por oferecer veículos revisados a cada locação, garantindo a seus clientes o conforto de

estar sempre de carro novo.

Hoje a empresa pretende ampliar seus negócios, disponibilizando para seus clientes a

possibilidade de realizar a reserva de veículos pela internet através de um website. Neste website, os

proprietários gostariam de disponibilizar o seu serviço de locação e reserva. Outra preocupação dos

proprietários é de prover o pagamento de seus serviços por intermédio de cartão de crédito.

Atualmente a reserva de veículos pode ser feita por telefone, mas o pagamento só é efetivado na

hora da retirada do veículo. Outra dificuldade apontada pelos proprietários é em relação à

demonstração dos veículos para os clientes que realizam reserva por telefone, enviando folder com

os veículos por e-mail ao cliente.

Para simplificar essas atividades espera-se que o cliente possa visualizar toda a frota da

empresa e suas tarifas online. O cliente deve selecionar um veículo, esses dispostos em categorias,

por exemplo: passeio, utilitários e blindados. A busca de um veículo também pode ser feita por

grupos, como, por exemplo: A-econômico, C-econômico com ar, e etc. Outra informação que deve

ser apresentada é o valor da diária e valor semana + dia extra. O folder em anexo ilustra uma

possível maneira de apresentar estas informações (Anexo E).

Após a seleção de um veículo, o cliente deve fornecer os dados da reserva. A reserva

compreende a data e hora de retira e devolução, escolha da tarifa e opção de cobertura de risco. Para

o contrato de cobertura de risco é utilizada uma tabela, em anexo (Anexo F).

Na finalização da reserva devem ser calculados os valores referentes à reserva do cliente,

mais o valor das opções de cobertura de risco. O sistema deve apresentar todas essas informações, e

solicitar a autenticação do usuário que está realizando a reserva. O cliente poderá optar por

pagamento à vista (boleto, transferência bancária e cartão de débito) ou a prazo com cartão de

crédito, conforme registrado em ata de reunião em anexo (Anexo G).

182

Para a autenticação do cliente, o mesmo poderá ser feito através do endereço de email e

senha cadastrados em sua primeira reserva. Para o cadastro do cliente são necessários os seguintes

dados: nome, data de nascimento, número do documento (cpf ou passaporte), endereço, e-mail e

senha para acesso. Uma opção para realizar a recuperação de senha perdida também se faz

necessária, enviando-a para o endereço de e-mail cadastrado pelo cliente.

Após o pagamento, deseja-se que o sistema registre um comprovante da transação, contendo

dados do cliente, dados da reserva, data e hora que foi efetuado o encerramento da reserva, e demais

dados da transação realizada com a operadora de cartão conforme anexo (Anexo D).

Deseja-se também que o website seja compatível com os dois navegadores de internet

líderes do mercado (Internet Explorer e Mozzila Firefox). Como se trata de um serviço on-line,

torna-se necessário estabelecer um tempo de resposta razoável (estima-se que o tempo de 4

segundos seja um valor razoável), e utilizar-se de uma interface leve e amigável obedecendo as

recomendações de ergonomia feita pela ErgoList disponível em <

http://www.labiutil.inf.ufsc.br/ergolist/ >.

Para o gerenciamento do sistema, é necessário um módulo de administração, o qual deve ser

restringido por meio de senha de acesso. Deseja-se neste módulo de administração a execução das

seguintes funções:

Check-in: é a retirada do carro em si. No check-in o cliente deve apresentar a carteira

de habilitação e assinar o contrato de locação. Somente serão aceitos condutores com

idade mínima de 21 anos com carteira de habilitação emitida a mais de 2 anos. No

caso de outra pessoa também utilizar o veículo será necessário o preenchimento de

um termo de condutor adicional. As informações do termo de condutor adicional são:

nome do condutor, data de nascimento, número da carteira de habilitação. Ainda no

check-in, deve-se também ser assinado pelo cliente um termo de aceitação da vistoria

técnica.

Check-out: é a devolução do veículo a locadora. Neste momento será realizada uma

avaliação do estado do veículo através de um check list, caso seja constatado alguma

não conformidade a mesma será cobrada do cliente, alguns exemplos de verificação

do check list seriam: entrega com tanque cheio, presença dos itens de acessórios, etc.

183

Manutenção das categorias de veículos;

Manutenção dos veículos. As informações sobre os veículos são: categoria, grupo,

valor diária, valor semana, valor dia (o valor dia é utilizado quando um cliente opta

pelo “valor semana” e estende o prazo de reserva), modelo de veículos.

Neste módulo alguns relatórios e consultas são desejáveis:

Resumo de reservas por período. As informações exibidas devem ser agrupadas e totalizadas

por dia, semana, mês e ano. Para cada agrupamento, o relatório deve conter o nome do cliente,

descrição grupo, modelo de veículo, valor das opções de cobertura de risco, desconto promovido e

total geral da reserva. Este permite a exibição de informações sobre estatísticas de reserva.

184

APÊNDICE F - MODELO DE CORREÇÃO DO ESTUDO DE CASO 1

Este modelo de correção destina-se a servir de referência para correção do estudo de caso 1:

livraria virtual.

Quadro 11 - Requisitos funcionais.

Id Resumo Descrição do requisito Classificação RF01 Realizar venda Deve haver uma função para realizar uma venda para

um cliente. Cada venda deve conter as seguintes informações:

cliente; produtos; valor de venda de cada item de produto; quantidade de item de venda; data/hora; id da venda; valor do frete.

Uma venda é a realização de uma transação comercial no estabelecimento (efetivação do recebimento de venda de item de produto). Cada venda é exclusivamente identificada por um id da venda.

Transação

RF02 Consulta de produtos/livros (Para efeitos de correção, serão aceitos quais atributos em relação dos dados a serem exibidos pela consulta em virtude de não ter sido especificado no estudo de caso)

Deve haver uma consulta que mostre os produtos/livros que retorne uma lista de produtos. O seu objetivo é permitir a exibição dos produtos já existentes. Para cada produto, a consulta deve exibir o seguinte:

id do produto nome; fabricante; preço de venda.

Os itens a serem exibidos serão ordenados pelo nome do produto/livro. No caso do produto ser um livro, os itens a serem exibidos pode ser especificado por se adequar em qualquer dos seguintes critérios de seleção:

título da obra; autor; editora; seção; ISBN.

No caso dos demais produtos, os itens a serem exibidos podem ser especificados por se adequar em qualquer dos seguintes critérios de seleção:

Consulta

185

id produto; nome do produto.

O usuário deve ser capaz de navegar sobre a lista de produtos/livros retornada. O usuário deve ser capaz de interagir com a consulta podendo selecionar um ou vários produtos/livros para adicionar ao seu

RF03 Manter produto/livro

O sistema deve armazenar as seguintes informações sobre um livro:

título da obra; data de cadastro; autor(es); editora; ISBN; n. da edição; ano; assunto; local; n. páginas; língua; peso; sinopse; em pré-venda.

Um livro é tratado como um item de venda. Cada livro é identificado exclusivamente por id do produto.

Entidade ativa

RF04 Auto-registro de Cliente

Uma pessoa deve ser capaz de se registrar como um cliente, por um formulário de cadastro de cliente. Deve ser solicitado a informar os seguintes dados pessoais:

nome; data de nascimento; número do documento; endereço; e-mail; senha para acesso.

Registro de usuário

RF05 Registro comprovante de venda

Deve haver uma função para criar o comprovante de venda para um cliente. Cada comprovante de venda deve conter as seguintes informações:

nome do cliente; documento; data/hora do encerramento da compra do

cliente; descrição dos produtos comprados; qt. dos produtos; descrição do cálculo do frente dados da operadora (quando for cartão de

crédito);

Transação

186

o TID (número único gerado pela loja a cada transação);

o MERCHID (nome do arquivo de configuração da loja);

o PRICE (valor capturado pela transação);

o FREE (campo de livre digitação); o LR (código retorno da transação,

sendo: 0 = capturado, 1 = autorização negada, 3 = captura já efetuada.);

o ARS (mensagem da transação); e o cap (retorno do valor capturado).

Um registro do comprovante de venda é o registro dos dados retornados pelos provedores de pagamento (operadoras de cartão e bancos). Um registro de comprovante de venda considera-se que uma transação de venda foi finalizada com sucesso.

RF06 Manter Administrador

O sistema deve armazenar as seguintes informações sobre o administrador:

id do administrador. nome do administrador; login; senha.

Um Administrador é uma pessoa que tem acesso ao módulo de administração da loja. Cada administrador é identificado exclusivamente por id de administrador.

Entidade ativa

RF07 Registrar informações sobre o processo de envio dos pedidos (módulo administrador)

Deve haver uma função para registrar informações sobre o processo de envio dos pedidos para um cliente. Cada registro sobre o processo de envio deve conter as seguintes informações:

registro de venda; data de despacho do pedido; informações de rastreamento do pedido; data prevista para entrega;

Um registro de informações sobre o processo de envio dos pedidos fornece informação sobre o controle de envio do pedido para o cliente, passando informações sobre sua localização (no transporte e logística). Um registro de informações sobre o processo de envio dos pedidos é realizado logo após o processo de envio do pedido ao cliente.

Transação

RF08 Relatório de pedidos pendentes de envio (módulo administrador)

Deve haver um relatório que mostre a lista de pedidos de clientes que ainda estão pendentes de envio ordenadas pela ordem crescente do id de venda. O objetivo deste relatório é informar o departamento de logística sobre os pedidos ainda pendentes de serem

Relatório

187

enviados. Para cada pedido de cliente, o relatório deve mostrar o seguinte:

nome do cliente; data da compra; dados da entrega; descrição do item de produto; qt. do item de produto.

Os itens a serem exibidos podem ser especificados por enquadrar no seguinte critério de seleção:

pedidos não enviados. Os totais devem ser mostrados para cada venda. Uma nova página deve ser iniciada por uma nova venda.

RF09 Relatório de resumo de vendas por período (módulo administrador)

Deve haver um relatório que mostre o resumo de vendas por um determinado período de vendas ordenadas por dia. O objetivo deste relatório é a exibir informações para estatísticas de venda. Para cada dia de movimento, o relatório deve mostrar o seguinte:

nome do cliente; descrição dos produtos comprados; qt. dos produtos; valor do frente; total geral da compra.

Os itens a serem exibidos podem ser especificados por enquadrar em qualquer dos seguintes critérios de seleção:

período informado. Os totais devem ser mostrados para exibir resultados agrupados e totalizados por dia, semana, mês e ano.

Relatório

Quadro 12 - Requisitos não funcionais.

Id Resumo Descrição do requisito Classificação RNF01 Formas de

pagamento Deve ser possível especificar a forma de pagamento com o objetivo de especificar os tipos de pagamentos aceitos. Este é um tipo de ativo aceito como forma de pagamento (por exemplo, dinheiro, cheque ou cartão de crédito/débito), sendo aceitos pagamentos feitos em dinheiro, cheque e cartões. Este valor só pode ser alterado apenas na inicialização do sistema.

Configuração

RNF02 Determinação do valor do frete

O frete deve ser determinado da seguinte forma: 1. calcula-se o valor do peso total da compra; 2. calcula-se o valor total da compra (valor

declarado); 3. com base no peso total calculado, seleciona-se

Fórmula de cálculo

188

o valor correspondente “peso/destino” na tabela de preços do sedex fornecida pelos correios.

Limite máximo para declaração de valor: R$ 10.000,00. Referência do cálculo: tabela de valores do sedex. Por exemplo, peso total da compra é de 1kg, o valor da compra é de R$ 450,00, o destino é interior de Goiás. Para esta compra o valor do frete é de R$ 30,80.

RNF03 Cálculo do valor total da compra

Total da compra deve ser calculado da seguinte forma: total da compra = (soma(valor unitário * quantidade) + valor do frete) Onde valor unitário é o valor unitário estabelecido para o item de produto atual quantidade é a quantidade do item selecionado para o pedido. valor do frete é valor do cálculo realizado para o frete do pedido. percentual de desconto é o valor em percentual de desconto proporcionado sob o valor total da compra. Por exemplo, uma compra de dois itens, no primeiro item corresponde a 2 unidade de valor unitário R$ 230,00. O segundo item, 1 unidade de valor unitário R$ 45,00 e frete calculado em R$ 25,40. A expressão do cálculo corresponde: total da compra = (((230,00 * 2) + (45,00 *1)) + 25,40)

Fórmula de cálculo

RNF04 Autenticação/Login Cliente

Um cliente deve ser capaz de autenticar-se em um processo de log in entrando com o endereço de e-mail e senha. Ele pode optar por efetuar login em qualquer momento (visitando a página de login), mas se não tiver feito, ao tentar finalizar uma compra deve-se solicitar para que o faça, sendo que o cliente não poderá prosseguir a finalização da compra sem que tenha feito isso. A identidade de cada cliente deve ser determinada antes que possam finalizar ou visualizar suas compras. Isto será conseguido por parte do cliente digitando seu endereço de e-mail e senha.

Autenticação de usuário

RNF05 Autenticação/Login Um cliente que esqueceu sua senha deve ser capaz Autenticação

189

Cliente (Recuperação de senha)

de recuperar-la utilizando seu endereço de e-mail cadastrado, no qual receberá uma mensagem com um código para sua autenticação. Isto deve ser obtido utilizando o seguinte processo:

1. O cliente indica via tela de log-in que esqueceu a senha e informa seu endereço de e-mail.

2. O sistema de e-mails envia a senha perdida para seu endereço de e-mail registrado.

Após a recepção da senha, o cliente pode fazer log-in.

de usuário (requisito extra)

RNF06 Compatibilidade com os navegadores de internet

A interface do usuário deverá ser compatível com os navegadores de internet (Internet Explorer e Mozzila Firefox. Internet Explorer nas versões 8 e 9, e o navegador Mozzila Firefox na versão 4. Entende-se que estes dois navegadores são os mais utilizados pelos clientes alvos da empresa.

Tecnologia

RNF07 Tempo de resposta para as transações

Cada transação deve ter um tempo de resposta não superior a 3 (três) segundos. Este valor é baseado em indicativos de testes anedóticos que os usuários começam a perder a paciência logo após esse tempo. Este requisito não se aplica as consultas em grandes volumes de dados onde critérios de seleções arbitrárias são permitidos.

Tempo de resposta

RNF08 Em conformidade com o padrão ergonomia

O sistema deve obedecer em sua totalidade do padrão de ergonomia recomenda pela ErgoList a fim de apresentar interfaces mais amigáveis aos seus usuários. Fonte: http://www.labiutil.inf.ufsc.br/ergolist.

Aderência ao padrão

RNF09 Autenticação/Login Administrador

Um administrador deve ser capaz de autenticar-se em um processo de log in entrando com o endereço de e-mail e senha. A identidade do administrador deve ser determinada antes que possa realizar qualquer função do módulo administrativo.


190

APÊNDICE G - MODELO DE CORREÇÃO DO ESTUDO DE CASO 2

Este modelo de correção destina-se a servir de referência para correção do estudo de caso 2:

locadora de veículos.

Quadro 13 - Requisitos funcionais.

Id Resumo Descrição do requisito Padrão RF01 Registrar reserva Deve haver uma função para registrar reserva para

um cliente. Cada reserva deve conter as seguintes informações:

cliente; veículo; data e hora da retirada (check-in); valor da tarifa aplicada; e data e hora da devolução (check-out); plano de cobertura de risco (o valor do plano de

cobertura de risco é determinado grupo em que o veículo pertence)

id reserva.

Um registro de reserva deve gravar os dados referentes a uma reserva realizada pelo cliente. Cada registro de reserva é exclusivamente identificado por um id reserva.

Transação

RF02 Registrar pagamentos de locações

Deve haver uma função para realizar o pagamento de uma locação pelo cliente. Cada pagamento de locação deve conter as seguintes informações:

id da transação; id da locação; data/hora pagamento.

Um pagamento de locação é um registro de pagamento (entrada no caixa) de pagamento do serviço de locação. Cada pagamento é exclusivamente identificado por um id da transação.

Transação

RF03 Consulta de veículos da frota da empresa

Deve haver uma consulta de veículos da frota da empresa que retorne todos os veículos disponíveis para reserva/locação. O seu objetivo é exibir os veículos pertencentes à frota da empresa para que o cliente possa selecionar para realizar um reserva/locação. Para cada veículo, a consulta deve exibir o seguinte:

categoria (passeio, utilitário e blindados);

Consulta

191

grupo (A-econômico, C-econômico com ar, e etc);

valor da diária; valor semana + valor do dia extra; modelo do veículo (GM Celta 1.0, WG Gol 1.6,

e etc); qt. de portas; motorização; direção (manual ou incluído); ar condicionado (não ou incluído) trio elétrico; rádio cd player; air bag freios ABS; n. de ocupantes; capacidade bagagem (qt. de malas grandes e qt.

de malas pequenas); imagem do veículo.

Os itens a serem exibidos serão ordenados e agrupados por grupo (A-econômico, C-econômico com ar, e etc). Os itens a serem exibidos podem ser especificados por se adequar em qualquer dos seguintes critérios de seleção:

grupo; categoria.

O usuário deve ser capaz de navegar pela lista de veículos disponíveis. O usuário deve ser capaz de interagir com a consulta podendo selecionar um veículo para uma reserva/locação.

RF04 Auto-registro de Cliente

Uma pessoa deve ser capaz de se registrar como um cliente, por um formulário de cadastro de cliente. Deve ser solicitado a informar os seguintes dados pessoais:

nome; data de nascimento; número do documento (cpf ou passaporte); endereço; e-mail; senha para acesso.


RF05 Registro comprovante de transação

Deve haver uma função para criar o comprovante de transação para um cliente. Cada comprovante de transação deve conter as seguintes informações:

nome do cliente; cpf do cliente;

Transação

192

data/hora do encerramento da locação do cliente;

dados da reserva (veículo, cobertura de risco, data/hora da retirada e devolução);

dados da operadora; o TID (número único gerado pela loja a

cada transação); o MERCHID (nome do arquivo de

configuração da loja); o PRICE (valor capturado pela

transação); o FREE (campo de livre digitação); o LR (código retorno da transação,

sendo: 0 = capturado, 1 = autorização negada, 3 = captura já efetuada.);

o ARS (mensagem da transação); e o cap (retorno do valor capturado).

Um registro do comprovante de transação com provedor de pagamento é o registro dos dados retornados pelos provedores de pagamento (operadoras de cartão e bancos). Um registro de comprovante de transação considera-se que aconteceu quando uma operação de locação é finalizada pelo cliente.

RF06 Manter Administrador

O sistema deve armazenar as seguintes informações sobre o administrador:

nome do administrador; login; senha.

Um Administrador é uma pessoa que tem acesso ao módulo de administração da locadora. Cada administrador é identificado exclusivamente por id de administrador.

Entidade ativa

RF07 Realizar check-in Deve haver uma função para realizar check-in para um cliente. Cada registro de check-in deve conter as seguintes informações:

dados da reserva; dados da carteira de habilitação do condutor;

Um check-in é a retirada efetiva do veículo junto à locadora pelo cliente. Cada check-in é exclusivamente identificada por um id do check-in. Um check-in considera-se que aconteceu quando o cliente assinou o contrato de locação, apresentou um

Transação

193

condutor habilitado com idade mínima de 21 anos com carteira de habilitação emitida a mais de 2 anos, e assinou o termo de aceitação da vistoria técnica.

RF08 Manter condutor adicional

O sistema deve armazenar as seguintes informações sobre o condutor adicional:

nome do condutor; data de nascimento; n. carteira de habilitação; dados da reserva; id do condutor adicional.

Um condutor adicional é uma pessoa que também utilizará o veículo reservado/locação. Cada condutor adicional é identificado exclusivamente por id do condutor adicional.

Entidade ativa

RF09 Registrar check-out Deve haver uma função para registrar o check-out para um cliente. Cada check-out deve conter as seguintes informações:

dados da reserva; dados do check list.

Um registro de check-out é a devolução do veículo para a locadora. Cada check-out é exclusivamente identificada por um id do check-out. Um registro de check-out considera-se que aconteceu quando o cliente realizou a devolução do veículo na locadora e o mesmo passou por uma avaliação dos itens do check list.

Transação

RF10 Registrar pagamento de não conformidade com check list

Deve haver uma função para registrar pagamento de não conformidade com algum item do check list para um atendente. Cada cobrança de não conformidade com check list deve conter as seguintes informações:

id da cobrança; id dos itens de check list; id da locação; valor da taxa cobrado (de cada item de check

list); dados do check list.

Um registro de pagamento de não conformidade com check list é o registro de pagamento (entrada no caixa) de pagamento de taxas referente a não conformidade de um item do check list realizado no momento do check-out. Cada registro de pagamento de não conformidade com check list é exclusivamente identificada por um id da cobrança.

Transação

194

Um registro de pagamento de não conformidade com check list considera-se que aconteceu quando o cliente realizou a devolução do veículo na locadora e o mesmo não passou na avaliação de algum dos itens do check list.

RF11 Manter check list O sistema deve armazenar as seguintes informações sobre o check list:

itens do check list (por exemplo, itens de acessório, tanque cheio).

valor da taxa. Em um check list são itens verificados quando realizado um check-out. Cada check list é identificada exclusivamente por id do check list.

Entidade ativa

RF12 Manter categorias de veículos

O sistema deve armazenar as seguintes informações sobre categorias de veículos:

id da categoria; descrição da categoria.

Uma categoria de veículo é um determinado tipo de veículos. Cada categoria de veículo é identificada exclusivamente por id da categoria.

Entidade ativa

RF13 Manter grupos de veículos

O sistema deve armazenar as seguintes informações sobre grupos de veículos:

id do grupo; descrição do grupo.

Um grupo de veículo é um tipo de categoria no qual o veículo é enquadrado (por exemplo, A-econômico, C-econômico com ar, etc). Cada grupo de veículo é identificado exclusivamente por id do grupo.

Entidade ativa

RF14 Manter Veículos O sistema deve armazenar as seguintes informações sobre veículos:

id do veículo; categoria; grupo; valor diária; valor semana; valor dia extra (o valor dia é utilizado quando

um cliente opta pelo "valor semana" e estende o prazo de reserva);

modelo; qt. de portas; motorização; direção (manual ou incluído); ar condicionado (não ou incluído)

Entidade ativa

195

trio elétrico; rádio cd player; air bag freios ABS; n. de ocupantes; capacidade bagagem (qt. de malas grandes e qt.

de malas pequenas). Imagem do veículo

Um veículo é um produto de reserva/locação da locadora. Cada veículo é identificado exclusivamente por id veículo.

RF15 Relatório de resumo de reserva/locação por período

Deve haver um relatório que mostre o resumo de reservas por um determinado período ordenadas por data. O objetivo deste relatório é a exibir informações estatísticas sobre as reservas/locação. Para cada reserva/locação, o relatório deve mostrar o seguinte:

nome do cliente; descrição do grupo; modelo de veículo; valor das opções de cobertura de risco; desconto promovido; total geral da reserva/locação.


período informado. Os totais devem ser mostrados para exibir resultados agrupados e totalizados por dia, semana, mês e ano.

Relatório

Quadro 14 - Requisitos não funcionais.

Id Resumo Descrição do requisito Classificação RNF01 Formas de

pagamento Deve ser possível especificar a forma de pagamento com o objetivo de especificar os tipos de pagamentos aceitos. Este é um tipo de ativo aceito como forma de pagamento (por exemplo, dinheiro, cheque ou cartão de crédito/débito), sendo aceitos pagamentos feitos em dinheiro, cheque e cartões. Este valor só pode ser alterado apenas na

Configuração

196

inicialização do sistema. RNF02 Autenticação/Login

Cliente Um cliente deve ser capaz de autenticar-se em um processo de log in entrando com o endereço de e-mail e senha. Ele pode optar por efetuar login em qualquer momento (visitando a página de login), mas se não tiver feito, ao tentar finalizar uma reserva/locação deve-se solicitar para que o faça, sendo que o cliente não poderá prosseguir a finalização da reserva/locação sem que tenha feito isso. A identidade de cada cliente deve ser determinada antes que possam finalizar ou visualizar suas reservas/locações. Isto será conseguido por parte do cliente digitando seu endereço de e-mail e senha.


RNF03 Autenticação/Login Cliente (Recuperação de senha)

Um cliente que esqueceu sua senha deve ser capaz de recuperar-la utilizando seu endereço de e-mail cadastrado, no qual receberá uma mensagem com um código para sua autenticação. Isto deve ser obtido utilizando o seguinte processo:

3. O cliente indica via tela de log-in que esqueceu a senha e informa seu endereço de e-mail.

4. O sistema de e-mails envia a senha perdida para seu endereço de e-mail registrado.

Após a recepção da senha, o cliente pode fazer log-in.

Autenticação de usuário (requisito extra)

RNF04 Compatibilidade com os navegadores de internet

A interface do usuário deverá ser compatível com os navegadores de internet (Internet Explorer e Mozzila Firefox. Internet Explorer nas versões 8 e 9, e o navegador Mozzila Firefox na versão 4. Entende-se que estes dois navegadores são os mais utilizados pelos clientes alvos da empresa.

Tecnologia

RNF05 Tempo de resposta para as transações

Cada função de atendimento ao cliente (reserva/locação, cadastro de cliente, e etc.) deve ter um tempo de resposta não superior a 4 segundos, a partir da correta entrada de dados (quando se utiliza configuração mínima exigida pelo sistema). Este valor é baseado em indicativos de testes anedóticos que os usuários começam a perder a paciência logo após esse tempo.

Tempo de resposta

RNF06 Em conformidade com o padrão ergonomia

O sistema deve obedecer em sua totalidade do padrão de ergonomia recomenda pela ErgoList a fim de apresentar interfaces mais amigáveis aos seus usuários. Fonte: http://www.labiutil.inf.ufsc.br/ergolist.


197

RNF07 Autenticação/Login Administrador

Um administrador deve ser capaz de autenticar-se em um processo de log in entrando com o endereço de e-mail e senha. A identidade do administrador deve ser determinada antes que possa realizar qualquer função do módulo administrativo.


198

APÊNDICE H - PROJETO DA FERRAMENTA DE APOIO

Esta seção apresenta a modelagem da ferramenta de apoio à abordagem. Assim os requisitos e

diagrama de casos de uso são apresentados.

Os requisitos identificados para o projeto da ferramenta de apoio à abordagem proposta foram

especificados utilizando o formato desenvolvido pela própria abordagem proposta, os quais são

descritos na seção 1.5 (requisitos funcionais) e na seção 1.6 (requisitos não funcionais). Na Seção

1.7são apresentados os principais casos de uso do projeto da ferramenta e o protótipo de telas

correspondente a cada caso de uso.

1 REQUISITOS

As seções a seguir tratam de descrever os requisitos funcionais, não funcionais e regras de

negócio para o projeto da ferramenta de apoio da abordagem aqui proposta.

1.5 REQUISITOS FUNCIONAIS

Considerando os requisitos para implementação de uma ferramenta para apoiar a abordagem

aqui proposta, a Tabela 30 apresenta os requisitos funcionais identificados.

Tabela 30 - Requisitos funcionais.

Id Descrição do requisito Classificação RF01 O sistema deve armazenar as seguintes informações sobre o projeto:

id do projeto; nome do projeto; descrição do projeto; nome da empresa; nome do responsável pelo projeto; data de criação do projeto; projeto compartilhado - Flag para compartilhar os requisitos

destes projetos com os outros usuários; projeto finalizado; data de finalização do projeto.

Cada projeto é identificado por um identificador único, o qual não poderá ser reutilizado.

Entidade ativa

RF02 Deve haver uma consulta de projetos que retorna os projetos existentes do usuário logado no sistema e projetos marcado como compartilhado por outros usuários. Para cada projeto, a consulta deve

Consulta

199

exibir o seguinte: id do projeto; nome do projeto; data de criação; data de finalização - Mostra como “Em andamento” para

projetos “não finalizados”, e “Finalizado” para projetos finalizados;

projeto compartilhado - Mostrar como "Proprietário" para projetos em que o usuário é o autor, e "Compartilhado" para projetos de outros usuários.

Os itens a serem exibidos serão enumerados em ordem decrescente do id do projeto.

RF03 Uma pessoa deve ser capaz de se registrar como um usuário, por um formulário. Deve ser solicitado os seguintes dados pessoais:

nome; e-mail - Será utilizado como verificador para acesso (ver

requisitos RNF13); senha - que deve ser inscrita duas vezes; data de registro.


RF04 O sistema deve armazenar as seguintes informações sobre o interessado no projeto:

id do interessado; nome do interessado; descrição do papel do interessado; função; e-mail; telefone ;

Cada interessado no projeto é identificado por um identificador único, o qual não poderá ser reutilizado.

Entidade ativa

RF05 Deve haver uma função para preencher as seções do documento de ERS. Cada cadastro das seções do documento de ERS deve conter as seguintes informações:

1. propósito; 2. escopo; 3. definições, acrônimos e abreviaturas; 4. referências; 5. organização; 6. perspectiva do produto; 7. funcionalidades; 8. característica do utilizador; 9. restrições; 10. assunções e dependências.

Um cadastro das seções do documento de ERS é realizada para cada projeto.

Transação

RF06 Deve haver uma função para criar a matriz de rastreabilidade entre requisitos de sistema do tipo funcional x não funcional. Cada matriz de rastreabilidade entre requisitos deve conter as seguintes

Transação

200

informações: id da matriz de rastreabilidade; id do projeto; id requisito do RF; id requisito do RNF.

Uma matriz de rastreabilidade é realizada para cada projeto. A rastreabilidade entre requisito de usuário e requisito de sistema é feita no registro do requisito de sistema, não sendo necessário cria uma função para este tipo de matriz.

RF07 Deve haver uma consulta de padrões de requisitos que retorne os padrões de requisitos disponíveis. O seu objetivo é permitir a seleção de um padrão para a escrita de requisito. Para cada padrão de requisito, a consulta deve exibir o seguinte:

nome do padrão; objetivo do padrão; contexto; problema; forças; exemplos; categoria do padrão.

Os itens a serem exibidos serão ordenados em ordem alfabética, agrupados em suas categorias. Os itens a serem exibidos podem ser especificados por se adequar em qualquer dos seguintes critérios de seleção:

busca pelo nome; busca pela categoria; padrão de requisito relacionado.

O usuário deve ser capaz de interagir com a consulta utilizando-a para selecionar um padrão na elaboração de uma especificação de requisito de software.

Consulta

RF08 Deve haver uma função para criar o cadastro de requisito de usuário. Cada cadastro de requisito de usuário deve conter as seguintes informações:

id do projeto; id do requisito de usuário; id do interessado - Utilizado para gerar o relatório de

requisitos ordenados por usuário; texto do requisito de usuário.

Um cadastro de requisito de usuário é exclusivamente identificado por um Id do requisito de usuário, o qual não deverá ser reutilizado.

Transação

RF09 Deve haver uma função para criar o cadastro de requisitos de sistema utilizando um padrão. Cada cadastro de requisito de sistema utilizando padrão deve conter as seguintes informações:

id do requisito de usuário; id do requisito de sistema; id do usuário; tipo do requisito – (como definido no requisito RNF14);

Transação

201

id do padrão; id do Requisito - (como definido no requisito RNF01); texto resumo do requisito; texto do requisito de sistema; importância - (como definido no requisito RNF10); urgência - (como definido no requisito RNF11); versão - data da última versão.

Um cadastro de requisitos de sistema utilizando padrão é exclusivamente identificado por um Id do requisito de sistema, qual não deverá ser reutilizado.

RF10 Deve haver uma função para criar o cadastro de requisitos de sistema sem a utilização de um padrão. Cada cadastro de requisito de sistema sem a utilização de um padrão deve conter as seguintes informações:

id do requisito de usuário; id do requisito de sistema; id do usuário; tipo do requisito – (como definido no requisito RNF14); id do Requisito - (como definido no requisito RNF01); texto resumo do requisito; texto do requisito de sistema; importância - (como definido no requisito RNF10); urgência - (como definido no requisito RNF11); versão - data da última versão.

Um cadastro de requisitos de sistema sem a utilização de um padrão é exclusivamente identificado por um Id do requisito de sistema, qual não deverá ser reutilizado.

Transação

RF11 Deve haver uma consulta de requisitos de outros projetos que estejam compartilhados para reuso. O seu objetivo é permitir a seleção de requisitos para reuso em um novo projeto. Para cada requisito compartilhado, a consulta deve exibir o seguinte:

texto da especificação do requisito. Os itens a serem exibidos podem ser especificados por se adequar em qualquer dos seguintes critérios de seleção:

busca por requisitos relacionados na matriz de rastreabilidade através de requisito já reutilizado;

busca por requisito que utiliza o mesmo padrão selecionado. O usuário deve ser capaz de interagir com a consulta utilizando-a para selecionar requisitos para reuso em novo projeto.

Consulta

RF12 Um usuário deverá ser capaz de alterar sua própria senha. Deve ser solicitado a informar os seguintes dados pessoais:

id do usuário - obtido através de sua sessão iniciada; endereço de e-mail do usuário; senha antiga; nova senha, duas vezes. (O segundo momento é de proteger

contra erro na digitação, resultando em uma senha que o usuário não sabe.)


202

RF13 Deve haver um relatório que mostre as especificações de requisitos e demais seções de um documento de ERS, de um determinado projeto. Para cada projeto, o relatório deve mostrar o seguinte:

requisitos funcionais - observa-se que os requisitos funcionais devem de ser relacionados com o usuário interessado que especificou o requisito de usuário, para que se possa gerar o documento de ERS organizado por classe de usuário;

requisito de performance; requisitos de projeto; atributos do sistema de software; outros requisitos - Requisitos que não foram classificados

em nenhum dos grupos anteriores. 11. Demais seções do documento ERS: propósito, escopo,

definições, acrônimos e abreviaturas, referências; organização, perspectiva do produto, funcionalidades, característica do utilizador, restrições, assunções e dependências.


12. Id do projeto.

Relatório

1.6 REQUISITOS NÃO FUNCIONAIS

Considerando os requisitos não funcionais para implementação da de apoio a abordagem

proposta, os seguintes requisitos não funcionais foram identificados e estão listados na Tabela 31.

Tabela 31 - Requisitos não funcionais.

Id Descrição do requisito Classificação RNF01 Cada requisito de sistema deve ter um id único que está sob a forma de

um número seqüencialmente acrescido no dígito de verificação, anteriormente acrescido da tags RF para requisitos do tipo funcional e RNF para requisitos do tipo não funcional atribuído pelo requisito, iniciando em 01 para o primeiro requisito de sistema de cada novo projeto. Os ids dos requisitos funcionais serão apresentados na seguinte forma: RF0x. E os ids dos requisitos não funcionais como: RNF0x. Onde “x” é o número identificador do requisito de sistema.

Identificação

RNF02 O sistema deverá disponibilizar opção para gerar o documento de ERS em arquivos de formato RTF e PDF.

Tecnologia

RNF03 O sistema deve obedecer a seção 5 do padrão IEEE 830-1998 a fim de recomendar a estrutura do documento de especificação de requisitos gerado pelo sistema, para o documento como um todo. Fonte: http://standards.ieee.org/findstds/standard/830-1998.html


RNF04 O sistema deverá utilizar a interface de usuário baseada na web para que todas as funções funcionem plenamente como o navegador Internet

Tecnologia

203

Explorer na versão 8.0. RNF05 Deve haver uma forma de ajuda on-line para cada função do sistema que

contém uma descrição de como utilizar uma determinada função, de tal forma que um usuário com pouca experiência possa ser capaz de utilizá-la como pretender. Deve ser sob a forma de arquivos do tipo HTML.

Documentação

RNF06 O sistema deve obedecer a seção 5.3.7 do padrão IEEE 830-1998 a fim de recomendar o relacionamento dos requisitos do tipo funcionais com o usuário, para que se possa gerar o documento de ERS organizado por classe de usuário. Fonte: http://standards.ieee.org/findstds/standard/830-1998.html


RNF07 O sistema deve obedecer a seção 5.3 do padrão IEEE 830-1998 a fim de recomendar a estrutura do documento de especificação de requisitos gerado pelo sistema, para a seção 3 do documento de especificação de requisito gerado pelo sistema. Fonte: http://standards.ieee.org/findstds/standard/830-1998.html


RNF08 O sistema deve obedecer a classificação dos requisitos por tipos de acordo com a classificação proposta pela abordagem aqui proposta a fim de enquadrar os requisitos gerado pelo sistema em uma classificação por tipo de requisito. Fonte: catálogo de padrão proposto pela abordagem


RNF09 Um usuário deverá ser capaz de acessar e alterar os dados somente em seus projetos. No caso da informação designada como acesso compartilhado por outros usuários, este deve ser considerado apenas a capacidade de visualizar as informações.

Autorização específica

RNF10 O campo importância de um padrão de requisito deverá assumir os seguintes itens de informação: - essencial - condicional - opcional

Estrutura de dados

RNF11 O campo urgência de um padrão de requisito deverá assumir os seguintes itens de informação: - alta - média - baixa

Estrutura de dados

RNF12 Os campos “Definição do requisito”, que são utilizados para o cadastro de requisitos (requisitos de usuário e requisitos de sistema), devem ser do tipo texto. Deve oferecer opções de formatação de texto como: enumeração, negrito, itálico, sublinhado e etc.

Tipo de dado

RNF13 Os campos endereço de e-mail, que são utilizados para preenchimento do endereço de e-mail do usuário, devem ser do tipo texto. Deve de ser verificada na sua utilização, não é permitido o registro de mais de um usuário utilizando o mesmo endereço de e-mail. Também deve de ser verificada a sintaxe válida para um endereço de e-mail, para que não se possam cadastrar endereços de e-mails inválidos.

Tipo de dado

RNF14 O campo tipo de requisito deverá assumir os seguintes itens de informação: - funcional - não funcional

Estrutura de dados

204

RNF15 Um usuário deve ser capaz de autenticar-se informando seu endereço de e-mail e senha. A identidade de cada usuário deve ser determinada antes que eles podem dar início ou realizar transações.


RNF16 Se um usuário esquece sua senha, ele deve de ser capaz de recuperá-la utilizando seu endereço de e-mail cadastrado, no qual receberá uma mensagem com um código para sua autenticação. Isto deve ser obtido utilizando o seguinte processo:

1. O usuário indica via tela de log-in que esqueceu a senha e informa seu endereço de e-mail.

2. O sistema de e-mails envia um código de confirmação para seu endereço de e-mail registrado.

3. Após a recepção do código de confirmação, o usuário pode fazer log-in. Ele obrigatoriamente deve alterar a sua senha antes de executar qualquer função ou transação.

Autenticação de usuário (exemplo de requisito adicional)

RNF17 O usuário deve ter a possibilidade de encerrar uma sessão ativa, qualquer aplicação aberta por aquela sessão será terminada.

Autenticação de usuário (exemplo de requisito adicional)

1.7 MATRIZ DE RASTREABILIDADE

A matriz de rastreabilidade entre os requisitos funcionais e requisitos não funcionais estão

ilustrados na Tabela 32.

Tabela 32 - Matriz de rastreabilidade RF x RNF.

RN

F01

RN

F02

RN

F03

RN

F04

RN

F05

RN

F06

RN

F07

RN

F08

RN

F09

RN

F10

RN

F11

RN

F12

RN

F13

RN

F14

RN

F15

RN

F16

RN

F17

RF01 x x x RF02 x x x RF03 x x x RF04 x x x RF05 x x RF06 x x x x RF07 x x RF08 x x x x x RF09 x x x x x x x x x x RF10 x x x x x x x x x x RF11 x x x RF12 x x x x x x RF13 x x x x x x x x x

205

1.8 CASOS DE USO

Os casos de uso que representam as funcionalidades da ferramenta de apoio a abordagem

apresentada são ilustradas pela Figura 34. A descrição desses casos de uso é apresentada a seguir.

uc Caso de Uso Geral

Usuário

UC01 - Cadastrar projeto

UC02 - Cadastrar usuário

UC03 - Cadastrar requisito de usuário

UC04 - Cadastrar requisito de sistema a

partir de padrão

UC05 - Cadastrar requisito de sistema

sem usar padrão

UC06 - Criar matriz de rastreabilidade

UC07 - Cadastrar seções do documento de ERS

UC08 - Cadastrar interessado

UC09 - Gerar documento de ERS

UC10 - Consultar padrões de requisitos

UC11 - Reutilizar requisito

«extend»

Figura 34 - Casos de uso para o projeto da ferramenta de apoio a abordagem.

A seguir os casos de uso são brevemente detalhados, bem como as telas prototipadas das

principais funcionalidades são apresentadas.

UC01 – Cadastrar projeto Requisitos associados: RF01, RF02, RNF04, RNF05, RNF9 Descrição: Permite ao usuário incluir, alterar, excluir e consultar os projetos sobre

sua responsabilidade. No caso de consulta, o usuário também pode consultar projetos compartilhados por outros usuários, porém, a sua alteração e exclusão não serão permitidas.

Protótipo: N/D UC02 – Cadastrar usuário Requisitos associados: RF03, RNF04, RNF05, RNF09, RNF13, RNF15, RNF16, RNF17

206

Descrição: Permite ao usuário efetuar seu cadastro na ferramenta, devendo a efetivação da conta ocorrer após confirmação de um link enviado por email. Além disso, o usuário pode alterar os dados de seu perfil.

Protótipo: N/D UC03 – Cadastrar requisito de usuário Requisitos associados:

RF04, RF08, RNF04, RNF05, RNF12.

Descrição: Permite ao usuário incluir, alterar, excluir e consultar os requisitos de usuário sobre sua responsabilidade.

Protótipo:

UC04 – Cadastrar requisito de sistema a partir de padrão Requisitos associados: RF07, RF09, RF11, RNF01, RNF04, RNF05, RNF08, RNF10, RNF12,

RNF14 Descrição: Permite ao usuário incluir, alterar, excluir e consultar os requisitos de

sistema, utilizando-se de padrões de requisitos.

207

Protótipo:

UC05 – Cadastrar requisito de sistema sem usar padrão Requisitos associados:

RF10, RNF01, RNF04, RNF05, RNF10, RNF11, RNF12, RNF14

Descrição: Permite ao usuário incluir, alterar, excluir e consultar os requisitos de sistema, sem o apoio dos padrões de requisitos.

208

Protótipo:

UC06 – Criar matriz de rastreabilidade Requisitos associados:

RF06, RF09, RF10, RNF04, RNF05

Descrição: Permite ao usuário a criação e manutenção da matriz de rastreabilidade entre requisitos funcionais e requisitos não funcionais.

209

Protótipo:

UC07 – Cadastrar seções do documento de ERS Requisitos associados:

RF05, RNF03, RNF04

Descrição: Permite ao usuário incluir, alterar e consultar as seções do documento de especificação de requisitos.

210

Protótipo:

UC08 – Cadastrar interessado Requisitos associados: RF04, RNF04, RNF05 Descrição: Permite ao usuário incluir, alterar, excluir e consultar os interessados do

projeto.

211

Protótipo:

UC09 – Gerar documento de ERS Requisitos associados: RF13, RNF02, RNF03, RNF04, RNF05, RNF06, RNF07 Descrição: Permite ao usuário a geração do documento de especificação de requisitos

do projeto. Protótipo: N/D UC10 – Consultar padrões de requisitos Requisitos associados: RF07, RNF04, RNF05, RNF08 Descrição: Permite ao usuário consultar os padrões de requisitos. Protótipo: N/D UC11 – Reutilizar requisito Requisitos associados:

RF11, RNF04, RNF05

Descrição: Permite ao usuário a partir da consulta a requisitos de outros projetos que estejam compartilhados para reutilização, selecionar um requisito para ser reutilizado no projeto atual.

Protótipo:

Atualmente existem diversas ferramentas para apoiar e etapa de engenharia de requisitos. No entanto, pode-se afirmar que existem poucas que suportem o reuso de requisitos e, além disso, não foi encontrada nenhuma ferramenta que forneça o apoio ao reuso a partir de uma abordagem de utilização de um catálogo de padrões de requisitos, associado a rastreabilidade.

212

APÊNDICE I - PLANEJAMENTO DA AVALIAÇÃO

Este apêndice apresenta o planejamento de um estudo que será realizado para avaliação da

abordagem proposta por esta dissertação. A avaliação visa verificar se a abordagem proposta

realmente torna mais eficiente e eficaz a atividade de elicitação de requisitos, com relação à

execução desta atividade sem o apoio da abordagem. O planejamento do estudo foi realizado

utilizando o framework elaborado por Kochanski (2009). A Tabela 33 apresenta uma instância

adaptada do framework que delineia o planejamento realizado para a execução do experimento.

Tabela 33 - Planejamento do experimento.

I – Definição do Experimento Estratégia de pesquisa: Justificativa [X] Quantitativa A estratégia de pesquisa quantitativa será utilizada para

obtenção de evidência para as hipóteses de pesquisa. Forma de realização Justificativa [X] in-vitro O estudo será realizado in-vitro, por haver disponível grupos

de estudantes os quais representam a população de interesse, além de ser realizado em laboratório de uma Universidade

Abordagem de pesquisa: Justificativa [X] Descritiva A abordagem de pesquisa utilizada será a descritiva pelo fato

do objetivo do estudo estar focado na descrição dos efeitos de um fenômeno dado uma intervenção propositalmente realizada.

Estratégia para seleção do grupo experimental e grupo de controle:

Os participantes do experimento serão acadêmicos da disciplina de Engenharia de Software, do curso de graduação em Ciências da Computação. Serão aplicados 2 estudos de caso na avaliação, assim, para cada estudo de caso serão necessários 2 grupos para o seus desenvolvimento, 1 grupo que fará uso da abordagem e um outro que não à utilizará. Será necessário a divisão do grupo total de participantes em no mínimo 4 grupos. Prefere-se grupos de no máximo 3 participantes para a execução da atividade, acredita-se que grupos com número maior de participantes pode introduzir efeitos de dispersão da atenção na condução das atividades nos grupos. A divisão dos grupos será feita de forma aleatória, utilizando uma lista numerada com o nome de todos os participantes (0). Os nomes correspondentes a numeração na seqüência ímpar farão parte do grupo experimental e os nomes correspondentes a numeração na seqüência par farão

213

parte do grupo de controle. No momento do experimento os grupos serão nomeados, por exemplo: grupo A (experimental), grupo B (controle). Prefere-se que os grupos realizem a avaliação em salas separadas, sem comunicação, com o objetivo de evitar influência entre os grupos. O grupo experimental deverá receber treinamento para utilização da ferramenta.

Questionários/termos: Conteúdo: [X] Concordância O conteúdo do termo de concordância encontra-se no

Apêndice J. [X] Perfil do participante O conteúdo do questionário sobre o perfil dos participantes

encontra-se no Apêndice K. Pré-condições para realização do experimento: Para participar do experimento os acadêmicos devem estar cursando no mínimo o quinto semestre de um curso na área de Computação/Informática.

II - Planejamento

Seleção do contexto O estudo deverá ser realizado após o término das aulas que abordem o assunto de engenharia de requisitos na disciplina de engenharia de software. O estudo deverá ocorrer em laboratório de Informática para que ambos os grupos de participantes possam utilizar a ferramenta de apoio à abordagem. Porém, somente o grupo experimental terá acesso a todas as funcionalidades da ferramenta, o grupo de controle irá utilizar uma versão limitada da ferramenta. As funções disponíveis para o grupo de controle serão: cadastro do projeto, cadastro dos requisitos do usuário, cadastro dos interessados e cadastros de requisitos de sistemas (este sem as opções de uso de padrões e sugestões de reuso). Hipóteses: Descrição H01 Não existe diferença quanto à eficiência do processo de

elicitação quando utilizada a abordagem de reuso em relação ao seu não uso.

HA1 A eficiência do processo de elicitação utilizando abordagem baseada em reuso é maior que quando não utilizada esta abordagem.

H02 Não existe diferença quanto à eficácia do processo de elicitação quando utilizada a abordagem de reuso em relação ao seu não uso.

HA2 A eficácia do processo de elicitação utilizando abordagem baseada em reuso é maior que quando não utilizada esta abordagem.

Variáveis de controle: Detalhamento Variável 1 Tempo de execução da atividade de especificação de

requisitos. Variável 2 Quantidade de requisitos especificados considerados corretos. Variável 3 Quantidade total de requisitos especificados existentes

214

(conhecidos), descrito no modelo de correção.

Seleção dos participantes Os participantes serão selecionados aleatoriamente entre os alunos que estejam cursando a disciplina de Engenharia de Software ministrada no primeiro semestre de 2011. O total de alunos será divido de forma equânime para compor grupos de ordem par, metade dos grupos para a experimentação e a outra metade para o grupo de controle. Design de experimento utilizando: Detalhamento R X1 O R X2 O

Para o experimento serão utilizados 2 tratamentos diferentes (com o apoio dos mecanismos de reuso e sem as opções de reuso), onde O é a avaliação do documento produzido, e R representa a seleção aleatória.

Legenda: X = representa um tratamento O = representa um teste/avaliação R = representa a seleção aleatória dos participantes

Planejamento da instrumentalização Tratamento a ser realizado: Antes da aplicação do experimento, os participantes deverão

ter participado das aulas e atividades referentes a engenharia de requisitos ministradas nas aulas de engenharia de software. Acredita-se que depois de ministrado todo o conteúdo sobre engenharia de requisito, seja o momento mais oportuno para aplicação do experimento. O experimento será divido em duas etapas. Na primeira etapa, todos os participantes receberão aulas sobre padrões de requisitos para escrita de requisitos. Esta aula aplicada em uma primeira oportunidade, e revisada em uma segunda oportunidade. Em seguida, todos os participantes realizarão o preenchimento do termo de concordância e o questionário sobre o perfil do participante, assim, terminando a primeira etapa. Na segunda etapa, será aplicado o experimento com os grupos em ambientes separados. Serão desenvolvidos dois projetos provenientes dos estudos de caso com os grupos. Com o grupo experimental todas as funcionalidades da ferramenta de apoio estarão disponíveis, já os participantes do grupo de controle, a ferramenta não disponibilizará suporte a sugestões de reuso de requisitos, nem sugestões de padrões relacionados, e formulário baseado em template para escrita dos requisitos.

Objetos/equipamentos: Os materiais necessários serão: Questionários; Ferramenta de apoio a abordagem; Microcomputadores; Estudos de caso

Diretrizes: Os experimentos serão aplicados na cidade de Itajaí-SC, na

215

mesma ocasião serão preenchidos os termos de concordância e questionário de perfil. Após esse momento, os grupos serão divididos e separados em salas diferentes para cada tipo de grupo.

Instrumentos de medição: Como instrumento de medição será utilizados as medições quanto a eficiência e eficácia:

Eficiência: é razão entre o número de requisitos corretamente descritos e o tempo gasto na execução na atividade de elicitação de requisitos.

Eficácia: é medida como a relação entre o número de requisitos corretamente descritos e o número total de requisitos existentes.

Para tanto, será utilizado um documento de especificação de requisitos aprovado por especialista, como modelo de correção dos estudos de caso.

Avaliação da validade

Validade de conclusão: Nenhuma ameaça foi identificada para este tipo de validade, isso porque os dados coletados serão armazenados pela própria ferramenta de apoio.

Validades internas: Ameaça 1 Os participantes não estarem interessados pelo estudo realizado, e não colaborarem com uma efetiva participação. Ação: motivar os participantes na realização das atividades do experimento.

Ameaça 2 O fato de a abordagem envolver certo grau de dificuldade na utilização/seleção dos padrões de requisitos pode gerar fadiga nos participantes pelo esforço empregado, diminuindo o empenho e comprometimento dos mesmos. Ação: ministrar uma aula sobre padrões de requisitos, e motivar os participantes na realização do experimento. Para ajudar a manter a motivação e comprometimento, a professora da disciplina avaliará a participação dos grupos com o emprego de nota pela execução da atividade.

Validades de construção: Ameaça 1 Desigualdade na seleção dos grupos de participantes do ponto de vista de utilização da ferramenta de apoio. Ação: ministrar uma aula explicando como utilizar a ferramenta.

Ameaça 2 Desigualdade no nível de experiência entre os participantes do grupo experimental e do grupo de controle. Ação: avaliar os grupos através do questionário de perfil dos participantes.

216

Validades externas: Ameaça 1 Participantes de determinado grupo terem conhecimento prévios. Ação: avaliar participantes através do questionário de perfil dos participantes.

III - Operação Informações: Os participantes serão informados previamente sobre a

aplicação do estudo. Materiais: Os materiais utilizados serão:

Termo de concordância; Relação de participantes; Questionário de perfil; Estudo de caso 1: loja virtual; Estudo de caso 2: ambiente virtual de aprendizagem; Ferramenta de apoio a abordagem;

Comprometimento: Informação sobre o interesse e comprometimento dos participantes será obtida no questionário de perfil.

Coleta dos dados: Os dados do estudo serão coletados através dos dados armazenados pela ferramenta de apoio. A análise destes dados será repassada para uma planilha de eletrônica que realizará os cálculos necessários.

Ambiente: O estudo está previsto para ser realizado nas dependências da UNIVALI, campus Itajaí-SC.

Validade: O entendimento dos participantes será validado através de correção com o confronto do modelo de correção dos estudos de casos. Este modelo validado previamente com especialista.

Conformidade: O pesquisador acompanhará a realização de todas as atividades, com o intuito de garantir que o estudo seja realizado em conformidade com o planejado.

217

APÊNDICE J - TERMO DE CONCORDÂNCIA

TERMO DE CONSENTIMENTO LIVRE E ESCLARECIDO

Você está sendo convidado para participar da pesquisa AVALIAÇÃO DE UMA NOVA

ABORDAGEM PARA O REUSO DE REQUISITOS.

Você foi selecionado por estar matriculado na disciplina de Engenharia de Software e sua

participação não é obrigatória. A qualquer momento você pode desistir de participar e retirar o seu

consentimento. Sua recusa não trará nenhum prejuízo em sua relação com o pesquisador ou com a

instituição. Os objetivos deste estudo são avaliar uma nova abordagem para reuso de requisitos

quanto a sua eficiência e eficácia em comparação a outra abordagem.

Sua participação nesta pesquisa consistirá em assistir uma aula sobre padrões de requisitos

para escrita de requisitos de software, responder aos questionários e desenvolver um projeto guiado

por um estudo de caso.

Os riscos relacionados com sua participação são nenhum.

Os benefícios relacionados com a sua participação são aprendizagem de conceitos sobre

padrões de requisitos de software e sobre desenvolvimento de documentos de especificação de

requisitos de software.

As informações obtidas através dessa pesquisa serão confidenciais e asseguramos o sigilo

sobre sua participação. Os dados não serão divulgados de forma a possibilitar sua identificação.

Declaro que entendi os objetivos, riscos e benefícios da minha participação na pesquisa e concordo

em participar.

________________________________

Nome do participante:

________________________________

Rodrigo Cezario da Silva – Pesquisador

218

APÊNDICE K - QUESTIONÁRIO DO PERFIL DOS PARTICIPANTES

Questionário de Perfil do Participante Nome: ________________________________________________________________ Disciplina: _____________________________________________________________ Universidade: ___________________________________________________________ Prezado acadêmico, em relação ao seu perfil, responda as seguintes perguntas: 1) Você é acadêmico do curso de: [ ] B.Sc. em Ciências da Computação. [ ] B.Sc. em Engenharia da Computação. [ ] B.Sc. em Sistema de Informação. [ ] B.Sc. em outro curso na área de Computação. Qual?:__________________________. [ ] B.Sc. em outro curso. Qual?:_____________________________________________. [ ] Tecnólogo em outro curso. Qual?:_________________________________________. 2) Você já é graduado em outro curso? [ ] Não. [ ] Sim. Qual curso?:_____________________________________________________. 3) Você trabalha na área de Computação/Informática? [ ] Não. [ ] Sim. Em que em quanto tempo? [ ] com Técnico de suporte ao usuário. Por _____anos. [ ] com Técnico de manutenção de hardware. Por _____ anos. [ ] como Técnico de manutenção de software. Por _____ anos.

[ ] como Programador. Por _____ anos. [ ] como Projetista. Por _____ anos. [ ] como Analista. Por _____ anos. [ ] como Arquiteto. Por _____ anos. [ ] como Testador. Por _____ anos. [ ] como Gerente de projetos. Por _____ anos. [ ] como Consultor. Por _____ anos. [ ] como Instrutor de treinamentos. Por _____ anos. [ ] Outros. Qual?: ___________________________________. Por _____ anos.

4) Qual o seu conhecimento atual em engenharia de requisitos? [ ] Nenhum. [ ] Tenho pouco conhecimento do assunto. [ ] Conheço o básico. [ ] Aplico na prática como dependência de outros. [ ] Aplico na prática sem dependência de outros.

219

[ ] Tenho bastante conhecimento do assunto. [ ] Sei tudo sobre o assunto. 5) Como você considera a área de engenharia de requisitos? [ ] Nada importante. [ ] Pouco importante. [ ] Importante. [ ] Muito importante. 6) Você tem interesse em aprender sobre engenharia de requisitos? [ ] Nada interessado. [ ] Pouco interessado. [ ] Interessado. [ ] Muito interessado.

220

APÊNDICE L - QUESTIONÁRIO DE PERCEPÇÃO (GRUPO EXPERIMENTAL)

Questionário de Percepção Nome: ________________________________________________________________

Concordo totalmente


Indiferente Não concordo parcialmente



A ferramenta foi fácil de utilizar. O reuso de requisitos contribuiu significativamente na elicitação (identificação) dos requisitos.


Utilizaria a ferramenta na minha prática profissional.

Considero como aspectos positivos da atividade (ferramenta, padrões, reuso, etc.) realizada: ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Considero como aspectos a serem melhorados na atividade (ferramenta, padrões, reuso, etc.) realizada: ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Descreva sua impressão sobre as opções de sugestão de reuso (Auxiliaram a encontrar mais requisitos? Como ajudaram na atividade? Tem alguma sugestão para melhorar esta funcionalidade?): ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

221

APÊNDICE M - QUESTIONÁRIO DE PERCEPÇÃO (GRUPO DE CONTROLE)

Questionário de Percepção Nome: ________________________________________________________________

Concordo totalmente


Indiferente Não concordo parcialmente



A ferramenta foi fácil de utilizar. O uso dos padrões auxiliou na escrita dos requisitos.

Utilizaria a ferramenta na minha prática profissional.

Considero como aspectos positivos da atividade (ferramenta, padrões, etc.) realizada: ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Considero como aspectos a serem melhorados na atividade (ferramenta, padrões, etc.) realizada: ________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

222

APÊNDICE N - RELAÇÃO DE PARTICIPANTES

Relação de Participantes do Estudo “Avaliação de uma nova abordagem para o reuso de requisitos”

Disciplina: _____________________________________________________________ Universidade: ___________________________________________________________ Data: _____________ Nome Grupo Aula Tratamento

223

APÊNDICE O - QUESTIONÁRIO PARA AVALIAÇÃO COM ESPECIALISTAS

Questionário de avaliação de uma abordagem de apoio ao reuso de requisitos

Avaliador:

Objetivo:

Avaliar uma abordagem de reuso de requisitos em relação à eficiência e eficácia sob o ponto de vista de especialistas experientes em engenharia de requisitos no contexto de especificação e documentação de requisitos de software.

Esta pesquisa está colaborando com resultados de uma avaliação qualitativa de uma abordagem proposta em uma dissertação de mestrado “Avaliação empírica de uma nova abordagem proposta para o reuso de requisitos”, do Mestrado em Computação Aplicada da UNIVALI.

Instruções:

O questionário apresenta questões com respostas fechadas, no entanto, é oportunizado complemento das respostas com a descrição das dificuldades encontradas e/ou benefícios proporcionados.

Perfil do avaliador:

As questões apresentadas nesta seção estão fora do escopo da avaliação da abordagem, tendo como objetivo identificar o perfil do avaliador.

Qual a sua formação acadêmica?

Ciências da Computação Sistema de Informação Outra:_________________________

Você tem pós-graduação em Engenharia de Software ou afim?

Sim Não Qual?_______________________________________

Você tem experiência na elaboração do documento de especificação de requisitos?

Sim Não Quanto tempo?_______________________________

Questões:

Q1. Qual a sua impressão subjetiva sobre o percentual de agilidade (ganho de tempo) que a atividade de elicitação e documentação de requisitos obtêm quando da utilização da abordagem, comparado com a não utilização desta?

Nenhum 1% - 25% 26% - 50% 51% - 75% 76% - 100%

224

Q2. Em relação ao artefato de software “Documento de especificação de requisitos” produzido com a abordagem:

a) Entendendo por artefato mais completo como a quantidade de requisitos corretamente identificados, qual a sua impressão subjetiva sobre o percentual de melhoria da abordagem em relação à completude?

Nenhum 1% - 25% 26% - 50% 51% - 75% 76% - 100%

b) Entendendo por artefato mais correto como a quantidade de requisitos corretamente descritos, qual a sua impressão subjetiva sobre o percentual de melhoria da abordagem em relação à corretude?

Nenhum 1% - 25% 26% - 50% 51% - 75% 76% - 100%

c) Analisando o artefato produzido, relacione os itens não atendidos na sua elaboração.

Q3. Em relação a utilização dos padrões/catálogo de requisitos:

a) Qual a sua impressão subjetiva sobre o percentual de ajuda na escrita dos requisitos quando considerado o emprego dos padrões adotados pela abordagem?

Nenhum 1% - 25% 26% - 50% 51% - 75% 76% - 100%

b) Você considera que foi fácil localizar um padrão adequado no catálogo disponibilizado?

Concordo totalmente Concordo parcialmente Não concordo

c) Retrate aqui (caso existam) as dificuldades encontradas com a utilização dos padrões.

Q4. Em relação às sugestões de reuso:

a) Você concorda que as sugestões associadas aos padrões foram adequadas?


b) Você concorda que as sugestões associadas à rastreabilidade foram adequadas?


c) Retrate aqui (caso existam) as dificuldades encontradas com as sugestões de reuso.

225

Q5. Em relação a ferramenta de apoio:

a) A ferramenta de apoio proporcionou algum benefício na execução da atividade de elicitação e documentação de requisitos?


b) Em que percentual?

Nenhum 1% - 25% 26% - 50% 51% - 75% 76% - 100%

c) Retrate aqui (caso existam) as dificuldades encontradas com o uso da ferramenta.

226

ANEXO A - TRADUÇÃO DOS PADRÕES DE WHITALL (2007)

Modelos dos padrões.

Padrões de requisitos fundamentais Quadro 15 - Padrão de interface entre sistemas.

Resumo Definição <<nome da interface>> interface (<<identificador da interface>>)

Deverá haver uma interface bem definida (chamada <<identificador da interface>>) entre <<componente 1>> e <<componente 2>>. Objetivos: <<objetivo da interface 1>> ... Interações através desta interface podem ser iniciadas por <<componentes iniciados>>. Esta definição de interface é de responsabilidade e propriedade de <<organização proprietária da interface>>. (Esta interface deve estar em conformidade com a versão <<versão do padrão>> do <<nome do padrão>>, cuja definição pode ser encontrada em <<local do padrão>>) (<<declaração da tecnologia>>)

Quadro 16 - Padrão de interação entre sistemas.

Resumo Definição <<resumo da interação>> A interface <<nome da interface>>

(<<identificador da interface>>) é <<descrição do objetivo da interação>> (que passa, no mínimo, as seguintes informações: <<informações para passar>>).

Quadro 17 - Padrão de tecnologia.

Resumo Definição <<resumo da tecnologia>> <<descrição da tecnologia>> deverá ser

utilizada para <<uso da tecnologia>>. (<<declaração da versão da tecnologia>>) (<<declaração da motivação>>)

<<resumo da tecnologia>> O sistema deverá utilizar a <<descrição da tecnologia>> para <<uso da tecnologia>>. (<<declaração da versão da tecnologia>>)

227

(<<declaração da motivação>>)

Quadro 18 - Padrão de aderência ao padrão (do inglês comply-with-standard).

Resumo Definição Em conformidade com o padrão <<nome do padrão>>

O sistema deve obedecer (partes <<lista de partes do padrão>>) do padrão <<descrição do padrão>> (a fim de <<objetivo do padrão>>). <<declaração da versão do padrão>>. Fonte: <<localização do padrão>>.

Quadro 19 - Padrão de referência a requisitos (do inglês refer-to-requirements).

Resumo Definição Requisito aplicado <<descrição do domínio>> O sistema deve satisfazer <<requisitos que se

aplicam>> especificados em <<versão da especificação>> para o <<nome da especificação>>, que reside no <<local da especificação>>. <<declaração de prioridade>>.

Quadro 20 - Padrão de documentação.

Resumo Definição <<nome do tipo do documento>> Deve haver um <<nome do tipo de

documento>> que contém <<descrição do documento>>. (Deve ser sob a forma de <<formato do documento ou intermédio>>) (Deve ser escrito <<nome da linguagem>> linguagem)

Padrões de requisitos para informação Quadro 21 - Padrão de tipo de dados.

Resumo Definição Tipo de dados <<nome do tipo de dado>> <<nome do tipo de dado>>, que são utilizados

para <<efeito do tipo de dados>>, deve ser do tipo <<formato do tipo de dado>>. (<<declaração do formato de exibição>>) (<<declaração das restrições>>) (<<declaração dos tratamentos especiais>>)

Quadro 22 - Padrão de estrutura de dados.

Resumo Definição <<nome da estrutura de dados >> <<descrição do tipo de dado>> inclui os

seguintes itens de informação:

228

<<descrição do item de dado 1>> ...

Quadro 23 - Padrão de identificação.

Resumo Definição <<nome do proprietário da entidade >> Cada <<nome do proprietário da entidade>>

deve ter um ID (identificador) único que está sob a forma de <<forma do identificador>> atribuído pelo <<como atribuiu>>. (<<formato para exibição>>) (Cada <<nome do identificador>> deve de ser único <<escopo de singularidade>>) (<<declaração da ordem de classificação>>) (<<declaração das condições de reuso>>)

Quadro 24 - Padrão de fórmula de cálculo.

Resumo Definição Cálculo do <<nome do valor >> <<descrição do valor>> deve ser calculado da

seguinte forma: <<nome do valor>> = <<fórmula>> Onde <<nome da variável 1>> é <<descrição da variável 1>> <<nome da variável 2>> é <<descrição da variável 2>>> ... (<<refinamento do cálculo>>) (<<limitações de aplicabilidade>>) (<<referência>>) (Por exemplo, <<exemplo>>)

Determinação do <<nome do valor>> <<descrição do valor>> deve ser determinado da seguinte forma:

1. <<descrição do passo 1>> 2. <<descrição do passo 2>> 3. ...

(<<limitações de aplicabilidade>>) (<<referência>>) (Por exemplo, <<exemplo>>)

Quadro 25 - Padrão de longevidade de dados.

Resumo Definição Armazenar <<descrição do dado >> <<forma de armazenamento>> por <<duração>>

<<descrição do dado>> deve ser armazenado <<forma de armazenamento>> para <<duração

229

da retenção>> de <<gatilho do início da retenção>>. (Quando os dados são ilegíveis para remoção, <<ação junto ao prazo determinado >>)

Quadro 26 - Padrão de arquivamento de dados.

Resumo Definição Arquivamento de <<resumo do dado >> <<descrição do dado>> deve ser (movido) /

(copiado) de <<origem do dado>> para <<destino do dado>> <<freqüência>>. <<descrição do gatilho iniciador>> (O objetivo deste é para <<objetivo do arquivamento >>)

Padrões de requisitos para entidade de dados Quadro 27 - Padrão de entidade ativa.

Resumo Definição <<nome da entidade ativa>> O sistema deve armazenar as seguintes

informações sobre o <<nome da entidade ativa>>:

<<descrição do item de dado 1 >>. …

Um <<nome da entidade>> é <<explicação sobre a entidade>>. Cada <<nome da entidade>> é identificada exclusivamente por <<entidade(s) identificador>> (<<detalhe das entidades geradas>>).

Quadro 28 - Padrão de transação.

Resumo Definição <<nome da transação>> Deve haver uma função para criar uma <<nome

da transação>> transação para um <<proprietário da entidade da ativa>>. Cada <<nome da transação>> deve conter as seguintes informações:

<<descrição do item de dado 1 >>. …

Um <<nome da transação>> é <<explicação da transação>>. Cada <<nome da transação>> é exclusivamente identificada por um <<identificador(es) da transação>>. Um <<nome da transação>> considera-se que aconteceu <<descrição do tempo em que ocorre a transação >> (<<declaração da longevidade da transação>>).

230

Quadro 29 - Padrão de configuração.

Resumo Definição <<nome do valor de configuração>> Deve de ser possível especificar <<nome do

valor de configuração>> com o objetivo de <<efeito do valor>>. Este é um <<descrição do tipo de dados>> (por exemplo, <<o valor representante>>) e é <<descrição do nível de configuração>>. (Este valor só pode ser alterado apenas <<descrição da alteração do tempo>>)

<<nome da entidade de configuração>> O sistema deverá armazenar as seguintes informações sobre uma <<nome da entidade de configuração>> com o objetivo de <<objetivo da entidade>>:

<<descrição do valor de configuração 1 >>.

… Cada <<nome da entidade de configuração>> é unicamente identificada pelo <<entidade identificador>>. (Essa entidade só pode ser alterada << descrição da alteração do tempo >>)

Quadro 30 - Padrão cronologia.

Resumo Definição Registro <<resumo do tipo de ocorrência>> Cada <<descrição do(s) tipo(s) de ocorrência>>

serão automaticamente gravadas. Para cada uma, serão registrados os seguintes dados:

<<detalhe da ocorrência 1 >>. <<detalhe da ocorrência 2 >>. …

(Todos os eventos devem ser tratados como tendo uma gravidade de <<descrição da gravidade>>)

Padrões de requisitos para funções de usuário Quadro 31 - Padrão de consulta.

Resumo Definição Consulta <<nome da consulta>> Deve haver uma consulta <<nome da

consulta>> que retorne <<informações exibidas>>. O seu objetivo é <<intenção de negócio>>. Para cada <<nome da entidade>>, a consulta deve exibir o seguinte:

<< item de informação 1 >>. <<item de informação 2>>

231

… (Os itens a serem exibidos serão ordenados em <<detalhes sobre a sequência de classificação>>) (Os itens a serem exibidos podem ser especificados por se adequar em qualquer dos seguintes critérios de seleção:

<<critério de seleção 1>> <<critério de seleção 2>> ...)

(O usuário deve ser capaz de navegar <<detalhes de navegação do usuário>>) (O usuário deve ser capaz de interagir com a consulta <<detalhes da interação do usuário>>) (As informações apresentadas são atualizadas automaticamente <<detalhes da atualização automática>>)

Quadro 32 - Padrão de relatório.

Resumo Definição Relatório <<nome do relatório>> Deve haver um relatório que mostre

<<informações a serem exibidas>> <<critério de seleção>> ordenadas por <<sequência de ordenação>>. O objetivo deste relatório é a <<intenção do negócio>>. Para cada <<nome do tipo de item>>, o relatório deve mostrar o seguinte:

<<nome do valor 1 >>. <<nome do valor 2 >>. …

(Os itens a serem exibidos podem ser especificados por enquadrar em qualquer dos seguintes critérios de seleção:

<<critério de seleção 1 >>. <<critério de seleção 2 >>. …)

Os totais devem ser mostrados para <<níveis de totalização>>. (Uma nova página deve ser iniciada por <<níveis de páginas>>) (O relatório destina-se a ser executado automaticamente <<detalhe da execução automática>>)

Quadro 33 - Padrão de acessibilidade.

Resumo Definição Acessíveis a pessoas com determinada Um <<parte do sistema>> deve ser acessível a

232

necessidade de <<nome específico da necessidade>>

pessoas com determinada necessidade de <<descrição da necessidade específica>> (na medida em que <<extensão do apoio>>). (Estima-se que <<percentagem afetada>>% dos usuários são susceptíveis para o benefício.) (Isso se refere à <<cláusula na lei>>)

Padrões de requisitos para performace Quadro 34 - Padrão de tempo de resposta.

Resumo Definição Tempo de resposta <<tipo da operação>> Cada <<tipo de operação>> deve ter um tempo

de resposta não superior a <<tempo tolerável de duração>> do <<tempo de limite inicial>> a <<tempo de limite final>> (quando se utiliza <<configuração indicativa de hardware >>). Este valor é baseado em <<justificativa>>. (Este requisito não se aplica aos <<casos excepcionais>>) (<<advertência de carga elevada>>) (A motivação para este requisito é <<motivação>>)

Quadro 35 - Padrão de rendimento (do inglês throughput).

Resumo Definição Razão <<tipo de rendimento>> <<parte do sistema>> deve ser capaz de lidar

com <<tipo de objeto de rendimento>> transações a um razão de pelo menos <<quantidade de rendimento>> por <<unidade de período de tempo>> (quando se utilizado << configuração indicativa de hardware >>). (<<declaração do cumprimento do prazo>>) (<<declaração de contingência>>) (<<declaração de justificativa>>)

Quadro 36 - Padrão de capacidade dinâmica.

Resumo Definição Capacidade simultâneo do <<tipo de entidade>> O sistema deverá satisfazer <<quantidade da

entidade>> <<tipo da entidade>> simultâneos <<declaração da condição da entidade>> (<<declaração da duração do pico>>).

233

(<<declaração do tempo de execução>>) (<<declaração do período de pico da concessão>>)

Quadro 37 - Padrão de capacidade estática.

Resumo Definição Capacidade total do <<tipo de entidade>> O sistema deve ser capaz de lidar com um

mínimo de <<quantidade da entidade>> <<tipo da entidade>>. <<critério de inclusão da entidade>> . (<<declaração do tempo de execução>>)

Quadro 38 - Padrão de disponibilidade.

Resumo Definição Disponibilidade <<extensão>> O sistema deve estar normalmente disponível

para os usuários <<declaração da extensão de disponibilidade>> (exceto em circunstâncias excepcionais de freqüência e duração não superior a <<qualificador para tolerância de indisponibilidade>>. “Normalmente disponível” deve de ser entendido como <<significado para disponibilidade>>.

Padrões de requisitos para flexibilidade Quadro 39 - Padrão de escalabilidade.

Resumo Definição Escalabilidade <<aspectos da escalabilidade>> O sistema deve ser escalável para acomodar um

número ilimitado de <<tipo de item a ser escalável>>. <<indicativo de alto volume de negócios>>. (<<facilidade de comunicação de expansão >>) (<<declaração de motivação>>)

Quadro 40 - Padrão de extensabilidade.

Resumo Definição Extensabilidade <<aspectos do sistema>> Deve ser possível expandir o <<aspecto do

sistema>>, através do desenvolvimento e “ligação com” um módulo de software extra. A introdução de qualquer módulo não deve exigir mudanças fundamentais para o software central, para permitir a sua introdução. <<facilidade de extensabilidade>>.

234

(<<detalhe da configuração>>) Ligação com <<tipo de subcomponente>> Deve ser possível adicionar um novo <<tipo de

subcomponente>> através do desenvolvimento e “ligação com” o software necessário para apoiá-lo. Um novo <<tipo de subcomponente>> não deve exigir mudanças fundamentais para o sistema central do software para permitir a sua introdução. <<facilidade de extensabilidade>>. (<<detalhe da configuração>>)

Quadro 41 - Padrão de ilimitado (do inglês unparochialness).

Resumo Definição Não é especificado um <<único nome do ambiente>>

O sistema deve ser adequado para o uso por qualquer organização que <<condições adequadas>>. (<<declaração de motivação>>) Por exemplo, a <<declaração dos aspectos de variação>>.

Quadro 42 - Padrão de múltiplos. (do inglês multiness)

Resumo Definição Multi- << nome do múltiplo>> O sistema deverá suportar múltiplo <<descrição

do tipo de múltiplos>>. <<declaração de extensão>>. (<<declaração do número de casos>>) (<<declaração das limitações>>)

Provisão para multi- << nome do múltiplo>> (no futuro)

O sistema deverá prever a futura introdução de suporte para múltiplos << descrição do tipo de múltiplos >>. <<declaração de extensão>>. (<<declaração das limitações>>)

Quadro 43 - Padrão de multi-linguagem.

Resumo Definição Multi-lingual (<<qualificador de escopo>>) O sistema deverá suportar vários idiomas.

<<declaração de extensão>>. (<<declaração do número de casos>>) (<<declarações de limitações>>)

Provisão (para <<qualificador de escopo>>) para se tornar multi-lingual

O sistema deverá prever a futura introdução de suporte para vários idiomas. <<declaração de extensão>>.

235

(<<declarações de limitações>>)

Quadro 44 - Padrão de instalabilidade.

Resumo Definição Instalabilidade do <<parte do sistema>> Deve ser possível para o <<parte do sistema>>

para ser instalado por uma <<pessoa que irá instalar>>. <<declaração para uma fácil instalação>>. (<<declaração de instalação por intermédio>>)

Padrões de requisitos para controle de acesso Quadro 45 - Padrão de registro de usuário.

Resumo Definição Auto-registro <<classe usuário>> Uma pessoa deve ser capaz de se registrar como

um <<classe usuário>>, por <<descrição do processo de registro>>. Deve ser solicitado a informar os seguintes dados pessoais:

<<detalhe do usuário 1>> <<detalhe do usuário 2>> ...

Registro de <<classe usuário>> Será possível registrar uma pessoa como um <<classe usuário>>, por <<descrição do processo de registro>>. As seguintes informações devem ser inscritas sobre eles:

<<detalhe do usuário 1>> <<detalhe do usuário 2>> ...

Quadro 46 - Padrão de autenticação de usuário.

Resumo Definição Autenticação/Login <<classe usuário>> Um <<classe usuário>> deve ser capaz de

autenticar-se (log in) em <<passos de autenticação>>.

Quadro 47 - Padrão de autorização específica.

Resumo Definição Acesso <<resumo dos privilégios>> <<descrição dos privilégios>> deverá (não)

estar acessível <<descrição da regra de acesso>>.

Acesso <<resumo dos privilégios>> Um <<tipo de usuário>> deverá (não) ser capaz de <<descrição do privilégio>>.

Quadro 48 - Padrão de autorização configurável.

Resumo Definição Acesso de <<classe usuário>> para <<natureza Um <<classe usuário>> deve ser capaz de

236

do acesso>> acessar apenas <<descrição da natureza de acesso>> aos quais tenha sido concedida autorização (por força das funções atribuídas a eles). A motivação para este requisito é <<declaração de motivação>>

Quadro 49 - Padrão de aprovação.

Resumo Definição Aprovação de <<nome da ação >> Um <<descrição da ação>> deve

<<circunstâncias para aprovação>> ser aprovado por <<descrição do aprovador>>. (<<declaração de prontidão da aprovação>>) (<<declaração do mecanismo de aprovação>>) (Se a aprovação for negada <<descrição da ação de rejeição>>)

Padrões de requisitos comerciais Quadro 50 - Padrão de multi-organizacional.

Resumo Definição Multi- <<nome do tipo de unidade>> O sistema deverá suportar múltiplo <<nome do

tipo de unidade>> (por <<nome do tipo de unidade pai>>). (Para os fins desta especificação, um <<nome do tipo de unidade>> é <<definição do tipo de unidade>>) (<<declaração das características>>) (<<declaração do número de casos>>)

Estrutura da organização <<resumo da estrutura>>

Deve ser possível definir uma estrutura organizacional <<descrição da estrutura>>. (<<declaração das características>>)

Quadro 51 - Padrão de taxas.

Resumo Definição Taxa/Imposto de <<nome da taxa/imposto >> O sistema deve calcular uma taxa de << nome

da taxa/imposto >> com base <<base>> sobre <<origem>> desde que <<condição>>. É pago por <<pagador>> ao <<receptor>> <<quando cobrado>>. A taxa deve ser determinada por <<razão para determinação da taxa/imposto>> O sistema é responsável pela <<responsabilidade do sistema>>. Fonte: <<referencia>>.

237

ANEXO B - FICHA DE CADASTRO DE LIVROS (ESTUDO DE CASO 1)

238

ANEXO C - TABELA FORNECIDA PELOS CORREIOS PARA O CÁLCULO DO FRETE (ESTUDO DE CASO 1)

239

ANEXO D - DADOS DA TRANSAÇÃO RETORNADOS PELA OPERADORA DE CARTÃO DE CRÉDITO (ESTUDO DE CASO 1 E 2)

240

ANEXO E - FOLDER (ESTUDO DE CASO 2)

241

ANEXO F - TABELA DE CONTRATO DE COBERTURA DE RISCO (ESTUDO DE CASO 2)

Cobertura exclusiva para o carro alugado, incluindo acessórios, em caso de furto, roubo,

incêndio e colisão, com pagamento de indenização por custos operacionais obrigatória até os

limites abaixo:

COBERTURA DO CARRO GRUPO DIÁRIA INDENIZAÇÃO POR

CUSTOS OPERACIONAIS A, C, F e M R$ 25,00 R$ 2.000,00 H, I, J, K, N, R, S, U e V

R$ 36,00 R$ 4.000,00

Y R$ 36,00 R$ 10.000,00 T R$ 36,00 R$ 15.000,00 P R$ 36,00 R$ 7.000,00 (perda parcial)

R$ 14.000,00 (perda total, furto e roubo)

242

ANEXO G - ATA DE REUNIÃO DE ENTREVISTA (ESTUDO DE CASO 2)

Ata de Reunião de Entrevista

Projeto: Sistema de reserva online de locadora de veículo

Data: 24/3/2011

Entrevistado: Otávio da Silva – Sócio gerente

Entrevistadores: Rodrigo C. da Silva, Julia Sitko

Duração: 00:40

Assunto: Formas de pagamento disponíveis. Objetivos: • Levantamento inicial das formas de pagamentos que serão disponibilizadas para os clientes. Perguntas Formuladas: • Quais as formas de pagamento que serão disponibilizadas para os clientes? • No caso de pagamentos por com cartão de crédito, existe algum tipo de manual de implementação? Principais Pontos Discutidos: • Foi acertado que as formas de pagamento serão de boleto, transferência bancária e cartão de débito. No caso de pagamento parcelado serão também aceito o pagamento com cartão de crédito. • A empresa optou em disponibilizar o pagamento com cartão de crédito/débito por duas bandeiras (VISAX E MASTERCARDX), sendo que ambas dispõem de guia de implementação para o desenvolvedor. O anexo “dados da transação retornados pela operadora de cartão de crédito” (Anexo D) apresenta os dados que devem ser registrado sobre o retorno da transação.

UMA ABORDAGEM PARA O REUSO DE REQUISITOS …siaibib01.univali.br/pdf/Rodrigo Cezario da...

Documents

Transcript of UMA ABORDAGEM PARA O REUSO DE REQUISITOS …siaibib01.univali.br/pdf/Rodrigo Cezario da...