Conceitos e Requisitos

Conteudista: Prof. Me. Artur Marques

Revisão Textual: Prof. Me. Luciano Vieira Francisco

Objetivos da Unidade:

Conceituar o levantamento de requisitos;

Conhecer as técnicas de elicitação tradicionais e ágeis.

ʪ Material Teórico

ʪ Material Complementar

ʪ Referências
1 /3

ʪ Material Teórico

Fundamentação sobre Requisitos

Os requisitos do sistema são uma declaração que identifica a funcionalidade necessária a um sistema de informação, programa ou software para
satisfazer às condições do cliente.

Os requisitos correspondem à forma mais eficaz de se atender às necessidades do usuário e reduzir o custo de implementação. Podem fazer com
que uma empresa economize muito dinheiro e tempo – ou exatamente o contrário. São a primeira e mais importante parte de qualquer projeto,
dado que se os requisitos do sistema não forem atendidos o projeto não estará completo.

Você já deve ter percebido que o maior desafio está em perceber que o requisito existe, de modo que é importante, relevante e claro entendê-lo
completamente. A falha nisso poderá comprometer as fases futuras de um projeto de software de forma moderada ou importante – por isso de
sua relevância no contexto da engenharia de software e a produção de um produto sistêmico útil e que agregue valor na corporação ou, em última
instância, ao mercado.

Softwares são celebrados ou cancelados no mercado por causa do sucesso ou insucesso do levantamento dos requisitos e na transformação
destes em funções úteis ao sistema. Portanto, a declaração desses requisitos ou das necessidades que o sistema futuro deverá atender deve
explicar claramente o que o cliente quer e como ele quer.

A necessidade de um cliente pode ser satisfazer um contrato, resolver um problema, atingir um objetivo, atender a um padrão ou a quaisquer
outras diretrizes do projeto ao qual se designa.

Os requisitos do sistema sempre variam de acordo com o projeto, de modo que não há dois sistemas com requisitos idênticos. No entanto, ter
muitos requisitos de sistema descritos para um projeto pode fazer com que o custo e tempo aumentem drasticamente, e como você sabe, em um
mundo ágil isso pode parecer contraproducente. Por outro lado, ter poucos requisitos pode fazer com que o futuro sistema não funcione
corretamente ou pior, mostre aos usuários e às partes interessadas algo completamente disfuncional – você percebe como descrever requisitos
se torna o aspecto mais importante para que as outras etapas de planejamento e execução possam fluir de maneira ótima?

Os requisitos do sistema podem vir do cliente, da empresa ou mesmo de outros grupos maiores que definem os requisitos para categorias
específicas e inteiras.

Saiba que quando tratamos de requisitos, o tamanho dessa área, como o número de atividades e o quanto cada uma pode ser envolvida é o
suficiente para se criar ramos da engenharia de software chamados de engenharia de requisitos e voltados exclusivamente ao processo de
gerenciamento desses requisitos.

Podemos classificar em grandes áreas as seguintes, que lidam com os requisitos de sistema, por exemplo:

Elicitação: o levantamento de requisitos para o software;

Classificação: categorização dos requisitos;

Validação: confirmação dos requisitos com as partes interessadas;

Desenvolvimento e implementação: utilização dos requisitos na construção do software para atender às necessidades;
 Negociação: lidar com conflitos de interesse das partes envolvidas no que tange aos requisitos;

Verificação: avaliar se a função construída no software satisfaz ao que o requisito declarou.

Ademais, existem vários tipos de requisitos que devem ser considerados quando se trata de projetar ou modificar software, vejamos:

Requisitos de negócio: descrevem o caso de negócio e a razão para se fazer o produto, em

primeiro lugar. São igualmente conhecidos como requisitos das partes interessadas, pois
descrevem as características do produto proposto do ponto de vista do usuário final. Não
definem aquilo que o sistema deve fazer ou como deve ser feito, mas estabelecem os requisitos
do porquê – por exemplo, por que o cliente precisa disso? Ou seja, define a visão do produto de
software a ser construído;

Requisitos de software: são separados em dois subtipos:

Os requisitos funcionais são os requisitos “o quê”. Descrevem o que o sistema foi projetado
para fazer. Os requisitos funcionais, como o próprio nome diz, permitem que o sistema
funcione, afinal, sem eles, ou o sistema simplesmente não funciona, ou fica seriamente
comprometido e perde a sua razão de existir;

Os requisitos não funcionais são os requisitos “como”. Descrevem como o sistema fará o
que foi projetado para fazer. Este tipo de requisito está fortemente associado à qualidade –
por exemplo, o sistema executará uma transação a cada segundo: pode ser que durante um
dia de operação ele faça transações a cada 0,5 segundo ou em alguns momentos a cada 2
segundos; todavia, dentro desse intervalo ele não causa danos, tal como a ausência de um
requisito funcional que impeça o sistema de funcionar, por exemplo.

