Gestão de Requisitos no Desenvolvimento de Software

A gestão de requisitos no desenvolvimento de software é a “ferramenta” utilizada para garantir que as soluções finais atendam (seria melhor dizer satisfatoriamente, né?) às necessidades dos stakeholders, sendo uma área que mescla métodos técnicos e metodologias interativas. Esta prática é crucial porque falhas na gestão de requisitos são frequentemente citadas como uma das principais causas de insucesso em projetos de software. Uma gestão inadequada pode levar a produtos que não apenas falham em satisfazer as necessidades dos usuários, mas também excedem os custos e prazos previstos. Portanto, uma abordagem sistemática pode significativamente melhorar a qualidade do produto final e otimizar o uso de recursos e tempo de desenvolvimento.

O principal desafio da gestão de requisitos é capturar completamente as expectativas e necessidades, que muitas vezes são vagas ou ambíguas, e transformá-las em especificações claras e operacionais. Além disso, é vital gerenciar esses requisitos de forma eficaz ao longo do ciclo de vida do projeto, adaptando-se às mudanças que inevitavelmente ocorrem. Técnicas como workshops e brainstorming com stakeholders são cruciais na fase inicial de elicitação para obter uma visão ampla das necessidades do usuário. Em projetos mais complexos, diagramas de caso de uso e prototipagem rápida podem ser utilizados para visualizar melhor as demandas antes do início da codificação.

Elicitação, Análise e Especificação de Requisitos

A gestão de requisitos é um dos pilares que dão sustentação ao desenvolvimento de software, ao assegurar que os produtos finais se alinhem com as expectativas e necessidades dos stakeholders. Esta seção aborda a elicitação, análise e especificação de requisitos, três fases críticas que moldam a base para um desenvolvimento de software bem-sucedido.

Elicitação de Requisitos

A elicitação de requisitos é a fundação sobre a qual todo o desenvolvimento de software é conduzido, sendo crucial para garantir que o produto final atenda efetivamente (ou satisfatoriamente) às necessidades dos usuários e stakeholders. Essa fase inicial do processo de gestão de requisitos envolve uma interação detalhada e metodológica com os usuários finais, stakeholders e outros envolvidos para captar suas necessidades e expectativas.

A técnica de elicitação escolhida pode variar consideravelmente dependendo do contexto do projeto e das características dos stakeholders. Por exemplo, entrevistas individuais são preferidas quando as informações necessárias são profundamente técnicas ou sensíveis, permitindo uma discussão mais aberta e confidencial. Por outro lado, workshops facilitam a interação em grupo e são ideais para gerar ideias criativas e consolidar visões diversas sobre o que o sistema deve realizar.

Outra técnica eficaz é a observação direta, onde os analistas de requisitos observam os usuários em seu ambiente de trabalho. Esta abordagem pode revelar necessidades que os próprios usuários podem não ter percebido, levando à identificação de requisitos implícitos que são vitais para o sucesso do sistema. Além disso, a criação de personas baseadas em dados reais ajuda a equipe de desenvolvimento a visualizar o usuário final, o que é especialmente útil em sistemas com uma grande base de usuários diversificados.

Essas técnicas, quando combinadas com ferramentas modernas como plataformas de colaboração online e software de gestão de requisitos, proporcionam uma base sólida para a documentação e análise subsequente. É crucial que as informações coletadas nesta fase sejam precisas e completas, pois erros ou omissões podem levar a custos significativamente maiores mais adiante no ciclo de vida do desenvolvimento.

Ao avançar para a análise de requisitos, é essencial que os dados coletados na fase de elicitação sejam meticulosamente avaliados para garantir sua viabilidade e adequação. Este processo de transição não apenas refina os requisitos, mas também prepara o terreno para a sua efetiva implementação e gerenciamento ao longo do projeto.

Análise de Requisitos

Após a fase de elicitação, a análise de requisitos assume uma posição central no ciclo de desenvolvimento de software, funcionando como um filtro crítico que busca assegurar a viabilidade técnica e a relevância dos requisitos coletados. Esta etapa tem por propósito identificar e resolver conflitos entre requisitos, avaliar riscos associados e estabelecer prioridades para a implementação.

Durante a análise, os requisitos são detalhadamente examinados para garantir que sejam consistentes, completos, realizáveis e testáveis. Esta análise envolve várias técnicas, como modelagem de domínio, que ajuda a visualizar e entender o sistema a ser desenvolvido em seu contexto operacional. Além disso, análises de viabilidade e técnicas de validação são aplicadas para assegurar que os requisitos sejam tecnicamente e financeiramente realizáveis, minimizando riscos de falhas futuras.

Outro componente crucial nesta fase é a priorização de requisitos. Métodos como MoSCoW (Must have, Should have, Could have, Won’t have this time) ou a matriz de priorização ajudam a equipe a identificar quais requisitos devem ser desenvolvidos imediatamente, quais podem ser adiados e quais são menos críticos. Esta priorização é essencial em ambientes ágeis, onde o foco é entregar valor ao cliente de forma iterativa e incremental.

Além disso, a análise de requisitos frequentemente revela necessidades de alterações nos processos de negócios dos stakeholders ou ajustes nas expectativas, o que pode requerer uma re-elicitação ou ajustes nos requisitos já coletados. Este aspecto iterativo enfatiza a natureza dinâmica da análise de requisitos, que não é apenas uma ponte entre a elicitação e a especificação, mas também uma etapa de constante revisão e adaptação.

Especificação de Requisitos

Após a (cuidadosa) análise dos requisitos, a fase de especificação de requisitos é onde os requisitos validados são traduzidos em documentação detalhada que guiará as fases subsequentes de design e implementação no ciclo de desenvolvimento de software. Esta etapa é fundamental para assegurar que todas as partes interessadas tenham uma compreensão clara e uniforme dos objetivos do projeto e de como eles serão alcançados.

A especificação de requisitos envolve a criação de documentos como o Documento de Especificação Requisitos de Software (SRS), que detalha todos os requisitos funcionais e não funcionais do sistema. Este documento tem por objetivo não apenas guiar os desenvolvedores, mas também para servir como um contrato entre desenvolvedores e clientes. Para garantir a precisão, o SRS deve ser composto de maneira clara, concisa e sem ambiguidades, incorporando diagramas de casos de uso, d_escrições de interfaces de usuário_ e protocolos de comunicação quando necessário.

Além disso, a especificação de requisitos também deve considerar a adaptabilidade do sistema a mudanças futuras, uma prática conhecida como “design para mudança”. Isso é crucial em ambientes de negócios que evoluem rapidamente, onde as necessidades podem mudar no meio de um projeto. Para facilitar essa flexibilidade, técnicas de modelagem como UML (Unified Modeling Language) são frequentemente utilizadas para criar representações visuais que são fáceis de entender e modificar.

