Não Existe Separação entre Requisitos e Desenvolvimento
Acho que uma das primeiras coisas que todos aprendemos ou deveríamos ter aprendido na faculdade ou em uma curso técnico (sou do antigo PD) ou até mesmo trabalhando é que o modelo em Cascata é ruim. De facto não é um modelo ruim por natureza, só que para o desenvolvimento de software não funciona!
Muitos sabem disso ou pior pensam que sabem, provavelmente qualquer pessoa que você falhe vai concordar com você sobre isto, porem na prática na hora de executar as coisas, o que eu vejo por ai é muito projeto em Cascata até mesmo projetos que se dizem ágeis.
É o velho desenho do balanço. Mas a grande questão que esse desenho nos trás é a seguinte palavra: Requisitos. Também não é nenhuma novidade que cada real gasto em requisitos pode ser 60% mais caro em produção. Muitos falam que sabem disso mas na prática eu vejo justamente o contrário.
Um sintoma de que as coisas não estão indo bem, sinal de confusão :) é separar as disciplinas em fases ou momentos. Não existe um momento de análise ou um momento de programação. O que existe são momentos em que existe mais desenvolvimento do que análise, bem como o RUP já nos mostra através do gráfico de Baleias.
Quando estamos realizando a análise de requisitos existe um processo inicial chamado de triagem que é nele que vão nascer os requisitos candidatos. Esses requisitos candidatos podem ser desenvolvidos e gerenciados por um lista simples. Uma vez eles devidamente validados eles viram requisitos consolidados e deixam de ser requisitos candidatos.
Os requisitos e o processo de triagem não é de uso exclusivo para requisitos do usuário, devemos utilizar isso para requisitos não funcionais também, leia-se arquitetura de sistemas meus amigos. Muitas vezes o processo de requisitos e análise vai bem mas quando falamos de arquitetura os requisitos são esquecidos. Não podemos deixar de trabalhar com requisitos para o desenvolvimento da Arquitetura assim como de Casos de Uso.
Quando estamos realizando o trabalho de requisitos de alguma forma mesmo que não tão direta como a codificação estamos dando características para a solução essas características são tão fortes que devem ser visíveis de fora do sistema. Assim já estamos de certa forma fazendo a solução, as pessoas se enganam quando acham que a solução vem com projeto e desenvolvimento, na verdade a solução inicia nos requisitos.
Por que ?
O grande objetivo da Arquitetura, Projeto e Codificação é atender os requisitos, sejam eles Use Cases, Features, Stories ou o que forem. Logo você deveria estar sempre se pergunta qual requisito ou quais requisitos esse seu código ai está atendendo. Com isso as coisas se encaixam, as atividades de codificação e de levantamento de requisitos não podem ser coisas separadas.
Você precisa saber o que construir antes de construir(Requisitos) mas você também precisa saber se o que você está construindo é viável (Arquitetura) e também precisará ver como construir (Projeto) e por fim construir e testar. Por isso não ache que é perda de tempo quando os analistas de Requisitos estão conversando muito com os desenvolvedores e arquitetos.
De novo, muitas pessoas dizem que sabem disso, mas no final na hora de fazer o projeto não fazem essas coisas, por fim pecam nas práticas mais básicas.
Muitos sabem disso ou pior pensam que sabem, provavelmente qualquer pessoa que você falhe vai concordar com você sobre isto, porem na prática na hora de executar as coisas, o que eu vejo por ai é muito projeto em Cascata até mesmo projetos que se dizem ágeis.
É o velho desenho do balanço. Mas a grande questão que esse desenho nos trás é a seguinte palavra: Requisitos. Também não é nenhuma novidade que cada real gasto em requisitos pode ser 60% mais caro em produção. Muitos falam que sabem disso mas na prática eu vejo justamente o contrário.
Um sintoma de que as coisas não estão indo bem, sinal de confusão :) é separar as disciplinas em fases ou momentos. Não existe um momento de análise ou um momento de programação. O que existe são momentos em que existe mais desenvolvimento do que análise, bem como o RUP já nos mostra através do gráfico de Baleias.
Quando estamos realizando a análise de requisitos existe um processo inicial chamado de triagem que é nele que vão nascer os requisitos candidatos. Esses requisitos candidatos podem ser desenvolvidos e gerenciados por um lista simples. Uma vez eles devidamente validados eles viram requisitos consolidados e deixam de ser requisitos candidatos.
Os requisitos e o processo de triagem não é de uso exclusivo para requisitos do usuário, devemos utilizar isso para requisitos não funcionais também, leia-se arquitetura de sistemas meus amigos. Muitas vezes o processo de requisitos e análise vai bem mas quando falamos de arquitetura os requisitos são esquecidos. Não podemos deixar de trabalhar com requisitos para o desenvolvimento da Arquitetura assim como de Casos de Uso.
Quando estamos realizando o trabalho de requisitos de alguma forma mesmo que não tão direta como a codificação estamos dando características para a solução essas características são tão fortes que devem ser visíveis de fora do sistema. Assim já estamos de certa forma fazendo a solução, as pessoas se enganam quando acham que a solução vem com projeto e desenvolvimento, na verdade a solução inicia nos requisitos.
Por que ?
O grande objetivo da Arquitetura, Projeto e Codificação é atender os requisitos, sejam eles Use Cases, Features, Stories ou o que forem. Logo você deveria estar sempre se pergunta qual requisito ou quais requisitos esse seu código ai está atendendo. Com isso as coisas se encaixam, as atividades de codificação e de levantamento de requisitos não podem ser coisas separadas.
Você precisa saber o que construir antes de construir(Requisitos) mas você também precisa saber se o que você está construindo é viável (Arquitetura) e também precisará ver como construir (Projeto) e por fim construir e testar. Por isso não ache que é perda de tempo quando os analistas de Requisitos estão conversando muito com os desenvolvedores e arquitetos.
De novo, muitas pessoas dizem que sabem disso, mas no final na hora de fazer o projeto não fazem essas coisas, por fim pecam nas práticas mais básicas.
