Levantamento de Requisitos - 5W2H

via imagens.tiespecialistas.com.br

Existem várias maneiras de se obter informações sobre um determinado requisito, principalmente para garantir que ele fique cada vez mais completo.

Uma dessas técnicas, conhecida como 5W2H, ajuda a construir de maneira simples as principais informações que um requisito de negócio/software precisa.

A sigla 5W2H vem do inglês, e significa:

What?

O que está atrapalhando seu negócio? O que acontece hoje? O que você gostaria que o sistema fizesse? O que deve ser obtido como produto final do sistema? O que restringe este requisito?

Who?

Quem irá usar o sistema? Quem irá aprovar os requisitos? Quem irá responder às dúvidas? Quem é afetado por este requisito?

When?

Quando os usuários precisarão ter acesso? Quando vocês poderá aprovar os requisitos? Quando poderemos testar? Quando poderemos realizar a entrega?

Why?

Por quê fazer desta maneira? Por quê é preciso fazer isso? Por quê priorizar agora? Por quê não agregar com este outro requisito?

Where?

Onde deverá ser exibido? Onde será desenvolvido? Onde será testado? Onde será acessado pelos usuários?

How?

Como o sistema irá responder? Como deve funcionar? Como deve ser exibido? Como deverá ser documentado? Como você usa? Como você gostaria de usar?

How much?

Quanto tempo temos para desenvolver? Quanto tempo o time do projeto estimou? Quantas pessoas serão necessárias no projeto? Quantas pessoas irão de fato utilizar o sistema?

Gostou? Agora é só tentar aplicar na próxima análise. =)

Até a próxima!

Classificação de Requisitos

O BABOK® Guide classifica de uma maneira muito interessante os tipos de requisitos à que se refere ao longo do livro. Vale a pena dar uma conferida nesta prévia:

• Requisitos do Negócio são metas de mais alto nível, objetivos ou necessidades da organização. Descrevem as razões pelas quais um projeto foi iniciado, os objetivos que o projeto vai atingir e as métricas que serão utilizadas para medir o seu sucesso.
• Requisitos das partes interessadas (steakholders) são necessidades e interações de uma parte interessada em particular ou grupo de partes interessadas. 
• Requisitos da solução descrevem as características de uma solução que atende aos requisitos do negócio e aos requisitos das partes interessadas. São frequentemente divididos em duas subcategorias:
• Requisitos Funcionais descrevem o comportamento e a informação que a solução irá gerenciar, bem como as capacidades que o sistema será capaz de executar em termos de comportamentos e operações – ações ou respostas especificas de aplicativos de tecnologia da informação.
• Requisitos Não-Funcionais capturam condições que não se relacionam diretamente ao comportamento ou funcionalidade da solução, mas descrevem condições ambientais sob as quais a solução deve permanecer efetiva, ou qualidades que os sistemas precisam possuir.
• Requisitos de transição descrevem capacidades que a solução deve possuir com o objetivo de facilitar a transição do estado atual da organização para um estado futuro desejado, mas que não serão mais necessárias uma vez concluída a transição.

Bacana né? Estou aprendendo muito com este livro.

Até a próxima!

Conhece o The IIBA?

O The IIBA (International Institute of Business Analysis) é uma instituição sem fins lucrativos, destinada à disseminação do conhecimento na área de Análise de Negócios.

É possível você se tornar um membro desta instituição pagando uma taxa anual, e nós que moramos no Brasil, ainda ganhamos um descontinho e pagamos um valor diferenciado do normal em função de o Brasil estar na lista de países "with lower Purchasing Power Parity" (Global Membership Program) .

O interessante, é que tornando-se membro do The IIBA, além de você entrar em contato com Analistas de Negócios de diversas partes do mundo e participar de várias comunidades, você tem acesso à uma biblioteca virtual com mais de 300 e-books relacionados ao assunto, incluindo a última versão do BABOK (2.0).
Legal também é que você pode obter suas certificações como Business Analyst. O The IIBA oferece duas: 

• CCBA (para Analistas de Negócio em nível Pleno)
• CBAP (para Analistas de Negócio em nível Sênior)

O The IIBA também tem uma chapter aqui em Porto Alegre (IIBA Porto Alegre Chapter) que está iniciando suas atividades aqui no sul, e espero que em breve tenhamos eventos por aqui.

Por hoje é só...  Até breve!

O que é Business Analysis?

Hoje em dia muito se fala sobre Análise de Negócios (Business Analysis) e as empresas cada vez mais buscam Analistas de Negócios, pois antes de promover qualquer tipo de produto no mercado, é preciso conhecimento sobre o mesmo. Você precisa conhecer o que está vendendo, o motivo que o leva a vender e como irá realizar a venda, para que seu produto não seja um fracasso.

Achei muito boa a definição sobre as atividades do Analista de Negócios apresentada na Wikipédia:

“O Analista de Negócios busca as melhores oportunidades de negócio, analisa tendências, cria novos produtos, recria produtos existentes, está sempre preocupado em encontrar novos caminhos para a empresa. Ele está em permanente contato com o cliente e os donos do negócio.
O analista de negócios (...), vem de maneira a complementar o analista de processos e o analista de sistemas. Os três tipos de analistas diferentes não devem ser confundidos entre si, não são mutuamente exclusivos e eles podem se complementar naquilo que têm de melhor. Fundamentalmente, esta função está atrelada ao conhecimento e facilidade em lidar com negócios, assim como descrita acima, mas muito focada nos recursos de TI e de Sistemas (em toda sua extensão) para poder prover soluções exequíveis para um atingir um determinado objetivo.”

Basicamente, o Analista de Negócios é a pessoa que irá identificar e propor soluções para as necessidades de negócio de um determinado seguimento. Então, se sua empresa precisa de um novo software, o analista de negócios irá realizar entrevistas, para entender o que você faz, como você faz o seu trabalho, e como  você espera que o software possa lhe ajudar, para que juntos, o Analista e o Cliente, cheguem a um acordo sobre a melhor solução possível.

Mas não é uma tarefa exclusiva do Analista de Negócios conhecer e identificar estas melhorias.

Se você trabalha em um time de desenvolvimento de software, e aqui vamos imaginar um Analista de Negócios, um Analista de Sistemas, um Desenvolvedor e um Analista de Testes, quem você acha de deve reter o conhecimento de negócio? A resposta é simples; o time todo!

Ok, nem sempre é possível levar o time completo para uma entrevista, e muitas vezes não é necessário que isso ocorra. Mas é imprescindível que o conhecimento de negócio seja disseminado de forma clara ao time inteiro, seja por meio de reuniões, lista de regras, ou qualquer outra forma que se julgue adequada para que todos estejam alinhados em relação ao assunto, e o desenvolvimento do projeto ocorra com sucesso.