Durante esta fase, a colaboração contínua com os stakeholders é vital para refinar a especificação e garantir que ela atenda às suas necessidades e expectativas. Workshops de validação e revisões frequentes do documento com todas as partes interessadas ajudam a evitar mal-entendidos e garantem que o produto final esteja alinhado com as necessidades do negócio.

Técnicas de Elicitação de Requisitos

Vimos anteriormente que é durante a fase de elicitação de requisitos que as necessidades dos stakeholders são identificadas, compreendidas e documentadas. Mostramos também que uma elicitação eficaz é crucial para o sucesso do projeto, uma vez que falhas nesta etapa podem levar a discrepâncias significativas entre o produto final e as expectativas dos usuários. Esta seção explora diversas técnicas de elicitação de requisitos, oferecendo insights sobre como cada uma pode ser aplicada para maximizar a compreensão das necessidades do usuário.

Entrevistas

Dentro do espectro das técnicas de elicitação de requisitos, as entrevistas se destacam pela sua capacidade de oferecer insights profundos e personalizados sobre as necessidades e expectativas dos stakeholders. Esta subseção explora como as entrevistas podem ser estruturadas e otimizadas para maximizar a qualidade dos requisitos coletados no desenvolvimento de software.

As entrevistas, quando bem conduzidas, permitem uma comunicação direta e efetiva com os usuários e stakeholders, proporcionando um entendimento detalhado de suas necessidades. Para serem eficazes, elas devem ser cuidadosamente planejadas com perguntas abertas que estimulem os entrevistados a compartilhar suas experiências e visões sem restrições. A técnica de entrevista pode ser adaptada para diferentes tipos de projetos e stakeholders, variando entre entrevistas estruturadas, semi-estruturadas e não estruturadas, dependendo do nível de flexibilidade desejado e da profundidade de informação requerida.

Em entrevistas estruturadas, um roteiro fixo de perguntas é seguido, o que é ideal para coletar dados específicos e comparáveis entre diversos entrevistados. Já as entrevistas semi-estruturadas combinam perguntas pré-definidas com a oportunidade de explorar tópicos que emergem durante a conversa, oferecendo um equilíbrio entre a obtenção de respostas diretas e a exploração de novas ideias. As entrevistas não estruturadas são particularmente úteis em fases iniciais de projetos exploratórios, onde o entendimento do domínio ainda está sendo formado.

Para maximizar o potencial das entrevistas, é crucial que o entrevistador possua habilidades de comunicação efetiva, empatia e capacidade de escuta ativa. Essas competências ajudam a criar um ambiente onde os entrevistados se sentem confortáveis para expressar suas verdadeiras necessidades e preocupações. Além disso, a utilização de técnicas como a repetição e o resumo das respostas ajuda a confirmar o entendimento das necessidades expressas, minimizando o risco de mal-entendidos.

Entretanto, é evidente que esta técnica não apenas coleta dados essenciais para a definição de requisitos, mas também estreita o relacionamento entre desenvolvedores e usuários, facilitando um projeto mais alinhado às expectativas dos stakeholders. Avançando, a próxima seção abordará os Workshops, outra técnica fundamental que complementa as entrevistas ao reunir múltiplos stakeholders para um diálogo enriquecedor e colaborativo.

Workshops

Workshops de elicitação de requisitos representam uma técnica colaborativa para a consolidação de entendimentos e a resolução de conflitos entre diferentes stakeholders. Este método de interação em grupo proporciona uma plataforma dinâmica para a exploração profunda e o alinhamento das expectativas dos usuários, elementos essenciais para a definição precisa dos requisitos de um sistema ou produto de software.

Os workshops são particularmente eficazes devido à sua natureza interativa, que facilita a comunicação direta entre diferentes partes interessadas, incluindo usuários finais, gerentes de projeto, desenvolvedores e designers. Ao reunir esses diferentes atores em um ambiente estruturado, os workshops permitem não apenas a coleta de requisitos, mas também a identificação imediata e tratamento de qualquer discrepância ou mal-entendido que possa surgir entre as partes.

Para maximizar a eficácia dos workshops, é essencial empregar técnicas de facilitação que engajem todos os participantes. Estas podem incluir atividades como brainstorming, card sorting, desenvolvimento de cenários de uso, personas e role-playing. Essas atividades são projetadas para estimular a criatividade e encorajar a participação ativa, garantindo que as necessidades e expectativas de todos os stakeholders sejam adequadamente exploradas e documentadas.

Além disso, a utilização de ferramentas visuais, como quadros brancos, post-its e diagramas, pode ajudar na visualização e no entendimento compartilhado dos requisitos. Essas ferramentas visuais são particularmente úteis para mapear processos, definir interfaces de usuário e detalhar fluxos de trabalho, elementos que são frequentemente complexos e difíceis de descrever apenas verbalmente.

Ao final de um workshop bem-sucedido, os participantes devem ter uma compreensão clara e consensual dos requisitos, preparados para serem formalizados em documentos de especificação. Este consenso é premissa para a próxima fase do desenvolvimento, onde esses requisitos serão transformados em funcionalidades concretas do software.

Observação e Shadowing

A observação direta e o shadowing são técnicas de elicitação de requisitos que oferecem uma visão profunda e autêntica sobre como os usuários interagem com sistemas existentes ou realizam suas atividades diárias sem a influência direta de um sistema. Essas técnicas são especialmente valiosas em contextos onde as descrições verbais dos usuários podem não capturar completamente a essência de suas necessidades ou onde os processos são tão intrincados que apenas a observação pode revelar os detalhes cruciais.

Durante a observação, analistas de requisitos visualizam os usuários em seu ambiente natural de trabalho, o que proporciona insights não apenas sobre como uma tarefa é realizada, mas também sobre os desafios, ineficiências e as adaptações que os usuários incorporam em suas rotinas diárias. Esta técnica é particularmente eficaz para identificar requisitos não articulados - aqueles que os usuários podem considerar tão fundamentais que eles os omitem em descrições ou que eles próprios podem não ter consciência de sua importância.

O shadowing, uma forma mais intensiva de observação, envolve seguir um usuário durante um período de tempo enquanto ele realiza suas tarefas regulares. Isso permite que o analista de requisitos ganhe uma compreensão contextual da utilização do sistema, identificando pontos onde melhorias podem ser necessárias ou onde novas funcionalidades poderiam ser introduzidas para aumentar a eficiência ou a eficácia do trabalho do usuário.