Ambos os requisitos são importantes, pois fornecem informações sobre o que será necessário
para o desenvolvimento e teste do sistema, além de darem pistas para o pessoal que cuidará da
solução técnica, ou seja, da gerência de configuração;

Requisitos de hardware: são necessários para se desenvolver e criar um dispositivo de hardware. Às vezes, um produto é
totalmente baseado em software e, portanto, pode não ser necessário. Mas se a sua empresa fabrica um produto físico, há
muitos aspectos a serem considerados antes de projetar e fabricar o dispositivo. Isso ocorre em produtos com software
embarcado, afinal, estes precisam de um processador (hardware), entre outras coisas para ser executado. Como visto, são
necessárias análises de múltiplos aspectos, tal como a velocidade necessária do processador, quanta memória é necessária,
que forma o produto terá etc., todos os aspectos devendo ser revisados. Os requisitos de hardware e software precisam ser
considerados juntos para se determinar a compatibilidade de software ao sistema projetado.

Os requisitos precisam ser estabelecidos e detalhados no início do desenvolvimento para que haja um caminho claro à verificação e validação;
mesmo em um desenvolvimento ágil, o mínimo de detalhamento é necessário para que o time de desenvolvimento consiga entender a
complexidade envolvida, por exemplo. Sem uma visão de como verificar e validar o produto de software, não há como afirmar que este é de boa
qualidade e está pronto para ser utilizado pelos usuários.

Os requisitos são fundamentais para a verificação e validação, pois ajudam o time de testes a projetar e implementar estratégias em todo o ciclo
de desenvolvimento. O teste de verificação ocorre à medida que um novo software é criado e lançado.

De forma geral, se não tivermos requisitos devidamente capturados, isto poderá levar a uma infinidade de problemas.
Normalmente, o primeiro lugar para se encontrar o ponto problemático é com os testadores, pois estes terão o trabalho complicado, em tentar
descobrir como testarão um produto sem nenhuma orientação clara acerca do que ou como deve operar.

Assim, requisitos não documentados podem levar a:

Software não implementado corretamente;

Lacunas na funcionalidade em todo o sistema;

Hardware que não funciona conforme o esperado;

Gerentes de projeto sem saber se o produto está pronto;

Cliente sem saber o que esperar ou pagar;

Engenheiros de software abandonados;

Programadores desenvolvendo da forma que entenderem;

Um sistema cheio de bugs.

Mesmo um conjunto de requisitos realmente detalhados pode ser inconsistente e isto tem relação, em parte, com a falta de comunicação e a
forma como foram coletados.

Descreveremos um pouco mais os requisitos funcionais e não funcionais, de modo que são tipos de requisitos funcionais e as suas
especificações:

Os requisitos funcionais podem ser classificados de acordo com diferentes critérios. Por
exemplo, podemos agrupá-los com base nas funções que um determinado recurso deve
desempenhar no produto. É claro que diferem dependendo do produto desenvolvido, mas, a
título de exemplo, os tipos de requisitos funcionais podem ser:

Autenticação;

Níveis de autorização;

Conformidade com leis ou regulamentos;

Interfaces externas;

Processamento de transações;

Comunicação/mensagens;

Regras de negócio, entre outros.

Os requisitos geralmente são escritos em texto, sendo os formatos e documentos mais comuns:

Documento de especificação de requisitos de software (Ders): artefato formal;

Casos de uso: artefato UML;

Histórias de usuários: artefato ágil;

 Estrutura analítica do trabalho/projeto (WBS), ou decomposição funcional: artefato de
controle e descoberta;

Protótipos: artefatos de modelagem e apresentação;

Modelos e diagramas: artefatos visuais de conhecimento.

Como observação importante, todas as histórias de usuários nos processos ágeis devem se adequar ao modelo de qualidade Invest que, em linhas
gerais, significa o seguinte:

Independente: significa que você pode agendar e implementar cada história de usuário
separadamente. Isso é útil se você implementar processos de integração contínua dentro de um
conceito DevOps, por exemplo;

Negociável: significa que todas as partes concordam em priorizar as negociações sobre a especificação. Isto diz que os
detalhes serão criados constantemente durante o desenvolvimento. Ou seja, os requisitos são levantados, porém, melhor
conhecidos durante o planejamento do sprint ao qual serão executados;

De valor: uma história de usuário (requisito) deve ser valiosa para o cliente. Você deve se perguntar, pela perspectiva do cliente,
“por que” você precisa implementar determinado recurso?

