Não é fácil explicar, mas problemas com “requisitos” seguem respondendo por grande parte das falhas e atrasos em projetos. Um estudo recém publicado pelos Capítulos Brasileiros do PMI mostra que entre os principais problemas enfrentados, 62% refere-se à mudanças em requisitos e 60% tem a ver com a (má) definição destes. Quando olhamos especificamente para projetos do setor de TI, os números sobem para 83% e 81%, respectivamente. Publiquei no Graffiti um artigo comentando o estudo. Aqui vou apresentar uma idéia que pode ajudar a reduzir os problemas com requisitos.
Trata-se de uma idéia “requentada”. Há 5 anos ela foi o núcleo do primeiro trabalho que apresentei em público, no Seminário de Gestão de Projetos promovido pela SUCESU-SP e pelo PMI. Requentada não, amadurecida. Ela é uma das partes principais de meu trabalho para Formação de Analistas de Negócios. Além da experiência, utilizei os trabalhos de Karl Wiegers e de Suzanne e James Robertson para chegar no desenho que apresento abaixo. Neste último livro, publicado em 2005, conheci o Volere e o Requirements Knowledge Model, propostas que reforçaram minha idéia sobre a Estruturação de Requisitos.
Para começar, vale a pena revisar a definição de requisitos e seus tipos. Em levantamentos informais que realizo nos cursos e oficinas descobri que a definição mais comum para requisitos é: “uma necessidade do cliente ou usuário”. Correta, mas não explica bem a amplitude e heterogeneidade dessas “necessidades”. Uma das melhores definições para requisitos foi criada por Ian Summerville e Pete Sawyer em Requirements Engineering – A Good Practice Guide :
Requisitos são… uma especificação do que deve ser construído. São descrições de como o sistema deve se comportar, ou uma propriedade ou atributo do sistema. Podem ser uma restrição ao processo de desenvolvimento.
O diagrama acima ilustra todas essas possibilidades. Começamos pelos Objetivos do Negócio. Normalmente eles são os primeiros requisitos que recebemos. Infelizmente, também são os primeiros que esquecemos no decorrer de um projeto. Mas isso fica para outro artigo. Esses objetivos podem ser “quebrados” em objetivos mais específicos, ou metas, que vinculamos diretamente a Processos de Negócio. Por exemplo: “reduzir em 10% os custos de vendas é uma meta colocada para o processo de vendas”; um requisito que deve ser atendido pelo projeto. O diagrama também mostra que as Regras de Negócio são vinculadas aos Processos de Negócio. O destaque se faz necessário porque é comum a confusão entre requisitos e regras de negócio. E se torna ainda mais relevante quando percebemos que as regras são muito mais voláteis (passíveis de mudanças) do que os requisitos. Exemplificando: “nas operações de vendas o sistema deve permitir a aplicação de um desconto sobre o valor total da transação”. “O desconto máximo de 10% só pode ser aplicado em vendas superiores a R$ 100,00”. A primeira frase é um requisito funcional. A segunda, uma regra de negócio. A chance da segunda mudar é muito maior.
Na seqüência temos os Requisitos do Usuário, solicitações que podemos quebrar em vários Requisitos Funcionais. Esta classificação, originalmente proposta por Karl Wiegers , gera uma certa confusão. Um Requisito de Usuário é de alto nível. Por exemplo: “Emitir uma Nota Fiscal”. Reparem no diagrama acima: um Requisito do Usuário pode se transformar em um Caso de Uso. Pode. Acontece que nem todo requisito é incorporado ao Escopo do Projeto; Foi uma idéia que, por algum motivo qualquer, foi abandonada em determinado momento.
Os Casos de Uso nos ajudam a agrupar logicamente os Requisitos Funcionais. Estes são, portanto, as “menores unidades de solicitações” dos usuários ou clientes. Existe muita confusão neste ponto porque o nível de detalhamento dos requisitos funcionais varia muito, entre organizações e até mesmo entre projetos de uma mesma empresa. Pior: o nível pode variar até mesmo em um mesmo projeto. Não há receitinha mágica aqui. Fábricas normalmente optarão pelo maior nível de detalhamento possível. Equipes mais experientes (ou exigentes) brigarão por espaço para sua “criatividade”, ficando satisfeitas com requisitos definidos em nível mais alto. Em um processo iterativo e incremental, não raro os analistas descobrirão que alguns requisitos funcionais, dada sua superficialidade, se transformarão em requisitos de usuário (e, consequentemente, em novos Casos de Uso), exigindo assim seu maior detalhamento.
Por fim, no lado direito do diagrama, temos os Requisitos Não-Funcionais. Apenas para fins de ilustração aparecem duas especializações: Arquitetura (Tecnológica) e Restrições. Dependendo da organização ou projeto, essa estrutura pode ser modificada de forma a receber outros conjuntos específicos de requisitos não-funcionais. Este grupo e os casos de uso dão forma ao Escopo do Projeto.
.:.
O diagrama acima ilustra o núcleo de uma Base de Conhecimentos para um projeto específico. Gosto de apresentá-la como uma forma de se ver, analisar, desenvolver e gerenciar requisitos. Em projetos de médio e grande porte, ou ainda em empresas que lidam com vários projetos simultâneos, a criação desta base como um banco de dados pode significar um grande avanço em todas as atividades de engenharia de requisitos (desenvolvimento e gerenciamento de requisitos). Na parte 2 deste artigo apresentarei outra parte da base, que trata especificamente dos atributos dos requisitos.Quando discutimos ferramentas para o desenvolvimento e gerenciamento de requisitos, como aconteceu na última oficina, sempre surge a questão sobre o melhor front-end para esta base de conhecimentos. Costumo dizer que nunca vi um front-end melhor do que uma ferramenta CASE, aquela que uso para elaborar os diagramas UML. Há muito tempo vi uma versão do Together que implementava algo parecido. Há mais tempo ainda participei do desenvolvimento de um add-on para o Rational Rose (a implementação foi feita, em VB(!), pelo grande Nelson Ponce de Leon). Simplifica muito o trabalho do analista: um clique com o botão direito do mouse em qualquer elemento UML apresentava a opção Requisitos. Lá podíamos inserir novos ou então ver todos os requisitos vinculados a determinado artefato. A rastreabilidade era total: íamos dos casos de uso e atores até métodos e propriedades de determinada classe. Infelizmente a ferramenta ficou por um tempo esquecida. Felizmente (!) alguns colegas do grupo Analistas de Negócios.br estão trabalhando no desenvolvimento de uma nova versão. Não é difícil perceber que um banco de dados faz muito mais sentido do que documentos Word, planilhas, matrizes imensas (olá Requisite Pro!), post-its ou “papel de pão”. A próxima parte do artigo tentará reforçar isso, falando de análise e rastreabilidade total dos requisitos. Inté.
.:.
Bibliografia:
- Software Requirements
Karl Wiegers. Microsoft Press (1999). - More About Software Requirements
Karl Wiegers. Microsoft Press (2006). - Requirements-Led Project Management
Suzanne Robertson e James Robertson. Addison-Wesley (2005). - Requirements Engineering – A Good Practices Guide
Ian Sommerville e Pete Sawyer. Wiley (1997).