Essas técnicas são complementadas por entrevistas e questionários que podem ser conduzidos após as sessões de observação para esclarecer observações e discutir possíveis melhorias com os usuários. Essa abordagem integrada ajuda a garantir que os requisitos capturados sejam tanto precisos quanto relevantes, baseando o desenvolvimento do software em uma compreensão real das necessidades do usuário.

Ao passar de uma abordagem passiva de observação para interações mais diretas em técnicas subsequentes, como prototipagem, a próxima seção explora como os insights obtidos podem ser validados e refinados com os usuários para moldar soluções ainda mais alinhadas com suas expectativas e necessidades reais.

Prototipagem

A prototipagem – ou prototipação – é uma técnica de elicitação de requisitos altamente interativa e visual que desempenha um papel crucial especialmente em projetos que envolvem interfaces de usuário complexas ou novas funcionalidades. Este método permite aos desenvolvedores e stakeholders explorarem ideias de design e interagirem com representações funcionais ou não funcionais do produto final, facilitando a identificação e a comunicação de requisitos de maneira intuitiva e tangível.

Ao criar protótipos, as equipes podem testar conceitos, experimentar diferentes abordagens de design e avaliar a usabilidade antes do desenvolvimento completo. Isso não só ajuda a evitar mal-entendidos sobre as expectativas do produto mas também permite ajustes rápidos em resposta ao feedback dos usuários. A prototipagem pode variar desde esboços em papel até modelos interativos de alta fidelidade, dependendo do estágio do projeto e dos recursos disponíveis.

Uma das grandes vantagens da prototipagem é sua capacidade de demonstrar funcionalidades em tempo real, permitindo que os usuários finais e os stakeholders forneçam feedback direto sobre a utilidade e a adequação do design. Isso é particularmente valioso em ambientes ágeis, onde a iteratividade e a capacidade de adaptação rápida são essenciais. Além disso, protótipos funcionais ajudam a equipe de desenvolvimento a compreender melhor as complexidades técnicas do projeto, guiando o planejamento e a execução mais eficaz na construção (codificação).

A técnica de prototipagem também é um excelente meio de facilitar a colaboração entre equipes multidisciplinares, incluindo designers, desenvolvedores, gerentes de produto e usuários finais. Ao visualizar as ideias e testar funcionalidades em um estágio inicial, as equipes podem resolver problemas de design e requisitos técnicos de maneira proativa, evitando retrabalho significativo nas fases posteriores de desenvolvimento.

Avançando, a próxima seção explorará a Análise de Documentos, detalhando como essa técnica complementa a prototipagem ao fornecer uma base sólida de requisitos documentados que apoiam o desenvolvimento e a implementação de software. Este progresso assegura uma transição suave de ideias conceituais para soluções de software concretas e eficazes, consolidando os insights obtidos através de métodos interativos como a prototipagem.

Análise de Documentos

A análise de documentos é uma técnica de elicitação de requisitos especialmente valiosa em ambientes onde os sistemas precisam se conformar com normas regulatórias ou quando estão sendo feitas melhorias em sistemas já existentes. Esta técnica envolve o exame detalhado de documentação existente, incluindo relatórios técnicos, manuais de usuário, especificações de software anteriores e até mesmo e-mails e comunicações de projeto.

O valor da análise de documentos reside na sua capacidade de proporcionar uma base sólida de conhecimento que pode ser usada para entender melhor o contexto do projeto, as funcionalidades existentes e as limitações dos sistemas atuais. Esta abordagem é particularmente eficaz para identificar requisitos que foram implícitos ou não documentados em iterações anteriores do sistema, ajudando a garantir que nenhuma funcionalidade crítica seja perdida em novas versões.

Além de consolidar o entendimento sobre o sistema, a análise de documentos permite aos analistas de requisitos identificar discrepâncias ou conflitos nos requisitos existentes, o que pode orientar discussões futuras com stakeholders e usuários finais. Este processo também ajuda a definir o escopo do projeto de maneira mais clara, alinhando as expectativas e reduzindo o risco de derrapagens no projeto devido a mal-entendidos ou suposições incorretas.

Para implementar efetivamente a análise de documentos, os analistas devem adotar uma abordagem metodológica, criando um inventário de todos os documentos disponíveis, identificando as partes relevantes para o projeto atual e resumindo os pontos chave que influenciarão a definição de requisitos. Este trabalho preparatório é essencial para garantir que a fase de análise seja tanto abrangente quanto focada.

Considerações sopbre a escolha das técnicas mais adequadas

Ao concluir esta seção sobre técnicas de elicitação, é evidente que a escolha da técnica apropriada depende do contexto específico do projeto e das características dos stakeholders envolvidos. A integração dessas técnicas pode proporcionar uma visão abrangente das necessidades do projeto, fundamentando o desenvolvimento subsequente em um entendimento sólido e detalhado dos requisitos.

Histórias do usuário

Histórias de usuário são uma técnica fundamental no desenvolvimento ágil de software. Elas ajudam a capturar requisitos de uma maneira que seja compreensível tanto para os desenvolvedores quanto para os clientes e usuários finais. Vamos explorar o que são, para que servem e como construir e usar histórias de usuário.

O que são Histórias de usuário?

Histórias de usuário são descrições breves e simples de uma funcionalidade ou característica de um sistema, escritas da perspectiva do usuário final. Elas são utilizadas no desenvolvimento ágil para capturar requisitos de software de maneira que enfatize o valor para o usuário. Aqui está uma estrutura típica de uma história de usuário:

Como [tipo de usuário], eu quero [ação] para [benefício].

Exemplo:

“Como um usuário do sistema de e-commerce, eu quero poder filtrar produtos por categoria para que eu possa encontrar facilmente o que estou procurando.”

Componentes Principais:

• Título: Uma frase curta que resume a história.
• Descrição: Detalhes da história em formato “Como , eu quero para ".
• Critérios de Aceitação: Condições que definem quando a história está completa e funcionando conforme o esperado.
• Tarefas: Passos específicos que a equipe de desenvolvimento deve seguir para implementar a história.

Benefícios das Histórias de Usuário:

1. Foco no Usuário: Mantém a equipe centrada nas necessidades dos usuários.
2. Comunicação Clara: Facilita a comunicação entre membros da equipe e stakeholders.
3. Flexibilidade: Permite adaptações e mudanças rápidas no desenvolvimento do software.
4. Critérios de Aceitação: Proporciona clareza sobre o que é necessário para que a funcionalidade seja considerada completa.

Exemplo de Critérios de Aceitação:

• O usuário pode selecionar uma categoria de uma lista.
• Apenas produtos da categoria selecionada são exibidos.
• O filtro é aplicado sem necessidade de recarregar a página.