Estimável: uma história de usuário de qualidade pode ser estimada. Isto ajudará uma equipe a agendar e priorizar a
implementação. Quanto maior a história, mais difícil será a estimar;

Pequena: boas histórias de usuários tendem a ser pequenas o suficiente para planejar lançamentos de produção curtos.
Pequenas histórias permitem estimativas mais específicas;

Testável: se uma história pode ser testada, será clara e boa o suficiente. Histórias testadas significam que os requisitos estão
prontos para uso no desenvolvimento e posteriormente como funcionalidade apresentada ao usuário.

Quanto aos requisitos não funcionais há uma série de classificações, de modo que veremos aqui as que o IEEE e ISO consideram as principais:

"Requisitos do produto: esses requisitos especificam o desempenho do produto de software. Os requisitos do produto
incluem o seguinte;

Requisitos de eficiência: descreva até que ponto o software faz uso otimizado dos recursos, a velocidade com que o
sistema é executado e a memória que consome para sua operação. Por exemplo, o sistema deve ser capaz de operar pelo
menos três vezes mais rápido que o sistema existente;

Requisitos de confiabilidade: descreva a taxa de falha aceitável do software. Por exemplo, o software deve ser capaz de
operar mesmo se ocorrer um erro;

Requisitos de portabilidade: descreva a facilidade com que o software pode ser transferido de uma plataforma para outra.
Por exemplo, deve ser fácil portar o software para um sistema operacional diferente sem a necessidade de reprojetar
todo o software;

Requisitos de usabilidade: descreva a facilidade com que os usuários são capazes de operar o software. Por exemplo, o
software deve ser capaz de fornecer acesso à funcionalidade com menos pressionamentos de teclas e cliques do mouse;
 Requisitos organizacionais: esses requisitos são derivados das políticas e procedimentos de uma organização. Os
requisitos organizacionais incluem o seguinte;

Requisitos de entrega: especifique quando o software e sua documentação devem ser entregues ao usuário;

Requisitos de implementação: descrever requisitos como linguagem de programação e método de design;

Requisitos de padrões: descrever os padrões de processo a serem usados durante o desenvolvimento de software. Por
exemplo, o software deve ser desenvolvido usando padrões especificados pelos padrões ISO e IEEE;

Requisitos externos: esses requisitos incluem todos os requisitos que afetam o software ou seu processo de
desenvolvimento externamente. Os requisitos externos incluem o seguinte;

Requisitos de interoperabilidade: defina a maneira pela qual diferentes sistemas baseados em computador irão interagir
entre si em uma ou mais organizações;

Requisitos éticos: especificar as regras e regulamentos do software para que sejam aceitáveis para os usuários;

Requisitos legislativos: garantir que o software opere dentro da jurisdição legal. Por exemplo, software pirata não deve
ser vendido."

- THAKUR, 2022, p. 7-9

Figura 1 – Exemplo de tipos de requisitos não funcionais e suas categorias

#ParaTodosVerem: Figura contendo os macros componentes dos requisitos não funcionais. Sob fundo branco, na parte
central da imagem, uma elipse cujo conteúdo é: requisitos não funcionais. A partir dele irradiam 3 linhas que terminam
em caixas azul claro contendo agrupamentos de requisitos não funcionais. A primeira caixa, chamada requisitos
organizacionais, se liga à uma caixa azul escura com o seguinte conteúdo: entrega, implementação e padronização. A
segunda caixa azul-claro, chamada requisitos externos, se liga à uma caixa azul escuro cujo conteúdo é:
interoperabilidade, ética e legislação. A terceira e última caixa azul clara, chamada requisitos de produto, se liga à caixa
azul escuro cujo conteúdo é: eficiência, confiabilidade, portabilidade, usabilidade e acessibilidade. Fim da descrição.
De que forma podemos mensurar o quanto um requisito não funcional é atendido? Bem, vejamos métricas e unidades de medida no seguinte
Quadro:

Quadro 1 – Exemplo de requisitos não funcionais, suas características a serem mensuradas e as unidades para mensuração

Características Medidas

Transação processada por segundo

Tempo de resposta do usuário por evento

Velocidade
Taxa de atualização da tela

Quantidade de memória
Tamanho
Número de chips de RAM

Tempo de treino
Fácil de usar
Número de janelas de ajuda

Tempo médio até a falha (MTTF)

Portabilidade de indisponibilidade
Confiabilidade
Taxa de ocorrência de falhas

Tempo para reiniciar após falha

Porcentagem de eventos que causam falha

Robustez
Probabilidade de corrupção de dados em caso de falha

Porcentagem de declarações dependentes de destino

