Requisito/Análise é o mais importante?

Na faculdade eu “aprendi” (!?) que a parte mais importante de um software é o Requisito. Também com uma vital importância encontra-se a Análise que realizamos baseada nos requisitos para chegarmos a um projeto de Software bem modelado, detalhado e definido. Após essa fase, dizem os “professores” (!?), teremos um conjunto de artefatos que possibilitará aos programadores apenas transcrever os requisitos em código. Feito isso, temos o nosso Software funcionando.

Bem, nunca é demais frisar que isso (o parágrafo a cima) não funciona. A (?) fase de análise (?) ou a Identificação dos requisitos, é apenas uma exploração. Trata-se de um pequeno passo na CONSTRUÇÃO (Código!!) de um software. Pequeno mas importante passo, é claro. O fato é que a única forma correta de validarmos os requisitos de um software é codificar o software e entregar uma parte dele para o cliente usar. Dessa forma sim, saberemos se estamos no caminho certo, e se os requisitos são aqueles mesmos que foram identificados.

Temos que entender que Codificar também é modelar (vide TDD). E precisamos aprender de uma vez por todas que modelagem gráfica (modelos e diagramas UML) ajuda na comunicação da equipe, ajuda a modelar também, mas que só poderá ser dada como válida ou correta após a implementação da mesma, do contrário é tudo especulação, é tudo desenho e ainda é uma abstração incompleta de um sistema.

Existem mais coisas importantes num ciclo de desenvolvimento de um software além do código… mas, quando vemos um software funcionando, a única certeza que temos é que ele foi realmente codificado por algum programador. Além disso, um software em produção está apenas iniciando a sua vida, então, mesmo tendo a melhor documentação do mundo, se o código estiver podre e mal cheiroso, essa documentação não irá adiantar de nada. Mas, se não tivermos nenhuma linha de documentação ou especificação desse produto mas o seu código for legível, coeso, expressivo, organizado, padronizado e possuir uma boa cobertura de testes, tenha certeza de que manter esse software será algo simples e divertido.

A verdade é que não existe, ou não deveria existir, uma separação entre as fases de requisito/análise e desenvolvimento. Vejo que é justamente tentando separar essas fases é que caimos numa perigosa cascata.