Histórias de usuário são uma ferramenta poderosa no desenvolvimento ágil, ajudando a garantir que as funcionalidades desenvolvidas realmente atendam às necessidades dos usuários finais.

Para que servem?

As histórias de usuário têm várias finalidades:

1. Capturar Requisitos: Elas ajudam a capturar o que os usuários realmente precisam e querem, mantendo o foco nos benefícios e no valor.
2. Comunicação: Facilitam a comunicação entre stakeholders (clientes, usuários, desenvolvedores, etc.), garantindo que todos entendam as necessidades de maneira uniforme.
3. Planejamento e Prioritização: Auxiliam na priorização do backlog do produto, permitindo que a equipe de desenvolvimento foque no que é mais importante para o usuário.
4. Base para Discussão: Servem como um ponto de partida para discussões detalhadas sobre a implementação da funcionalidade.

Como Construir Histórias de Usuário:

1. Identificar os Usuários: Comece identificando os diferentes tipos de usuários do seu sistema. Estes podem ser clientes, administradores, fornecedores, etc.
2. Entender as Necessidades: Compreenda o que cada tipo de usuário precisa realizar no sistema.
3. Escrever as Histórias: Use o formato padrão para escrever as histórias de usuário. Certifique-se de incluir o tipo de usuário, a ação desejada e o benefício esperado.

Exemplo:

Como cliente, eu quero visualizar o histórico de pedidos para rastrear minhas compras anteriores.

Exemplos de Histórias de Usuário:

1. Como administrador, eu quero gerar relatórios mensais para analisar o desempenho das vendas.
2. Como usuário, eu quero resetar minha senha para poder acessar minha conta se esquecer minha senha atual.
3. Como fornecedor, eu quero atualizar o status do pedido para manter os clientes informados sobre o andamento das suas compras.

Usando Histórias de Usuário:

1. Discussão e Refinamento: As histórias de usuário devem ser discutidas com a equipe de desenvolvimento para garantir que todos entendam os requisitos e possam fornecer feedback.
2. Divisão em Tarefas: Quebre as histórias de usuário em tarefas menores e mais gerenciáveis durante as reuniões de planejamento de sprint.
3. Aceitação e Teste: Defina critérios de aceitação para cada história de usuário, que servirão como base para testar e validar a implementação.

Boas Práticas

O acrônimo INVEST é uma técnica amplamente utilizada para garantir que as histórias de usuário sejam eficazes e úteis para o desenvolvimento ágil. Use-o para garantir que as histórias de usuário sejam:

• Independentes
• Negociáveis
• Valiosas
• Estimáveis
• Sucintas (Small)
• Testáveis

Vamos detalhar cada um dos componentes do INVEST:

I - Independente (Independent)

Histórias de usuário devem ser independentes entre si, de modo que possam ser desenvolvidas, testadas e entregues de forma isolada.

Por quê?

• Facilita a priorização e o planejamento do backlog.
• Reduz o risco de bloqueios durante o desenvolvimento, uma vez que uma história não depende de outra para ser concluída.

Como?

• Evite criar histórias que dependem fortemente de outras funcionalidades.
• Se uma história for muito complexa, considere dividi-la em partes menores, mas ainda independentes.

N - Negociável (Negotiable)

Histórias de usuário devem ser vistas como um convite para a conversa, e não como requisitos rígidos.

Por quê?

• Promove a colaboração e a comunicação contínua entre os stakeholders e a equipe de desenvolvimento.
• Permite ajustes e refinamentos conforme novas informações surgem ou requisitos mudam.

Como?

• Escreva histórias de usuário de forma que haja espaço para discussão e adaptação.
• Utilize as histórias como ponto de partida para discussões detalhadas.

V - Valiosa (Valuable)

Cada história de usuário deve agregar valor ao usuário final ou ao negócio.

Por quê?

• Garante que a equipe está trabalhando em itens que realmente importam e fazem diferença.
• Alinha o trabalho da equipe com os objetivos de negócios e as necessidades dos usuários.

Como?

• Envolva stakeholders e usuários na definição das histórias para garantir que elas realmente atendam a uma necessidade.
• Priorize histórias que ofereçam benefícios claros e tangíveis.

E - Estimável (Estimable)

Histórias de usuário devem ser suficientemente claras e detalhadas para que a equipe possa estimar o esforço necessário para implementá-las.

Por quê?

• Permite um planejamento mais preciso e eficiente das sprints e do backlog.
• Ajuda a identificar histórias que são muito grandes ou vagas, que podem precisar ser refinadas ou divididas.

Como?

• Detalhe claramente os critérios de aceitação.
• Envolva a equipe de desenvolvimento na discussão e no refinamento das histórias.

S - Pequena (Small)

Histórias de usuário devem ser pequenas o suficiente para serem concluídas em um curto espaço de tempo, geralmente dentro de uma sprint.

Por quê?

• Facilita o progresso contínuo e a entrega regular de funcionalidades.
• Reduz a complexidade e o risco de atrasos.

Como?

• Divida histórias grandes em menores e mais gerenciáveis.
• Certifique-se de que cada história pequena ainda agrega valor e faz sentido por si só.

T - Testável (Testable)

Histórias de usuário devem incluir critérios de aceitação claros que permitam à equipe testar e verificar se a história foi implementada corretamente.

Por quê?

• Garante que a equipe possa validar o trabalho feito e garantir a qualidade.
• Facilita a definição de “pronto” para cada história.

Como?

• Defina critérios de aceitação claros e específicos para cada história.
• Envolva a equipe de QA (Quality Assurance) no processo de definição das histórias.

Exemplo Prático:

Vamos pegar um exemplo de história de usuário e aplicar os princípios INVEST:

História Original: Como cliente, quero poder adicionar itens ao carrinho de compras para que eu possa comprá-los mais tarde.

Aplicando INVEST:

1. Independente:
   • A funcionalidade de adicionar itens ao carrinho deve ser independente de outras funcionalidades como “verificar histórico de compras”.
2. Negociável:
   • Discussões com stakeholders podem refinar o que significa “adicionar itens” (quantidade, variantes, etc.).
3. Valiosa:
   • Claramente agrega valor permitindo que os clientes façam compras de forma conveniente.
4. Estimável:
   • Critérios de aceitação claros permitem que a equipe estime o esforço. Por exemplo: “Um item pode ser adicionado ao carrinho, a quantidade pode ser ajustada, e o item pode ser removido do carrinho.”
5. Pequena:
   • Se a história original for muito grande, pode ser dividida. Exemplo: “Adicionar um item”, “Ajustar a quantidade de um item”, “Remover um item”.
6. Testável:
   • Critérios de aceitação devem permitir testes claros, como “Dado que um cliente selecionou um item, quando ele clica em ‘Adicionar ao Carrinho’, então o item aparece no carrinho com a quantidade correta”.

