Forem: Angelo Silva

My Spooky Cozy Haven: exploring CSS, SVGs, and interactivity for Halloween

Angelo Silva — Sat, 01 Nov 2025 17:36:49 +0000

Halloween is the perfect time to unleash creativity, and this year I decided to turn that idea into code. The result was My Spooky Cozy Haven, a project developed for the Frontend Challenge: Halloween Edition by the DEV Community.

In today’s article, I want to share how I turned limitations into experimentation, the techniques I used, and what I learned throughout the process.

🎯 The starting point

The challenge was simple to describe but complex to execute: build something interactive, responsive, and visually engaging without relying on frameworks or external libraries.

The main focus was CSS, but a touch of JavaScript could be used to enhance interactivity.

In practice, this meant:

Layouts that worked well on any screen size.
Lightweight, animated elements.
Interactions that surprised the user, including visual and sound effects.

🛠️ Technical decisions and experimentation

To turn the idea into something that really worked in practice, I had to experiment with different approaches and combine CSS, SVGs, and JavaScript techniques.

Every decision had to balance user experience, performance, and visual expressiveness, ensuring the scene ran smoothly and felt immersive on any device.

💧 CSS Fluid Scaling

To make the scene work across different screen sizes, I explored CSS Fluid Scaling. Instead of relying solely on media queries, the goal was to maintain fluid proportions and spacing, creating a consistent experience from desktop to mobile.

🕸️ Animated SVGs

SVGs were used to bring the scene to life. I modeled and animated vector elements in a lightweight and scalable way, keeping performance and accessibility in mind, as SVGs preserve visual quality without weighing down the page.

✨ Breathing glow effect

One of the most challenging effects was creating a pulsing glow from scratch, synchronized with the visual elements. I used CSS for the animation and JavaScript to anchor the effect, ensuring it responded naturally to user interaction.

🔊 Sound interactivity

To enhance immersion, I implemented sound effects triggered by keyboard on desktop and double tap on mobile, with i18n support (pt-BR and en-US) and visual instructions on how to activate them. This added an extra layer of interaction, reinforcing the playful nature of the experience.

🧠 Learnings and reflections

Beyond the visual result, this project showed me how to combine technique and storytelling, turning each element into an experience that users can feel and interact with, while respecting solid front-end fundamentals.

Key lessons:

Planning animations and interactions before coding prevents rework.
Animated SVGs can be powerful, lightweight, and accessible when structured properly.
Small details, like synchronized sound and glow effects, increase immersion without sacrificing performance.
Fluid responsiveness is essential for any modern web experience.

💻 Technologies used

HTML
CSS (Fluid Scaling, animations, and glow)
JavaScript (interactivity and effect synchronization)

If you enjoy challenges that mix creativity, technical skill, and user experience, I invite you to check out the project and explore the scene:

🔗 Online Project: https://dev-sigo.github.io/my_spooky_cozy_haven
🔗 GitHub Repo: https://github.com/dev-sigo/my_spooky_cozy_haven

My Spooky Cozy Haven: explorando CSS, SVGs e interatividade para o Halloween

Angelo Silva — Sat, 01 Nov 2025 17:29:19 +0000

O Halloween é o momento perfeito para soltar a criatividade, e este ano decidi transformar essa ideia em código. O resultado foi o My Spooky Cozy Haven, um projeto desenvolvido para o Frontend Challenge: Halloween Edition da DEV Community.

No texto de hoje, quero compartilhar como transformei limitações em experimentação, quais técnicas usei, e o que aprendi ao longo do processo.

🎯 O ponto de partida

O desafio era simples de enunciar, mas complexo de executar: construir algo interativo, responsivo e visualmente envolvente, sem recorrer a frameworks ou bibliotecas externas.

O foco seria principalmente CSS, mas um toque de JavaScript podia ser usado para incrementar interatividade.

O que isso significava na prática:

Layouts que funcionassem bem em qualquer resolução.
Elementos animados e leves.
Interações que surpreendessem o usuário, incluindo efeitos visuais e sonoros.

🛠️ Decisões técnicas e experimentação

Para transformar a ideia em algo que realmente funcionasse na prática, precisei testar diferentes abordagens e combinar técnicas de CSS, SVGs e JavaScript.

Cada escolha teve que equilibrar experiência do usuário, performance e expressividade visual, garantindo que a cena funcionasse de forma fluida e envolvente em qualquer dispositivo.

