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