SERS: Uma Ferramenta de Apoio ao Reuso de Requisitos

SERS: Uma Ferramenta de Apoio ao Reuso de Requisitos Rodrigo Cezario da Silva 1, Fabiane Barreto Vavassori Benitti 1 1 1 Universidade do Vale do Itajaí (UNIVALI) Mestrado em Computação Aplicada Caixa Postal 360 88302-202 Itajaí SC Brazil rodrigo@studiodesigner.com.br, fabiane.benitti@univali.br Abstract. This paper presents a tool to specify system requirements (called SERS), which provides support for the reuse of software requirements, conducting recommendations to reuse, based on a catalog of requirement patterns and traceability between requirements. 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 [Davey e Cope 2008; Liu, Li e Peng 2010]. Essa busca por novas práticas ocorreu porque as organizações perceberam que o êxito no projeto está cada vez mais relacionado a um melhor entendimento dos requisitos [Wiegers 2006; Robertson e Robertson 2006]. Diversos autores [Young 2004; Hood et al. 2008] relatam dificuldades encontradas na fase de elicitação de requisitos e apontam como principal problema a compreensão na elicitação de requisitos. Neste sentido, a literatura apresenta várias técnicas como entrevistas, brainstorming, cenários, observação, dentre outras, que são comumente utilizadas nesta etapa do desenvolvimento de software. Complementarmente, autores apontam o reuso de requisitos como uma solução para ajudar a minimizar os problemas relacionados à elicitação de requisitos [Lutowski 2005; Falbo et al. 2007]. O reuso de requisitos tende a conduzir a uma melhora na qualidade do processo de engenharia de requisitos [Perednikas, 2008], reduzindo o tempo de desenvolvimento, aumentando a qualidade do produto desenvolvido [Cybulski e Reed, 2000] e promovendo especificações de requisitos de maior qualidade [Robertons e Robertons, 2006]. 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) 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. No entanto, há poucas ferramentas disponíveis atualmente que suportem o reuso de requisitos e, dentre as existentes, 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, percebeu-se a oportunidade de contribuir com

área de Engenharia de Requisitos através de uma ferramenta de apoio a uma abordagem de reuso de software que auxilie na identificação de potenciais requisitos para reuso. Assim, SERS (Sistema para Especificação de Requisitos de Software) tem como foco o reuso de requisitos a partir de uma abordagem apoiada em um catálogo de padrões de requisitos e a rastreabilidade 1 entre requisitos. Para compreender a proposta, este artigo aborda na seção 2 conceitos sobre reuso de requisitos de software, bem como os principais pontos da abordagem da ferramenta SERS - padrões de requisitos e rastreabilidade. Na seção 3 é apresentada uma visão geral da ferramenta descrevendo as principais funcionalidades, os mecanismos de apoio ao reuso e sua arquitetura. A seção 4 discorre sobre as ferramentas correlacionadas apresentando um comparativo. Na seção 5 são abordadas as considerações finais e trabalhos futuros. 2. Reuso de Requisitos 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 e Spínola, 2007] devendo sua utilização ser ampla e não só restrita ao reuso de código [Konda e Mandava 2010]. A reutilização 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, beneficiar-se com especificações de requisitos de maior qualidade [Robertons e Robertons 2006]. Uma forma de reuso de requisitos é através da rastreabilidade entre requisitos pois, além do seu foco principal que é apoiar a análise de impacto (auxiliando na gestão de mudanças), também serve de apoio ao processo de reutilização dos artefatos [Dick 2002; Spanoudakis e Zisman 2005]. Para Wahono (2002), a reutilização baseada na experiência pode ser usada para identificar necessidades que uma solução deve satisfazer. Neste sentido, padrões proveem uma reutilização de alto nível que pode ser implementado em muitas linguagens e plataformas [Oliveira 2009]. 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. Sendo assim, os padrões de requisitos são vistos pela comunidade como uma abordagem viável de apoio a reutilização [Franch et al. 2010]. 2.1. Padrões de requisitos Padrões de requisitos propõem soluções genéricas e reutilizáveis para escrita de requisitos [Franch et al. 2010; Withall 2007], ou para problemas recorrentes na engenharia de requisitos [Hagge e Lappe, 2004]. 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. Um mapeamento do estado da arte referente a padrões para escrita de requisitos foi realizado através de uma revisão sistemática [Silva e Benitti, 2011] e, a partir deste mapeamento, a ferramenta SERS adotou o padrão proposto por Withall (2007), por ser o mais completo e detalhado - apresentando 37 padrões de requisitos que foram organizados na ferramenta em seis domínios 2. 1 A rastreabilidade é a capacidade de rastrear um elemento do projeto a outros elementos correlatos, ou seja, no contexto da SERS referese a dependência entre requisitos funcionais e não funcionais. 2 O catálogo com os padrões está disponível em http://www.studiodesigner.com.br/mestrado/sers/catalogo/

