Segundo SOMMERVILLE (2011), requisitos de um sistema são as descrições dos serviços fornecidos pelo sistema e as suas restrições operacionais. Todo o detalhamento do desenvolvimento do software está descritos nos levantamentos de requisitos entre os usuários e desenvolvedor. A técnica consiste em ajudar a resolver problemas na sua elaboração final de desenvolvimento. Requisitos também é uma definição formal e detalhada de uma função do sistema. Quando o cliente ou usuário contrata a área de TI sendo o desenvolvimento interno ou externo de um projeto de software, ela precisa definir suas necessidades e desejos. Para um bom atendimento destes desejos ou necessidades, a área de TI precisa elaborar de uma forma clara, precisa e consistente um documento com as definições mais detalhada do sistema para que o cliente possa compreender e validar os requisitos. Segundo SOMMERVILLE (2011) segundo o autor, os Requisitos de Negócio, são declarações, em uma linguagem natural como diagramas de quais serviços são esperados do sistemas e as restrições sob as quais ele dever operar, os Requisitos de Sistemas, seriam os detalhamentos, as funções, os serviços e as restrições operacionais do sistema. O documento de requisitos de sistema (chamado de especificação funcional) precisa ser preciso e validado entre o cliente o desenvolvedor. Este documento deve ser definido exatamente como dever ser implementado. Todos estes processos de desenvolvimento seriam ideais para o desenvolvimento de um sistema quando é iniciado.
Às vezes por afobação do próprio desenvolvedor ou do usuário, o documento de requisitos passam despercebidos, ou às vezes sem muita relevância para as partes, deixando de “lado” este tipo de procedimento de documentação. Muitas vezes por experiência da área de desenvolvimento ou pelo convívio direto com o usuário este procedimento que muitas vezes “informal” deixa de existir entre as negociações. Estes procedimentos de conduta começam acontecer os maiores problemas entre a negociação e o desenvolvimento do software.
O processo passa para uma atividade informal e sem controle e que acabam ocorrendo durante o desenvolvimento algumas ações do tipo:
O usuário diz ao programador mais ou menos o que fazer, o programador entende mais ou menos a necessidade de desenvolvimento de um sistema e o usuário vê que não era bem isso que ele queria e por fim ele solicita uma mudança no sistema. Por fim o método informal de desenvolvimento, geram “Retrabalhos”, “Dificuldade de dar manutenção”, “Os sistemas se tornam uma caixa preta” e por fim “O sistema resolve de maneira certa o problema errado”. O cliente fica insatisfeito com a área, a área de TI não agüenta mais ouvir reclamações sobre o projeto.
E por fim estes procedimentos informais geram conflitos de desenvolvimento do software.
Segundo relatório – Chaos Report (2011) “O estudo mostrou que: quanto maior o tamanho do projeto, maior a probabilidade de fracasso”. O relatório mostrou também que uma boa prática em projetos ou o sucesso no desenvolvimento do software, os prazos precisam ser concluídos conforme a sua especificação e estar dentro do orçamento e com uma boa parte dos requisitos implementados.
Podemos verificar no gráfico 1 do relatório CHAOS a distribuição em percentual quanto ao desenvolvimento de software.
Gráfico 1 – Percentuais de Desenvolvimento de Software – CHAOS REPORT 2011.
Segundo o relatório Chãos Report (2011), este percentual de insucesso no desenvolvimento de software está distribuído da seguinte forma conforme tabela 1 abaixo:
Tabela 1 – Percentuais por tipos de insucesso no desenvolvimento de Software – CHAOS REPORT 2011
Conclusão
Podemos concluir que o documento de requisitos passa a ser um documento fundamental entre as áreas de negócios e com as áreas de desenvolvimento de software. O documento passa a ser um tipo de descritivo técnico das etapas de desenvolvimento do software entre as partes. Na falta desta documentação a tabela 1 demonstra bem que o maior percentual está relacionado em requisitos incompletos.
Depois dessas informações, podemos afirmar que realmente “apressado como cru”, afinal softwares não são feitos da noite para o dia. Eles requerem muito mais que linhas de código, necessitam que todas as etapas do processo de analise de requisitos sejam seguidas corretamente. O trabalho do desenvolvedor é árduo e requer muita atenção, deve-se definir uma metodologia a ser seguida e uma boa gestão dos requisitos no desenvolvimento do software, o comprometimento e o cumprimento das expectativas do cliente.
Referências Bibliográficas
. SOMMERVILLE, Ian, Engenharia de Software, 8ª Edição, São Paulo, Editora Pearson Prentice Hall, 2007.
. CHAOS REPORT, Site http://blog.standishgroup.com/ , acessado em 18/06/2012.