Objetivo

Após ler esse artigo, por favor, veja também: Levantamento de requisitos e SCRUM. É um complemento a este artigo, sob a perspectiva de metodologias ágeis.

O objetivo deste artigo é oferecer uma visão geral dos desafios encontrados no processo de levantamento de requisitos para se construir um software, bem como um pouco das técnicas para documentá-los.

Para entender a importância desse processo, basta olhar os dados. Segundo o estudo do NIST (National Institute of Standards and Technology), 80% dos bugs dos softwares nascem nos requisitos (fonte: http://www.nist.gov/public_affairs/releases/n02-10.htm). O estudo é um pouco antigo, mas garanto que represente bem a realidade.

Na prática isso significa que a maioria dos problemas encontrados nos softwares são pelo levantamento incorreto ou inacertivo de requisitos, ou seja, definir um software que na prática não atende às necessidades dos usuários finais.

Esse artigo foca principalmente em sistemas empresariais baseados em bancos de dados. Existem sistemas com necessidade de detalhamento de requisitos muito maior do que estes como missão crítica, sistemas embarcados, etc.

Como documentar bem um requisito?

O desafio aqui está em chegar num “nível” correto da documentação de um requisito para sua organização. Documentar requisitos custa caro. Você pode chegar numa documentação de 500 páginas de um único requisito com diagramas, wireframes, protótipos, documentação descritiva e no final das contas produzir um artefato que ninguém vai ler ou seguir, ou ainda, escrever uma documentação de meia-página que não ilustra o problema real. Então como chegar no nível certo de documentação?

Podemos chegar na resposta correta, respondendo essas três perguntas:

• O cliente entende o documento? Ele entende que o documento é uma poderosa ferramenta para garantir que todas as suas solicitações serão contempladas no sistema?
• O desenvolvedor entende o documento? Ele entende que esse é sua única garantia de que está atendendo todas as solicitações do usuário e qualquer solicitação fora disso poderá ser considerado como modificação e ele terá tempo extra para fazê-las?
• O responsável pela implantação consegue entender como o sistema funciona baseado nesse documento?

Que artefatos usar para documentar um requisito?

Geralmente, dependendo da metodologia, usa-se um nome diferente para um documento de requisito. Em cada uma das metodologias, inventou-se um artefato diferente para realizar a documentação:

• Em análise estruturada (voltando aos anos 70-80), usava-se o DFD, e muita documentação descritiva.
• Algumas correntes usaram fluxogramas para desenhar requisitos.
• Alguns chamam o documento de requisito de “Especificação Funcional”.
• Para metodologias baseadas em UML (processos de software como UP – Unified Process ou RUP – Rational Unified Process), geralmente chama-se de “caso de uso”.

A UML (Unified Modelling Language), ao contrário do que muita gente pensa é uma linguagem, não uma metodologia. Foi uma “convenção” criada para normalizar um pouco dos artefatos gerados durante o desenvolvimento de um software. Várias metodologias ou processos de software baseiam-se na UML para documentar seus artefatos. RUP é metodologia. UML é linguagem. Quem diz que utiliza metodologia UML para desenvolver sistemas provavelmente está enganado.

Algumas pessoas podem confundir outros diagramas e artefatos usados em tempo de implementação com documentos de requisito. Os seguintes artefatos não são artefatos para se documentar requisitos (apesar de serem úteis!):

• DER – Diagrama Entidade/Relacionamento: Talvez o diagrama mais popular para “desenhar” bases de dados, ainda usados largamente hoje em dia (Ferramentas como o ERWin e o Embarcadero ER/Studio são formas de desenhar e gerar bases de dados baseadas nesses diagramas).
• Diagrama de Classes da UML: É um diagrama para documentar **como será implementado** o sistema, e não o que o sistema deve fazer. Por isso não será abordado aqui.

DFD’s

Um DFD (ou Diagrama de Fluxo de Dados) é a forma mais “dinossaurica” de representar o funcionamento de um sistema. Não recomendo a utilização dela mais hoje em dia. Pode-se saber um pouquinho mais sobre eles aqui: http://pt.wikipedia.org/wiki/Diagrama_de_Fluxos_de_Dados.

Diagramas de Casos de Uso (UML)

É um artefato muito interessante da UML que serve para “contextualizar” os requisitos. Geralmente descreve-se uma série de requisitos, mas onde exatamente eles entram?

O diagrama de caso de uso para dar uma visão geral do sistema, definindo atores (perfis de usuário, como Administrador, Comprador, Requisitante, ou mesmo sistemas externos) e as operações que eles realizam no sistema (incluir usuário, exportar informações de crédito, etc).

Essa visão de contexto geralmente é interessante para “encaixar” os descritivos de caso de uso ou especificações funcionais dentro do sistema, criando níveis de detalhes maiores, até chegar no detalhamento dos mesmos (visões descritivas ou com diagramas).

Exemplo: Sistema (muito simples) de gestão de pedidos de vendas:

Especificação Funcional ou Descrição de Caso de Usos

A especificação funcional e a descrição do caso de uso são a mesma coisa. É uma forma “descritiva” de documentar os requisitos sem seguir muito padrão.

Geralmente contém as seguintes informações:

• Pré-requisitos: Direitos de acesso que o usuário precisa para usar a funcionalidade descrita, ou perfil de acesso necessário. Qualquer condição que impeça totalmente o usuário de “começar” a funcionalidade. Dados pré-cadastrados, configurações. Tudo isso entra aqui.
• Fluxo principal de execução: Passo a passo o que o usuário faz e como o sistema se comporta, num caso de sucesso. Ex.: (cadastro de produto):
  • O usuário informa o código do produto.
  • O sistema verifica se o código já existe. Caso positivo, exibe mensagem “Código do produto já existe, favor informar outro”, impedindo o usuário de prosseguir no cadastramento até que o código seja alterado.
  • O usuário informa a descrição do produto (obrigatório)
  • O usuário seleciona o grupo de produtos, pré-cadastrado no caso de uso “cadastro de grupo de produtos”.
  • Se o usuário clicar em “Gravar” o sistema salva as informações e direciona para o caso de uso “Consulta de Produtos”.
  • Se o usuário clicar em “Cancelar” o sistema direciona para a “Consulta de Produtos”.
• Fluxo alternativo de execução.
  • Caso não exista grupo de produto cadastrado, o usuário pode clicar em “Buscar” à frente do campo de grupo de produtos e cadastrar o mesmo, retornando para o cadastro de produtos, sem perder as informações q ele já cadastrou.

Geralmente esse método de documentar os requisitos acaba sendo o mais funcional, principalmente se aliado a um “desenho” da tela (não precisa ser no layout final).

Diagrama de Atividades (UML)

O diagrama de atividades http://pt.wikipedia.org/wiki/Diagrama_de_atividade é uma espécie de fluxograma que serve para documentar um processo.

Muitas pessoas utilizam esse diagrama para descrever fluxos “macro” do sistema (usando “raias de natação” para identificar a interação de diferentes áreas ou atores no processo), ou ainda para “detalhar” alguns casos de uso mais complexos.

Acho um artefato muito interessante, para uso “opcional”.

Diagrama de Máquina de Estados (UML)

É um diagrama que representa o “fluxo” de estados de um determinado processo. Bem específico para entender o ciclo de vida de um dado processo num sistema.

Acho bom, como uso opcional também.

Diagrama de Sequência (UML)

É um diagrama muito interessante para descrever o fluxo de navegação de uma dada funcionalidade. Muita gente usa para representar a navegação entre páginas Web num sistema.

Não acho que é um artefato que deve ser “obrigatório” na descrição de requisitos.

Protótipos ou Wireframes

Protótipo é construir a “casca” de um sistema para validar com o usuário final, contendo todos os campos, ordem, etc. O Wireframe é a mesma idéia, porém, geralmente num formato de apresentação (as vezes um vídeo flash, ou um powerpoint).

O termo Wireframe é comumente usado principalmente por agências de publicidade com forte atuação na Web. Mas a idéia central é a mesma de um protótipo.

A grande questão aqui é o custo do protótipo. É uma ferramenta excelente para validar o sistema com o cliente final, mas em muitos casos pode ser muito custosa ou desnecessária.

Se vc tem usuários bons, ativos dentro do projeto, consegue validar o sistema com ele somente com os descritivos de caso de uso. Se tem usuários difíceis, com dificuldade para entender o relacionamento entre as funcionalidades, o protótipo pode ser uma saída.

Se tem usuários ou projetos com forte exigência de layout e identidade visual, é recomendável que o protótipo esteja no layout final, para evitar grandes refluxos após a entrega final do sistema.

Dicas para Levantar Bons Requisitos

Documente só o necessário, mas não esqueça do necessário.

Se determinada parte do documento que está sendo elaborado tem mais a ver com o negócio que o cliente opera, seus dados transacionais (faturamento, meta, resultado) do que como ele vai ser implementado no sistema que está sendo desenvolvido, então provavelmente o documento que está sendo escrito não é uma especificação funcional, ou uma documentação de requisito.

Em contrapartida, não existe “óbvio” em documentação. Se não está na especificação, não foi solicitado. Se está na especificação e o entendimento não está claro, não está bem documentado.

Pense numa televisão. Se não foi especificado se a TV é a cores ou preto e branco, qualquer uma das duas atende aos requisitos especificados (até se no final a televisão for de fósforo verde!).

Crie exemplos

Sempre que tiver um procedimento mais complexo, como procedimento de cálculo, campos calculados, procedimentos complexos como geração de faturas baseadas em pedidos, não hesite em criar exemplos. Serve para testar melhor, para matar dúvidas e com certeza terá o esforço justificado.

Entenda quais informações são necessárias para os requisitos.

Conforme citado anteriormente, o artigo foca principalmente em sistemas empresariais baseados em bancos de dados. Para esse tipo de sistema, é possível agrupar os requisitos em algumas grandes categorias:

• Manutenção: Pares de funcionalidades de cadastros/consultas para toda e qualquer entidade do sistema. Ex.: Cadastros de usuários, Consulta de Perfis de usuário, Cadastro de Pedido, Cadastro de Requisição, etc.
• Procedimentos de Cálculo: Regras de cálculo complexas, valorização de títulos de renda fixa, cálculo de desconto comercial, campos calculados, taxas de juros em longos períodos de tempo.
• Relatórios: Extrações de informações complexas de sistemas (valem gráficos também). Relatórios de vendas, pedidos por período, estatísticas de acesso do sistema, etc.
• Procedimentos Batch: Geralmente procedimentos pesados que são executados nos sistemas. Ex.: Fechamento de cota de fundo, Faturamento mensal, Fechamento contábil, etc. Qualquer procedimento que demora bastante tempo para ser executado (e dependa de processamento assíncrono) e que gere atualizações diversas no sistema, não interativas para o usuário em questão.
• Integrações com outros sistemas: Geração de informações para o sistema financeiro, dados para BI, acessar um web service, permitir que as informações sejam consultadas por web service, etc.

Criando Padrões

Um dos fatores que dificultam a operação e o entendimento do sistema por conta do usuário é a falta de padronização entre as funcionalidades do sistema.

Não é incomum encontrar sistemas que possuem telas de parâmetros e cadastros de forma completamente desuniforme. Por exemplo, um sistema que em determinada tela o ícone para o botão salvar em um lugar é um disquete, no outro é um “check”. Num lugar a botoneira é no topo da tela, no outro, no rodapé. Num lugar a consulta é junto do cadastro, em outro é separado.

Para evitar esse tipo de desnormalização, é interessante definir “padrões de navegação” com os usuários chaves antes de iniciar o levantamento, assim para as funcionalidades desenvolvidas nos 4 grupos citados acima já são “especificadas” seguindo o padrão de navegação.

O layout também é interessante ser pré-aprovado. Geralmente definindo a “cara” e as cores no início do projeto pode ser suficiente. Mas é muito importante perceber o nível de exigência do usuário e do projeto em relação à layout. Nesses casos pode ser interessante criar “prints” das telas já no layout final, para que a validação seja realizada pixel a pixel. Não é difícil perder o controle do projeto e estourar o orçamento por causa de constantes mexidas no layout que as vezes acabam impactando até a codificação.

Requisitos para funcionalidades de Manutenção

Pré-requisitos:

• Através de qual menu/fluxo de navegação o usuário precisa seguir para chegar até a funcionalidade?
• Qual é o parâmetro/forma de controle de acesso a permissões do usuário?

Itens necessários no levantamento funcional:

• Todos os campos estão descritos?
  • Os componentes usados para o usuário colocar as informações estão definidos? (Ex.: Text Box, Check Box, Text Area).
  • O tamanho máximo?
  • Validações necessárias para o campo? (CPF, CNPJ, Inscrição estadual, somente números inteiros, somente números decimais, CEP, telefone).
  • Precisa de máscara?
  • No caso de campos do tipo “Combo”, são opções fixas ou originárias de dados pré-cadastrados? Se originárias de dados pré-cadastrados, existe alguma forma do usuário colocar essas informações?
• No caso de cadastro master-detail, está descrita a forma de colocar os itens filhos?
• Todos os botões de ações para realizar inclusão, alteração, exclusão estão claros?
• Se precisa de exclusão múltipla ou alteração múltipla, está claro na interface como o usuário consegue realizar isso?

Consistências

• A regra de negócio para cadastrar está clara? Todas as consistências estão descritas e as informações necessárias para realizá-las estão disponíveis?
  • Ex.: Uma consistência para cadastrar um pedido: Se o valor total do pedido for maior do que o valor máximo de faturamento do cliente, o sistema deve emitir uma mensagem: “Não é possível incluir o pedido pois o valor total excede o valor máximo de faturamento do cliente”. No exemplo acima, tudo parece claro, exceto se o campo não existir no cadastro de cliente, ou depender de algum cálculo. Nesse caso, ao levantar o requisito, deve-se ter certeza que o mesmo fecha na outra “ponta”.
• A regra para exclusão foi definida? As mensagens para o caso de exclusão englobam os casos de violação de integridade referencial? Ex.: Excluir um perfil de acesso que já está sendo usuários cadastrados.

Procedimentos de Cálculo

O grande problema de descrever procedimentos de cálculo mais complexos é que geralmente uma série de parâmetros usados no cálculo não tem sua origem descrita.

Em resumo, precisamos saber se:

• Todos os parâmetros de entrada foram definidos?
• Todos os valores de saída foram definidos?

Exemplo prático: Descrever a regra de cálculo de ICMS.

A princípio pensamos: É fácil… é só pegar o valor total dos produtos e aplicar a alíquota.

De repente, percebemos que a alíquota varia entre os estados e pensamos que uma tabela com a alíquota por estado resolve o problema.

Analisando o problema um pouquinho mais a fundo, percebemos que a alíquota varia de estado origem para estado destino. Então precisamos definir uma tabela Estado Origem, Estado Destino e Alíquota.

Porém, analisando mais ainda, percebemos que existem produtos com redução de base de cálculo, isenções.

Em resumo, todas essas variáveis precisam estar definidas. Se o sistema prevê um procedimento de cálculo que considera exceção, tabelas de alíquota, obviamente os requisitos destas funcionalidades (cadastro de exceção, cadastro de alíquota) precisam ter sido definidos.

Relatórios

No caso dos relatórios o problema mais comum é a definição de uma extração de informações que o sistema não possui. É muito mais comum do que parece.

Um exemplo prático: Num sistema de estoque define-se uma funcionalidade de “movimentar estoque”. Porém, dada uma analise muito superficial do problema, cria-se um cadastro que se informa o tipo de movimento (entrada/saída) o produto e a quantidade. Ótimo! Funciona!

Porém, não fica claro na definição dos requisitos se é necessário armazenar o “histórico” das movimentações.

Então, de repente aparece um relatório que é um “extrato do estoque”. Aparece o produto, quanto tinha no estoque no começo do período, quanto entrou, quanto saiu, e quanto ficou no final do período, por dia, por semana, por mês.

De onde o sistema vai extrair essa informação?

Então, para descrever um bom requisito de relatório é importante que:

• Todos os filtros estejam descritos, qual é o funcionamento deles (como os dados são filtrados) e a origem dos dados dos filtros (no caso de combos)
• Todos os campos existentes no relatório tenham sua origem descrita (onde foi cadastrado). No caso de campos calculados, a regra para se obter os mesmos.
• No caso de um relatório que precise de modificações no sistema para ter as informações necessárias, é importante que todos os demais casos de uso ou especificações funcionais sejam criadas e/ou revisadas para concluir todo o requisito.

Processos Batch

Geralmente esses processos relacionados a fechamentos precisam ter alguns cuidados especiais. Um exemplo prático é que por serem processos lentos, o usuário final precisa de uma interface para “disparar” o processamento, mas não necessariamente ele irá acontecer naquela hora.

Por isso, principalmente para aplicações Web é necessário prever que alguns problemas inerentes à tecnologia podem prejudicar a criação da funcionalidade. Ex.: Tempos de timeout de request, carga de processamento, etc. Dependendo do tipo de processamento, vale muito a pena entrar em contato com os desenvolvedores e criar provas de conceito.

Assim como os procedimentos de cálculo o mais importante aqui é descrever as entradas e as saídas. Como filtros, e artefatos gerados. Ex.: Para um processo de faturamento temos como entrada um conjunto de pedidos e como saída um conjunto de notas fiscais. E dentro a regra de como será o relacionamento dos pedidos em notas, regras de split ou consolidação, etc.

Outro ponto muito importante para esse tipo de processamento é: É importante que o usuário possa voltar atrás? As vezes isso gera um requisito completamente novo. Como “desfazer um fechamento”, “cancelar o faturamento”. É muito comum esquecer do requisito que “desfaz” um procedimento batch complexo e acabar descobrindo a necessidade dele somente numa questão emergencial.

Integrações com outros sistemas

O problema clássico aqui é achar que somente com o layout de integração do sistema destino (documento descrevendo a estrutura do texto posicional, do xml, do arquivo excel ou ainda descrição do web service usado) é possível fazer a integração.

Não, não é possível. É muito comum existirem informações que o outro sistema não tem, e elas precisarem ser derivadas através de outras ou com regras fixas, ou com tabelas de/para.

Ex.: Nosso sistema vai exportar informações cadastrais de produto para um determinado sistema. No sistema destino, o campo “Conta contábil” é obrigatório. No nosso sistema não. De onde vamos extrair essa informação? Ou será sempre enviada uma conta contábil fixa (parametrizada ou não no sistema origem) ou vamos ter que incluir esse campo no sistema origem.

No caso de tabelas de/para, como as mesmas serão alimentadas? Como o sistema deve se comportar caso não ache um registro nessas tabelas?

Outra grande preocupação que devemos ter é com o “evento” da integração. Sempre que cadastramos um produto ocorrerá a integração? Será um processo batch comandado pelo usuário? O que fazer no caso de erro, não cadastra o produto?

E por último outro ponto crítico: Existem ferramentas para monitorar as informações dessas integrações? Como sabemos que houve erro e como proceder para reprocessar os arquivos?

Conclusão

Nosso objetivo nesse breve artigo é apenas dar algumas “dicas” de como levantar os requisitos e criar processos para isso nas empresas.

De forma alguma quero criar um “padrão” para isso, ou ainda esgotar o assunto.

Espero que com essas sugestões possam criar alguns processos básicos ou ainda melhorar processos já existentes, sempre com o objetivo de minimizar os problemas em todo o ciclo de desenvolvimento por requisitos mal definidos.