💧 CSS Fluid Scaling

Para garantir que a cena funcionasse em telas de diferentes tamanhos, explorei CSS Fluid Scaling. Em vez de depender apenas de media queries, a ideia era manter proporções e espaçamentos fluídos, criando uma experiência consistente do desktop ao mobile.

🕸️ SVGs animados

SVGs foram usados para dar vida à cena. Modelei e animei elementos vetoriais de forma leve e escalável, pensando em performance e acessibilidade, já que SVGs permitem manter qualidade visual sem pesar a página.

✨ Efeito de breathing glow

Um dos efeitos mais desafiadores foi criar do zero um glow pulsante, sincronizado com elementos visuais. Usei CSS para a animação e JavaScript para ancorar o efeito, garantindo que ele respondesse naturalmente à interação do usuário.

🔊 Interatividade sonora

Para aumentar a imersão, implementei efeitos sonoros acionados por tecla no desktop e double tap no mobile, com suporte a i18n (pt-BR e en-US) e instruções visuais de como ativá-los. Isso trouxe uma camada extra de interação, reforçando o caráter lúdico da experiência.

🧠 Aprendizados e reflexões

Mais do que o resultado visual, esse projeto me mostrou como combinar técnica e narrativa, tornando cada elemento uma experiência que o usuário sente e interage, mas que também respeita fundamentos sólidos de front-end.

Principais lições:

Planejar animações e interações antes de codar evita retrabalho.
SVGs animados podem ser poderosos, leves e acessíveis quando bem estruturados.
Pequenos detalhes, como efeitos sonoros e glow sincronizado, aumentam imersão sem sacrificar performance.
Responsividade fluida é essencial para qualquer experiência web hoje.

💻 Tecnologias usadas

HTML
CSS (Fluid Scaling, animações e glow)
JavaScript (interatividade e sincronização de efeitos)

Se você gosta de desafios que misturam criatividade, técnica e experiência do usuário, convido você a conferir o projeto e apreciar a cena:

🔗 Projeto Online: https://dev-sigo.github.io/my_spooky_cozy_haven
🔗 Repo no GitHub: https://github.com/dev-sigo/my_spooky_cozy_haven

De "Faça uma Casa" a um Blueprint Perfeito: 5 Maneiras de Extrair Requisitos Claros de Stakeholders Indecisos

Angelo Silva — Sat, 25 Oct 2025 13:09:36 +0000

💭 Já recebeu uma demanda que soava mais como um enigma do que um projeto?

Algo do tipo: “precisamos de um sistema que faça isso aqui… sabe?”

Essa é a clássica situação do “faça uma casa”, quando o cliente sabe que precisa de um teto, mas não consegue descrever quantos cômodos, janelas ou portas.

E é exatamente aí que mora o perigo: os requisitos invisíveis.

Eles são os maiores responsáveis por retrabalho, escopo indefinido e produtos que não resolvem o problema real.

Mas aqui vai o ponto central: stakeholders não precisam ter todas as respostas.

Quem precisa fazer as perguntas certas somos nós.

Neste artigo, compartilho 5 técnicas práticas que transformam o caos das ideias vagas em um blueprint claro e acionável.

1. 🗣️ Vá Além do "Sim" ou "Não": Priorize Perguntas Abertas

Perguntas fechadas são aquelas que podem ser respondidas com "sim", "não" ou uma opção de múltipla escolha.

Elas são excelentes para validar informações já conhecidas.

No entanto, para a fase de descoberta, o verdadeiro valor está nas perguntas abertas, que incentivam respostas detalhadas e subjetivas.

Isso permite que os stakeholders explorem o problema em seus próprios termos.

Em um estudo de caso sobre o projeto SAPPE, um simulador de provas do ENADE, a equipe de desenvolvimento partiu de um documento de visão que continha apenas três requisitos funcionais.

Ao aplicar técnicas como entrevistas e questionários com perguntas abertas, eles conseguiram identificar seis novos requisitos funcionais, mais que dobrando o escopo conhecido do sistema.

Por que isso funciona?

O estudo conclui que:

“A utilização de perguntas abertas facilita a identificação de requisitos que não poderiam ser descobertos com perguntas fechadas.” — estudo SAPPE

Em contraste, no projeto NaData, do mesmo estudo, o uso exclusivo de questionários fechados não se mostrou eficaz para coletar requisitos.