Portabilidade
Número de sistemas de destino

Além dessas características e desses tipos, os requisitos podem ser classificados da seguinte maneira:

Derivado, imposto ou emergente:

 O requisito deriva de outros requisitos?

O requisito é imposto explicitamente por uma parte interessada, conhecida também como
stakeholder?

O requisito é uma propriedade emergente? Em outras palavras, não pode ser tratado por um
único componente, mas depende de como todos os componentes de software interoperam.
Ou seja, surgiu ou foi descoberto a partir da execução de outras partes, portanto,
“emergiu”.

Processo ou produto:

O requisito pode estar relacionado ao produto? Por exemplo, o sistema deve verificar se um
cliente pode fazer a sua primeira compra usando cartão de crédito, ou se deverá pagar com
cartão de débito, ou ainda em dinheiro?

O requisito pode estar relacionado ao processo? A melhor abordagem de desenvolvimento

para esse sistema é o método iterativo/incremental, dado que os requisitos serão descritos
com maior detalhe quando forem utilizados em sprint.

Prioridade:

Foca em equilibrar o custo de desenvolvimento e implementação versus a necessidade de

entrega. Ou seja, orçamento versus cronograma;

Pode usar uma escala de rótulo fixo como obrigatória – por exemplo, o requisito é
altamente desejável, desejável ou opcional.

Alcance:

Usado para considerar o impacto na arquitetura de software e projetos de componentes;

Os requisitos não funcionais geralmente têm um escopo global e não local no sistema.

Volatilidade/estabilidade: probabilidade de que um ou vários requisitos mudarão durante o ciclo de vida do software (SDLC), o
que ajudará a implementar designs que sejam tolerantes a mudanças.

Gerenciamento de Requisitos
Lembremos que os analistas de negócios, na grande maioria dos casos e do porte das empresas, conduzem a elicitação de requisitos para
identificar as necessidades de negócio, escopo, suposições e riscos de um projeto com base nos dados das principais partes interessadas.

É uma parte imperativa do gerenciamento de requisitos, pois o resultado afeta o entendimento fundamental do objetivo do projeto de software. A
falha em definir claramente as necessidades de negócio pode levar a resultados catastróficos, tais como erros caros, falhas do sistema ou
cancelamento do projeto em execução.

O processo de elicitação revela insights de requisitos das principais partes interessadas. Ao se fazer as perguntas certas aos usuários, líderes e
especialistas no assunto, permitindo conversas profundas e registrando descobertas, encontramos as verdadeiras necessidades de negócio para
impulsionar o projeto no caminho correto.

Certo, mas talvez você ainda esteja pensando: “o que é elicitação de requisitos?” Simples, é o que fazemos para descobrir os requisitos e
utilizamos diversas técnicas para isso. O importante aqui é entendermos os processos que estão associados à elicitação de requisitos.
A primeira coisa a desmistificar é o próprio termo que muitos profissionais, por incrível que pareça, ainda confundem: elicitação e coleta de
requisitos. Coleta é o ato de colher dados e documentos de fontes dispersas/espalhadas. Por outro lado, elicitar é o ato de extrair informações de
uma fonte. Ambos os atos são essenciais para o processo geral de elicitação de requisitos e exigem expertise para serem executados
adequadamente.

A segunda condição é identificar as partes interessadas, ou seja, quem são os principais atores que influenciarão ou que possuem interesse que
os requisitos e, por consequência, o sistema sejam corretamente elicitados, com quem trataremos etc. É importante identificar as pessoas certas
antecipadamente, pois isto eliminará a necessidade de preencher requisitos ausentes posteriormente, o que poderia alterar o curso e custo do
projeto.

Em terceiro lugar, devemos elicitar junto a essas partes interessadas. Para tanto, lançaremos mão de várias técnicas, por exemplo:

Brainstorming: discussão de forma livre para gerar novas ideias e soluções. Veja, a seguir, um
exemplo de brainstorming:

Idéia utópica e aparentemente sem pé nem cabeça pode dar origem, num momento
posterior, a ideias mais realistas;

Não só a crítica como também a rotina do pensamento convencional cortam o campo

perceptivo. É conveniente, portanto, romper os esquemas culturais;

No grupo, as ideias de uns devem atuar como estimulante para os outros;

A eliminação, mesmo que seja temporária, do juízo crítico em grupo cria um clima de muita
aceitação, de caramadagem, de espontaneidade, de liberação, de euforia e de dinamismo
criativo.

Análise de documentos: analisar a documentação existente para entender os requisitos potenciais;

Grupos de foco: facilitar discussões em pequenos grupos sobre um produto ou serviço, sendo geralmente usado para se obter
feedback das partes interessadas externas à sua organização;

