O Que São e Para que Servem os Requisitos de Software

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:

1. 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.
2. 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.
3. ser testável, a descrição do requisito servirá para validar se o software foi desenvolvido de acordo com o que foi proposto.
4. 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

1. Enumere os requisitos para que seja fácil referencia-los.
2. 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.
3. Se o requisito ficar muito complexo tente dividi-lo em partes menores.
4. 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.
5. 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

1. Dados um código de produto, o sistema deve informar a quantidade de itens disponíveis para venda.
2. Ao confirmar um pedido, o sistema deve diminuir a quantidade de itens disponíveis para venda dos itens que foram vendidos.
3. 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.
4. 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.
5. 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.
6. Caso uma nota fiscal de saída seja cancelada, deve haver um novo registro de movimentação para cada item que retornou ao estoque.
7. Etc.....

Controle de Pedidos de Venda

1. 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.
2. 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.
3. 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.
4. 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.
5. Os campos de cadastro devem ser visíveis para os vendedores mas não podem ser alterados por eles.
6. Se houver necessidade de alterar a forma de recebimento, o campo de forma de recebimento deve ser alterável.
7. 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.