Perguntas abertas dão aos stakeholders a liberdade para articular o problema, revelando nuances e necessidades que os analistas talvez não tivessem previsto.

Essencialmente, perguntas abertas transferem o poder da "solução" para a "exploração do problema", permitindo que você descubra o valor real em vez de apenas validar suposições.

2. ✏️ Pergunte com Protótipos: Transforme o Abstrato em Concreto

A prototipagem é uma técnica que permite "fazer perguntas" através de um modelo funcional, em vez de palavras.

Como define Danielle Teixeira, um protótipo é "a forma mais rápida e econômica de se definir e até mesmo validar um produto".

Ele transforma conceitos abstratos em algo tangível com o qual os stakeholders podem interagir.

Imagine uma equipe desenvolvendo a tela de login de um aplicativo.

Em vez de perguntar "Como você quer que a tela de login funcione?", a equipe cria um protótipo de baixa fidelidade.

Simplesmente "rabiscando" as primeiras necessidades em uma folha de papel.

Ao interagir com o rascunho, o cliente imediatamente percebe que precisa de uma opção de "Esqueci minha senha" e de login social (Google/Facebook), requisitos que não haviam sido mencionados na conversa inicial.

A partir desse feedback, a equipe pode evoluir para wireframes (média fidelidade) e mockups (alta fidelidade) para refinar os detalhes.

Como destaca o padrão IEEE Std 830, os clientes reagem de forma mais imediata e precisa a um protótipo visual do que a um documento escrito denso.

Isso é especialmente eficaz para superar a dificuldade de stakeholders que "não sabem exatamente o que querem".

Isso transforma a validação de requisitos de um exercício intelectual para uma experiência tátil, desarmando a abstração que muitas vezes esconde desalinhamentos críticos.

Um protótipo falho é um sucesso, pois representa um fracasso barato e precoce, que evita um fracasso caro e tardio no desenvolvimento.

3. 👀 Observe o Trabalho Real: Use a Etnografia para Descobrir Requisitos Ocultos

A Etnografia é uma técnica de observação na qual o analista se insere no ambiente de trabalho do cliente.

O objetivo não é perguntar como o trabalho é feito, mas sim observar "como as pessoas realmente trabalham" no seu dia a dia.

Essa imersão revela processos e necessidades que muitas vezes não são verbalizados.

Exemplo Prático: Uma equipe está criando um software para gerenciar o atendimento em um hospital.

Em entrevistas, os enfermeiros descrevem um processo de registro de pacientes que parece perfeitamente linear e organizado.

No entanto, ao observar o trabalho real, o analista percebe que os enfermeiros são constantemente interrompidos para atender emergências.

Eles colaboram de maneira informal, anotando informações temporárias em post-its colados nos monitores.

Essa observação revela um requisito crucial que jamais seria mencionado:

O sistema precisa permitir salvar rascunhos de registros e ter um mecanismo de notificação para colaboração rápida entre a equipe.

A Etnografia é poderosa para descobrir requisitos sociais e organizacionais que os stakeholders omitem, seja por acharem óbvios ou por não perceberem sua relevância para o sistema.

A Etnografia não apenas refina requisitos, ela descobre oportunidades de inovação.

Ao entender o fluxo de trabalho real, com suas interrupções e soluções improvisadas (como os post-its), você pode projetar uma solução que não apenas digitaliza um processo, mas o otimiza de uma forma que os próprios stakeholders não haviam imaginado.

4. 🎬 Construa Histórias com Cenários: Pergunte "E se…"

A técnica de Cenários estrutura a coleta de requisitos em torno de histórias de uso.

Um cenário geralmente inclui um nome, ator, pré-condições, um fluxo normal e, o mais importante, fluxos alternativos.

É na exploração dos "fluxos alternativos" que a equipe consegue descobrir os requisitos para tratamento de exceções e situações anormais.

Por Exemplo, para um sistema de caixa eletrônico (ATM), a equipe cria o cenário "Sacar dinheiro".

O fluxo normal é simples: o cliente insere o valor, confirma e o dinheiro é liberado.

A verdadeira descoberta acontece quando a equipe começa a perguntar "E se…?":

"E se o saldo for insuficiente?"
"E se o caixa não tiver notas de R$10 para compor o valor?"
"E se a conexão com o banco cair após o débito na conta, mas antes da entrega do dinheiro?"