Análise de interface: analisar a interface entre sistemas, ou entre o usuário e um sistema, a fim de entender os requisitos do
estado atual ou os requisitos do estado futuro para permitir uma integração. Desta análise às vezes surgem protótipos de
interfaces de usuários, por exemplo, para validação;

Entrevistas: conversas focadas em se fazer perguntas de requisitos específicos de um indivíduo ou grupo de partes
interessadas. Uma dica importante é ter as perguntas elaboradas e revisadas antes de ir fazer a entrevista – ou seja, nada de
improviso;

Observação ou etnografia: observar uma parte interessada concluindo um processo de negócio ou função de trabalho é útil
para entender os detalhes do processo;

Prototipagem: criar uma representação visual de uma possível solução para revisar com as partes interessadas e obter
confirmação ou novas ideias sobre os requisitos:
 Figura 2 – Exemplo de prototipagem em alto nível de uma tela de interface humano
computador
Fonte: Adaptada de DIAS, 2019

#ParaTodosVerem: Imagem de um mockup de aplicativo em preto e branco. Na lateral superior esquerda, encontra-se o
espaço para colocação de uma logomarca, logo abaixo, os itens de menu. No topo da página há um botão de voltar e na
lateral superior direita, o nome do usuário. Logo abaixo, no espaço central, encontramos a área de cadastro com campos
para a digitação de nome do produto e outras informações distribuídas em duas linhas com caixas de inserção de dados.
Abaixo desses espações de digitação, temos 3 imagens contendo vistas do produto. Abaixo disso, o local onde a
quantidade desse produto em estoque é apresentada. Por fim, no canto inferior direito, encontramos os botões de ação:
Limpar e Salvar nessa sequência. Fim da descrição.

Workshops de requisitos: uma reunião mais formal e altamente estruturada, comumente de

duração mais longa – pelo menos meio-dia, chegando a durar vários dias –, projetada para
descobrir, analisar e validar a documentação de requisitos;

Pesquisa/questionário: um pedido de feedback estruturado ou não estruturado na forma de respostas a perguntas específicas.
É útil para coletar informações de muitas partes interessadas e descobrir informações sobre o impacto potencial de uma
decisão.

Lembre-se de que as abordagens não se encerram com estes itens, de modo que há sempre novidades neste meio, com a ampliação do uso da
tecnologia.

Muitas vezes utilizamos várias dessas técnicas em conjunto. Por exemplo, o brainstorming comumente acontece como parte de um workshop de
requisitos que também pode ter um componente de entrevista, ou ainda, para se preparar para uma entrevista torna-se necessário fazer
antecipadamente a análise de documentos e, assim, criar uma lista de perguntas coerentes.

O próximo passo no processo de elicitação de requisitos é documentar os requisitos elicitados até o momento.

Depois que documentamos os requisitos, é chegado o momento de garantir que sejam registrados corretamente. Os requisitos são enviados a
todas as partes interessadas para revisão, a fim de que haja entendimento coletivo do que é desenvolvido. As partes interessadas provavelmente
farão refinamentos, sugestões e outros apontamentos. Igualmente é possível que esta etapa elicite, portanto, descobrindo-se novos/outros
requisitos que exigirão revisões antes que a aprovação possa ocorrer.

Elicitar requisitos de forma coerente e precisa é fundamental, de modo que vejamos quais são os principais desafios:

Encontrar as partes interessadas corretas;

Encontrar a melhor técnica ou o conjunto das quais para descobrirmos da melhor forma os requisitos;

Documentar de forma clara e concisa os requisitos;

Planejar as mudanças e adaptações da melhor maneira.

Você aprendeu até aqui que a análise de requisitos envolve a comunicação frequente com os usuários do sistema para determinar as expectativas
de recursos específicos, a resolução de conflitos ou a ambiguidade nos requisitos, conforme exigido pelos vários usuários ou grupos de usuários,
a fim de se evitar a fluência de recursos e documentação de todos os aspectos do processo de desenvolvimento do projeto, do início ao fim.

A energia deve ser direcionada para se garantir que o sistema ou produto de software esteja em conformidade com as necessidades do cliente, em
vez de se tentar moldar as expectativas do usuário para atender aos requisitos.

A análise de requisitos é um esforço de equipe que exige uma combinação de conhecimentos de engenharia de hardware, software e fatores
humanos, bem como habilidades para lidar com pessoas. Portanto, não são apenas hard skills que fazem a engenharia de software, mas também
soft skills.

