Engenharia de Requisitos: todo mundo fala, poucos fazem
Autor: Alexandre Simundi | Publicado: 2010-05-21T00:24:00-03:00

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 porTexto 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ócioCuidado! 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..