3. Ferramenta SERS A ferramenta SERS é uma ferramenta destinada a apoiar a elicitação e documentação de requisitos de software. O diferencial da ferramenta é prover funcionalidades específicas para o reuso de requisitos, provendo automaticamente sugestões de requisitos para reuso através de uma abordagem baseada na rastreabilidade entre requisitos e em padrões de requisitos (organizados na forma de um catálogo de padrões, conforme descrito na seção 2.1). 3.1 Funcionalidades Pode-se dividir as principais funcionalidades da ferramenta 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 1a ilustra a busca por um padrão (que pode ser feito por palavrachave, selecionando uma categoria ou por tipo de requisito) o resultado da busca está retratado na figura 1b. Ao selecionar 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 1c). Figura 1. Busca e seleção de um padrão Uma vez selecionado um padrão, o sistema apresenta a tela para cadastro de requisitos de sistema, contemplando no campo de descrição o template do padrão selecionado (Figura 2a). Nesta mesma interface, em havendo requisitos para reusar, é apresentado o alerta ao usuário (Figura 2b). Acessando a aba Sugestões de reuso o

usuário encontra uma lista de requisitos de sistemas (Figura 2c) que podem ser selecionados para: (i) reutilização compartilhada situação em que alterações no requisito do projeto original serão propagadas no projeto em que foi reutilizado (o contrário não se aplica) destaca-se que nesta modalidade alterações somente são permitidas a partir do projeto original; (ii) copiar e manter ligação situação em que alterações no requisito do projeto original não alterarão o projeto que o reutilizou. Nesta modalidade é permitida alteração no requisito reutilizado, no entanto, mantendo o vínculo com o projeto original (permitindo comparação com o projeto original); e (iii) copiar caso em que nenhum vínculo é mantido e alterações são permitidas. Figura 2. Reuso de requisito 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. 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. 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. 3.2. Arquitetura A ferramenta SERS foi desenvolvida utilizando uma arquitetura de 3 camadas (figura 3): (a) a primeira camada trata da apresentação, na qual envolve tecnologias da Web 2.0; (b) a camada controle trata das regras da ferramenta, destacando-se nesta camada as classes wucreusoporpadrao (gerencia as sugestões de reuso baseado na escolha de um padrão de requisito) e wucreusorastreabilidade (gerencia as sugestões de reuso baseando-se nos vínculos de rastreabilidade entre os requisitos); e (c) a camada de modelo composta pelas classes persistentes.

