Por que eu devo ler este artigo:Este tema é útil para organizações de desenvolvimento de software que contam com equipes de desenvolvimento que precisam estar preparadas para as mudanças dos requisitos impostas pelos clientes durante os projetos, que visam o desenvolvimento focado no valor de negócio da aplicação e organizações que tenham vontade de reduzir os impactos da alta rotatividade das equipes. Para isso, o artigo discute a abordagem dirigida a comportamento para apoiar as atividades de requisitos. Nela, os critérios de aceitação são primeiramente identificados e escritos em linguagem natural estruturada, as funcionalidades do sistema são identificadas e documentadas como histórias de usuário, a partir daí, pode-se dar início à criação dos testes como determina o desenvolvimento dirigido por testes. Esta abordagem prioriza o comportamento do software, adequando-se ao valor de negócio da aplicação de maneira que o desenvolvimento é dirigido suficientemente às reações do software.

A engenharia de requisitos é abordada em diferentes contextos do desenvolvimento de software. No contexto das metodologias tradicionais como o modelo em cascata e o RUP (Rational Unified Process), existe um grande esforço nas atividades de identificação, análise, especificação, documentação e validação dos requisitos do software. Tais atividades fazem parte do processo de engenharia de requisitos. Neste contexto das metodologias tradicionais, o esforço empregado em todas essas atividades tenta abordar todos os requisitos do software nas fases iniciais do projeto, como concepção, elaboração e projeto.

Na literatura podem ser percebidas lições de que em empresas e instituições que desenvolvem software, essas práticas podem ser custosas. Custosas no sentido de que erros em algumas das atividades da engenharia de requisitos, notados somente nas fases finais como verificações e validações do software resultam em retrabalho. Tais empresas argumentam que no início do projeto é a fase que a equipe e cliente entendem menos do software. Com o avanço do projeto é que se tem mais conhecimento sobre as funcionalidades e características do software a ser desenvolvido.

No contexto das metodologias de desenvolvimento ágeis, os projetos passam por ciclos menores, na qual ao final de cada ciclo, versões incrementais e testáveis do software são lançadas e podem ser utilizadas pelo cliente. Como em cada versão apenas algumas funcionalidades estão presentes, somente essas serão especificadas conforme a abordagem adotada. A priorização das funcionalidades identificadas normalmente é definida pelos desejos do cliente e a importância delas na aplicação.

A abordagem do desenvolvimento dirigido por comportamento (Behaviour Driven Development - BDD) é uma alternativa para o processo de engenharia de requisitos ágil. Não necessariamente precisa ser utilizada somente com metodologias ágeis, mas ela evolui desses paradigmas e já é bastante utilizada em organizações situadas em locais que utilizam algum tipo de metodologia ágil para o desenvolvimento, como o Scrum e Extreme Programming, por exemplo. Tal abordagem também já é difundida em empresas do Brasil e em instituições públicas que desenvolvem software.

O BDD evoluiu do desenvolvimento dirigido por testes (Test Driven Development - TDD), pois a concepção do software e as atividades de identifi ...

Quer ler esse conteúdo completo? Seja um assinante e descubra as vantagens.
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo