21 de mai. de 2010

Engenharia de Requisitos: todo mundo fala, poucos fazem

Hoje terminei o treinamento sobre Requisitos de Software com o Luiz Parzianello, que ao meu ver é um dos "CARAS" de requisitos no brasil.

O objetivo do post é falar um pouco do porquê resolvi estudar requisitos e algumas dicas para quem está começando a estudar sobre isso.

Motivação
  • É um assunto abordado de forma muito pobre nas faculdades
  • Existe muita gente(inclusive eu) definindo requisitos baseado na experiência(empírico), sem fundamento teórico.
  • É nítido os problemas que requisitos errados e/ou inconsistentes geram nos projetos.


1) Entenda o que um projeto de software representa

É importante entender que os investimentos realizdados em projetos de software são para realizar transformação entre o cenário atual e um cenário desejado. Significa que o patrocinador do projeto busca eficiência, eficácia e novas oportunidades.

A figura abaixo exemplifica como entender o "AS IS" e o "TO BE".

Óbvio não?


2) Levantamento de requisitos não é descrever solução...


Entendido que projeto de software faz parte da transformação do "AS IS" para o "TO BE", precisamos explorar o "AS IS", ou seja, o PROBLEMA!!!!

Ir para no cliente fazer levantamento de requisitos não significa emitir pedidos, mas sim explorar o cenário atual. Não vá falar com o cliente esperando que ele diga: Faça a tela X, importe os arquivos e comunique com webservices. Isso são soluções.


Levantamento de requisitos = Desbravamento


Realizar o levantamento de requisitos e entender o cenário atual, compreender os problemas existentes, identificar os objetivos de negócio com o projeto e especificar os requisitos de usuário e software necessários para atingí-los.


3) Descrição do Problema







Quando você for entender/descrever os problemas que precisa resolver, tenha em mente que deve utlizar uma estrutura NARRATIVA, ou seja, você vai contar fatos que acontecem hoje.






A descrição do problema pode ser composta por
  • Texto narrativo:
    • Ex: atualmente o gerente utilizar uma planilha para...

  • Resultados do cenário atual
    • Ex: estamos perdendo clientes pelos motivos...

  • Possíveis causas
    • O fato de o cliente não ter acesso ao nosso sistema..


4) Descrição da Visão

Até agora escrevi sobre o objetivo dos projetos e que requisitos não começam com definição das soluções. Passei algumas dicas para escrever o quê o projeto deve resolver.
Antes de começar a identificar funcionalidades e ações dos usuários, precisamos ter uma visão claro de o que o cliente espera do projeto.

Para isso podemos descrever qual a visão (projeção, expectativa, etc) do cliente.

Essa descrição pode conter:
  • Texto descrevendo a expectativa sobre projeto
  • Resultados esperados: redução de 50% do tempo de... , aumento de produção no...
  • Benefícios esperados: aumento na captação de clientes, etc.
  • Recursos necessários: utlizar um sistema para fazer isso, ter acesso ao notebook, etc..
5) Requisitos de negócio
Cuidado! Requisitos de negócio devem estar associados VALORES DE NEGÓCIO, ou seja, eficiências, eficácias e oportunidades.
Este é o mindset:

Requisito de Negócio = Cenário atual(perdas de oportunidades, ineficiências) + Cenário Desejado (objetivos, conformidades, etc.)

A análise de requisitos não pára por aqui. Na verdade ela só para nos requisitos de software (features), mas isso é assunto para outro post.


O importante é o entendimento de como pensar requisitos.


Ainda existem muitos outros aspectos abortados no curso de requistios que fiz. Este é só um pedacinho..


O curso de requisitos de software que fiz vale a pena!!! Pra mim deve ser PRÉ-REQUISTITO para qualquer um que deseja intitular-se analista de sistema/negócio/teste.

Era isso..


4 comentários:

André Danelon disse...

Encontrei por acaso seu post no Infoblogs, mas o título chamou a atenção logo de cara. Na empresa onde trabalho se cobra muito por qualidade das soluções, porém, a maioria não sabe realmente o que é um requisito. Ando lutando para tentar mudar este patamar, e mostrar a importância do mesmo, que do meu ponto de vista é o ponto chave da solução, refletindo inclusive nos testes à serem realizados.
Quero parabenizá-lo por este ótimo post!

Alexandre Simundi disse...

Valeu André!

Eu também estou tendo alguns problemas com isso.

Frequentemente acompanho projetos que existe falha na capatação dos requisitos.

É extintivo. A maioria dos analistas de sistemas, quando vai fazer levantamento de requistios pensa em solução. Pensa em telas, funcionalidades, etc.


O pior é que as pessoas não se dão conta que um levantamento de requistios correto MAXIMIZA os lucros!!

OL disse...

Parabéns pela concisão do conteúdo... uma rápida leitura neste teu post já pode dar uma bela contribuição na atividade de levantamento de requisitos usual...mto bom!

Robson disse...

clap clap clap!