A ferramenta foi desenvolvida na plataforma.net para Web (ASP.NET baseada no Framework 3.5) utilizando Visual Basic como linguagem de programação e MS- Access como banco de dados. Para implementação da camada de apresentação foi utilizado um pacote de extensões ASP.NET, a biblioteca Microsoft ASP.NET AJAX (Asynchronous JavaScript and XML) e o pacote Control Toolkit. Em relação ao desenvolvimento, a ferramenta SERS foi projetada e testada por dois engenheiros de software e implementada por um programador. Cabe salientar que a primeira versão da ferramenta SERS foi finalizada a apenas 3 meses, sendo utilizada por 24 usuários envolvidos em um experimento (a Seção 5 apresenta mais detalhes). Figura 3. Arquitetura 4. Ferramentas correlatas Atualmente existem diversas ferramentas que oferecem suporte a engenharia de requisitos. Em INCOSE (2011) constam 34 ferramentas destinadas a esta área da engenharia de software. Como critério para comparação, verificou-se quais citavam algum tipo de suporte à reutilização de especificações de requisito resultando em 4 ferramentas comerciais correlatas. Além dessas, outras 3 ferramentas desenvolvidas no escopo de projetos de pesquisa foram elencadas. A análise comparativa considerou: (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; e (iii) utilização de padrões verifica se há algum suporte ao uso de padrões de requisitos. A Tabela 1 demonstra o resultado da análise. Ferramenta Forma de reuso 3 Tabela 1. Comparativo entre ferramentas Sugestão de reuso Utilização de padrões Contour 4 CC Não oferece Não Informação técnica Aplicação web na plataforma Java com BD MySQL, SQL Server, HSQL e Oracle 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. 4 http://www.jamabackstage.com;

integreat Requirement Studio 5 CC / CL Não oferece Não Aplicação desktop na plataforma.net 3.5 Aplicação cliente/servidor na MKS Integrity 6 CC / CL / C Não oferece Não plataforma Java com os BD Oracle, SQL e DB2 IRQA 7 CC / CL / C Não oferece Não Aplicação cliente/servidor na plataforma.net com BD Sql Server, Oracle e Ms Access COMPASS-S [Lam 1997] REMAP-tool [Schmid et al. 2006] C Não identificado Não oferece Propõe definir pontos de variabilidade do requisito e um modelo de decisão para sugerir requisitos em uma linha de produto. Formulários padrões variando de acordo com a categoria do requisito MIA [Monzon 2008] CC / CL / C Não oferece Não SERS CC / CL / C - a partir do uso de um padrão - a partir da rastreabilidade entre requisitos Não Catálogo com 37 padrões de requisito [Withall, 2007] Aplicativo desktop em VB com BD Ms Access Plugin para a ferramenta DOORS Plugin para a ferramenta DOORS Aplicação web na plataforma.net com BD Ms Access A parte a ferramenta SERS, observa-se que apenas 3 das 7 ferramentas (42%) declaram implementar o reuso considerando as 3 formas (CC, CL e C). Ainda, apenas uma das ferramentas disponíveis apresentou um mecanismo para sugerir requisitos (mecanismo este diferente do proposto na ferramenta deste artigo). No mais, observa-se que apenas uma ferramenta implementa recurso para auxiliar no emprego de padrões, utilizando padrões diferentes dos contemplados na SERS. Neste ponto é importante destacar que, na prática, em todas as ferramentas os requisitos podem ser descritos observando um padrão, mas dependerá exclusivamente do conhecimento do usuário para isso, o que se buscou observar foi um apoio da ferramenta ao emprego de padrões. Pelas informações técnicas destacadas, observa-se que existem opções de ferramentas de diferentes tipos (web, desktop e plugins) para apoiar o reuso de requisitos, suportadas por diferentes bancos de dados. Por fim, destaca-se que não foi encontrada uma ferramenta que reúna as 3 características exploradas pela SERS, bem como os mecanismos de sugestão para reuso e os padrões de requisitos adotados são também diferentes dos demais identificados. 5. Considerações Finais Este artigo apresentou a ferramenta SERS para apoio ao reuso de especificação de requisitos. Esta ferramenta foi concebida com o objetivo de apoiar uma abordagem de reuso de requisitos que utiliza os vínculos de rastreabilidade e catálogo de padrões de requisitos como mecanismo para o apoio ao reuso de requisitos. Conforme pode ser observado na análise comparativa, as ferramentas da área de requisitos que oferecem suporte ao reuso adotam abordagens distintas da SERS e, em nenhum caso, foi encontrado o uso de sugestões e padrões em uma mesma abordagem, consistindo em um diferencial da SERS. Um estudo de viabilidade foi realizado utilizando dois estudos de caso (um projeto de e-commerce para livraria e o outro de um sistema de locação/reserva de veículos) distribuídos, equanimente, entre os 12 participantes (visando identificar a 5 http://www.edevtech.com/products.html 6 http://www.mks.com/platform/integrations/int-modeling 7 http://www.visuresolutions.com/requirementsdefinitionmanagement

viabilidade da ferramenta SERS em contextos diferentes). Cabe salientar que foi realizado um teste não-paramétrico Chi-Square para confirmar que não existia diferença significativa no nível de conhecimento (p-value = 0,530) em engenharia de requisito (obtidos por um questionário de perfil do participante) entre os grupos. Os resultados do experimento demonstraram que o estudo de caso do projeto de e-commerce obteve uma média superior a 45% de reuso dos requisitos e o outro estudo de caso teve uma média de 75% de reutilização. Observou-se também que a maioria das aceitações de reuso foi promovida pelas sugestões baseada nos padrões (perto de 60% das reutilizações realizadas), 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. Estes dados indicam que ambos os mecanismos de apoio favoreceram ao reuso. Outros resultados são apresentados pela figura 5 que demonstra a percepção dos participantes quanto à ferramenta SERS (obtendo avaliação positiva quanto a sua adequação, facilidade de uso, apoio ao reuso e utilização dos padrões). 15 10 5 Análise da percepção dos participantes 0 Concordo totalmente Concordo parcialmente Indiferente Não concordo particialmente 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 Não concordo totalmente Figura 4. Avaliação da SERS Algumas das principais contribuições da ferramenta, além de apoiar a atividade de elicitação e especificação de requisito, são: (a) provê mecanismos para encontrar requisitos utilizados em outros projetos, como forma de se obter requisitos indiretamente; (b) busca o aumento da qualidade de escrita dos requisitos (através dos padrões de requisito); e (c) auxilia na diminuição do esforço na atividade de elicitação e especificação promovendo o reuso. Em relação às limitações, a ferramenta SERS ainda não possui funcionalidade de gerenciamento dos requisitos, como o controle de versão e gerenciamento de mudanças. Como trabalho futuro pretende-se realizar 2 avaliações visando mensurar o potencial de reuso dos mecanismos implementados: (i) uma avaliação empírica visando identificar a eficiência e eficácia 8 e; (ii) uma avaliação GQM com especialistas na área de Engenharia de Requisitos. Além disso, algumas melhorias já estão previstas, como implementar novos mecanismos de sugestão de reuso e possibilidade de gerenciar os 8 No contexto deste trabalho a eficiência é considerada 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).

