Classificação e Categorização de Requisitos de Software

TODO programador, de alguma forma, trabalha com requisitos no seu dia-a-dia. Não, eu não estou generalizando.

Vamos refletir um pouco e aí você me diz se estou correto, combinado?

Como mencionei neste outro post, uma das definições para requisito é que se trata de uma condição ou capacidade requerida pelo usuário para resolver um problema ou atingir um objetivo. Mantenha isto em mente, ok?

Todo profissional deveria precisa ser organizado, principalmente um analista de requisitos. Após a obtenção dos requisitos, é necessário classificá-los e categorizá-los para que se tenha um embasamento técnico para as próximas fases do processo, principalmente a de negociação e priorização de requisitos. Desta forma, podemos classificar um requisito como:

Requisito Funcional

Definição elegante: É um requisito relativo ao resultado de um comportamento que deve ser provido por uma função do sistema.

Definição simplificada: Sem este requisito o sistema está incompleto.

Eles geralmente são subdivididos da seguinte forma:

Funcionais: São os requisitos que em sua documentação leva-se em consideração as informações recebidas, métodos que processam esta informação, ordem de execução dos métodos e como esta informação volta para o contexto do sistema.

Comportamentais: São os requisitos que em sua documentação leva-se em consideração o comportamento do sistema, como reações em determinados cenários, garantia de que ele vai reagir desta forma e o impacto que o sistema terá em seu contexto.

Dados: São os requisitos que em sua documentação leva-se em consideração informações estáticas, como dados que entram e saem do sistema ou dependências com outros sistemas ou serviços.

Costumo dizer que os requisitos funcionais são essenciais para o sistema, pois, além de influenciar no seu perfeito funcionamento, eles são solicitações explícitas dos stakeholders que devem ser desenvolvidas. Ou seja, há uma expectativa da existência desta funcionalidade por parte dos interessados no projeto, que, com certeza, serão testadas na versão final do projeto, antes do documento de aceite ser assinado.

Exemplos de requisitos funcionais:

• RF002 — Exibir os módulos do sistema de acordo com as permissões atreladas ao perfil de acesso do usuário autenticado.
• RF001 — Emitir carta de cobrança para clientes inadimplentes conforme critérios pré-estabelecidos.
• RF003 — Cadastrar ordem de serviço.

Requisito de Qualidade (Não Funcional)

Definição elegante: Um requisito de qualidade é um requisito que pertence a preocupação com a qualidade que não está presente nos requisitos funcionais.

Definição simplificada: São os requisitos que tratam daquilo que, muitas vezes, não estão visíveis ao usuário. São eles: Segurança, escalabilidade, usabilidade, performance e etc. São muitas vezes chamados de não funcionais pois o sistema pode funcionar sem eles.

Um sistema não se trata apenas de desenvolver as funcionalidades solicitadas pelos stakeholders. Além disto, precisamos nos preocupar com tudo aquilo que dará suporte a este sistema e que também seja importante para os interessados. Por exemplo, se temos um sistema com dados sigilosos, requisitos de segurança serão implementados para garantir que estes dados permaneçam sigilosos.

Exemplos de requisitos de qualidade:

• RNF001 — O sistema terá um uptime de 99,99%
• RNF002 — O sistema bloqueará o usuário após três tentativas de login sem sucesso;
• RNF003 — O sistema suportará 300 conexões simultâneas;
• RNF004 — Todas as funcionalidades do sistema estarão acessíveis com, no máximo, 3 cliques.

Requisito de Restrição

Definição elegante: Um requisito de restrição é um requisito que limita a solução além do que é necessário para atingir os requisitos funcionais e de qualidade.

Definição simplificada: É um requisito que é imposto ao projeto e que independe dos seus requisitos funcionais e não funcionais.

Todo projeto possui limitações que precisam ser respeitadas para que, por exemplo, metas sejam atingidas ou normas sejam atendidas. Desta forma, requisitos de restrições são aqueles que determinam estes limites.

Exemplos de requisitos de restrições:

• O sistema deve ser entregue até o segundo bimestre de 2017
• Entregas incrementais do sistema serão feitas a cada 15 dias
• Todas as informações do usuário devem ser excluídas do banco de dados após 5 anos de registro

Agora que entendemos como classificar os requisitos, vamos entender como categorizá-los. Para isto, existe um modelo muito famoso que é o modelo de Kano:

No gráfico de kano nós temos três tipos de requisitos:

Requisitos Encantadores (requisitos inconscientes) são aqueles que os stakeholders não esperam e quando os veem tomam uma boa surpresa. Estes requisitos, com o tempo, acabam se tornando conscientes ou subconscientes, devido ao hábito.

Requisitos satisfatórios (requisitos conscientes) são aqueles conhecidos pelos stakeholders e foram solicitados explicitamente. Quando esses requisitos foram desenvolvidos, o cliente ficará satisfeito e contente, o que é desejado. No entanto, caso não estejam, o cliente provavelmente não aceitará o produto. A satisfação do cliente vai diminuindo a cada requisito que esteja faltando. Estes requisitos podem ser levantados através de técnicas de pesquisa.

Requisitos insatisfatórios (requisitos subconscientes) precisam ser totalmente desenvolvidos, caso contrário o cliente estará desapontado e suas expectativas não foram atendidas. Lembrando que, desenvolvendo os requisitos satisfatórios não necessariamente nos dá uma posição positiva, mas nos livra do pior cenário possível, onde nada foi feito e o cliente está insatisfeito.

Requisitos insatisfatórios são altamente influenciados por sistemas legados, mas observações e foco em documentação também devem fazer parte da levantar estes fatores.

Pois bem, dito tudo isto, gostaria de voltar ao comentário do topo deste texto. O que você acha, caro leitor? Mesmo que você não documente nada durante o seu freela ou algo do tipo, você não se vê pensando na prioridade dos requisitos do seu cliente? Para isto, é necessário organizar bem os requisitos para que você consiga seguir uma ordem no desenvolvimento da sua aplicação, certo?

Classificar, categorizar, priorizar e negociar os requisitos são fases extremamente importantes, pois afetam todo o desenvolvimento de software. Um requisito mal elaborado pode prejudicar todo o projeto, causando um prejuízo enorme para os stakeholders.

Desta forma, caros amigos, organizem bem seus requisitos a fim de facilitar o trabalho dos desenvolvedores e evitar despesas desnecessários durante o desenvolvimento do sistema. Quando mais organizado seu projeto estiver, mais propício ao sucesso ele estará.

Abraço!