Cada uma dessas perguntas, estruturadas pelo cenário, gera requisitos detalhados para tratamento de erros, comunicação com o usuário e transações de recuperação, que poderiam ser facilmente esquecidos.

Cenários transformam a coleta de requisitos em uma atividade de storytelling colaborativo.

Isso força stakeholders e desenvolvedores a pensarem além do "caminho feliz" e a especificarem como o sistema deve se comportar quando as coisas dão errado.

Construir cenários é construir a resiliência do produto.

A confiança do usuário não é conquistada no fluxo ideal, mas na forma como o sistema lida com a imperfeição.

A exploração dos "E se…?" é o que transforma um produto funcional em um produto confiável.

5. 🔍 Mapeie os Pontos de Vista: Entenda Quem Responde a Qual Pergunta

Diferentes stakeholders têm perspectivas, necessidades e, às vezes, requisitos conflitantes sobre o mesmo sistema.

A análise de "Pontos de Vista" (Viewpoints) é uma técnica para organizar essa complexidade, em vez de tentar criar uma solução única que agrade a todos.

"diferentes stakeholders possuem diferentes requisitos que expressam de maneira diferente" - Sommerville, Ian

Imagine que no desenvolvimento de um sistema bancário, a equipe precisa definir os requisitos para a funcionalidade de "consultar saldo".

Em vez de fazer uma pergunta genérica, eles identificam os principais pontos de vista:

Titular da conta: Precisa ver o saldo detalhado com todas as transações.
Caixa do banco: Talvez só precise saber se o saldo é suficiente para um saque, sem visualizar o valor exato, por questões de privacidade e segurança.
Gerente de contas: Pode precisar ver um histórico de saldos ao longo do tempo para fazer uma análise de crédito.

Cada ponto de vista gera um requisito funcional distinto e evita o conflito que surgiria ao tentar criar uma única tela de "consulta de saldo" para todos.

Essa técnica estrutura a elicitação, garantindo que as perguntas certas sejam feitas às pessoas certas.

Ao invés de buscar um consenso forçado, a equipe identifica e organiza as necessidades específicas de cada grupo.

Esta técnica transforma conflitos de requisitos de um obstáculo em uma ferramenta de design.

Em vez de buscar um "meio-termo" medíocre, a análise de pontos de vista permite entregar valor focado e preciso para cada grupo de stakeholders, reconhecendo que uma solução "tamanho único" raramente serve a todos com excelência.

🎨 A Arte de Fazer a Pergunta Certa é Usar a Ferramenta Certa

Fazer perguntas melhores não se resume a encontrar uma única "pergunta mágica".

Trata-se de ter um arsenal de técnicas:

perguntas abertas para explorar
protótipos para tangibilizar
observação para descobrir o oculto
cenários para testar os limites
análise de pontos de vista para organizar a complexidade

Cada uma dessas abordagens é uma ferramenta para guiar a conversa da ambiguidade à clareza.

Um processo de requisitos bem executado é a fundação de qualquer projeto de sucesso.

É a sua melhor ferramenta para evitar o retrabalho, o escopo indefinido e a insatisfação do cliente que tanto assombram nossa indústria.

Ao dominar essas técnicas, você não está apenas coletando requisitos; você está construindo um entendimento compartilhado que é o verdadeiro blueprint para o sucesso.

4 Técnicas de Elicitação que Grandes Times de Software Usam e Você Também Pode

Angelo Silva — Sat, 18 Oct 2025 23:27:44 +0000

Todo projeto de software começa com uma conversa.

Uma ideia jogada na mesa, um “e se a gente criasse um app que…”.

Mas entre o entusiasmo e a entrega existe um terreno cheio de armadilhas: entender o que realmente precisa ser construído.

🧭 De Suposições a Entendimento Compartilhado

Se você já começou um projeto achando que estava com tudo sob controle, e semanas depois percebeu que entendeu tudo errado…

Bem-vindo ao clube.

Acontece com todo mundo.

No início, tudo parece claro.

Mas conforme as conversas avançam, as certezas evaporam e o que sobra são dúvidas, retrabalhos e aquela sensação de estar construindo um castelo em terreno instável.

É exatamente nesse momento que a engenharia de requisitos mostra seu verdadeiro valor.

Ela é o mapa que transforma o caos em direção.

E dentro dela existe uma etapa onde a confusão ganha forma: a elicitação.

É ali que a mágica (e às vezes o caos) acontece:

Quando ideias vagas se transformam em necessidades reais,
e o que antes era “acho que” vira “agora entendi”.

A seguir, você vai conhecer 4 técnicas essenciais de elicitação de requisitos — as mesmas usadas por grandes equipes de software, mas simples o bastante para aplicar até no seu projeto pessoal.

1. 📍 Faça as Perguntas Certas

Toda boa elicitação começa com escuta.

Mas escutar não é o mesmo que entender.

Quantas vezes você já participou de uma reunião em que o cliente falava…

E, no fundo, parecia que todo mundo só esperava a vez de responder?

É assim que os ruídos nascem, e que projetos promissores começam a desalinhar.

A maioria dos desenvolvedores anota o que o cliente diz.

Os bons tentam entender o que ele quis dizer.

Mas os melhores vão além: investigam o que ele nem percebeu que precisava dizer.

Imagine uma cena.

Um cliente pede: “Quero um botão para exportar relatórios em PDF.”

Simples, certo?

Mas um dev curioso pergunta:

“Por que o PDF é tão importante?”

E descobre que o problema não é o formato, mas o fato de o gerente precisar imprimir os relatórios para assinar à mão.

Uma rotina que poderia ser resolvida com assinatura digital, economizando tempo e papel.

É isso que a entrevista faz quando usada do jeito certo:
transforma pedidos superficiais em insights profundos.

Perguntas como:

👉🏻 “Qual é o problema que você está tentando resolver?”
👉🏻 “O que aconteceria se essa funcionalidade não existisse?”
👉🏻 “Como você faz isso hoje?”

Essas perguntas abrem espaço para histórias reais.

E é nelas que moram os verdadeiros requisitos, aqueles que o cliente sente, mas não sabe explicar.

💡 Dica prática:

Grave (com permissão) e transcreva suas entrevistas.

As palavras exatas das pessoas escondem mais do que informações, elas revelam emoções, dores e prioridades.

E é aí que nasce um software que realmente faz sentido.

2. 👀 Veja o Que as Palavras Não Dizem

Nem sempre as pessoas conseguem explicar o que realmente fazem.

Às vezes, não é má vontade é costume. Elas já se adaptaram às falhas do sistema há tanto tempo que o problema parece parte do trabalho.

É por isso que observar pode revelar o que nenhuma entrevista mostraria.

Essa é a essência do Shadowing, ou Etnografia de Usuário: acompanhar o dia a dia real de quem vai usar o sistema.

Imagine que você está desenvolvendo um software para uma clínica.

Durante uma visita, nota que a secretária mantém um bloquinho de anotações ao lado do computador.

Ela anota nomes de pacientes, ligações perdidas, horários remarcados… tudo à mão.

Quando você pergunta o motivo, ela responde com naturalidade:

“Ah, é que o sistema demora demais pra abrir a agenda. Assim é mais rápido.”

E ali está a verdade que o briefing nunca traria.

O problema não é o sistema antigo, é o processo.

A “nova funcionalidade” que pediram talvez seja só uma tentativa de contornar essa lentidão.

🔍 Observar muda tudo.

Você começa a enxergar o que as pessoas realmente fazem, e não apenas o que dizem que fazem.

É nesse contraste que surgem os requisitos mais valiosos.

No fim das contas, os melhores insights não nascem da mesa do escritório.

3. 💬 Quando Mentes Diferentes se Encontram

Alguns problemas não se resolvem em uma conversa a dois.

Eles se desdobram quando diferentes vozes se cruzam, cada uma enxergando o mesmo desafio sob uma luz diferente.

É aí que entram os workshops de requisitos e as sessões de brainstorming.

São como laboratórios de entendimento coletivo, onde desenvolvedores e stakeholders colocam suas perspectivas na mesa (às vezes em harmonia, às vezes em atrito).

Imagine a cena:

Uma sala (ou uma call) cheia de post-its, cafés e opiniões.

Alguém fala sobre usabilidade, outro rebate com limitações técnicas, e um terceiro lembra que o cliente final nem sabe usar o recurso anterior.

O clima é de debate, mas também de descoberta.

Porque é justamente nesse atrito construtivo que as boas ideias se pulem e os requisitos ganham corpo.

Uma técnica poderosa para guiar esse tipo de encontro é o Brainwriting.

Em vez de uma discussão caótica, cada pessoa escreve suas ideias em silêncio por alguns minutos.

Depois, o grupo lê, combina, aprimora.
Sem interrupções, sem vozes dominantes.