padrões. A ferramenta SERS encontra-se disponível para uso no link http://www.studiodesigner.com.br/mestrado/sers/ 9. 6. Referências Alves, V., Niu, N., Alves, C. and Valença, G. (2010) Requirements engineering for software product lines: A systematic literature review IST, Volume: 52, Issue: 8, August, 2010, pp. 806-820, Elsevier Cybulski, J. L. and Reed, K. (2000) Requirements Classification and Reuse: Crossing Domain Boundaries, in ICSR'2000, (Vienna, Austria, 2000), 190-210. Davey, B. and Cope, C. (2008) Requirements Elicitation What s Missing?, IISIT, vol.5. Dick, J. (2002) Rich Traceability, Proceedings of the 1 st International Workshop on Traceability in Emerging Forms of Software Engineering, Edinburgh, Scotland. Falbo, R. A., Martins, A. F., Segrini, B. M., Baiôco, G., Dal Moro, R. and Nardi, J. C. (2007) 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ú. Franch, X., Palomares, C., Quer, C. and Renault, S. (2010) A Metalmodel for Software Requirement Patterns*, REFSQ 2010, Springer-Verlag: Berlin, p.85-90. Hagge, L. and Lappe, K. (2004) Patterns for the RE Process, Proceedings of the 12 th IEEE International Requirements Engineering Conference (RE 04). Hood, C., Wiedemann, S., Fichtinger, S. and Pautz, U. (2008) Requirements Management: The Interface Between Requirements Development and All Other Systems Engineering Processes, Springer: Berlin. INCONSE, International Council On Systems Engineering (2011) Tools survey: requirements management (RM) tools, Seattle, WA, USA. Disponível em: <http://www.incose.org/productspubs/products/rmsurvey.aspx>, Acessado abril de 2011. Johnson, W. L. and Harris, D. R. (1991) Sharing and Reuse of Requirements Knowledge, Proc. KBSE-91, IEEE Press, Los Alamitos, CA; pp. 57-66. Konda, B. M. and Mandava, K. K. (2010) A Systematic Mapping Study on Software Reuse, University essay from Blekinge Tekniska Högskola/COM - Master Thesis Software Engineering. Monzon, A. (2008) A Practical Approach to Requirements Reuse in Product Families of On-Board Systems, International Requirements Engineering. 16th IEEE, pp.223-228, 8-12 Sept. 2008 Lam, W. (1997) Developing component-based tools for requirements reuse: a process guide, 8 th IEEE IWCASE, pp.473-483. Lamsweerde, A. (2000) Requirements Engineering in the Year 00: A Research Perspective, 22 th International Conference on Software Engineering, Liu, L., Li, T. and Peng, F. (2010) Why Requirements Engineering Fails: A Survey Report from China, Requirements Engineering Conference (RE), 18 th IEEE International. Lutowski, R. (2005). Software requirements: encapsulation, quality, and reuse. Boca Raton, Fl: Aurebach. Oliveira, K. (2009) Proposta de um Catálogo de Padrões Aplicados ao Processo de Elicitação de Requisitos Para Software de Gestão Comercial, Tese em Engenharia de Produção, São Paulo. Oliveira, K. and Spinola, M. (2007) POREI: Patterns-Oriented Requirements Elicitation Integrated Proposta de um Metamodelo Orientado à Padrão para Integração do Processo de Eliciação de Requisitos, Latin America Conference on Pattern Languages of Programming, 6ª., Pernambuco. Perednikas, E. (2008) Requirements Reuse Based on Forecast of User Needs, International Conference 20 th EurOPT-2008. Neringa, Lithuania: pp: 450 455. Robertson, S. and Robertson, J. (2006). Mastering the Requirements Process, 2 ed. Addison Wesley. 9 Posteriormente os fontes serão liberados sob a licença MIT (Massachusetts Institute of Technology)

Schmid, K.; Krennrich, K.; Eisenbarth, M. (2006) Requirements management for product lines: extending professional tools, Software Product Line Conference, 10th International, pp.10 pp.-122 Silva, R. C. and Benitti, F. B. V. (2011) Padrões de Escrita de Requisitos: um mapeamento sistemático da literatura, In Proceedings 14 th Workshop on Requirements Engineering - WER 2011. Spanoudakis, G. and Zisman, A. (2005) Software Traceability: A Roadmap. Advances in Software Engineering and Knowdledge Engineering, v. 3, World Scientific Publishing. Wahono, R. S. (2002) On the Requirements Pattern of Software Engineering, Temu Ilmiah XI 2002. Wiegers, K. E. (2006). More About Software Requirements: Thorny Issues and Practical Advice, Microsoft Press. Withall, S. (2007). Software Requirement Patterns, Washington: Microsoft Press. Young, R. R. (2004). The Requirements Engineering Handbook. Artech House.