4. Dificuldades Comuns com Requisitos

4. Dificuldades Comuns com Requisitos

1. 4.1. Comunicação

   • uma das dificuldades mais comuns ao trabalho de requisitos é conseguir comunicar-se de forma clara, seja com as partes interessadas, seja com os demais membros da equipe do projeto.
   • Deve-se, portanto, conhecer aos demais elementos na comunicação e considerá-los para que a comunicação seja efetiva:
     • Emissor: alguém que emite a mensagem. Pode ser uma pessoa, um grupo, uma empresa, uma instituição.
     • Receptor ou destinatário: a quem se destina a mensagem. Pode ser uma pessoa, um grupo ou mesmo um animal, como um cão, por exemplo.
     • Código: a maneira pela qual a mensagem se organiza.
     • Canal de comunicação: meio físico ou virtual que assegura a circulação da mensagem, por exemplo, ondas sonoras, no caso davoz.
     • Mensagem: é o objeto da comunicação, constituída pelo conteúdo das informações transmitidas.
     • Referente: o contexto, a situação à qual a mensagem se refere. O contexto pode se constituir na situação, nas circunstâncias de espaço e tempo em que se encontra o destinador da mensagem.

2. 4.2. Acesso às partes interessadas

   • Muitas vezes o trabalho de requisitos acontece sem que seja permitido ao analista de requisitos interagir diretamente com algumas partes interessadas. Seja por falta de disponibilidade de tempo ou interesse da parte interessada, por questões políticas, sociais, culturais ou qualquer outro motivo.
   • Se o analista de requisitos não tiver poder ou autoridade para vencer essa barreira de acesso às partes interessadas, é fundamental a participação do gerente de projetos (ou alguém com mais autoridade) para ajudar na busca de uma solução que minimize esses riscos no trabalho de requisitos. O ideal é trabalhar para que a presença do analista seja desejada por aqueles que podem criar essa barreira.

3. 4.3. Indecisões/Indefinições do usuário

   • A dificuldade de o usuário em saber o que quer, ou, então, de se expressar corretamente quanto ao que deseja, é uma percepção de praticamente todos os analistas de requisitos com alguns anos de experiência. Varia a intensidade com que ocorre, desde a parte interessada que não sabe expressar sua necessidade até aquela que expressa a necessidade errada.
     • Para essas partes interessadas, deve-se também buscar um método mais adequado de obtenção de informação. Entrevistas, por exemplo, talvez não sejam tão produtivas.

4. 4.4. Requisitos implícitos ou não ditos

   • Caso comum na experiência profissional de muitos analistas de requisitos é achar que fez um bom trabalho de requisitos: ouviu as partes interessadas, documentou e confirmou suas necessidades, especificou uma solução, apresentou e a validou com todos e obteve sua aprovação.
     • Haveria alguma forma do analista tomar conhecimento dessas necessidades implícitas? Não há nenhuma ferramenta ou técnica que garanta que a especificação de requisitos está completa. Por isso, a dificuldade em lidar com necessidades implícitas.
       • O que se pode fazer é buscar estratégias paraminimizar essas surpresas.

5. 4.5. Mudanças

   • Uma reclamação muito comum entre alguns analistas de requisitos é a frequência alta de mudanças em requisitos. E, de fato, toda mudança acarreta algum ônus ao trabalho já feito. Mudanças deveriam existir para aumentar (ou preservar) o valor do projeto.
     • No entanto, quanto maior o tamanho do projeto, maior tende a ser sua duração e, consequentemente, maior a incidência de mudanças.

6. 4.6. Conflitos

   • Quanto maior a quantidade de partes interessadas em um projeto, maior o potencial de conflitos de interesses, necessidades e informações. Os conflitos podem ser de várias naturezas: de ordem pessoal, profissional, político, familiar etc.
     • Requisitos de partes interessadas que são inviáveis de atender simultaneamente.
     • Informações inconsistentes sobre como funciona um processo de negócio. As explicações de duas partes interessadas sobre o mesmo processo não se encaixam.
     • Solicitações de partes interessadas fora do escopo do projeto.
     • Partes interessadas que são adversárias, antipáticas ou hostis umas às outras.
     • Falta de sintonia entre as áreas de negócio envolvidas. Cada área está preocupada apenas com o seu contexto e interesse, sem se importar com as demais.

