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...”. 


segunda-feira, 7 de fevereiro de 2011

A Gestão de Requisitos como uma ferramenta de apoio à área comercial.

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

Em empresas fornecedoras de serviços de TI, uma das atribuições do Analista de Negócio e Analista de Requisitos é dar suporte à área comercial. Esses profissionais colaboram fazendo o levantamento das necessidades do negócio do cliente e, a partir dessas necessidades, elicitam requisitos dos usuários, regras de negócio e um conjunto de requisitos de software e elaboram um artefato popularmente conhecido como Documento de Visão.

A partir deste documento, é elaborada a Proposta Técnica a qual descreve o escopo do projeto através de seções que abordam as necessidades do negócio, os requisitos funcionais, requisitos não-funcionais, regras de negócio, casos de uso, especificações suplementares, premissas, restrições e requisitos inversos.

Tenho percebido que os Analistas de Negócio (ou Analistas de Requisitos) frequentemente confundem o que significa cada uma desses objetos de Gestão de Requisitos e, por isso, sentem dificuldades em descrevê-las, cometendo erros que levam à elaboração de uma proposta imprecisa, ambígua e com o escopo aberto, permitindo que o cliente, em ocasiões futuras, solicite novos requisitos alegando que a proposta permite tal mudança.

Na tentativa de colaborar com os Analistas de Negócio e com as equipes comerciais, vou comentar sobre cada um desses objetos de Gestão de Requisitos. Tomo como pressuposto que se esses objetos estiverem corretamente descritos, teremos um Documento de Visão e, como conseqüência, uma proposta consistente e com o escopo bem delimitado.  

Necessidades do negócio
Descreve o que é esperado pelos stakeholders de nível executivo da empresa. A correta elicitação dessas necessidades é fundamental para a eficácia do projeto. Para tal será necessário que reflitam as causas-raiz dos problemas do negócio. A análise dos problemas e a identificação das respectivas causas-raiz constituem numa excelente técnica que leva à correta elicitação das necessidades do negócio. Ela irá determinar o alvo a ser alcançado pelo sistema a ser desenvolvido. Será a partir das necessidades que os requisitos do sistema serão elicitados.

Requisito Funcional.
Como o próprio nome afirma, trata-se de uma funcionalidade, ou seja, é uma AÇÃO que será executada pelo sistema que, antes da automação do processo, era executada manualmente. O termo funcional deve remeter à idéia de uma função que o sistema irá executar. Por isso a descrição deverá ter uma conotação VERBAL. Exemplos: Calcular o saldo da conta corrente. Debitar saque na conta corrente. Calcular faturamento mensal. Note que cada sentença inicia com um verbo, caracterizando uma ação a ser executada pelo sistema.

Requisito Não-Funcional.
É uma descrição da CARACTERÍSTICA do sistema como um todo, ou de algum elemento seu, tais como, uma interface gráfica, relatório, arquivo, etc. Pode também descrever aspectos genéricos do sistema, tais como, segurança, manutenibilidade, desempenho (performance), interoperabilidade, confiabilidade, portabilidade, etc. A ISO-9126 descreve em detalhes todas essas características não-funcionais de uma aplicação de software.  Um requisito não-funcional QUALIFICA um aspecto do sistema. Por isso sua descrição deve ter uma conotação QUALITATIVA. Exemplo: Todos os campos obrigatórios de uma tela deverão estar marcados com um asterisco. O cadastro de clientes deverá ter um crescimento mensal de 10%. O tempo de resposta para transações na ATM não deverá ultrapassar a 3 (três) segundos. Note que não há nenhuma ação na descrição destas sentenças. Elas descrevem características que devem ser implementadas no sistema.

Regras de Negócio.
Nem é uma ação a ser executada pelo sistema, nem é uma descrição qualitativa do sistema. Trata-se de uma RESTRIÇÃO IMPOSTA PELO NEGÓCIO. Ela afeta o comportamento do negócio e, como conseqüência, afeta o comportamento do sistema que o automatiza. Não tem nada a ver com requisito de software. Uma regra de negócio existe independente do processo de negócio ser ou não automatizado por software. Por isso sua descrição deverá ter uma conotação RESTRITIVA. Exemplo: Cliente inadimplente não pode fazer compras a prazo. Um item de estoque só poderá ser reposto quando seu saldo atingir o nível mínimo.

Casos de Uso.
É uma descrição do diálogo entre o ator (papel executado por um usuário, sistema ou um dispositivo de hardware) e o sistema (foco do projeto), o qual produz um resultado de valor do ponto de vista do ator. É uma excelente técnica de captura de requisitos funcionais e não-funcionais. Por isso podemos dizer que os casos de uso realizam os requisitos funcionais e requisitos não-funcionais (também conhecidos como requisitos especiais). Alguns requisitos não-funcionais que não possuem relação com nenhum caso de uso, são popularmente chamados de Especificações Suplementares

Premissa.
É um PRESSUPOSTO que deverá ser levado em consideração pela EQUIPE DO PROJETO. Descreve ações a serem (ou não serem) executadas pela equipe do projeto. Sua descrição deve referenciar aspectos que devem ser levadas em consideração durante a execução do projeto. Exemplos: Os desenhos das telas serão feitos pelo Web-Design por ocasião do Modelo de Análise. A equipe de implementação deverá ter experiência em UML 2.1. Os requisitos deverão ser validados pelos usuários antes da elaboração do Modelo de Design da aplicação.

Restrições.
São fatos que restringem o projeto ou a solução. É diferente de uma Regra de Negócio. Enquanto uma Regra de Negócio restringe o comportamento do sistema, uma Restrição restringe decisões a serem tomadas pela gestão ou pela equipe operacional do projeto. Restrições do projeto estão associadas ao orçamento, prazo, disponibilidade de recursos, etc. Restrições da solução estão associadas à arquitetura, design, tecnologia e infra-estrutura. Exemplo: Toda documentação deverá ser feita em UML 2.1. O modelo de processo utilizado deverá ser o SCRUM.

Requisitos inversos.
São requisitos do sistema que não serão contemplados pelo projeto em foco. Reconhece-se a existência do requisito, mas deixa-se claro que o presente projeto não irá abordá-lo. É uma declaração explícita de que o projeto não entregará aquele requisito. Isso é muito útil para não causar expectativas por parte do cliente/usuários. Ajuda a delimitar o escopo do projeto.

Conclusão.
Esses elementos acima descritos constituem o foco da Gestão de Requisitos. Não é necessário que a equipe comercial tenha experiência em Gestão de Requisitos. Minha sugestão é que toda empresa que presta serviços de Engenharia de Software, deve ter uma célula de trabalho especializada em Gestão de Requisitos, onde uma das suas funções é dar suporte à área comercial. Este suporte consiste na elaboração do Documento de Visão, o qual deverá conter todos esses itens tão essenciais para a elaboração de uma Proposta Técnica, a qual será usada como ponto de partida para o correto planejamento do projeto. Sem esses itens corretamente descritos e negociados, existirá um forte risco do sistema “iniciar torto”.