Motivação para Análise de Sistemas

O PMI classifica o projeto como sendo um esforço temporário para criar um produto, serviço ou resultado exclusivo.

Agora pense na aplicação deste conceito para a sua vida[...]pensou?

Então, se você se esforçou um pouco já deve ter entendido que esta definição se aplica a qualquer atividade. Desde a construção de uma ponte, o projeto de um carro ou o desenvolvimento de um software. Até para atividades mundanas como cursar uma graduação, se preparar para uma prova ou planejar um feriado. Toda a atividade que não é repetitiva (ou sistêmica, se preferir) pode ser entendida como um projeto, com maior ou menor duração, custo e/ou escopo.

É nesse ponto que apresento a você, caro leitor, o "triunvirato" do projeto (com a qualidade de seu projeto sendo diretamente afetada pela alteração de qualquer uma dessas três dimensões).

Não preciso de explicar a ninguém o que venha a ser tempo e custo, né? Agora escopo, essa palavrinha nem sempre é entendida corretamente.

O bom dicionário da linha portuguesa define...

Agora aplicando esse significado a um projeto, podemos dizer que escopo é a descrição detalhada do projeto, e para isso temos que determinar as necessidades do cliente a fim de atingir o objetivo do projeto ou, coletar os requisitos do projeto.

Dá uma olhada no projeto de construção desse balanço, "mano, que medo"

Aí eu te pergunto, onde a merda do problema começou? Ah queridão, olha só o que o cliente queria (a última figura, se você tá perdido) e o que ele explicou (a primeira figura). Claramente o início do problema já se dava no levantamento dos requisitos do projeto. E só para você não ficar achando que, ah é uma figurinha, ele tá exagerando[...] Em um artigo publicado na revista Engenharia de Software de 14/06/2010 é demonstrado que 55% dos erros no desenvolvimento de um software são inseridos na fase análise de requisitos (Tabela 1).

Além disso, a última coluna da tabela mostra como varia o custo de correção dos erros encontrados em projetos relativos ao estado de implementação, e o crescimento é exponencial.

Isso nos mostra a necessidade de fazer uma coleta de requisitos com a maior assertividade possível a fim de evitar ambiguidades ou pontos que não foram colocados pelo nosso querido cliente. O trabalho consiste em identificar, quantificar, definir, priorizar e classificar os principais problemas que o futuro software deverá resolver. O problema é quando ele o cliente não sabe o que quer, aí que o problema do analista/desenvolvedor começa. Porque o cliente não pede nada com precisão, mas quer precisamente tudo, e como um software não é um prédio onde é visível o trabalho hercúleo que aquela alteração vai exigir, o cliente acha que é só fazer meia dúzia de malabarismo com comandos e está resolvido. Isso quando ele NÃO SABE MESMO o que quer.

o cliente não pede nada com precisão, mas quer precisamente tudo

O desenvolvedor deve estar preparado para fazer a abordagem correta com cada cliente e isso exige um bocado de experiência. Conheço poucos desenvolvedores com problemas de caráter técnico, todos são ótimos com códigos e aplicam técnicas elaboradas de desenvolvimento, mas quando se trata em lidar com pessoas há, a maioria roda.

Isso é porque as faculdades não têm costume de ensinar sobre técnicas de análise e levantamento de requisitos muito por falta de tempo (outras matérias técnicas têm uma exigência de carga horário muito maior) ou dá dificuldade em trazer profissionais com esse know-how para dentro da sala de aula.

Mas aí, independente de todos os problemas e dificuldades ainda é obrigação sua do desenvolvedor fazer com que o software funcione de acordo com os desejos mais profundos, obscuros e incompreendidos do cliente.

Então [...] FAÇA DIREITO.

Fontes:

ÁVILA, Ana Luiza; SPÍNOLA, Rodrigo Oliveira. Artigo engenharia de software: introdução à engenharia de requisitos. Disponível em: http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034 Acesso em: 02 de abril. 2017

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML: um guia prático para modelagem de sistemas orientados a objetos através da linguagem de modelagem unificada. [S.l.]: Campus, [20--?]. v. 1.

FALBO, Ricardo de Almeida. Engenharia de requisitos: notas de aula. 1. ed. Vitória, [201-]. 187 p. v. 1.

MACHADO, Felipe Nery. Análise e gestão de requisitos de software: onde nascem os sistemas. 2. ed. [S.l.]: Érica, [201-]. xx p. v. 1.

PROJECT MANAGEMENT INSTITUTE. Global standart. Um guia do conhecimento em gerenciamento de projetos: guia PMBOK. 5. ed. Pennsylvania: PMI Book Service Center, 2013. 568 p. v. 1.