7. 4.7. Resistência à mudança

   • Todo projeto de software implica em algum tipo de mudança para as partes interessadas. Novidades frequentemente geram temor e/ou preocupação nas pessoas. Manter a zona de conforto é a reação natural da maioria, por isso éfrequente encontrar resistência a mudanças.
     • A primeira coisa que o analista deve buscar é compreender o impacto que o projeto acarretará a cada parte interessada. Para aquelas onde já se sabe que o impacto será negativo, deve-se buscar meios alternativos para obtenção de informação que não dependa da interação direta com elas.

8. 4.8. Parte interessada não domina seu negócio

   • Apesar de ser uma situação estranha, é comum ouvir essa reclamação de muitos analistas de requisitos. Embora longe de ser desejável, isso pode ocorrer por vários motivos

9. 4.9. Parte interessada não lê a especificação de requisitos

   • Como visto no Capítulo 2, a especificação de requisitos é o contrato da equipe de desenvolvimento com o cliente. Ela deve comunicar ao cliente tudo que será entregue (logicamente, satisfazendo todas as suas necessidades) e o cliente deve conseguir compreendê-la e dar sua aprovação para que o trabalho no projeto possa seguir adiante.
     • É importante tentar entender as razões pelas quais não há interesse das partes interessadas na especificação de requisitos. E alguns motivos são.
       • Partes interessadas não compreendem a importância da especificação e entendem o papel de revisão como mera burocracia.
       • A estratégia adotada de apresentação da especificação para aprovação pode estar errada.
       • Parte interessada já está (ou acha que está) ciente do que será entregue e não vê necessidade de revisar a especificação, pois já sabe o que está contido ali.

10. 4.10. Partes interessadas insaciáveis com requisitos

    • Aqueles com alguma experiência notam que os requisitos possuem uma propriedade parecida com os gases: inicialmente não têm forma e volume bem definidos e tendem a ocupar todo o espaço disponível (neste caso, recursos do projeto). Essa característica expansiva dos requisitos torna a gestão do escopo de projetos um desafio.
      • Outra explicação para a característica expansiva dos requisitos é que, em muitas empresas, desenvolver software é de graça! Como assim? Na verdade, o desenvolvimento de software é uma atividade cara. Porém, para os clientes internos do desenvolvimento de software, o custo é zero: basta pedir que a TI faz.

11. 4.11. Consistência

    • Um bom trabalho de requisitos tem que resultar em uma especificação de requisitos que seja uma história bem contada: com início, meio e fim bem definidos e com todas as peças se encaixando e transmitindo com clareza a mensagem.
      • Ocorre que o trabalho de requisitos vai sendo desenvolvido de forma evolutiva; a especificação é criada e vai recebendo incrementos, melhorias e correções ao longo do tempo.
        • O conhecimento do autor da especificação vai mudando (aumentando) durante esse processo e partes da especificação elaboradas ao início podem já ter uma perspectiva diferente de partes elaboradas posteriormente.

12. 4.12. Necessidades vagas Quando se inicia um trabalho de requisitos, normalmente se encontra um cenário onde as necessidades apresentadas são mais ou menos vagas. É raro encontrar (mas não impossível) as necessidades iniciais das partes interessadas sendo expostas de forma clara e específica.

    • Encontrar uma especificação de requisitos, em tese finalizada, mas com requisitos vagos é quase sempre um sintoma de preguiça ou desatenção do autor. E, consequentemente, sua utilidade fica comprometida.

13. 4.14. Conclusão Como comentado no início, as questões apresentadas até aqui resumem boa parte das dificuldades com o trabalho de requisitos, mas não exaure a discussão. Certamente o leitor que tem alguma vivência em projetos pode relatar nuances distintas para os itens apresentados, bem como dificuldades que não foram apresentadas neste capítulo. Comente com os autores sobre essas experiências (via endereços de e-mail presentes no início do livro).

Images and files in the map