Esse artigo apresenta a granularidade de requisito de software. Descreve a sua aplicabilidade no desenho da solução a partir de uma necessidades de negócio em termos do roadmap de produto até a priorização de histórias de usuário no backlog das equipes de implementação. E revela a importância prática dessa aplicabilidade em entregar software atendendo aos objetivos do negócio.
Por que eu devo ler este artigo:
Requisitos de software, sejam em um novo produto ou em novas features para a próxima release, são identificados e descritos em diferentes graus de expansão; desde os requisitos mais «grossos» até os mais «finos». Como na classificação em grãos, os requisitos podem ter diferentes granularidades.
Os diferentes propósitos para os quais descrevemos requisitos exigem níveis de refinamento específicos e adequados a esses propósitos. Refinar requisitos antes do tempo é perda de tempo e o contrário transfere decisões sobre o software para pessoas que não tem toda a informação necessária para tomar as decisões necessárias. Isso sem contar com o potencial de novas descobertas e insights ao refinar os requisitos existentes.
Este artigo apresenta uma discussão de nível fundamental sobre três níveis de granularidade para classificação de requisitos funcionais conforme os seus objetivos sejam classificados como agregador, usuário ou subfunção.
Artigo publicado na RE Magazine
Acesse aqui para ter acesso ao artigo original (em inglês) de Carlos Eduardo Vazquez e Guilherme Siqueira Simões, publicado na Requirements Engineering Magazine – The magazine for ER professionals from IREB.
Versão em português na FATTO em Foco
Embora o conceito de nível de granularidade do RFU seja simples, na prática se percebe que muitos analistas de requisito não estão atentos a isto quando elaboram suas especificações.
Levar isso em consideração ajuda a definir o nível adequado de esforço nas tarefas de licitação e análise de requisitos, bem como entregar especificações de melhor qualidade.
Os requisitos do usuário para um software possuem duas dimensões: funcional e não funcional. O requisito funcional do usuário (RFU) descreve o comportamento de uma função do sistema (ou componente ou serviço) e especifica o que o software deve fazer em termos de tarefas e serviços aos usuários e abordando: transferência de dados, transformação de dados, armazenamento e recuperação de dados. O requisito não funcional (RNF) é a maneira em que as funções serão entregues aos usuários e podem abordar aspectos técnicos, de qualidade, ambientais e organizacionais.
Como exemplo, suponha que em um sistema de autoatendimento bancário seja possível encontrar as seguintes especificações funcionais:
- Movimentar a conta corrente.
- Transferir um valor de uma conta corrente a outra.
- Validar o cartão e senha do cliente.
- Garantir que o total de movimentações da conta corrente do cliente não exceda a R$5.000.
Embora estes quatro exemplos sejam casos válidos de RFU, é possível perceber que o nível de detalhe (ou granularidade) varia. Uma especificação de requisitos costuma apresentar diferentes níveis de granularidade, que podem ser classificados em três níveis conforme seu objetivo:
- Agregador: é um requisito de alto nível, por exemplo, relacionado a um processo de negócio ou um grupo de tarefas de um ou mais usuários (granularidade do exemplo 1).
- Usuário: é um requisito relativo a uma tarefa do usuário proporcionada pelo software. Ao final desta tarefa o usuário alcança seu objetivo, está satisfeito, não é necessário fazer mais nada (granularidade do exemplo 2).
- Subfunção: é um conjunto de passos intermediários ou regras de uma ou mais tarefas do usuário (este é o caso dos exemplos 3 e 4).
Pode-se dizer que há dois momentos chave no qual uma especificação de requisitos é necessária: oferecer uma visão ampla do software (e talvez ainda não detalhada) e oferecer uma visão detalhada do software (de uma parte ou do seu todo).
O primeiro caso é muito comum nas etapas iniciais do projeto. O objetivo neste momento é obter um acordo sobre o escopo, ainda de forma ampla e preliminar, para, por exemplo: planejar um projeto, obter uma estimativa de ordem de grandeza de custo ou prazo, ou efetuar uma análise de viabilidade.
O RFU especificado no nível agregado busca estabelecer que áreas funcionais e processos de negócio estão sujeitos à informatização para atender às necessidades de negócio. O custo para obter informação e especificá-la em um nível mais detalhado pode significar desperdício de esforço para detalhar o que ainda não é necessário. É também possível encontrar RFU nos níveis de usuário ou subfunção; isto não é necessariamente um erro. Para obter uma melhor compreensão das partes interessadas sobre o escopo ou diminuir a incerteza em uma estimativa, pode ser interessante aprofundar o nível de granularidade dos RFU mais críticos, mas não de todos.
No segundo caso, o RFU mais adequado é o com objetivo de usuário, pois é o único nível que oferece uma visão sem ambiguidade do escopo do software. Não por acaso, este é o nível usado por todos os métodos de medição funcional de software aderente à norma ISO/IEC 14143, como a Análise de Pontos de Função. É possível que também contenha RFU no nível agregado, mas apenas quando as tarefas abordadas pelo requisito estejam claras a todos as partes interessadas.
A definição do requisito no nível de subfunção é adequada quando o comportamento especificado é compartilhado entre várias tarefas realizadas pelo software para seus usuários. Isto torna mais fácil a manutenção da especificação de requisitos, já que a redundância de informação é diminuída por não ter que se descrever um conjunto de passos ou regras mais de uma vez. Isto reduz a chance de inconsistências e melhora a organização da especificação de requisitos e consequentemente sua legibilidade.
Embora o conceito de nível de granularidade do RFU seja simples, na prática se percebe que muitos analistas de requisito não estão atentos a isto quando elaboram suas especificações de requisitos. Levar isso em consideração ajuda a se definir o nível adequado de esforço nas tarefas de elicitação e análise de requisitos, bem como entregar especificações de requisito de melhor qualidade.
Webinar
Assista ao Webinar realizado por Guilherme Siqueira Simões sobre o assunto.