Requisitos Ágeis
Processos ágeis iterativos significam que as mudanças podem ser introduzidas em qualquer estágio de desenvolvimento. Por isso é importante
trabalhar em estreita colaboração com os clientes para se descobrir os requisitos e desenvolver soluções através de uma abordagem colaborativa.
Significa que engenheiros de software, testadores, proprietários de produtos e o pessoal da garantia de qualidade estão envolvidos no processo
de captura e revisão dos requisitos.

Quando tratamos de requisitos em processos de desenvolvimento ágil, pensamos em histórias dos usuários, de modo que entenderemos como
fazer isto de forma ideal e produtiva:

Rascunho inicial: é a primeira etapa para a captura da história, seguindo-se o bom e velho
script ou “receita de bolo”: “Eu, como um [ator x], quero [satisfazer a uma necessidade y] para
que eu possa [objetivo z para satisfazer à necessidade y]”. Às vezes serão necessárias algumas
iterações para corrigir isto, ou seja, deixar coerente;

Definir critérios de aceitação inicial: depois que tivermos a história, poderemos definir os
critérios de aceitação, podendo-se incluir alguns desenhos de rascunho, wireframes, mockups,
entre outros, levando-se em consideração aspectos de UX – experiência do usuário –,
necessidades específicas de desempenho, Requisitos Não Funcionais (RNF) e/ou casos de uso.
No ágil, os critérios de aceitação referem-se a um conjunto de requisitos predefinidos que
devem ser atendidos para marcar uma história de usuário como concluída. Os critérios de
aceitação também são chamados de definição de concluído ou, em inglês, definition of done,
porque determinam o escopo e os requisitos que devem ser executados pelos desenvolvedores
 para se considerar a história do usuário concluída. Ademais, são características para um
critério de aceitação as seguintes:

Devem ser testáveis: os testes devem revelar resultados simples de sim/não ou de

aprovação/reprovação;

Devem ser claros e concisos: mantenha cada critério o mais simples e direto possível;

Todos devem entender os critérios de aceitação: os critérios serão inúteis se os

desenvolvedores não os entenderem. Se não houver certeza de que algo está claro, reserve
um tempo para perguntar e fazer ajustes até que as coisas estejam claras;

Devem fornecer sempre a perspectiva do usuário: os critérios são meios de se olhar para o
problema do ponto de vista do usuário/cliente. Portanto, quando escrever, pense em fazer
isto no contexto de uma experiência do usuário.

Na metodologia ágil, comumente o proprietário ou gerente do produto é responsável por redigir

os critérios de aceitação ou, pelo menos, por facilitar a discussão sobre os quais. A ideia por
trás disto é garantir que os requisitos sejam escritos com as necessidades do cliente em mente
– e quem melhor para entender as necessidades do cliente do que uma pessoa do produto?

Revisar a história com as partes interessadas e atualizar, se necessário: muitas pessoas

simplesmente publicam histórias sem nenhuma revisão com as partes interessadas – clientes,
usuários, entre outros. Este papel cabe ao dono do produto, que em Scrum é conhecido como
product owner, pois é uma etapa de feedback essencial para se garantir que a história do usuário
realmente descreva a solução desejada. Depois de apresentada, devemos sempre revisar com a
equipe de desenvolvimento ou com o squad ágil e atualizar, se necessário. Após a história
revisada, precisaremos garantir que seja convergente, entre as partes interessadas e o time de
desenvolvimento Scrum, daí jogamos o plannig poker, por exemplo, a fim de se obter um
tamanho aproximado da história – quem faz isto é o time Scrum, ágil ou de desenvolvimento,
quando se chegar ao sprint que trabalhará as histórias, uma a uma;

Priorizar a história na lista de pendências ou backlog do produto: para fazer isto o dono do
produto deve entender a prioridade dos negócios e a complexidade técnica da história. O
critério de seleção de prioridades deve obedecer à quantidade de valor que será agregada – pois
sem isso teremos problemas futuros;

Revisar a história durante as sessões de preparação: se a história permanecer na lista de

pendências por um período significativo, será provável que fique “obsoleta” e que precise ser
revisada e possivelmente reestimada. É exatamente para isso que servem as sessões de
preparação no ágil.

Por fim, planejaremos o sprint: não é o momento de escrevermos sobre isto, de modo que mais adiante, nesta Disciplina, iremos mais a fundo.
Quando chegar o momento, colocaremos a história em sprint durante o planejamento, garantindo um “mergulho mais profundo” do que
qualquer esforço anterior para se certificar de que a equipe entenda completamente o que é pedido nos requisitos e o que é feito para entregar.

