Agora que a gente já falou um pouquinho sobre visão geral da arquitetura, diagramas, falar, documentar o que importa, a gente vai num outro ponto aqui. E essa é a parte que, na minha opinião, é mais cabeluda. Por quê? Porque a gente vai falar sobre requisitos. E quando a gente fala sobre requisitos, a gente fala requisitos funcionais. E o que são requisitos funcionais? gente fala requisitos funcionais tá e o que são requisitos funcionais são requisitos que fazem referência a como a aplicação vai funcionar os recursos que a aplicação vai ter como esses recursos funcionam quais são as principais regras que isso tem e é aqui que o bicho pega, galera. Por quê? Porque às vezes você pega arquitetos, principalmente na época um pouco mais tradicional, que você passava meses e meses só definindo esses requisitos. Antes de desenvolver uma linha sequer de código. O pior ponto é que, normalmente, esses requisitos mudam pra caramba. O cliente, na hora de estar falando com você, ele pensa que aquela ideia que ele teve está correta. Mas quando vai implementar ele fala, putz, mas era melhor daquele jeito? Pum, morreu o requisito. Entendeu o que eu estou querendo dizer? Então os requisitos funcionais, você vai colocar as principais funcionalidades do sistema, como elas funcionam, o que é esperado ali em relação delas. Coloque também sempre algum tipo de observação falando que, caso isso não funcione, pode impactar tais outras funcionalidades ou qualquer coisa desse tipo. Então requisitos funcionais são recursos, funcionalidades, features que vão agregar o valor do negócio. Quando eu falo agregar o valor, normalmente a gente está falando sobre diferencial competitivo. Como eu disse para você, o FAQ é uma feature importante? É, a pessoa vai lá, tira as dúvidas. Ela vai agregar valor como fazer uma compra? Não vai. Então, você vai colocar principalmente os principais requisitos tá obviamente que faq é uma coisa que vai ter você vai colocar entendeu mas não vai detalhar da forma como você vai detalhar um requisito tão importante como sei lá realizar uma compra entendeu a requisitos não funcionais requisitos não funcionais são performance escalabilidade segurança disponibilidade tá cross-cutting o que é cross-cutting qualquer coisa que corta a aplicação do início ao fim coisas que sempre vão estar ali na aplicação legal a então esses tipos de requisito eles são importantes você tem que ter por exemplo uma previsão de quantas pessoas vão acessar quantas requisições eu vou trabalhar né Qual é a performance em que eu vou ter no meu sistema como que eu vou trabalhar com a parte de segurança eu que vou processar os pagamentos eu vou guardar dados de cartão a eu tenho que ser pci compliance é compliant a então esses tipos de coisa que são extremamente importantes e aí novamente muita gente vai perguntar wesley mas como que eu vou calcular performance e setar um requisito de performance de um sistema que nunca foi ao ar? Boa pergunta, ótima pergunta. E essa pergunta pega todo mundo. Por quê? Existem empresas que já estão consolidadas. E essas empresas já têm uma projeção normalmente de quantas requisições ela vai receber, como é o fluxo pico ela tem sazonalidade então você já consegue gerar uma previsão disso agora se você tem uma empresa que está sendo criada agora uma área de mão business business unit está sendo criada agora e você não tem previsibilidade nenhuma o que você vai ter que fazer? Você vai ter que, pelo menos, aí, galera, podem falar o que quiser, tá? Essa é a minha opinião. Você vai ter que dar um chute, tá? Mas não somente dar um chute. Você vai ter que dar um chute de quanto que a sua aplicação, baseada em tanto de hardware, em tanto disso, ela vai suportar. Entendeu? Então não adianta falar, ah, eu vou botar tanto de máquina. Não. Se você botar tanto de máquina, quantas requisições ela vai aguentar? Qual que é o throughput que ela vai aguentar? Qual que vai ser a latência que ela vai ter? Quantos milissegundos ela vai conseguir responder? Tá? Então se você for dar chute, não tem problema. Dá o for dar chute não tem problema dá o seu chute faz um teste de carga e ver esses resultados faz uma projeção desses resultados aqui tá então chute é importante da é quando você não tem da onde partir mas não é só porque você não tem da onde partir que você não consegue fazer uma projeção que se eu tiver mil usuários simultâneos, eu vou ter que ter essa quantidade de recursos. Legal? Então isso aí é importantíssimo você saber. Não adianta só chutar e botar no ar. Faz um teste de performance, faz um teste de carga, você vai conseguir ter pelo menos uma ideia de quanto que você consegue baseado naquilo. Se vier muito mais requisição, você vai conseguir, vai ter que escalar, mas você já viu esse sistema de alguma forma, você não partiu do momento zero ali. Legal? Então, esse é um dos pontos importantes, galera. Requisito funcional ou não funcional. Essa parte é as que mais pegam. Normalmente, documente mais o que importa se você for dar um chute de um chute mais traga dados tá esse aí é um ponto importante aí pra vocês