PauloMotta.pro

Quando começamos a estudar desenvolvimento de sistemas somos apresentados à programação de computadores. Como tudo ainda é muito novo, dificilmente pensamos sobre os motivos de programar um computador. Há alguns anos, em meados dos anos 80, quando se deu o estouro dos computadores pessoais, estes eram comercializados sob a propaganda “você mesmo pode fazer seus programas.” O que depois descobriamos é que para usar um computador, diferente do que acontece hoje, você precisava aprender a programar. Não havia muito o que fazer com aquela máquina fantástica se você não programasse, não haviam muitos programas prontos, não haviam manuais claros, nem internet.

Atualmente, o desenvolvimento de sistemas evoluiu muito e chegou ao artesanato de software (embora algumas pessoas preguem a engenharia…) o que também nos leva a desenvolver sistemas maiores e aí começamos a ter problemas com nossos clientes e usuários. Isto porque para fazer um sistema corporativo não podemos simplesmente sentar e sair programando. Precisamos identificar o que deve ser feito. O primeiro passo é identificar o problema, em seguida precisamos descrever o problema detalhadamente para então, tendo vislumbrado a solução do problema, consultar o nosso cliente/usuário para listar tudo que deve fazer parte do sistema (assumindo que a solução do problema realmente é um sistema.)

Essa lista que descreve o que deve estar no sistema é a lista de requisitos. Basicamente existem duas categorias principais de requisitos:

1. Requisitos Funcionais – como o próprio nome sugere, representam as funcionalidades do sistema. Cadastros e relatórios são exemplos típicos de requisitos funcionais. Outra dica é que estão diretamente relacionados a atingir o objetivo organizacional do cliente. Por exemplo, segurança nas transações não tem influência direta sobre o objetivo organizacional, sejam seguras ou não, se as transações estiverem programadas elas serão executadas.
2. Requisitos Não-Funcionais – são os itens de software e/ou hardware que devem dar suporte aos requisitos funcionais. Esta é basicamente uma simplificação, dentro dos requisitos não-funcionais também podemos incluir características de desempenho, qualidade, tempo de resposta do sistema e necessidades de acessibilidade. Continuando o exemplo das transações seguras, aqui não importa como as transações são programadas e sim como fornecer a segurança necessária, se possível de forma transparente.

Existem muitos livros sobre o assunto, embora ainda não se tenha chegado a um consenso real sobre o que, como e de que forma identificamos e documentamos os requisitos.

Para fins didáticos costumo simplificar e dividir da seguinte forma:

• Requisitos Funcionais – para cada um deles deve existir pelo menos um Caso de Uso, servem também como uma lista que nos mostra o andamento do desenvolvimento do sistema, o percentual de itens já desenvolvidos até o momento.
• Requisitos Não-Funcionais -  representam os itens técnicos e de infraestrutura que vão guiar as decisões sobre a arquitetura do sistema e portanto não têm um artefato específico associado. Em geral são trabalhados pelo arquiteto do sistema.

Dadas as simplificações, costumo então trabalhar os requisitos no formato de lista, isso facilita até mesmo para identificarmos as prioridades e as dependências. Tipicamente os cadastros básicos precisam ser feitos imediatamente para dar apoio as pricipais regras de negócio.

Na maior parte dos livros sobre engenharia de requisitos são apresentados documentos extensos e complexos para relacionar os requisitos, o que percebi na prática de desenvolvimento de sistemas corporativos é que esse formato de documento complexo não é ágil o suficiente para acompanhar o dinamismo dos requisitos, sim, porque eles mudam ao longo do desenvolvimento do projeto. Quando dizemos que as necessidades do cliente vão mudando ao longo do projeto, estamos falando dos requisitos funcionais que vão sendo adequados as dinâmicas impostas pelo mercado.

Acredito que os requisitos devam ser apresetados de forma simples, e não em um documento a parte da documentação do projeto. Uma lista funciona bem, em casos em que o requisito é muito complexo cabe um parágrafo para descrição, se isso não for suficiente possivelmente aquele requisito pode ser dividido em mais de forma a trabalhar uma quantidade maior de requisitos mais simples.