segunda-feira, 28 de fevereiro de 2011

Requisitos de software existem por si só.

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Um dos principais medos que temos quando vamos entregar um sistema que estamos desenvolvendo, é ouvir a seguinte frase: “o sistema parece interessante, bem feito, mas...”. O grande problema está no “mas...”.

O que significa este “mas...”? Significa que alguma coisa está faltando, como por exemplo, uma funcionalidade fundamental, alguma informação necessária ou alguma característica de qualidade esperada. A questão é, porque esta funcionalidade, informação ou característica não foram entregues? Certamente é porque não foram lembradas na ocasião em que a equipe estava elicitando os requisitos. De quem é a culpa? Certamente não é do Usuário que foi interrogado. Com certeza é do Analista de Negócio. Então, o que faltou? Faltou o uso das técnicas e abordagens apropriadas para achar os requisitos.

Os requisitos existem nas mentes dos stakeholders. Cada stakeholder visualiza parte do problema do negócio cuja solução é refletida na forma de Necessidades, que precisam ser identificadas nas três esferas (ou camadas) administrativas da empresa: Estratégica, Tática e Operacional. Particularmente, gosto muito do verbo “achar”. Nosso papel é “achar” as Necessidades em toda a amplitude do negócio, ou seja, nas três esferas administrativas.

Muitas vezes, nos restringimos a identificar Necessidades somente na camada Operacional, porque envolve um público mais fácil de ser acessado, mas em algumas empresas, até esta camada é de difícil acesso. O fato é que a esfera Operacional abriga os usuários do sistema, ou seja, aqueles que interagem diretamente com o sistema. Se o analista de negócio analisar o problema somente do ponto de vista da camada Operacional, certamente irá identificar somente as Necessidades Operacionais do negócio.

Dessa forma, quando for entregar o sistema, os stakeholders Estratégicos e Táticos irão reclamar porque suas Necessidades não foram atendidas. Por isso irão dizer a tão temida expressão “sim, mas...”. Portanto, podemos concluir que as Necessidades existem, independentemente de achá-las ou não. O processo que nos leva a “achar” a totalidade das Necessidades requer o envolvimento das camadas Estratégica, Tática e Operacional.

O conjunto dessas Necessidades é usado como insumo no processo que leva à completa identificação dos requisitos de software. Em outras palavras, podemos afirmar que os requisitos de software são derivados a partir das Necessidades dos stakeholders. Se as Necessidades não forem completamente identificadas, isso implica que um determinado grupo de requisitos, conseqüentemente, não será identificado. Ora, se as Necessidades existem independentemente de achá-las, ou não, conseqüentemente os requisitos também existem, independentemente de achá-los, ou não.

É fácil achá-los? Claro que não. Mas este é o papel do Analista de Negócio. Em minhas aulas e palestras, gosto muito de usar a seguinte analogia. Elicitar requisitos é como achar agulha em um palheiro. As agulhas foram postas lá. Elas existem. Compete a nós achá-las.

Se não as encontrarmos, certamente iremos ouvir dos usuários: “Sim, o sistema parece interessante, mas...”. 


7 comentários:

oFOC@ disse...

Concordo 100% com o post! O maior problema é que as empresas adotam ou criam sua propria MDS, e os templates nao contemplam uma forma de valudação formal dos requisitos não funcionais!
Como nao ha uma forma de prototipar esses requisitos, cai no esquecimento do usuário e geralmente nao sao especificados e obedecidos!
Passo por este problema todos oa dias. Como resolver?

Wagner

mFOGO disse...

Esta á a mais pura verdade!!! Sempre que uso as técnicas para "achar" os requisitos fico com algumas dúvidas que não foram respondidas na primeira entrevista com o steakholder. Por convoco novas entrevistas para não deixar passar os requisitos que estão no "palheiro".

O problea é que nem sempre os steakholders dos níveis mais altos da pirâmide estão disponíveis. Mas a gente sempre dá um jeito e consegue haha.

Unknown disse...

Pois é Evandro, o que diser do cara que mais me ensinou de requisitos!
Concordo plenamente com seu artigo, o grande profissional é aquele que conseguindo acesso aos stakeholders das três camadas consegue a confiança deles e assim um passe de vantagem para "achar" todos os requisitos! É o começo de um projeto de sucesso!!! Beijos Chris

Evandro Moreira Pinto disse...

Wagner.
Com referência aos requisitos não-funcionais, existem alguns tipos que realmente são mais difíceis de prototipar, mas poderia te lembrar que os requisitos do tipo usabilidade são facilmente prototipáveis. Mas lembre-se que prototipação é uma técnica de elicitação de requisitos. É muito mais do que desenhar telas. Para você fazer uma prototipação adequada, se faz necessário que o planejamento do projeto contemple essa atividade. Qualquer dia desses vou escrever um post sobre prototipação. Aguarde.
Obrigado por escrever.
Um grande abraço.

Evandro Moreira Pinto disse...

Fogo.
Que bom que esteja buscando acesso aos stakeholders de nível executivo. Uma boa maneira de identificá-los é utilizar a técnica de Análise do Problema do Negócio que eu ensino no meu curso de Gestão de Requisitos com Casos de Uso. Esta técnica leva você a identificar as Necessidades Estratégicas, Táticas e Operacionais. Se você conseguir identificar essas Necessidades, fica muito mais fácil você identificar a quem elas pertencem, ou seja, os Stakeholders. A partir dessas Necessidades, faça a decomposição para elicitar as Features (Características de Software – veja ISO9126), Regras de Negócio, Casos de Uso, Requisitos Suplementares, etc. As Necessidades de Negócio estão associadas aos Stakeholders de nível estratégico. As Features estão associadas aos Stakeholders de nível tático. Casos de Uso e Requisitos Suplementares estão associados aos Stakeholders de nível operacional.
Um grande abarco.

Evandro Moreira Pinto disse...

Oi Chris
Obrigado por ler minhas crônicas neste blog. Na verdade eu criei este blog exatamente para isso, conversar com meus amigos, colegas, alunos e ex-alunos. Fique sempre à vontade para fazer seus comentários e formular as perguntas que desejar.
Beijos.

Alexander Picoli disse...

Acho que seria legal colocar um pouco de sua experiência pessoal, na forma de histórias, especialmente casos de insucesso, pois são os mais elucidativos...