A criatividade flui e as perspectivas se multiplicam.

📌 O resultado?

Um conjunto mais rico de soluções, construído de forma colaborativa.

Menos ego, mais empatia.
Menos “minha ideia”, mais “nossa visão”.

No fim, elicitar requisitos é isso:

não sobre impor respostas, mas construir entendimento (juntos).

4. ✏️ Dê Forma ao Que Ainda É Nebuloso

Nem sempre as palavras bastam.

Algumas ideias só se revelam quando ganham forma, quando deixam o plano do discurso e passam a existir, ainda que de modo imperfeito.

É aí que entra a prototipagem: a ponte entre imaginação e entendimento.

Imagine que, depois de uma longa reunião, o cliente diz:

“Acho que entendi o que você quis dizer.”

Mas você sabe, esse “acho” é perigoso.

Então, em vez de mais explicações, você abre o Figma, rabisca algumas telas e mostra um fluxo simples.

De repente, ele aponta para a tela e diz:

“Ah, é isso! Era exatamente isso que eu queria.”

E pronto! O que antes era uma abstração vira um consenso.

Um protótipo pode ser um esboço rápido no papel ou um wireframe mais elaborado.

O formato não importa tanto quanto o efeito: tornar visível o que antes era apenas imaginado.

Cada feedback nessa fase é ouro.

Porque quanto mais cedo o cliente discorda, melhor.

Cada ajuste feito agora é um bug que você não precisará corrigir depois.

Prototipar não é perder tempo.

É evitar o desperdício,

De código, de energia e de expectativa.

💡 No fim das contas, é muito mais fácil alinhar quando todos estão olhando para o mesmo desenho, e não para interpretações diferentes de uma mesma ideia.

💬 O Código Nasce da Conversa

Todo projeto começa com um punhado de suposições.

O cliente “acha” que sabe o que quer.
O time “acha” que entendeu o que precisa ser feito.

E, no meio desse achismo mútuo, o projeto segue (até que a realidade cobra a conta).

A elicitação é o momento de quebrar esse ciclo.

É quando paramos de assumir e começamos a entender de verdade.

Não é apenas uma etapa do processo, é o instante em que o futuro do sistema começa a se definir.

Grandes sistemas não nascem de ideias geniais.

Eles nascem de grandes conversas, daquelas em que alguém faz a pergunta certa e muda o rumo de todo o projeto.

Por isso, antes de abrir o editor de código, abra o diálogo.

Converse, observe, prototipe, investigue.

Descubra o que está sendo dito e, principalmente, o que ainda não foi dito.

💡 Cada pergunta bem feita é uma linha de código a menos desperdiçada.

E cada boa conversa é um passo a mais rumo a um produto que realmente faz sentido.

Além da Lista de Funcionalidades: 4 Verdades Surpreendentes Sobre Requisitos de Software

Angelo Silva — Sun, 12 Oct 2025 23:28:09 +0000

Todo grande projeto de software começa com uma fagulha, uma ideia, um problema a resolver, uma vontade de construir algo que faça sentido.

Mas entre essa fagulha e o produto final existe um território perigoso: a falta de clareza nos requisitos.

🧭 De uma Ideia Vaga a um Plano Sólido

Se você já começou um projeto com uma frase do tipo "precisa ser fácil de usar" ou "tem que ser rápido" sabe exatamente do que estou falando.

É como receber a missão de construir uma casa sem planta, apenas com um "dá um jeito!".

Esse tipo de ambiguidade é uma das principais razões pelas quais projetos estouram orçamentos, atrasam entregas e entregam produtos que ninguém realmente precisa.

A verdade é simples: escrever requisitos não é montar uma lista de tarefas, é um disciplina de engenharia.

Quando feita corretamente, ela evita retrabalho, frustração e desperdício.

No decorrer do artigo, vamos explorar 4 verdades surpreendentes sobre engenharia de requisitos, extraídas de padrões internacionais e práticas adotadas por grandes empresas.

1. 🚫 Um “Bom” Requisito Não É um Desejo — É um Contrato Verificável

Muitos documentos de requisitos estão cheios de frases bonitas, mas inúteis:

"O sistema deve ser amigável"
"O sistema precisa ser rápido"
"O sistema deve funcionar bem"

Tudo isso soa bem, mas… como você prova que alcançou isso?

Você não prova. E é aí que começam as discussões e decepções.