Aplicar o acrônimo INVEST ajuda a garantir que as histórias de usuário sejam eficazes e contribuam para um desenvolvimento ágil bem-sucedido. Elas se tornam ferramentas poderosas para capturar requisitos, facilitar a comunicação, priorizar trabalho e garantir a entrega de valor contínua ao usuário final.

Outra boa prática conhecida é a SMART. Ela é uma técnica utilizada para garantir que as histórias de usuário sejam bem definidas e eficazes. O acrônimo SMART significa:

• Specific (Específica)
• Measurable (Mensurável)
• Achievable (Atingível)
• Relevant (Relevante)
• Time-boxed (Limitada no Tempo)

Vamos detalhar cada um desses componentes:

S - Specific (Específica)

Histórias de usuário devem ser específicas o suficiente para que todos entendam exatamente o que é esperado.

Por quê?

• Evita ambiguidades e mal-entendidos.
• Facilita a compreensão clara dos requisitos e expectativas.

Como?

• Descreva a história de usuário com detalhes suficientes para que ela seja compreendida sem precisar de muitas suposições.
• Inclua informações sobre quem é o usuário, o que eles querem fazer e por quê.

M - Measurable (Mensurável)

Histórias de usuário devem ser mensuráveis para que seja possível determinar quando estão completas.

Por quê?

• Ajuda a definir critérios claros de aceitação.
• Garante que todos saibam como o sucesso será medido.

Como?

• Defina critérios de aceitação claros e objetivos que possam ser verificados.
• Inclua métricas ou condições que indiquem a conclusão da história.

A - Achievable (Atingível)

Histórias de usuário devem ser realizáveis dentro do tempo e recursos disponíveis.

Por quê?

• Assegura que as histórias podem ser completadas dentro de uma sprint ou ciclo de desenvolvimento.
• Evita frustração e sobrecarga da equipe de desenvolvimento.

Como?

• Verifique se a história é pequena o suficiente para ser completada dentro de um sprint.
• Divida histórias grandes em menores que sejam mais manejáveis.

R - Relevant (Relevante)

Histórias de usuário devem ser relevantes e alinhadas com os objetivos do negócio e as necessidades dos usuários.

Por quê?

• Garante que o trabalho realizado agrega valor ao negócio e aos usuários finais.
• Mantém o foco da equipe em prioridades importantes.

Como?

• Relacione cada história aos objetivos de negócios e necessidades dos usuários.
• Priorize histórias que tenham impacto significativo.

T - Time-boxed (Limitada no Tempo)

Histórias de usuário devem ser concluídas dentro de um período de tempo específico.

Por quê?

• Facilita o planejamento e a previsão do progresso.
• Garante que as entregas são feitas regularmente e dentro do cronograma.

Como?

• Planeje histórias de usuário que possam ser completadas dentro de uma sprint.
• Use técnicas de estimativa para garantir que as histórias sejam adequadamente dimensionadas.

Exemplo Prático:

Vamos pegar um exemplo de história de usuário e aplicar os princípios SMART:

História Original: Como cliente, quero poder adicionar itens ao carrinho de compras para que eu possa comprá-los mais tarde.

Aplicando SMART:

1. Específica (Specific):
   • Como cliente, quero poder adicionar itens específicos ao meu carrinho de compras para que eu possa revisá-los e comprá-los mais tarde.
2. Mensurável (Measurable):
   • Critérios de aceitação: O cliente pode adicionar um item ao carrinho, visualizar os itens no carrinho e ver a quantidade total de itens e o preço total.
3. Atingível (Achievable):
   • A funcionalidade de adicionar itens ao carrinho deve ser pequena o suficiente para ser desenvolvida e testada dentro de uma sprint.
4. Relevante (Relevant):
   • A capacidade de adicionar itens ao carrinho é essencial para a funcionalidade de um site de ecommerce e melhora a experiência do usuário.
5. Limitada no Tempo (Time-boxed):
   • Esta história deve ser completada dentro da próxima sprint de duas semanas.

Aplicar o acrônimo SMART ajuda a garantir que as histórias de usuário sejam claras, mensuráveis, realizáveis, relevantes e limitadas no tempo. Isso facilita o planejamento, a execução e a entrega de funcionalidades que realmente agregam valor ao usuário final e ao negócio.

E, outra boa prática é a Colaboração Contínua. Ela é fundamental para o sucesso de projetos de software, especialmente em ambientes ágeis. Vamos explorar o que é, por que é importante e como implementá-la de forma eficaz.

A colaboração contínua é a prática de manter uma comunicação constante e aberta entre todos os membros da equipe e os stakeholders durante todo o ciclo de vida do desenvolvimento de software.

Por Que a Colaboração Contínua é Importante?

1. Alinhamento de Visões:
   • Garante que todos os membros da equipe compartilhem a mesma visão e entendam os objetivos do projeto.
   • Facilita o alinhamento entre as expectativas dos stakeholders e as entregas da equipe de desenvolvimento.
2. Identificação Precoce de Problemas:
   • Permite a detecção precoce de problemas e obstáculos, possibilitando a resolução rápida antes que eles se tornem críticos.
   • Ajuda a evitar mal-entendidos e ambiguidades que podem levar a retrabalho e atrasos.
3. Melhoria Contínua:
   • Promove um ambiente de feedback constante, onde todos podem sugerir melhorias e ajustar processos.
   • Facilita a aprendizagem e o crescimento contínuo da equipe, melhorando a qualidade do produto final.
4. Maior Engajamento e Motivação:
   • Estimula um sentimento de pertencimento e responsabilidade entre os membros da equipe.
   • Aumenta a motivação, pois todos veem como suas contribuições impactam o sucesso do projeto.

Como Implementar a Colaboração Contínua?

1. Reuniões Diárias (Daily Stand-ups):
   • Realize reuniões curtas diárias onde cada membro da equipe compartilha o que fez no dia anterior, o que planeja fazer no dia atual e quaisquer impedimentos que estejam enfrentando.
   • Mantém todos informados sobre o progresso e problemas do projeto.
2. Reuniões de Planejamento de Sprint:
   • Envolva toda a equipe na definição das histórias de usuário e na priorização do backlog.
   • Assegura que todos compreendam as metas da sprint e saibam o que precisa ser feito.
3. Reuniões de Revisão e Retrospectiva:
   • Realize reuniões de revisão ao final de cada sprint para demonstrar o trabalho concluído aos stakeholders e coletar feedback.
   • Conduza retrospectivas para discutir o que funcionou bem, o que não funcionou e como a equipe pode melhorar continuamente.
