Sobre Requisitos…

 

Ao longo de minha vida, sempre comparei sistemas a pessoas. Pessoas nascem, atravessam um período atribulado e difícil (adolescência), amadurecem e um dia morrem. Sistemas também! Eles nascem, atravessam períodos em que apresentam muitos problemas (adolescência), estabilizam (maturidade) e, um dia, são retirados de operação (morrem). Assim como as pessoas, as primeiras fases do ciclo de vida de um sistema são as mais importantes. Elas vão determinar como será e como se comportará um sistema no futuro.

Um sistema “nasce” quando surge uma necessidade. Como todos já sabem, esta necessidade é, então, descrita em forma de requisitos. Recentemente, li uma pesquisa publicada pelo Gartner Consulting, que apontava como principal causa de fracassos e atrasos em projetos de TI, problemas com os requisitos de sistemas.

Em uma época, não muito distante, quando éramos analista-programador-operador-digitador-e-mais-alguma-coisa, tínhamos a oportunidade de sentar ao lado de nossos gestores e discutir/definir, quase que simultaneamente, os requisitos à medida que codificávamos e testávamos os sistemas. (que atire a primeira pedra quem nunca fez isso ou teve vontade de fazer!)

Apesar de vantajoso em algumas situações, este modelo apresentava muito mais desvantagens. Isso sem mencionar que os profissionais de sistema falavam uma linguagem própria, inteligível para o resto da organização. Surgiu, então, a necessidade de um profissional que soubesse interpretar as necessidades dos usuários e convertê-las em especificações para os analistas de sistemas. Este papel coube aos analistas de O&M inicialmente, que evoluíram para analistas de negócio. Este modelo persiste até os dias de hoje.

Ao refletir um pouco sobre a realidade de TI, neste contexto, gostaria de comentar:

  1. Escrever requisitos de sistemas não é uma tarefa fácil (tentem definir os requisitos para um sistema que resolva Sudoku, por exemplo). Faz-se necessário um profissional com este tipo de perfil e que possua habilidades específicas para este fim;
  2. Não existe uma boa notação (universalmente aceita) para a definição de requisitos. As implicações disso são enormes. Como determinar o nível de detalhamento ideal? Como escrever num só modelo, de tal forma que todos os envolvidos no projeto a compreendam? Como eliminar as ambigüidades dos requisitos? A questão fundamental na especificação resume-se ao “o que” e “como” descrever estes requisitos;
  3. Os requisitos devem descrever não só o que o sistema deve fazer, mas também o que ele NÃO deve fazer. O intuito disso é limitar, com mais precisão, o escopo do projeto;
  4.  Tão difícil quanto gerenciar um projeto é gerenciar a expectativa que este projeto gera sobre os envolvidos e a empresa. Mudanças nos requisitos quando o projeto já está em andamento, devem ser negadas ou negociadas. Se isso não for feito, corre-se o risco de se ter um projeto ad eternum;
  5. Falta uma abordagem estruturada para esta atividade. O ideal seria que sua empresa  possuísse um processo bem definido para a especificação de requisitos, que pudesse ser monitorado, medido e aprimorado;
  6. Não existe uma empatia entre os departamentos de sistemas e negócios (e isso não é uma exceção de nenhuma empresa que conheço no mercado). Constantemente reclamamos da qualidade dos requisitos que chegam até nós. Uma das soluções para este problema seria participar da elaboração destes requisitos juntamente com a área gestora e de negócios;
  7. A validação dos requisitos, com todos os envolvidos, deve ser uma atividade obrigatória para todo analista de sistemas;
  8. Acredito que o sucesso de um projeto está diretamente relacionado à clareza e qualidade de conteúdo da sua documentação inicial. Requisitos “bem escritos” aumentam as chances de um desenvolvimento com sucesso. Não basta ter uma documentação, ela também precisa ser eficaz.

 Os riscos, custos, tempo e qualidade de um sistema são diretamente proporcionais ao seu tamanho e complexidade. Em um trabalho que desenvolvi recentemente para a FIPECAFI/USP, observei que no começo de um projeto não existem muitas alternativas para validações dos requisitos de sistemas. Isso se torna um impasse e um dilema para os desenvolvedores: Como avaliar o sistema antes que os componentes-chaves sejam construídos? Depois de construído, mudanças no projeto são difíceis (se não impossíveis) de serem realizadas. Defendi, então, a utilização de protótipos para a validação desses requisitos.

One comment

  1. Um outro problema é que os requisitos muitas vezes partem de gestores dos sistemas, mas não dos usuários finais. Da mesma forma que o desenvolvedor não consegue prever todas as solicitações e necessidades do gestor, este, se não for o usuário final, não vai conseguir entender as necessidades de quem está na ponta…

    Gostar

Deixe sua opinião!

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s