Vejamos como é o requisito ágil: primeiramente, os requisitos ágeis são histórias de usuários preparadas para se fazer as estimativas de
desenvolvimento e contêm alguns elementos extras como, por exemplo, os nomes dos recursos, detalhes, as prioridades e a justificativa – esta
última não é obrigatória, mas bastante recomendada porque ajuda a equipe de desenvolvimento a entender melhor o motivo por trás da
funcionalidade declarada, veja no exemplo a seguir um exemplo de construção de uma história do usuário, extraída de uma entrevista com o
referido usuário:

Nome: visualizar calendário;

História: como médico, quero ver o meu calendário de consultas para saber quando os pacientes estão chegando;

Detalhes: o médico deve ver todas as consultas – desde o início dos tempos e para o futuro. Por padrão, o calendário deve exibir
a semana atual, com a opção de se navegar entre semanas e meses;

Justificativa: é uma funcionalidade básica em todos os produtos concorrentes; com base em pesquisas, tal experiência é
esperada pelos usuários, tornando-se necessária para a integração do compromisso;

Prioridade: 1.

Importante!
O dono do produto deve priorizar as histórias, por isso no item prioridade está o número 1, significando
ser importante. Poderá também, se for o seu desejo, agrupá-las em conjuntos lógicos para um plano de
liberação.

Quanto à equipe Scrum que realizará o desenvolvimento, fará perguntas ao dono do produto sobre cada história e obterá mais informações sobre
o que ela tentará realizar. Assim, os critérios de aceitação serão mais claros e até refinados durante o jogo do planejamento a fim de se fornecer
um tamanho relativo, uma estimativa em pontos de complexidade, por exemplo.

Pode-se dividir as histórias em excertos menores, de modo que caso uma história seja excessivamente complicada, a fim de que possam ser
feitas dentro de um sprint, quando for o momento de o planejar.

Contudo, como estamos no começo, realizaremos uma sequência de histórias, as quais advindas de uma reunião com usuários. Assim, perceba
que podemos variar os padrões e até mesmo criar os nossos e ir treinando.

Veja a seguir exemplos de histórias de usuários:

Cadastro de Usuário
Como cliente, quero me cadastrar no site para ter o controle das minhas compras e/ou vendas.

Critérios de aceite:

Todo usuário cadastrado, em um primeiro momento, é um usuário comum;

Somente um administrador poderá mudar o seu tipo de usuário;

 Para o cancelamento da conta, o usuário poderá realizar em sua própria conta, ou
solicitando através de um e-mail para contato.

Editar Dados de Cadastro

Como cliente, preciso editar as minhas informações pessoais para a atualização dos meus dados.

Critérios de aceite:

O usuário terá acesso aos seus dados e poderá editá-los a qualquer momento;

O sistema deverá prover a opção para se escolher entre tipo físico ou jurídico;

Todos os campos serão obrigatórios;

Após a atualização, uma mensagem de confirmação de dados editados será mostrada.

Alterar Senha e E-mail

Como cliente, preciso editar/atualizar senha e e-mail, caso eu considere necessário ou perca alguma dessas informações.

Critérios de aceite:

O sistema terá campos com a opção para visualizar senha e e-mail atuais;

Campos para confirmar a senha e o e-mail novos.

Contato
Como usuário, preciso ter uma página para entrar em contato com a livraria e esclarecer possíveis dúvidas.

Critérios de aceite:

É necessário haver tópicos pré-definidos: problemas técnicos, vendedor, entrega etc., a fim

de facilitar o atendimento ao usuário;

O sistema deverá montar um e-mail através desses campos obrigatórios e enviar as

informações ao e-mail próprio da livraria;

O usuário também receberá a sua resposta através do seu e-mail pessoal.

Nestes exemplos, temos um elemento útil inserido, o critério de aceitação que ajuda significativamente o entendimento pelo time de
desenvolvimento, bem como pode ajudar a equipe a criar testes que garantam os requisitos e as regras a esses impostas.
O time ágil divide a sua carga de trabalho em temas, épicos, histórias e tarefas, mas não se esgota somente nisso. Outro fato determinante é que
contar histórias tem papel fundamental no desenvolvimento ágil, ajudando as equipes a entender o que é necessário e fornece a estrutura criativa
de que precisam para chegar a uma entrega de valor.

"Temas: é uma ampla área de foco que ajuda uma equipe ágil a acompanhar seus objetivos organizacionais – pense nele
como um rótulo que pode ser usado para agrupar atividades semelhantes. Um tema ajuda a definir as características
comuns entre as diferentes áreas e a uni-las sob um título;

Épicos: é uma coleção substancial de histórias menores que se combinam para formar uma grande história. Um épico
não pode ser concluído em uma única iteração ágil ou sprint. O elemento-chave para um épico é que leva muito tempo;