4. Ferramentas de Comunicação e Colaboração:
   • Utilize ferramentas como Slack, Microsoft Teams, Jira, Trello e outras para facilitar a comunicação e a colaboração.
   • Mantenha toda a documentação, código e comunicação acessíveis e organizados.
5. Pair Programming e Revisões de Código:
   • Incentive o desenvolvimento em pares (pair programming) para melhorar a qualidade do código e compartilhar conhecimento.
   • Realize revisões de código regulares para garantir que todos os membros da equipe estejam cientes das mudanças e possam contribuir com melhorias.
6. Feedback Contínuo:
   • Estabeleça canais de feedback contínuo entre a equipe de desenvolvimento e os stakeholders.
   • Utilize técnicas como o NPS (Net Promoter Score) para medir a satisfação dos stakeholders e identificar áreas de melhoria.
7. Colaboração com Stakeholders:
   • Mantenha uma comunicação aberta e regular com os stakeholders para garantir que suas necessidades e expectativas estejam sendo atendidas.
   • Involva os stakeholders em fases críticas do projeto, como planejamento, revisão e testes.

Exemplo Prático

Reunião Diária (Daily Stand-up):

• O que fiz ontem:
  • Trabalhei na implementação da funcionalidade de login.
• O que vou fazer hoje:
  • Continuar a trabalhar na funcionalidade de login e começar a integração com a API de autenticação.
• Impedimentos:
  • Preciso de acesso à documentação da API que está com o time de segurança.

Ferramenta de Comunicação:

• Slack Channel:
  • Canal #desenvolvimento para discussões técnicas e atualizações diárias.
  • Canal #geral para comunicações de toda a equipe e anúncios importantes.

A colaboração contínua é essencial para o sucesso de projetos de software ágeis. Ela garante que todos os membros da equipe e stakeholders estejam alinhados, permite a identificação precoce de problemas, promove a melhoria contínua e aumenta o engajamento e a motivação. Implementando práticas como reuniões diárias, ferramentas de comunicação eficazes e feedback contínuo, as equipes podem melhorar significativamente a qualidade e a eficiência do desenvolvimento de software.

Como as HUs se relacionam, ou se conectam, com os testes segundo BDD?

Behavior-Driven Development (BDD) é uma abordagem de desenvolvimento ágil que promove a colaboração entre desenvolvedores, QA e não-programadores ou stakeholders. As histórias de usuário desempenham um papel fundamental no BDD, pois elas fornecem o contexto e os requisitos que guiam a criação de testes comportamentais.

Aqui está como as histórias de usuário se relacionam com os testes em BDD:

1. Definição de Cenários:
   • Cada história de usuário é expandida em um ou mais cenários de teste. Esses cenários descrevem situações específicas que devem ser testadas para garantir que a funcionalidade desejada esteja correta.
   • Os cenários de teste são geralmente escritos em uma linguagem simples e estruturada, como o Gherkin, que usa palavras-chave como “Given” (Dado), “When” (Quando), “Then” (Então) para descrever as pré-condições, ações e resultados esperados.
2. Estrutura dos Cenários de Teste:
   • Given (Dado): Define o contexto inicial do teste, como o estado do sistema antes da ação.
   • When (Quando): Descreve a ação que o usuário realiza.
   • Then (Então): Especifica o resultado esperado após a ação.
3. Exemplo de História de Usuário e Cenário de Teste BDD:
   • História de Usuário: “Como um usuário do sistema de e-commerce, eu quero poder filtrar produtos por categoria para que eu possa encontrar facilmente o que estou procurando.”
   • Cenário de Teste BDD:

     Cenário: Filtrar produtos por categoria
       Dado que existem produtos nas categorias "Eletrônicos" e "Roupas"
       E eu estou na página de listagem de produtos
       Quando eu seleciono a categoria "Eletrônicos"
       Então apenas os produtos da categoria "Eletrônicos" devem ser exibidos
     

4. Automação de Testes:
   • Os cenários de teste escritos em Gherkin podem ser automatizados usando ferramentas como Cucumber, SpecFlow ou Behave.
   • Essas ferramentas mapeiam as etapas definidas nos cenários para código de automação que executa as ações e verifica os resultados esperados.
5. Benefícios da Integração entre Histórias de Usuário e BDD:
   • Clareza e Colaboração: Facilita a comunicação entre todos os envolvidos no projeto, garantindo que todos tenham um entendimento comum dos requisitos e expectativas.
   • Documentação Viva: Os cenários de teste servem como documentação viva que reflete o comportamento atual do sistema.
   • Feedback Rápido: A automação de testes permite que os testes sejam executados continuamente, fornecendo feedback rápido sobre a qualidade do software e detectando problemas rapidamente.
6. Ciclo de Desenvolvimento BDD:
   • Escreva a história de usuário com critérios de aceitação claros.
   • Defina cenários de teste para cada critério de aceitação.
   • Automatize os cenários usando uma ferramenta BDD.
   • Desenvolva a funcionalidade até que todos os testes automatizados passem.
   • Refatore conforme necessário, garantindo que os testes ainda passem.

Integrando histórias de usuário e BDD, as equipes de desenvolvimento podem garantir que estão construindo software que realmente atende às necessidades dos usuários, ao mesmo tempo em que mantêm alta qualidade e facilitam a colaboração e a comunicação.

Ferramentas e Técnicas para Documentação e Gerenciamento de Requisitos

A documentação e gerenciamento de requisitos são aspectos cruciais no ciclo de vida do desenvolvimento de software, garantindo que as necessidades dos stakeholders sejam adequadamente capturadas, compreendidas e atendidas ao longo do projeto. Esta seção aborda as ferramentas e técnicas mais eficazes para realizar estas tarefas, destacando como cada uma pode ser aplicada para otimizar o processo de desenvolvimento.

Ferramentas de Gerenciamento de Requisitos

O gerenciamento de requisitos exige ferramentas que possam ajudar a organizar, rastrear e manter o controle das mudanças ao longo do projeto. Softwares como JIRA, Trello e Microsoft Azure DevOps são amplamente utilizados por sua capacidade de integrar tarefas de planejamento, rastreamento e colaboração em uma única plataforma. Essas ferramentas permitem que equipes criem e gerenciem backlogs, planos de sprint e dashboards de projetos, facilitando a visibilidade do progresso e ajudando na identificação precoce de desvios ou problemas.

Técnicas de Documentação de Requisitos

A documentação de requisitos é fundamental para garantir que todos os envolvidos no projeto tenham uma compreensão clara do que precisa ser feito. Métodos tradicionais, como a criação de Especificações de Requisitos de Software (SRS), continuam sendo essenciais. No entanto, técnicas ágeis, como user stories e critérios de aceitação, também são amplamente adotadas para capturar requisitos de uma maneira mais dinâmica e integrada ao ciclo de desenvolvimento ágil.

