bom pessoal seguinte tá como eu tinha falado pra vocês no início nem todo o sádio vou chamar de sádio daqui pra frente tá possui a mesma estrutura porque cada um vive de um contexto diferente legal normalmente o que a gente coloca o que se documenta nessa parada vocês vão ver que tem diversos template este em place variam de empresa para a empresa e esses templates que essas empresas utilizam normalmente elas dão ênfase principalmente a nos pontos que a empresa mais ou tem dificuldade ou pontos que a empresa realmente acha necessário documentar então a a gente documenta o que importa. Tem muita gente que fala, o que é arquitetura? Arquitetura é o que importa. Essa que é a grande sacada. Legal? Quanto maior o risco do projeto, maior a documentação. Legal? Agora, quais são os principais tópicos que normalmente a gente trata nesse documento aqui? Normalmente, agora a gente vai andar passo a passo aqui com você. Normalmente a gente tem uma introdução e essa introdução vai falar o propósito do documento. Normalmente é isso, um parágrafo, dois parágrafos no máximo. Para quem olhar e falar, poxa, eu vou desenvolver um sistema de ingresso para as pessoas contratarem um show, mas esse ingresso vai pegar shows apenas de gente muito famosa, então esse sistema tem que ser um sistema realmente muito parrudo desde o dia zero tá a o escopo da solução poxa esse sistema ele vai conseguir desde o início né é ser muito parrudo ele vai poder realizar os pagamentos desde o dia zero também o usuário vai ter uma parada que ele coloca na wallet cor mas ao mesmo tempo ele também vai ter parceiros que vão poder cadastrar o show ali. Estou dando uma visão geral do que vai ter. Legal? Quais são as minhas principais restrições? Galera, essa parte de restrição é a parte que a gente tem que tomar mais cuidado. Por quê? Porque normalmente, os orelhudos, a galera que mais critica os projetos quando não vê o contexto é isso. Nossa, por que você está utilizando Ruby para fazer um projeto desse que vai precisar de alta concorrência? Por que não foi feito um Elixir? Restrições. A maioria dos meus funcionários que vão participar desse projeto são programadores Ruby. dos meus funcionários que vão participar desse projeto são programadores rubi então o projeto a restrição está restringido por mão de obra fazendo ok então as restrições são pontos importantes por exemplo eu tenho uma janela de oportunidade se esse projeto não estiver pronto em quatro meses é melhor que esse projeto nem tivesse existido tá então nós temos restrições essas restrições elas podem ser de tempo de mão de obra restrições financeiras restrições a de propriedade intelectual restrições governamentais é de regulamentações então a gente pode ter diversas restrições que não consigam fazer com que a gente faça o projeto na sua plenitude. Nenhum projeto é perfeito, nenhum contexto é perfeito. Outro ponto aqui é pressuposto. Pressuposto, assumptions. O que isso significa? Eu, para fazer isso aqui, estou partindo do princípio que eu tenho uma equipe de 20 desenvolvedores que eu tenho 500 mil dólares para começar a desenvolver esse projeto eu tô partindo do princípio que eu vou ter um gerente de projeto eu tô partindo do princípio que eu vou poder contar tá com dez funcionários da empresa que já trabalham há 10 anos full time por aquele tanto tipo de coisa. Eu estou fazendo um pressuposto que para esse projeto ser economicamente viável, a gente vai conseguir um acordo com a Google Cloud para ela conseguir baixar o valor da taxa de transferência dela. Ou seja, para eu conseguir fazer isso, eu parto do princípio que eu já consegui esses aspectos esses aspectos vão ajudar eu ter é mais flexibilidade na hora que eu for trabalhar com o meu projeto legal então isso aqui é introdução basicamente tá escopo pressuposto, restrições e tudo mais. Maravilha, galera? Então, vamos seguir aí para o nosso próximo vídeo.