Histórias: é uma solicitação de formato curto que pode ser entregue em um sprint. Ele é escrito em linguagem simples do
ponto de vista do usuário. Os pontos de história são usados para medir a complexidade de uma história. O objetivo geral
de uma história é fornecer valor ao usuário dentro de um prazo definido;

Tarefas: é uma subseção de uma história. Isso ajuda a quebrar a história e delinear como ela será concluída. As tarefas
tendem a ser mais técnicas, pois são usadas por membros da equipe de desenvolvimento em vez de um usuário front-
end;

Existem outros termos de agrupamento que surgem ao trabalhar em uma estrutura ágil. Esses termos incluem iniciativas e

recursos.

Iniciativas: é um grupo de épicos. Pode incorporar épicos de muitas equipes diferentes, mas todos terão um objetivo
comum. Uma iniciativa naturalmente levará mais tempo do que um épico;

Características: é um recurso que se refere a uma determinada funcionalidade ou serviço que satisfaz a necessidade de
uma parte interessada. Cada recurso deve delinear os critérios envolvidos e oferecer um valor comercial
específico.Ainda se perguntando como esses termos se relacionam?

Vamos agora explorar como algumas dessas várias seções se comparam.

Épico versus história: uma história é um requisito único, enquanto um épico é um grupo de várias histórias. Imagine um
projeto com muitas pastas. As pastas são as histórias individuais que estão relacionadas de alguma forma. Todos eles se
combinam para formar um grande projeto, que é o épico. Outra diferença fundamental entre um épico e uma história é o
tempo que cada um leva.

Uma história ocorre dentro de um sprint, que geralmente dura cerca de 1 ou 2 semanas.

Por outro lado, um épico provavelmente levará entre 1 e 3 meses para ser concluído.

Tema versus tarefa: temas e tarefas são semelhantes, pois ambos ajudam na categorização, adicionando um senso de
ordem ao processo de gerenciamento do trabalho.

No entanto, os temas reúnem um grupo de épicos ou iniciativas sob uma bandeira relacionada.

As tarefas dividem uma história, criando subdivisões dentro de uma seção existente.

Os temas também são mais amplos e podem se espalhar por toda a empresa, relacionados a vários épicos, histórias e

iniciativas.
As tarefas, por sua vez, têm um propósito muito mais específico. Elas são usadas apenas no contexto de uma única história e

não são projetados para serem compartilhados fora dela.

Iniciativa versus recurso: iniciativas e recursos podem ser extraídos de várias áreas para criar compilações.

Uma iniciativa pode incluir épicos de diferentes equipes.

Um recurso pode envolver várias histórias diferentes.

O principal diferencial entre os dois é a quantidade de tempo necessária:

As iniciativas envolvem planejamento de longo prazo e podem levar até um ano para serem concluídas.

Os recursos, no entanto, normalmente ocorrerão em um único trimestre.”

- WRIKE, 2022, p. 3-4

Figura 3 – Estrutura e divisões do backlog de produto Scrum

Fonte: Reprodução

#ParaTodosVerem: Imagem contendo exemplo esquemático da hierarquia do backlog de um produto de software. No

topo da imagem, há uma caixa na cor azul escuro cujo conteúdo é: Épico. Dessa caixa saem duas linhas, para um nível
inferior. A caixa da esquerda está intitulada como História A, isso demonstra que um épico é formado por histórias de
usuário. A caixa da direita possui o enunciado História B. Ambas as caixas, A e B, possuem em seu nível inferior várias
caixas menores, em suas respectivas cores dos níveis superiores. Para História A temos as caixinhas tarefa A1, A2 e A3.
Para a História B temos as caixinhas B1 e B2. Isso indica que as histórias de usuário são também formadas por elementos
menores que chamamos de tarefas. Fim da descrição.
2/3

ʪ Material Complementar

Indicações para saber mais sobre os assuntos abordados nesta Unidade:

Vídeos

Desafio Ágil – Requisitos Ágeis

Desa o Ágil 02 - Requisitos Ágeis

Rastreabilidade de Requisitos

Rastreabilidade de Requisitos
Requisitos Funcionais e Não Funcionais

Aula 13 - Requisitos funcionais e não-funcionais (De nição)

Técnicas de Levantamento de Requisitos de Sistemas

Técnicas de levantamento de requisitos de sistemas

3/3

ʪ Referências

THAKUR, D. O que é requisito de software? Tipos de requisitos. ecomputernotes, 2022. Disponível em: <https://ecomputernotes.com/software-
engineering/softwarerequirement>. Acesso em: 19/07/2022.

WRIKE. Temas, épicos, histórias e tarefas em ágil. 2022. Disponível em: <https://www.wrike.com/agile-guide/epics-stories-tasks>. Acesso em:
19/07/2022.