User stories, por exemplo, são uma forma eficaz de capturar requisitos em linguagem natural, facilitando o entendimento entre desenvolvedores e stakeholders não técnicos. Essas histórias ajudam a moldar o desenvolvimento focando nas necessidades reais do usuário, garantindo que o produto final seja verdadeiramente valioso para o cliente.

Integração e Colaboração

A eficácia na documentação e gerenciamento de requisitos muitas vezes depende da capacidade das ferramentas e técnicas em facilitar a colaboração entre equipes dispersas geograficamente. Ferramentas modernas de colaboração, como Confluence e Slack, integram-se perfeitamente com plataformas de gerenciamento de requisitos para permitir a comunicação contínua e o compartilhamento eficiente de informações. Essa integração assegura que todas as partes interessadas estejam alinhadas e possam contribuir ativamente para o refinamento dos requisitos ao longo do projeto.

Considerações sopbre a escolha das ferramentas mais adequada

Da mesma forma que para a escolha das técnicas de elicitação, é evidente que a escolha de ferramentas e técnicas adequadas para a documentação e gerenciamento de requisitos pode significativamente influenciar o sucesso de um projeto de software. A próxima seção continuará a explorar como essas práticas são implementadas na vida real, fornecendo exemplos concretos e discutindo melhores práticas para enfrentar os desafios comuns no gerenciamento de requisitos.

Validação e Verificação de Requisitos

A validação e verificação de requisitos são etapas que buscam assegurar que o produto final esteja alinhado com as necessidades e expectativas dos stakeholders e que funcione conforme especificado. Esta seção explora as metodologias e práticas que garantem a corretude dos requisitos desde a sua concepção até a implementação final.

Validação de Requisitos

A validação de requisitos é o processo de garantir que os requisitos realmente refletem as necessidades do usuário e que todas as necessidades foram adequadamente compreendidas e documentadas. Esta etapa envolve revisões e avaliações com stakeholders para confirmar que os requisitos estão completos e são viáveis. Técnicas como revisões de requisitos, prototipagem para feedback do usuário, e sessões de validação de requisitos com o uso de cenários e casos de uso são comuns.

Cada requisito deve ser testado contra critérios de aceitação claramente definidos, e quaisquer inconsistências ou ambiguidades devem ser resolvidas. Isto é crucial para evitar problemas no desenvolvimento subsequente e para minimizar mudanças de escopo que podem causar atrasos e aumentar custos.

Verificação de Requisitos

A verificação de requisitos se concentra em garantir que o produto desenvolvido esteja em conformidade com os requisitos especificados. Esta fase envolve uma série de atividades técnicas que podem incluir testes de software, análises estáticas e revisões de código. A verificação é essencial para detectar e corrigir erros ou omissões nos estágios iniciais do ciclo de vida de desenvolvimento, antes que eles se tornem mais complexos e dispendiosos para resolver.

Durante a verificação, é vital utilizar técnicas rigorosas de teste, como testes de unidade, integração, sistema e aceitação, para garantir que cada requisito seja completamente testado em todos os cenários relevantes. Ferramentas automatizadas de teste e integração contínua podem desempenhar um papel significativo na eficiência desta etapa, proporcionando feedback rápido e frequente sobre a qualidade do software.

Gestão de Mudanças em Requisitos

A gestão de mudanças em requisitos é uma componente transversal a toda gestão de requisitos no ciclo de desenvolvimento de software que tem por objetivo tratar da capacidade de adaptar-se eficazmente às alterações nestes requisitos durante a vida útil de um projeto. Este processo existe para auxiliar no sucesso do projeto, pois tem por propósito garantir que as modificações sejam integradas de forma controlada e eficiente, minimizando perturbações e maximizando o valor entregue aos stakeholders.

Estruturação da Gestão de Mudanças

O primeiro passo para uma gestão de mudanças eficaz é estabelecer um processo claro que todos os membros da equipe entendam e sigam. Este processo deve incluir mecanismos para:

• Identificação de Mudanças: Como as mudanças são identificadas, seja por feedback de stakeholders, resultados de testes ou revisões de equipe.
• Avaliação de Impacto: Análise do impacto potencial da mudança nos requisitos existentes, na arquitetura do sistema, no cronograma do projeto e no orçamento.
• Decisão de Aprovação: Definição de quem tem autoridade para aprovar as mudanças, garantindo que decisões críticas sejam tomadas por indivíduos com conhecimento adequado e visão estratégica.
• Implementação: Planejamento e execução da mudança, incluindo a atualização da documentação de requisitos e a comunicação a todas as partes interessadas.
• Monitoramento e Avaliação: Acompanhamento do impacto das mudanças implementadas para garantir que elas atendam aos seus objetivos sem introduzir novos problemas.

Ferramentas de Apoio

Diversas ferramentas podem apoiar a gestão eficaz de mudanças em requisitos. Sistemas de rastreamento de requisitos como JIRA, IBM DOORS, ou Microsoft Azure DevOps oferecem funcionalidades robustas para registrar mudanças, avaliar impactos e manter um histórico auditável de todas as alterações. Essas ferramentas facilitam a colaboração entre equipes distribuídas e ajudam a manter a integridade dos requisitos ao longo do tempo.

Práticas Recomendadas

Para maximizar a eficácia da gestão de mudanças em requisitos, algumas práticas recomendadas incluem:

• Comunicação Clara e Frequente: Manter todas as partes interessadas informadas sobre mudanças potenciais e suas justificativas, promovendo um entendimento comum e reduzindo resistências.
• Treinamento Contínuo: Assegurar que todos os membros da equipe estejam familiarizados com as ferramentas e processos de gestão de mudanças.
• Revisões Regulares: Implementar revisões regulares dos requisitos e do progresso do projeto para identificar proativamente necessidades de mudanças.

Impacto dos Requisitos no Design e na Arquitetura de Software

A influência dos requisitos sobre o design e a arquitetura de software é profunda e multifacetada, estabelecendo as bases para as decisões de design técnico e a estruturação sistêmica do projeto de desenvolvimento. Esta seção explora como os requisitos determinam as características arquitetônicas e afetam a qualidade e a funcionalidade do software final.

Tradução de Requisitos em Design

Os requisitos são traduzidos em soluções de design através de um processo iterativo que envolve várias disciplinas dentro da equipe de desenvolvimento. Esta subseção detalha como os requisitos funcionais e não funcionais são incorporados no design de software:

