Muitos dos projetos de desenvolvimento de software falham porque os requisitos não são bem feitos. Encontrei na internet um Cartoon que mostra muito bem o assunto que pretendo tratar neste artigo.
Parece brincadeira, mas isso realmente acontece, embora de forma bem menos explicita.
Acho que posso definir o REQUISITO como a matéria prima que o analista de sistemas vai usar como base para definir o que o desenvolvedor deverá programar.
Muitas das falhas de projeto ocorrem nesta etapa. E ocorrem porque os requisitos são mal feitos. E são mal feitos porque escrever um bom requisito não é fácil. E fica ainda pior quando delegamos a descrição do requisito para o usuário final que não entende as necessidades do analista de sistemas porque não foi treinado para isso.
Elaborar requisitos com base nas necessidades do usuário final é correto, mas não podemos acreditar que todos os usuários finais consigam descrever os requisitos sem esquecer das informações necessárias para a próxima etapa. Para resolver isso, os requisitos devem ser escritos a quatro mãos, duas do usuário e outras duas de alguém que entenda as necessidades do analista de sistemas. Escrever requisitos é tão difícil que existem muitos desenvolvedores experientes que não conseguem faze-lo corretamente, eu mesmo fui um bom exemplo.
Pequeno Estudo de Caso - Relatório de Performance
Para deixar mais claro, vou dar um exemplo de como é complicado descrever um requisito. Há muitos anos atrás, uma cliente me pediu que desenvolvesse um relatório que tivesse: o cliente, o produto que foi vendido, a quantidade, o fornecedor do produto, o vendedor, o custo do produto, o valor de venda, os impostos e a forma de pagamento. Sei que muito desenvolvedor não pensaria duas vezes para começar a desenvolver o relatório solicitado. Mas ao invés disso eu fui para o computador e pesquisei a quantidade de registros que este relatório iria gerar. Cheguei a conclusão que o relatório deveria demonstrar aproximadamente 64 mil registros por dia, o que daria 800 páginas de 80 registros.
Com esta informação, quebrei a resistência para que esta cliente me explicasse qual era realmente a sua intenção. Ela disse que precisava saber quem eram seus melhores clientes em faturamento e contribuição, quem eram seus melhores vendedores em faturamento e contribuição, quais eram seus melhores produtos em faturamento e contribuição e quais eram seus melhores fornecedores em faturamento e contribuição. Todos os cálculos precisariam ser feitos sem impostos e com "valor presente", ou seja, como se fossem vendidos à vista.
O resultado final foi que criei 4 relatórios, um para clientes, outro para vendedores, outro para produtos e outro para fornecedores. Ela tinha pedido que queria ver os 100 melhores de cada grupo mas a convenci que o melhor seria pegar os 10 melhores e os 10 piores de cada grupo, caso contrario seria muita informação para ela conseguir analisar. Perceba que este caso exemplifica muito bem quando o usuário final entrega o requisitos sem mostrar qual era realmente a sua intenção, e isso acontece muitas vezes.
Para evitar casos como este é necessário que o desenvolvedor ou analista de sistemas consiga extrair a real necessidade do usuário final e não deixe que ele defina como o problema deve ser solucionado,
quem faz isso é o analista de sistemas.
Todo Desenvolvimento Precisa de uma Descrição de Requisitos?
A deficiência na descrição de requisitos não torna o desenvolvimento de software impossível, na verdade existem muitos softwares excelentes que foram desenvolvidos por equipes que não sabiam escrever requisitos. No entanto o requisito é indispensável quando você precisar de uma documentação sobre o que será entregue, então ela é necessária tanto para o cliente que vai solicitar um software para automatizar quanto para o desenvolvedor que vai receber o pedido de desenvolvimento do software.
Já estive em dois lados de contratos onde o requisito não foi bem elaborado. O caso em que eu era responsável pelo desenvolvimento da automação e o lado onde eu era o demandante da automação.
No primeiro caso o requisito foi simplesmente que o sistema deveria possuir um controle de estoque. Ao entregar o nosso controle de estoque padrão, o cliente se sentiu no direito de pedir que o controle de estoque deveria ter: controle de obsolescência de lote, estoque por corredor/prateleira/baia, estoque de itens com defeito, emissão de etiqueta de endereçamento de estoque com a impressora X, etc. Enfim, o projeto custou 5 vezes mais do que era planejado inicialmente.
No segundo caso o fornecedor deveria fazer um cadastro multidimensional de tarifas de reserva de veículos. A falta de requisitos fez com que o software fosse entregue sem vários dos recursos que seriam necessários. Mas neste caso o fornecedor não aceitou o argumento de que era ela que deveria ter feito o levantamento de requisitos. No final tive que gastar mais do que planejado no projeto.
O que Deve Conter um Requisito de Software
Um bom requisito de software deve:
- ser escrito em uma linguagem que o usuário consiga compreender, isto é necessário para que ele possa aprovar a descrição e se comprometer com a validação e a homologação da entrega.
- atender às necessidades do usuário, mesmo que ele inicialmente não saiba quais eram elas, o analista de sistema é responsável por descobrir qual é o problema que o usuário precisa resolver.
- ser testável, a descrição do requisito servirá para validar se o software foi desenvolvido de acordo com o que foi proposto.
- conter informações sobre o que ou deve ser feito, porque deve ser feito, quem deve fazer, como deve ser feito, quando deve ser feito e onde deve ser feito.
Dicas Quentes
- Enumere os requisitos para que seja fácil referencia-los.
- Utilize alguma ferramenta que facilite a comunicação. Ela deve controlar as alterações da descrição do requisito, permitir uma comunicação por escrito e com todos os interessados, possibilitar que sejam anexados arquivos anexos, atribuir responsabilidades e a quebra de requisitos grandes em vários requisitos menores. Particularmente eu uso o Asana.
- Se o requisito ficar muito complexo tente dividi-lo em partes menores.
- Peça a aprovação formal do requisito. Isto pode ser feito através de uma simples anotação na ferramenta que estiver utilizando, não há necessidade de faze-lo com uma assinatura, a não ser que existam outros requisitos contratuais que precisem ser cumpridos.
- Mesmo um requisito bem escrito pode ter falhas, por isso é normal que os requisitos sejam reformados ou alterados para que se tornem mais adequados. As alterações podem ser acompanhadas através de sistemas que controle de versão de texto. O Asana possui este recurso para os campos de descrição de tarefa.
A primeira recomendação do "manifesto ágil" diz que "Indivíduos e Interações" são mais importantes do que "processos ou ferramentas". Esta é a forma que eles encontraram de evitar a necessidade de escrever bons requisitos. A recomendação sobre os indivíduos e interações é muito bem vinda porque minimiza a chance de erros, mas nada substitui um requisito bem descrito.
Exemplos Práticos de Requisitos de Software
Controle de Estoque
- Dados um código de produto, o sistema deve informar a quantidade de itens disponíveis para venda.
- Ao confirmar um pedido, o sistema deve diminuir a quantidade de itens disponíveis para venda dos itens que foram vendidos.
- Dado um código de produto, o sistema deve informar quantas unidades são vendidas por dia. O cálculo deve ser feito dividindo-se o número 100 pela quantidade de dias necessários para vender estas últimas 100 unidades, se foram 10 dias a resposta deve ser 10 unidades por dia. Se foram vendidas mais do que 100 unidades no dia anterior então informe a quantidade vendida no dia anterior. O dia anterior deve ignorar os dias em que a empresa está fechada.
- Ao ser solicitado um período e o código de um dos itens de estoque, o sistema deve emitir relatório que relacione o saldo anterior do item no período informado, os movimentos de entrada e saída e o saldo final. Cada registro de movimento deve informar qual foi o documento (nota fiscal) que comprova a operação.
- O registro de movimentação de entrada e saída do estoque deve ser criado no momento em que uma nota fiscal de entrada é recebida e quando uma nota fiscal de saída é emitida.
- Caso uma nota fiscal de saída seja cancelada, deve haver um novo registro de movimentação para cada item que retornou ao estoque.
- Etc.....
Controle de Pedidos de Venda
- A abertura de um novo pedido de vendas deve ser possível com um único toque do cursor do mouse e também por uma combinação de teclas SHIFT-CTRL-N.
- Ao abrir o formulário de pedido de vendas, o cursor deverá focar no campo que deve receber a informação sobre qual é o cliente que está fazendo o pedido.
- Ao informar qual é o cliente que está fazendo o pedido, o vendedor deve poder digitar o código do cliente, parte do nome pelo qual ele é mais conhecido. Se o valor digitado for ambíguo, ou seja, coincidir com vários clientes, o sistema deverá mostrar os vários clientes que correspondem ao critério que foi digitado.
- Após selecionar o cliente, o sistema deverá preencher automaticamente os campos de vendedor que o atende, sua razão social, CNPJ, endereço que sairá na nota fiscal, etc (aqui a relação deve ser completa, não use etc em requisitos). O objetivo é que o vendedor possa conferir se os dados cadastrais estão corretos.
- Os campos de cadastro devem ser visíveis para os vendedores mas não podem ser alterados por eles.
- Se houver necessidade de alterar a forma de recebimento, o campo de forma de recebimento deve ser alterável.
- A inserção de um novo item no pedido deve possível através de um único toque no mouse ou através da combinação de teclas SHIFT-CTRL-T.