Segundo o IEEE 830, um bom requisito precisa ter características essenciais:

Não ambíguo: todos interpretam da mesma forma
Completo: cobre todos os comportamentos necessários
Verificável: pode ser testado de forma objetiva
Consistente: não entra em conflito com outros requisitos
Modificável: pode ser atualizado com facilidade
Rastreável: é possível identificar sua origem e propósito

O ponto central é a verificabilidade.

Um requisito forte é aquele que pode ser comprovado com testes reais.

Exemplo ruim:

"O sistema deve ser rápido"

Exemplo bom:

"O sistema deve retornar resultados em até 2 segundos após o envio da consulta"

Essa precisão não é burocracia, é clareza compartilhada.

É o que evita mal-entendidos, retrabalhos e discussões intermináveis.

2. 🤝 Requisitos Não São uma Lista de Pedidos — São uma Negociação

Existe um mito perigoso no mercado:

"O cliente manda a lista e a equipe de desenvolvimento executa."

Na prática, requisitos são construídos em conjunto, por meio de negociação entre especialistas.

De acordo com o padrão ISO/IEC/IEEE 29148, a engenharia de requisitos media o diálogo entre dois mundos:

O cliente, que entende o problema
O fornecedor (dev/team), que entende as soluções possíveis

Nenhum dos dois consegue escrever bons requisitos sozinho.

O resultado só é realmente valioso quando ambos negociam significado e viabilidade.

"Clientes normalmente não entendem o suficiente sobre desenvolvimento de software…
Fornecedores normalmente não entendem o suficiente sobre o negócio do cliente." — ISO/IEC/IEEE 29148 (traduzido)

Requisitos bem definidos nascem desse equilíbrio: do encontro entre visão do negócio e realidade técnica.

3. 🧪 Às Vezes Você Cria um Protótipo Para Descobrir os Requisitos

Parece contraintuitivo, mas é verdade:

Você nem sempre define requisitos antes de construir, às vezes, você os descobre enquanto constrói.

Prototipar não é só uma etapa de design, é uma poderosa ferramenta de descoberta.

Com protótipos, ideias abstratas ganham forma, permitindo que as pessoas toquem, vejam e reajam ao que está sendo proposto.

E quanto mais concreto for o feedback, mais claros ficam os requisitos.

Existem diferentes níveis de fidelidade:

Baixa fidelidade: rascunhos rápidos no papel, para explorar ideias iniciais
Média fidelidade: wireframes que mostram o fluxo e a estrutura
Alta fidelidade: mockups interativos, quase idênticos ao produto final.

"Um cliente tem muito mais facilidade de reagir a um protótipo do que a um documento de requisitos."

Em resumo:

Pare de discutir hipóteses, mostre algo, mesmo que imperfeito. O protótipo vira catalisador para feedback real e decisões mais rápidas.

4. 🌳 Requisitos Têm uma Árvore Genealógica

Muita gente fala "o documento de requisitos", como se fosse um único arquivo.

Mas em um projeto bem estruturado, existe uma cadeia de documentos, cada um com um propósito diferente.

Segundo o ISO/IEC/IEEE 29148, essa hierarquia é assim:

1. Business Requirements Specification (BRS)
O "por quê" do projeto (objetivos e motivações do negócio)

2. Stakeholder Requirements Specification (StRS)
Traduz o BRS em necessidades específicas de cada tipo de usuário ou parte interessada.

3. System Requirements Specification (SyRS)
Define os requisitos técnicos do sistema como um todo (software, hardware, pessoas…).

4. Software Requirements Specification (SRS)
Detalha o comportamento esperado apenas do software. É o contrato com os devs.

Essa estrutura cria uma cadeia de rastreabilidade, pois cada linha de código pode ser ligada a um objetivo real.

Nada é feito "porque sim".

🧱 Construa a Fundação Antes da Casa

A engenheira de software Danielle Teixeira resume com perfeição:

"Propõe-se construir as fundações de uma casa antes de entrar nela — para que ela não desabe"

E o mesmo vale para software.

Antes de escrever uma única linha de código, é preciso construir um entendimento sólido e compartilhado sobre o que deve ser feito, e por quê.

Da próxima vez que alguém disser "faz essa feature aqui rapidinho", não abra o editor de código ainda.

Pergunte.
Negocie.
Prototipe.

E transforme aquela ideia vaga em um plano verificável e colaborativo.