Requisitos Não Funcionais como User Stories
No Product Backlog são registrados os requisitos de um produto. Quando queremos formulá-los da perspectiva do usuário, frequentemente utilizamos o formato da User Story. Aqui, os requisitos funcionais para o produto são capturados de forma clara e específica. Mas e os requisitos não funcionais? Estes também devem ser incluídos no Product Backlog. Aqui você descobre por que os requisitos não funcionais são importantes e como eles podem ser melhor integrados ao Product Backlog, por exemplo, através do template de User Story.
As diferenças entre requisitos funcionais e não funcionais
Há muito tempo que na gestão de produtos se distingue entre requisitos funcionais e não funcionais. Também na gestão ágil de requisitos, os dois conceitos são diferenciados. Aqui apresentamos brevemente as diferenças.
Requisitos funcionais
Estes requisitos descrevem funções e especificações concretas do produto. Como User Story, os requisitos que são importantes para o usuário são listados da forma mais precisa e completa possível. Trata-se de requisitos específicos do produto que, em geral, não podem ser transferidos para qualquer outro produto. Estes exemplos são requisitos funcionais típicos:
Eu, como usuário de um programa de processamento de texto, quero poder inserir uma tabela.
O programa deve ser capaz de calcular o teor calórico do menu com base em uma fórmula.
Requisitos não funcionais
Os requisitos não funcionais são menos específicos. Eles descrevem, por exemplo, uma qualidade, uma condição ou uma característica do produto. Esses requisitos não são necessariamente específicos do produto. Podem ser válidos de forma geral para vários produtos ou até mesmo para todo o design ou arquitetura de um software:
Interface amigável
Tempos de resposta rápidos
Devido ao seu caráter inespecífico, existe o risco de que esses requisitos sejam negligenciados na criação do Product Backlog. No entanto, esses requisitos devem estar incluídos, pois são de grande interesse para o usuário. Se qualidade, confiabilidade ou rapidez não estiverem alinhadas às necessidades dos clientes, o produto provavelmente não será utilizado, pois a funcionalidade sozinha não é suficiente para satisfazer os usuários. Por isso, surge a questão de como os requisitos não funcionais podem ser integrados ao desenvolvimento do produto. Formulá-los como User Story é útil para priorizar esse tipo de requisito.
Como você pode descrever requisitos não funcionais em Scrum como User Stories
- Requisitos não funcionais devem ser descritos de forma mensurável
- Considerar os requisitos não funcionais do ponto de vista do cliente
- O requisito não funcional talvez seja melhor na "Definition of Done"?
Requisitos não funcionais devem ser descritos de forma mensurável
A afirmação de que sua página deve ter um tempo de resposta o mais rápido possível é muito vaga para a equipe de desenvolvimento. Aqui não são descritos requisitos mensuráveis. "Rápido" é, neste caso, uma declaração imprecisa que praticamente cada desenvolvedor define de forma diferente.
Para a equipe, neste exemplo, é útil receber especificações exatas. Estas podem ser elaboradas em conjunto. Um recurso pode ser uma restrição feita em relação ao requisito. Assim, as características se tornam mais tangíveis e podem ser implementadas sem problemas. Aqui o requisito pode ser, por exemplo:
A página deve carregar em menos de x segundos.
O consumo de calorias deve ser exibido em menos de 8 segundos após o clique.
Considerar os requisitos não funcionais do ponto de vista do cliente
Ao criar as User Stories, os envolvidos devem se colocar na perspectiva do cliente. Para a criação da User Story, pode ser útil imaginar o produto de forma concreta com a ajuda de um formato:
„Como <usuário> quero <objetivo>, para que <motivo>"
Este formato simples pode ajudar você e sua equipe a perguntar pelo motivo por trás do requisito. Por que pode ser importante para um usuário que o consumo calórico do menu seja exibido em menos de 8 segundos? Porque assim o usuário tem rapidamente um valor de referência com o qual pode preparar o menu dentro do seu próprio planejamento de tempo.No entanto, você deve questionar o resultado e considerar a fórmula apenas como uma "ferramenta de reflexão". Se a resposta ao "Por quê?" for muito complicada ou confusa, então você deve buscar uma conversa direta com o cliente ou usuário. Pergunte às pessoas por que essa característica é pessoalmente importante para elas. Às vezes descobre-se que um requisito não funcional não é tão inespecífico assim, mas apenas foi formulado de forma imprecisa.
A exigência não funcional talvez esteja melhor na "Definition of Done"?
Trata-se de pontos transversais como, por exemplo, os tempos de resposta de um programa? Então pode fazer sentido incluí-los na "Definition of Done". Junto com a tua equipa e eventualmente os stakeholders, vocês podem considerar se um tempo de resposta rápido não deveria ser um critério básico para todo o sistema.
A inclusão de uma exigência não funcional na Definition of Done significa que cada item deve cumpri-la. Isso é vantajoso quando se trata, por exemplo, de um design e da sua conformidade com a identidade corporativa ou similar.
Converter requisitos não funcionais em requisitos funcionais
Requisitos não funcionais podem ser formulados como User Stories, assim como os requisitos funcionais. E devem ser, para que não sejam esquecidos ou negligenciados. O importante é que sejam formulados de forma mensurável e limitados de alguma maneira. Se você não conseguir definir essa limitação sozinho, a fórmula apresentada acima pode ajudar. Ela pergunta pelo "Por quê?" e pode servir como um auxílio para o seu raciocínio. Caso contrário, a conversa direta com sua equipe, usuários ou stakeholders também ajuda.
Primeiras informações sobre Scrum e User Stories você encontra no nosso site. Quer aprender conhecimento aprofundado sobre Scrum? Então inscreva-se em um treinamento de Scrum e aprenda os fundamentos do trabalho ágil!
