Como preparar os requisitos de um projeto de software

O que são requisitos claros e o que devem permitir

Preparar os requisitos de um projeto de software significa definir o que a empresa precisa que o sistema faça, em que condições deve funcionar e como será possível verificar se responde ao que foi pedido. Para isso, é necessário compreender os processos e os problemas que se pretendem resolver, antes de escolher funcionalidades. Quanto mais claras forem estas necessidades, mais fácil será para quem desenvolve, utiliza e decide interpretar o projeto da mesma forma e comparar as propostas recebidas.

Como já abordámos no artigo sobre software à medida, definir os requisitos é uma das etapas importantes antes de avançar com o desenvolvimento. Mas como passar de uma necessidade genérica, como «gerir os pedidos de forma mais eficiente», para uma descrição concreta do que se espera do sistema? É precisamente essa diferença que permite avaliar se uma solução responde ao que a empresa realmente precisa.

Começar pelo problema

É comum começar um projeto com uma lista de funcionalidades, mesmo quando o problema que se pretende resolver ainda não está completamente definido. Pedir "uma aplicação para os técnicos" diz pouco sobre o que está a falhar. Dizer que os pedidos de assistência se perdem entre departamentos, que alguns clientes ligam duas vezes para saber o estado e que ninguém sabe ao certo quantos pedidos estão por resolver descreve o problema e deixa a quem desenvolve a liberdade de propor a melhor forma de o resolver.

Antes de definir o que o software deve fazer, é importante perceber como funciona o processo atual. Onde surgem os atrasos? Que informação se perde? Quem é afetado e com que frequência? Também vale a pena perceber o que acontece nas situações menos habituais, como um pedido urgente, um cliente com condições especiais ou um documento que chega incompleto. São muitas vezes estes casos que revelam necessidades que não tinham sido consideradas inicialmente.

De necessidade a requisito: um exemplo

Imagine uma empresa de assistência técnica que identifica uma necessidade: ter controlo sobre os pedidos. Escrita assim, é um objetivo, e qualquer proposta pode cumpri-lo de maneiras muito diferentes. Ao transformar essa necessidade em requisitos, a empresa pode definir que cada pedido deve ter um estado e um responsável, que os técnicos devem conseguir registar intervenções no telemóvel, mesmo sem ligação à internet, e que os clientes devem receber uma notificação quando o estado do pedido muda. A informação registada sem ligação deverá ser sincronizada assim que a ligação for restabelecida.

Também é importante definir como se verifica se o requisito foi cumprido. Por exemplo, se todos os pedidos devem ter um responsável, pode estabelecer-se que o sistema não permite concluir o registo de um novo pedido sem essa atribuição. Este é um comportamento concreto que pode ser testado antes de a solução ser aceite. Se os requisitos ficarem em "gerir os pedidos de forma eficiente", três empresas podem apresentar três propostas com âmbitos e valores muito diferentes, e a empresa só descobre as diferenças quando o projeto já começou.

Que tipos de requisitos vale a pena considerar

Além do que o sistema faz, os requisitos devem dizer com que dados trabalha e com que outros sistemas comunica. Se o novo software vai receber informação do CRM ou enviá-la para a faturação, é útil definir que dados circulam, em que sentido e com que frequência, como explicámos no artigo sobre como escolher a forma de integrar sistemas empresariais.

Há ainda condições de utilização que não devem ficar por definir. O software será utilizado apenas no escritório ou também no terreno? Precisa de funcionar em dispositivos móveis? Quem pode consultar ou alterar determinada informação? Estas decisões influenciam a forma como a solução é desenvolvida.

Também importa considerar o desempenho e a continuidade do serviço, sobretudo quando o sistema suporta processos essenciais. A documentação necessária para manter e evoluir a solução deve ser considerada nesta fase, como explicámos no artigo sobre o que deve ficar documentado num projeto tecnológico.

Prioridades e limites do projeto

Nem todos os requisitos têm a mesma importância. Distinguir o que é essencial para o funcionamento do processo daquilo que é desejável ajuda a estabelecer prioridades e a definir o que deve ser desenvolvido primeiro.

É igualmente importante identificar o que fica fora do âmbito do projeto, caso contrário, uma funcionalidade que a empresa considerava incluída pode não estar contemplada na proposta, o que dá origem a custos adicionais, atrasos ou alterações durante o desenvolvimento.

Quem deve participar na preparação

Os requisitos não devem ser definidos apenas pela gestão ou pela equipa técnica. Quem utiliza o processo diariamente conhece dificuldades e exceções que podem passar despercebidas a quem toma as decisões. Por outro lado, os responsáveis pelo negócio ajudam a estabelecer prioridades, enquanto a equipa técnica identifica limitações e necessidades de integração com os sistemas existentes. Antes de pedir propostas, é útil percorrer algumas situações reais com os intervenientes e confirmar se os requisitos descrevem adequadamente o que acontece em cada uma.

Onde a InovaDigital pode contribuir

A InovaDigital desenvolve software à medida e soluções de integração de sistemas para responder a necessidades específicas das empresas. Quando as necessidades estão bem definidas, torna-se mais fácil perceber as funcionalidades necessárias, como devem comunicar com os sistemas existentes e as soluções fazem sentido para a operação da empresa.

Por onde começar a escrever os requisitos

Para começar, escolha um dos processos que pretende melhorar e descreva o problema atual, quem é afetado e o resultado que espera alcançar. A partir daí, identifique o que o software terá de fazer para responder a essa necessidade e como poderá verificar se funciona como previsto.

Este exercício, realizado com quem conhece e utiliza o processo, ajuda a transformar expectativas em requisitos concretos e é também uma forma de preparar melhor o pedido de proposta, reduzir interpretações diferentes e estabelecer uma base mais transparente para o desenvolvimento.