Este capítulo tem como objetivo apresentar algumas considerações finais sobre os principais tópicos abordados nesta dissertação, incluindo as contribuições alcançadas e indicações para trabalhos futuros.
6.1.
Considerações Finais
A Engenharia de Requisitos é uma fase de fundamental importância na engenharia de software para o desenvolvimento de sistemas, pois envolve desde o processo de aquisição, entendimento e refinamento das necessidades do cliente até a correta especificação de cada requisito levantado.
Elicitar requisitos é uma tarefa na qual exige um cuidado especial para que os requisitos sejam compreendidos corretamente e atendam às expectativas neles lançado, uma vez que é o momento no qual os stakeholders expõem suas necessidades e a visão do sistema a ser desenvolvido. Por abordar requisitos, necessidades e características do sistema que estão sujeitos a constante mudança, a ER é uma fase do desenvolvimento de software onde erros e inadequações a esses requisitos são comuns, podendo não atender as reais necessidades da organização, resultando em retrabalho, custo e principalmente, na insatisfação do cliente.
Focando a atenção nos requisitos não-funcionais, de acordo estudos realizados em literaturas ao longo da elaboração dessa dissertação, verificou-se que nos projetos o foco principal da implementação é “atender aos requisitos funcionais definidos no escopo do projeto”, e que os NFR, muitas vezes apenas são verificados na conclusão do desenvolvimento do projeto. Em muitas situações, não é dado o devido valor a um determinado requisito não-funcional durante a fase de levantamento e desenvolvimento, supondo que o impacto causado por alguma inadequação ao requisito não influenciará no andamento do projeto. Além disso, a correta compreensão do requisito não-funcional e de suas relações, como interdependências e conflitos não é alcançada pela escassez de informações a respeito do NFR.
O constante avanço tecnológico tem acentuado a busca de melhores práticas para auxiliar no desenvolvimento de softwares, a fim de produzir um produto de alta qualidade garantindo a satisfação do cliente. Diante disso, as organizações têm buscado os métodos ágeis, cuja principal prioridade é garantir a satisfação do cliente. Qualidade do produto é algo procurado por organizações e por clientes, e está diretamente relacionada aos requisitos elicitados no início do projeto. Os requisitos essenciais, desejáveis e importantes são solicitados pelo cliente a fim de que o sistema execute as funcionalidades de forma satisfatória e em paralelo são informados os atributos de qualidade.
Como discutido ao longo do trabalho, os requisitos não-funcionais têm uma influência direta no alcance da satisfação do cliente. Eles estão relacionados à eficiente execução das funcionalidades no sistema preocupando-se em proporcionar um fácil uso e aprendizado do sistema, uma interface amigável e compreensível, segurança nas informações inseridas,
confiabilidade nos resultados atingidos. Dessa forma, foi vista a necessidade de uma melhoria na abordagem realizada nesses requisitos a fim de proporcionar uma compreensão correta de cada requisito não-funcional, auxiliando na atividade de desenvolvimento do sistema, possibilitando o atendimento às necessidades do cliente ao final do projeto
Baseado no conjunto de práticas ágeis descrito por [Jacobson, 2010] no Essencial Unified
Process (EssUP), centrado no desenvolvimento de software e que visa prover agilidade a um processo, foi proposta a prática Quality attributes Scenarios Essentials (QaSE). A QaSE é uma prática aplicada para a modelagem dos requisitos não-funcionais utilizando os quality scenarios que pode ser integrada ao fluxo do Scrum, em projetos ágeis.
A QaSE tem por objetivo proporcionar o correto entendimento dos NFR a partir dos
quality scenarios. Nos quality scenarios, os requisitos são descritos de forma clara e detalhada,
expondo as interdependências entre os NFR, os possíveis conflitos que poderão ocorrer de acordo com a influência de um requisito sobre o outro e os impactos que podem afetar o sistema, caso ele seja desenvolvido sem a preocupação de atender ao NFR solicitado.
O principal objetivo deste trabalho foi alcançado com a aplicação da prática QaSE em projetos ágeis, modelando os requisitos não-funcionais em quality scenarios, fornecendo um entendimento correto dos requisitos e de sua importância para o sistema, utilizando uma estrutura definidas nos templates elaborados. Essa prática pode ser implantada em projetos que utilizam métodos ágeis no desenvolvimento de softwares, a fim de possibilitar uma abordagem mais completa aos NFR na definição do Product Backlog e no Sprint Backlog, seguindo o fluxo do Scrum.
6.2.
Limitações da Pesquisa
A principal limitação desta pesquisa refere-se ao fato de o estudo de caso não ter sido realizado desde o início do projeto, uma vez que o mesmo já estava em desenvolvimento. Por esse motivo, um possível risco à validade da pesquisa é que a prática QaSE não seja adequada a qualquer tipo de projeto ágil seguindo o seu fluxo completo de fases.
Uma limitação considerável é o fato da elaboração dos quality scenarios requerer uma quantidade maior de tempo para sua modelagem, impactando na agilidade da técnica.
Como dito anteriormente, pesquisas qualitativas não costumam resultar em teorias universais, válidas para qualquer contexto. Assim, os resultados apresentados aqui refletem bem o ambiente estudado, ou seja, o universo de desenvolvimento de sistemas para web que utilizam métodos ágeis no desenvolvimento de software.
Algumas dificuldades foram encontradas na aplicação da prática QaSE :
• Devido ao pouco tempo para a realização e análise do estudo de caso, a prática não foi aplicada em outras organizações;
• Dependendo da dimensão do projeto, o gerenciamento da prática pode ser difícil devido a grande quantidade de requisitos elicitados;
• Grande quantidade de user stories que precisariam ser adequadas ao formato proposto pela Quality attributes Scenarios Essentials;
• Grande quantidade de requisitos não-funcionais que precisariam ser modelados, explicados e validados pelo time em uma reunião de definição de Product
Backlog;
• Os Quality Scenarios apenas explicitam os conflitos entre os requisitos não- funcionais, mas não os gerenciam e nem propõem tipo específico de tratamento; Com o objetivo de validar a aplicação da prática Quality attributes Scenarios Essentials em outros contextos, é necessário realizar estudos de caso em projetos completos e até mesmo em outras organizações de desenvolvimento de software.
6.3.
Trabalhos Futuros
Como sugestões de trabalhos futuros a esta dissertação podem ser explorados:
• Realizar estudos de caso em outras empresas desenvolvedoras de software para validar a integração da prática QaSE proposta ao fluxo do Scrum. A realização de novos estudos torna-se necessária devido à limitação de tempo para aplicação do estudo de caso e conclusão da dissertação. Dessa forma, o estudo de caso foi realizado apenas em uma organização;
• Validar a prática Quality attributes Scenarios Essentials em empresas de desenvolvimento de software aplicando a proposta em organizações relacionados a desenvolvimento de software;
• Analisar as melhorias sugeridas por profissionais que avaliaram a prática: subdividir as user stories por requisitos não-funcionais, informar nos quality
scenarios o relacionamento dos NFR e com os requisitos. As user stories e os
quality scenarios deverão receber uma numeração que será utilizada para
user stories e os quality scenarios nos templates da QaSE facilitando o entendimento dos NFR no momento da implementação,
Referências Bibliográficas
[Ambler, 2008]
[Ambler, 2009]
[Agile, Manifesto]
AMBLER, Scott W.. Complex Requirements On an Agile Project. Disponível em: http://www.drdobbs.com/high-performance-
computing/211800534;jsessionid=5RLUAR2QYGFXZQE1GHPCKH4ATMY32J VN?pgno=1 . Acesso em: 21/10/2010.
AMBLER, Scott W.. Agile Modeling: Introduction to User Story. SDLC 3.0: Beyond a Tacit Understanding of Agile, Volume1. Disponível em: http://www.agilemodeling.com/artifacts/userStory.htm#Introduction. Último acesso em: 06/10/2010.
Disponível em: http://www.agilemanifesto.org/. Último acesso em: 25/4/2010. [Bass, 2000]
[Bass, 2001]
BASS, Len; KLEIN Mark; BACHMANN, Feliz. Quality Attribute: Design
Primitives. Architecture Tradeoff Analysis Initiative. CMU/SEI- CMU/SEI-2000-
TN-017. December, 2000.
BASS, Len; KLEIN, Mark; MORENO, Gabriel. Applicability of General
Scenarios to the Architecture - Tradeoff Analysis Methods. CMU/SEI-2001-TR-
014.
[Boehm, 2003] BOEHM, Barry; TURNER, Richard. Balancing agility and discipline: a guide for
the perplexed. 1ª. ed. Boston: Addison-Wesley 2003
[Chichinelli, 2001]
[Chung, 1992]
[Chung, 2000]
CHICHINELLI, Micheli; CAZARINI, Edson Walmir. Requisitos Não-funcionais
e sua importância no desenvolvimento de sistemas de informação. In:
ENEGEP2001 - National Meeting of Industrial Engineering 2001.
CHUNG, Lawrence; MYLOPOULOS, John; NIXON, Brian. Representing and
Using Non Functional Requirements: A Process-Oriented Approach. In: IEEE Transactions on Software Engineering – Vol.IS.Nº6,1992.
CHUNG, L.; NIXON, B. A.; YU, E.; MYLOPOULOS, J. Non-Functional
Requirements in Software Engineering. Springer, 2000.
[Colares, 2008] COLARES, Felipe. Requisitos para Detecção de Interdependência entre
Requisitos de Software. Departamento de Ciências da Computação da Universidade
Federal de Minas Gerais, 2008.
[Cortês, 1998 ] CORTÊS, Márcio Lúcio. Engenharia do Produto. Disponível em: www.estig.ipbeja.pt/~eidces/produto.pdf . Último acesso em: 05/05/2010.
[Cysneiros, 1997]
[Cysneiros, 1997]
[Cysneiros, 1998]
CYSNEIROS, Gilberto; LEITE, Julio Cesar Sampaio do Prado. “Integrando
Requisitos Não-funcionais ao Processo de Desenvolvimento de Software”. Rio
de Janeiro. 119p. Dissertação de Mestrado. Departamento de Informática, PUC- RIO.
CYSNEIROS, Gilberto. Requisitos Não-funcionais: Da Elicitação ao Modelo
Conceitual. Departamento de Informática, Tese de Doutorado. Pontifícia
Universidade Católica, Rio de Janeiro, 1997.
[Cysneiros, 2002]
Requisitos Não-funcionais para Análise de Modelos Orientados a Dados. In:
WER – Workshop Requirements Engineering 1998.
CYSNEIROS, Gilberto, 2002. “Ferramenta para o Suporte do Mapeamento da
Modelagem Organizacional em i* para UML”. Centro de Informática,
Universidade Federal de Pernambuco, Tese de Mestrado, 2002.
[Easterbrook, 2007] EASTERBROOK, S. et al. Selecting Empiricals Methods for Software
Engineering Research. Guide to Advanced Empirical Software Engineering Research. Springer, 2007.
[Espindola, 2004] ESPINDOLA, Rodrigo Santos de; MAJDENBAUM, Azriel; AUDY, Jorge Luiz Nicolas. Uma Análise Crítica dos Desafios para Engenharia de Requisitos em
Manutenção de Software. Programa de Pós-Graduação em Ciência da Computação
Faculdade de Informática Pontifícia Universidade Católica do Rio Grande do Sul, 2004.
[Ferreira, 2002]
[Flick, 2004]
FERREIRA, Kécia Aline Marques; DRUMOND, Elayne Cristina. Normas ISO
para Usabilidade. Universidade Federal de Minas Gerais. Instituto de Ciências
Exatas. Departamento de Ciência da Computação - Especialização em Informática/ Engenharia de Software, 2002.
FLICK, U.. Uma Introdução à Pesquisa Qualitativa. Editora Artmed. 3ª edição, 2004.
[Gil, 2002] GIL, A.C.. Como Elaborar Projetos de Pesquisa. 4ª edição, São Paulo, Editora Atlas, 2002.
[Goldenberg, 1999]
[Grau, 2005]
GOLDENBERG, M.. A arte de pesquisar: como fazer pesquisa qualitativa em
Ciências Sociais., 2.ed. Rio de Janeiro,Record 1999.
GRAU, Gemma; XAVIER, Franch; MAYOL, Enric; AYALA, Claudia; CARES, Carlos; HAYA, Mariela; NAVARRETE, Fredy; BOTELLA, Pere; QUER, Carme.
RiSD: A Methodology for Building i* Strategic Dependency Models. In: College
of Information Sciences and Technology 2005 - Pennsylvania State University. [IEEE STD830, 1998] IEEE STD. 830. IEEE Guide to Software Requirements Specification. In: The
Institute of Electrical and Electronics Engineers, New York, EUA, 1998. [Jacobson, 2003]
JACOBSON, Ivar. Use Cases and Aspects - Working Seamlessly Together.
Rational Software Corporation. In: Journal of Object Technology - Chair of
Software Engineering. [Jacobson, 2008]
[Jacobson, 2010]
[Kotonya, 1997]
[Kotonya, 1998]
JACOBSON, Ivar. Being Agile in a Non-Agile World. Disponível em: http://www.ivarjacobson.com/resource.aspx?id=408. Último acesso em: 21/10/2010 JACOBSON, Ivar. Essential Practices – The Smart Way. Disponível em: http://www.ivarjacobson.com/resource.aspx?id=408. Último acesso em: 21/10/2010.
Kotonya, G e Sommerville, I. Requirements Engineering – Processes and
Techniques. John Willy & Sons, 1997.
KOTONYA, G; SOMMERVILLE, I. Requirements Engineering – Processes and
[Lacerof, 1998]
[Lawsweerde, 1998]
LACEROF, A.; PATERNÒ, F. (1998). Automatic Support for Usability
Evaluation. IEEE Transactions on Software Engineering, v.24, n.10, p.863-887.
LAWSWEERDE, A.; Darimont, R. e Letier, E.. Managing Conflicts in Goal-
Driven Requirements Engineering. IEEE Transaction on Software Engineering.
Special Issue on Managing Inconsistence in Software Development,1998. [Leffingwell, 2000]
[Loucopoulos, 1995]
LEFFINGWELL, Dean & Widrig, DON. Unified Process & Unified Modeling
Language. Managing Software Requirements: A Unified Approach – Addison- Wesley object technology series, Addison Wesley, 2000. ISBN: 0-201-61593-2
LOUCOPOULOS, P. E Karakostas, V. System Requirements Engineering. McGraw-Hill Book Company. 1995
[Nielsen, 1993]
[Nielsen, 1994]
[Nunes, 2009]
[Nuseibeh, 2000]
NIELSEN, J. Usability Engineering. London, United Kingdom, Academic Press, 1993.
NIELSEN, J. Usability Inspection Methods, chapter Heuristic evaluation. Pages 413–414. ACM, New York, NY, USA, 1994.
NUNES, Carlos Miguel. Uma Linguagem de Domínio Específico para o
Framework i*. Universidade Nova de Lisboa,Faculdade de Ciências e Tecnologia Departamento de Informática, 2009.
NUSEIBEH, Bashar; EASTERBROOK, Steve. Requirements Engineering: A
Roadmap. In A. C. W. Finkelstein (ed) "The Future of Software Engineering 2000.
[Otto, 2008] OTTO, Cristina Silveira; NEULAND, Renata das Chagas; FERREIRA, Adriane P. D. . Estudo Comparativos sobre as Técnicas de Elicitação de Requisitos. In: XX SBC - Congresso Brasileiro da Sociedade Brasileira de Computação 2008.
[Paetsh, 2003]
[Pergamum, 2010]
PAETSH, Frauke; EBERLEIN, Armin; MAURER, Frank. Requirements
Engineering and Agile Software Development. IEEE Computer Society 2003.
Disponível em: http://www2.dbd.puc- rio.br/pergamum/tesesabertas/0210666_06_cap_02.pdf . Acesso em Julho de 2010. [Portela, 1994]
[Preece, 2005]
PORTELLA, Cristiano R. R; Técnicas de prototipação na especificação de
requisitos e sua influência na qualidade do software. Dissertação de Mestrado,
Instituto de Informática. PUC-Campinas, Campinas, 1994.
PREECE, J.; ROGERS, Y.; SHARP, H. . Design de Interação: Além da Interação
Homem-Computador. Bookman, 2005.
[Pressman, 2001] PRESSMAN, R. Engenharia de Software. McGraw-Hill, 2001. [Robertson, 2004]
[Robertson, 2006]
ROBERTSON, J.; ROBERTSON, S. Volere Requirements: How to Get Started. London: Adison-Wesley, 2004. Disponível em: http://www.volere.co.uk/articles Último acesso em: Julho/2010.
ROBERTSON, Suzanne; ROBERTSON, James. Customer Satisfaction/dissatisfaction – Mastering the Requirements Process (Volere). 2ª ed,
2006.
[Robertson, 2008] ROBERTSON, Suzanne. Cutter Journal Article . Software Education Group, 2008. [Ryan, 1993] RYAN, M. Defaults in Specification. Proceedings of IEEE International
Symposium on Requirements Engineering. IEEE Computer Society Press. San
[Santander, 2007]
[Schwaber, 2004]
SANTANDER, Victor Franciso Araya; VICENTE, André Abe; KOERICH, Fabio Gausmann, CASTRO, Jaelson Francisco Brelaz. Modelagem de Requisitos
Organizacionais, Não-Funcionais e Funcionais em Software Legado com Ênfase na Técnica i*. Universidad de Talca, Facultad de Ingeniería - Curicó Chile,
Universidade Estadual do Oeste do Paraná, Cascavel – Paraná, Universidade Federal de Pernambuco, Recife - Pernambuco Brasil. In: Ideas 2007-
SCHWABER, Ken. Agile Project Management with Scrum. Ed. Microsoft Press, 2004. [Silva, 2006] [Silva, 2006] [Soares, 2004] [Sommerville, 1997] [Sommerville, 2007]
SILVA, Lyrene Fernandes da; LEITE, Julio Cesar Sampaio do Prado. Uma
Linguagem de Modelagem de Requisitos Orientada a Aspectos. Departamento
de Informática - PUC-Rio – Brasil. In: WER - Workshop Requirements Engineering 2006.
SILVA, Sonia Maria Antunes da; BONIN, Marcos Rodrigo; PALUDO, Marco Antonio. Levantamento de Requisitos segundo o Método Volere. RNTI – Revista de Negócios e Tecnologia da Informação, Volume 1 Nº1, 2006.
SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e
Tradicionais para o Desenvolvimento de Software. Universidade Presidente
Antônio Carlos, Faculdade de Tecnologia e Ciências de Conselheiro Lafaiete, 2004. SOMMERVILLE, Ian; SAWYER, Peter. Requirements Engineering – a good
practice guide. New York: John Wiley & Sons Ltd, 1997.
SOMMERVILLE, Ian. Engenharia de Software, Pearson Addison-Wesley, 8a. edição, 2007.
[Teles, 2004] TELES, Vinícius Manhães. Extreme Programming: aprenda como encantar seus
usuários desenvolvendo software com agilidade e alta qualidade. 1ª. ed. São
Paulo: Novatec, 2004.
[Thayer, 1997] THAYER, R. H.; DORFMAN, M.; “Introduction to Tutorial Software
Requirements Engineering” in Software Requirements Engineering, IEEE-CS Press, 2ª . ed. 1997.
[VersionOne, 2008] VERSIONONE, Simplifying Software Delivery. The State of Agile Development
Survey Results, 2008. Disponível em: http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf. Acesso em 20/08/2010. [Xavier, 2009] [Yin, 1994] [Yu, 1995] [Yu, 1996]
XAVIER, Laís. Dissertação cujo tema foi Integração de Requisitos Não-
Funcionais a Processos de Negócio: Integrando BPMN e RNF. Dissertação de
Mestrado. Universidade Federal de Pernambuco, Recife, PE, Brasil, 2009.
YIN, R.K.. Case Study Research: Design and Methods, Second Edition, Sage Publications London, 1994.
YU, Eric S. K... Modelling Strategic Relationships for Process Reengineering. Ph.D. thesis, Department of Computer Science, University of Toronto, 1995. YU, Eric S. K.; MYLOPOULOS, John; LESPERANCE, Yves. Modelling the
APÊNDICE A
Roteiro de Entrevista
Dados do Entrevistado
Projeto: Função:Gerente de Projeto
1. Existem, atualmente no projeto, práticas que são realizadas a fim de melhorar a abordagem aos requisitos não-funcionais? Se existem, quais são?
2. Como os requisitos não-funcionais são modelados no projeto?
3. Após a apresentação e explicação da modelagem utilizando os Quality Scenarios, o entendimento dos requisitos não-funcionais e de suas relações, como interdependências e conflitos, poderá ser melhorado por essa técnica?
4. De acordo com o scenario apresentado, como a prática Quality attributes
Scenarios Essentials contribuiu para o melhor entendimento dos requisitos não- funcionais referentes à usabilidade no projeto?
5. As informações descritas nos templates de User Story e Quality Scenarios propostos atendem às necessidades do projeto?
6. Em sua opinião, quais os pontos fortes e pontos fracos da prática QaSE para a modelagem de requisitos não-funcionais?
APÊNDICE B
Roteiro de Entrevista
Dados do Entrevistado
Projeto: Função:Engenheiro de Software
1. Quais preocupações um Engenheiro de Software deverá ter a fim de que os requisitos não-funcionais sejam devidamente compreendidos e possam ser atendidos ao longo do projeto, sem impactar em custos e retrabalho ao final do desenvolvimento do sistema?
2. Como os requisitos não-funcionais são abordados durante o desenvolvimento do sistema?
3. Após a apresentação e explicação da modelagem dos requisitos não-funcionais em
Quality Scenarios, o entendimento desses requisitos e de suas relações, como
interdependências e conflitos, poderá ser melhorado com o uso dessa técnica? 4. De acordo com a sua opinião, quais foram as melhorias proporcionadas pela
integração da prática Quality attributes Scenarios Essentials (QaSE) ao Scrum à atividade de desenvolvimento?
5. De acordo com o scenario apresentado, como a prática QaSE contribuiu para o melhor entendimento dos requisitos não-funcionais referentes à usabilidade no projeto?
6. Os templates propostos para as User Stories e os Quality Scenarios atendem às necessidades da atividade de desenvolvimento?
7. Em sua opinião, quais os pontos fortes e pontos fracos da prática QaSE para a modelagem de requisitos não-funcionais?