• Requisitos Funcionais: Diretamente transformados em conjuntos de funcionalidades que o software deve realizar. O design deve encapsular claramente todas as operações, entradas e saídas que são especificadas pelos requisitos funcionais.
• Requisitos Não Funcionais: Influenciam o design do sistema em níveis mais profundos, incluindo performance, segurança, usabilidade e conformidade. Por exemplo, um requisito de alta disponibilidade pode levar à escolha de uma arquitetura distribuída ou à implementação de redundâncias específicas.

Arquitetura Orientada por Requisitos

A arquitetura de software serve como o esqueleto para a construção do sistema, e sua adequação é diretamente influenciada pela precisão e pela qualidade dos requisitos coletados. Aspectos críticos incluem:

• Modularidade: Os requisitos ajudam a definir como o software deve ser dividido em módulos ou componentes, facilitando o desenvolvimento, a manutenção e a escalabilidade.
• Interoperabilidade: Requisitos de integração com outros sistemas guiam as decisões sobre protocolos de comunicação e interfaces de software.
• Tecnologia e Frameworks: Requisitos específicos podem ditar o uso de certas tecnologias ou frameworks para atender às expectativas de desempenho e funcionalidade.

Desafios Comuns e Soluções

A subseção final aborda os desafios típicos encontrados na ponte entre requisitos e arquitetura, com estratégias para superá-los:

• Mudanças de Requisitos: Como gerenciar e adaptar o design e a arquitetura quando os requisitos evoluem ao longo do projeto.
• Conflitos de Requisitos: Técnicas para resolver conflitos entre requisitos concorrentes, como compromissos entre segurança e desempenho ou entre custo e capacidade.
• Validação de Arquitetura: Como garantir que a arquitetura proposta atenda aos requisitos através de revisões de design e prototipagem arquitetural.

Conclusão: Reflexões e Caminhos Futuros na Gestão de Requisitos de Software

Ao revisitar os temas abordados neste artigo sobre a “Gestão de Requisitos no Desenvolvimento de Software”, emergem diversas lições vitais e indicações claras para futuras explorações. A gestão de requisitos é um processo complexo que tem como principal resposabilidade garantir que o software desenvolvido atenda tanto às expectativas do cliente quanto às exigências do mercado.

Através das discussões sobre as várias técnicas e ferramentas para a elicitação, documentação, validação, e gerenciamento de mudanças de requisitos, fica evidente que a adaptabilidade e a comunicação eficaz são fundamentais. As metodologias ágeis, com sua ênfase na colaboração e na capacidade de resposta às mudanças, destacaram-se como especialmente adequadas para a gestão moderna de requisitos, proporcionando frameworks flexíveis que podem ser adaptados às necessidades específicas de cada projeto.

A importância de ferramentas avançadas de gestão de requisitos, como JIRA e Confluence, também foi ressaltada, demonstrando como a tecnologia pode facilitar a rastreabilidade e a comunicação entre as equipes, essenciais para o sucesso do projeto.

Olhando para o futuro, há várias áreas dentro da gestão de requisitos que prometem evolução e inovação. A integração de tecnologias emergentes, como inteligência artificial (IA) e aprendizado de máquina, pode transformar as práticas tradicionais de gestão de requisitos, oferecendo novas maneiras de analisar e predizer as necessidades dos usuários mais eficientemente.

Além disso, a crescente complexidade dos sistemas de software e a expansão dos requisitos para incluir considerações de segurança e privacidade exigirão novas estratégias e ferramentas para lidar com esses desafios de maneira eficaz.

Referências

Para aqueles interessados em aprofundar seu conhecimento e manter-se atualizado com as últimas tendências e técnicas no campo da gestão de requisitos, as seguintes fontes são recomendadas:

• Ambler, S. W. (2004). “The Object Primer: Agile Model-Driven Development with UML 2.0”. 3rd Edition. Cambridge University Press, 2004.
• Bass, L., Clements, P., & Kazman, R. (2021). “Software Architecture in Practice”. 4th Edition, Addison-Wesley Professional.
• Cohn, M. (2004). “User Stories Applied: For Agile Software Development”. Addison Wesley Longman Publishing Co., Inc., USA.
• Davis, A. M. (2005). “Just Enough Requirements Management: Where Software Development Meets Marketin”. Dorset House Publishing.
• Gottesdiener, E. (2002). “Requirements by Collaboration: Workshops for Defining Needs”. Addison-Wesley Longman Publishing Co., Inc., USA.
• Hohmann, L. (2006). “Innovation Games: Creating Breakthrough Products Through Collaborative Play”. Addison-Wesley Professional.
• Holtzblatt, K., & Beyer, H. (2017). “Contextual Design: Design for Life”. Morgan Kaufmann; 2nd edition.
• Lancaster, A. (2004). “Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces”. in IEEE Transactions on Professional Communication, vol. 47, no. 4, pp. 335-336, Dec. 2004, doi: 10.1109/TPC.2004.837973.
• Leffingwell, D. (2011). “Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise”. Addison-Wesley Professional.
• Martin, R. C. (2017). “Clean Architecture: A Craftsman’s Guide to Software Structure and Design”. Pearson.
• Dick, Jeremy; Hull, Elizabeth; Jackson, Ken. (2017). “Requirements Engineering”. Springer Cham.
• Norman, D. A. (2013). “The Design of Everyday Things: Revised and Expanded Edition”. Basic Books; Revised edition.
• Nuseibeh, B., & Easterbrook, S. (2000). “Requirements Engineering: A Roadmap”. In Proceedings of the Conference on The Future of Software Engineering (ICSE ‘00). Association for Computing Machinery, New York, NY, USA, 35–46.
• Rettig, M. (1994). “Prototyping for Tiny Fingers”. Communications of the ACM 37, 4 (April 1994), 21–27.
• Robertson, S., & Robertson, J. (2025). “Mastering the Requirements Process: Getting Requirements Right”. Addison-Wesley Professional (September 25, 2024), 4th edition.
• Rubin, K.S. (2012). “Essential Scrum: A Practical Guide to the Most Popular Agile Process”. Addison-Wesley Professional; 1st edition.
• Pohl, K.; Rupp, C. (2015). “Requirements Engineering Fundamentals: A Study Guide for the Certified Professional for Requirements Engineering Exam - Foundation Level - IREB compliant”. Rocky Nook, 2nd Edition.
• Wiegers, K. & Beatty, J. (2013). “Software Requirements (Developer Best Practices)”. Microsoft Press; 3rd edition (August 15, 2013).
• Zowghi, D., & Coulin, C. (2005). “Requirements Elicitation: A Survey of Techniques, Approaches, and Tools”. In: Aurum, A., Wohlin, C. (eds) Engineering and Managing Software Requirements. Springer, Berlin, Heidelberg.