PROGRAMADOR FREELANCER: Como fazer o Levantamento de Requisitos de qualquer Software 🔍

semana passada eu fiz um vídeo completo aqui no meu canal Como que você pode começar nessa área de freelancer e nesse vídeo eu passei para você um roadmap completo O que você precisa ter desde o passo um até o último passo e esse vídeo eu passei informações gerais não aprofundadas de cada tópico do roadmap e a galera gostou bastante desse vídeo eu falei quem comentasse naquele vídeo desse sugestões de vídeo A gente podia fazer outros vídeos a respeito dessa área de freelancer e nesse vídeo vídeo específico eu vou falar sobre o documento de análise de requisitos um documento muito importante que você precisa ter em mãos para você conseguir fazer o levantamento de requisitos do sistema que você vai criar pro seu cliente então antes de a gente começar esse vídeo tudo que eu peço para você é que você deixe o like nesse vídeo o like é muito importante para ajudar o nosso trabalho e também ajudar a posicionar esse vídeo aqui na plataforma e mais pessoas que precisam dessas informações vão conseguir encontrar esse conteúdo com mais facilidade conto com seu apoio se você é novo no canal também recomendo que você se inscreva no canal Ative o Sininho com todas as notificações Porque toda semana eu trago notícias atualizações conteúdos incríveis no desenvolvimento Android em outras áreas também da programação então se você quiser receber os meus conteúdos se inscreve e não esquece de ativar o Sininho e a sugestão para eu fazer Esse vídeo foi através do comentário do André Jamine ele disse o seguinte aqui ótimas dicas e um vídeo sobre análise de requisitos seria muito interessante Obrigado André pela sua sugestão Então nesse vídeo a gente vai falar sobre análise de requisitos Então para que que serve esse documento de análise de requisitos esse documento vai conter todos os requisitos do projeto requisitos não funcionais e requisitos funcionais e mais algumas informações importantes esse documento ele vai deixar claro para você e pro seu cliente Quais são os requisitos daquele sistema ou seja esse sistema precisa por exemplo de autenticação de usuário esse s sistema precisa de cadastro de clientes então isso daí é um requisito cadastro de cliente autenticação de usuário é um requisito agendamento de clientes é um requisito Então as funcionalidades do aplicativo vão ser os requisitos você poderia fazer isso anotando numa folha de papel num bloco de notas isso seria para controle interno você não precisa de um advogado Esse documento não necessariamente precisa ter respaldo jurídico então é muito melhor você criar um documento onde ele pode ser adaptado a vários tipos de projetos Onde você consegue só alterar esse documento e enviar pro seu cliente é uma maneira profissional de você colocar toda a descrição do app e todos os requisitos nesse documento o cliente vai ver você também vai ter o controle disso tudo e você vai conseguir colher as assinaturas só depois que você passa pro contrato o levantamento de requisitos é muito importante para que você consiga concluir aquele projeto de maneira satisfatória eu não conheço nenhum programador freelancer nenhum desenvolvedor que criou um sistema sem levantar os requisitos é praticamente impossível vai ter muitos problemas durante esse processo você vai esquecer dos requisitos que o projeto tem o cliente vai esquecer e aí o cliente vai falar para você fazer tal coisa e vocês vão ficar perdidos e pode dar uma confusão do caramba então geralmente isso daí vai causar Muita confusão se você não levantar corretamente os requisitos Então vamos lá eu quero mostrar para vocês aqui um documento que eu mesmo fiz de análise de requisito que você pode utilizar aí nos seus projetos como freelancer Lembrando que não é uma regra o que eu vou passar aqui para você você pode utilizar esse modelo esse aqui é um modelo que eu usei bastante em produção e você pode estar utilizando também dessa mesma forma tá então vamos lá eu vou acessar aqui o Google Drve e esse daqui é o documento de análise de requisitos ele tá aqui no meu Google Drve eu tô utilizando aqui o DOC do Google né e eu vou mostrar para você aqui um exemplo né um exemplo de um sistema não tá completa aqui tá os requisitos do sistema mas só um exemplo para te mostrar aqui como que funciona aqui no começo você vai especificar Qual é o projeto que você tá levantando requisitos Então vamos supor que o cliente chegou em você ó eu preciso de um aplicativo de barbearia barbearia do Lucão aí você vai ligar pro cliente levantar esses requisitos então pode ser por ligação pode ser presencial pode ser por mensagem pode ser por uma vídeochamada a forma que você vai conversar com esse cliente pode ser de qualquer forma então aqui no começo você sempre vai colocar mais ou menos dessa forma aqui ó análise de requisitos ou levantamento de requisitos do do aplicativo de barbearia do Lucão então aqui você já deixa explícito esse documento vai ser entregue pro cliente tá pessoal a versão atual do documento Então nesse caso tá na versão 1. 0 porém se tiver alterações durante o processo do desenvolvimento desse documento se o cliente quiser mais requisitos ou retirar algum algum requisito você vai alterando esse documento e você vai mudando é o número da versão desse documento Então vai começar na versão 1. 0 Mas aí teve uma alteração Opa então agora vai pra versão 1.

1 teve mais sei lá quantas alterações vamos supor que a versão final é a versão 2. 0 é essa que vai ser entregue pro cliente para ele assinar Então tudo isso você tem que tá controlando no documento Então essa primeira versão aqui é a versão 1. 0 aí aqui embaixo você vai especificar de maneira resumida Qual é a sua equipe de desenvolvimento Você tá trabalhando sozinho ou você tem uma equipe né junto com você duas pessoas né dois programadores três pessoas quatro pessoas então aqui você vai especificar se é uma equipe de duas pessoas de três se é você sozinho no caso desse projeto aqui foi três pessoas né a nossa equipe tinha três pessoas o desenvolvedor Mobile Android era eu né Marcos duart Gomes então aqui você coloca se é só você você coloca desenvolvedor Mobile Android Fulano digital desenvolvedor mobile iOS fulando digital Então nesse caso aqui né a equipe de desenvolvimento desenvolvedor Mobile Android Marcos duart Gomes designer de aplicativos a pessoa que ia ficar responsável só por criar parte das interfaces do aplicativo e ia criar todo designer de aplicativos José Almeida a gente também tinha um testador nesse projeto uma pessoa que ia testar todo o projeto nesse caso aqui é o Carlos Augusto mas se você tá sozinho nesse caso você vai ser o testador você vai ser muit das vezes o design gráfico né e o desenvolvedor Mas se você tiver mais pessoas aí você pode separar as responsabilidades Beleza então tudo isso precisa ficar claro aqui no documento as tecnologias utilizadas no projeto aqui você faz um resumo isso daqui talvez não seja interessante pro o cliente mas caso esse projeto passe pra frente esse cliente precise fazer uma atualização ou implementar novas funcionalidades com outros desenvolvedores que não é da sua equipe né desenvolvedores externos porque ele pode muito bem fechar com você você criar a aplicação e num futuro distante ele implementar novas funcionalidades nesse app com outro desenvolvedor Então ele pode apresentar esse levantamento de requisito aqui e aqui já vai est as tecnologias utilizadas no projeto o desenvolvedor já vai ter ali é todas as informações necessárias desse projeto então é a título de desenvolvedores externos ou até pro cliente mesmo informações que são úteis para ele também então aqui você vai ter a linguagem de programação utilizada nesse projeto linguagem cotlin a ide utilizada no desenvolvimento Android Studio especificar claramente Aqui o banco de dados vai ser o firebase Fire Store por quê Porque vai ter uma cobrança em cima desse banco de dados aqui também no backend ó Qual backend é utilizado nesse caso aqui foi utilizado o dnet mas pode ser utilizado qual qualquer outro e backend tá então aqui você especifica de maneira resumida Qual é a linguagem a ids se tem banco de dados se tem servidor externo depois logo abaixo nós temos aqui uma introdução você vai fazer uma pequena descrição do sistema nesse caso aqui é um aplicativo de barbearia né o sistema de gerenciamento de barbearia é um aplicativo móvel desenvolvido para otimizar e modernizar o processo de agendamento e gestão de serviços em barbearias o aplicativo permite que os clientes agendem visualizem e cancel seus compromissos diretamente pelo celular além disso oferece funcionalidades para a barbearia gerenciar suas reservas visualizar feedbacks dos clientes e manter uma comunicação eficiente com os usuários com uma interface intuitiva e suporte a múltiplos idiomas o sistema busca proporcionar uma experiência de usuário fluída e acessível então isso aqui é uma descrição só para você entender tá mas você vai fazer a descrição do projeto do seu cliente aqui você também tem que especificar é muito importante o público alvo quem é o público alvo desse aplicativo Às vezes tem mais do que um público alvo nesse caso desse aplicativo de barbearia nós temos os clientes e os proprietários os funcionários né então a gente aqui tem os clientes ó os clientes da barbearia pessoas que frequentam ou desejam frequentar a barbearia buscando conveniência no agendamento e gerenciamento de seus serviços o público inclui homens e mulheres que buscam uma experiência personalizada e eficiente Na barbearia então o público alvo é clientes da barbearia e também proprietários e funcionários da barbearia e aqui você pode colocar um objetivo né Qual que é o principal objetivo desse projeto é melhorar a eficiência operacional das barbearias e proporcionar uma experiência de cliente mais conveniente e satisfatória através da automoção e gerenciamento simplificado aí logo abaixo É muito importante que isso esteja no seu documento que são os tipos de requisitos isso daqui vai ser importante tanto para um próximo desenvolvedor quanto pro seu cliente que vai ler esse documento ele vai ler esse documento aqui então ele precisa entender o que que é requisitos Fun ionais e não funcionais os requisitos do sistema são divididos em duas categorias os funcionais e os não funcionais o que que são requisitos funcionais requisitos funcionais definem o que o sistema deve fazer Então pessoal nessa aplicação né nesse sistema vai ter diversos requisitos funcionais Ou seja é o que o sistema vai fazer são as funcionalidades do aplicativo do site Enfim então isso são requisitos funcionais é o que o sistema deve fazer o que a aplicação precisa fazer pro seu cliente e nós temos os requisitos não funcionais que também são conhecidos como atributos de qualidade eles vão definir como o sistema deve funcionar Então os requisitos não funcionais muit das vezes é o que tá por debaixo do sistema né arquitetura do projeto e entre outras funcionalidades que o usuário final não vai ver muit das vezes então são atributos de qualidade né performance desempenho parte de segurança né são requisitos que o que o cliente não consegue visualizar mas ele precisa saber que tá dentro da aplicação dele aí logo abaixo eu faço isso eu recomendo que você faça isso né É você colocar aqui uma descrição dos níveis de prioridade dos requisitos por quê porque cada requisito tem um nível de prioridade tem requisito que tem uma prioridade baixa outro vai ter uma prioridade mais alta outro média então é importante que você deixe claro isso daí no documento né então aqui ó os requisitos são classificados em três categorias obrigatório nesse necessário e opcional obrigatório o sistema não funciona sem este requisito é imprescindível e deve ser implementado Obrigatoriamente ou seja esse nível de requisito obrigatório é um requisito que não pode faltar na aplicação do seu cliente se faltar esse requisito obrigatório a aplicação do cliente não vai funcionar não vai ser possível mandar pra produção então sem os requisitos obrigatórios o sistema não funciona basicamente é isso nós temos aqui o requisito né o nível de prioridade aqui do requisito necessário O sistema funciona mas de forma insatisfatória sem este requisito deve ser implementado mas o sistema ainda pode ser usado sem ele ou seja o nível de prioridade necessário de requisito é muito importante sem ele o sistema vai continuar funcionando porém não vai funcionar de de maneira satisfatória por exemplo pode ter problemas de desempenho ou uma funcionalidade que seria muito importante e que não está ali porque talvez o cliente não tem grana agora para fazer enfim e nós temos aqui o nível opcional O sistema funciona bem sem este requisito pode ser Deixado Para uma versão futura se não houver tempo para implementá-lo agora então o nível de prioridade opcional é um requisito opcional que se não tiver naquele sistema naquele momento o sistema vai continuar funcionando de maneira satisfatória e pode ser implementado no futuro e às vezes US o o cliente não tem dinheiro suficiente para colocar todas as funcionalidades naquele primeiro momento mas ele pode fazer com você em um futuro não tão distante aí você deixa tudo isso claro no documento Vai facilitar os trâmites para você e pro seu cliente aí depois que você deu essa breve descrição isso aqui é muito importante para o seu cliente aí você vai começar a colocar os requisitos funcionais desse sistema que você vai desenvolver pro seu cliente aqui nós temos os requisitos funcionais desse sistema de barbearia Esse sistema de barbearia vai ter eh vários requisitos aqui nesse caso não tá não tem todos aqui tá pessoal eu só trouxe alguns só para você entender tá pra gente não estender muito sempre quando você for colocar um requisito aqui coloca RF né isso aqui é um padrão que o mercado já reconhece então RF é de requisito funcional você coloca aqui RF de requisito funcional e o número dele nesse caso 001 que é o primeiro requisito funcional do sistema e o nome do requisito autenticação de usuário aí você vai ter a descrição D esse requisito funcional Coloque uma descrição Clara e concisa pro seu usuário o sistema deve permitir que os usuários se autentiques quecimento após a autenticação o usuário será redirecionado para a tela principal da aplicativo Então essa aqui é a descrição geral desse requisito aí aqui você vai ter as entradas e pré-condições e as saídas e pós condições as entradas e pré-condições e as saídas são muito importantes que você deixe explícito aqui no requisito pessoal isso aqui é quase que nem um padrão tá todo mundo vai colocar isso daqui Quais são as entradas e pré-condições desse requisito o usuário deve fornecer um endereço de e-mail e uma senha Então esse daqui é uma coisa que o usuário precisa fazer são pré-condições as entradas o usuário precisa fornecer um endereço de e-mail e uma senha o e-mail deve ser único e não deve estar registrado em outra conta então essa aqui é as pré-condições e as saídas e pós condições ou seja após o usuário fazer isso após a autenticação bem-sucedida o usuário será redirecionado para a tela principal do aplicativo e se a autenticação falhar uma mensagem de erro será exibida Então tudo isso precisa ficar claro pro seu usuário e qual é a prioridade desse requisito obrigatório aí o usuário vai vir aqui Opa requisito obrigatório precisa est no sistema senão o sistema não funciona então então aqui você já fez né você já descreveu tudo isso daqui e aqui você coloca ó prioridade desse requisito obrigatório próximo requisito Aí você coloca requisito funcional 002 próximo requisito gerenciar agendamentos de clientes tá aqui a gente tem mais um requisito que é o agendamento de clientes aí tem uma breve descrição ó o sistema deve permitir que os clientes agendem visualizem e cancelem seus compromissos Na barbearia através do aplicativo o usuário deve poder selecionar o serviço desejado escolher um horário de disponível e confirmar o agendamento o sistema deve enviar uma confirmação por e-mail ou notificação quando o agendamento for concluído E aí tem as entradas pré condições o cliente deve estar autenticado no sistema ou seja se ele não tiver autenticado essa ação não vai não vai ser possível ser feita tá vendo Então aqui você já dá mais detalhes sobre essas condições o cliente precisa estar autenticado o cliente deve selecionar um serviço específico lá do aplicativo e um horário disponível e o sistema deve verificar a disponibilidade do horário e o serviço escolhido saídas e pós condições após fazer tudo isso né o cliente vai receber uma confirmação do agendamento legal e o agendamento é registrado no sistema e fica disponível na visualização de agendamentos do cliente da e da barbearia Então você vai ter ali o agendamento na parte do cliente e na parte do administrador em caso de cancelamento o cliente deve receber uma confirmação e o horário deve ser liberado para outros clientes Então essas são as condições prioridade desse requisito obrigatório então sem esse requisito o sistema não pode ser entregue e aqui um exemplo de um requisito que não é obrigatório mas seria muito necessário seria nossa extremamente importante se tivesse não é obrigatório Beleza você poderia entregar o sistema sem esse requisito aqui mas aí você tem que deixar claro que por exemplo esse requisito ele não é obrigatório ele é necessário porque aí o usuário vai falar para você o que que ele quer fazer agora e o que que ele não quer não pode fazer o necessário também pode colocar o opcional vou fazer tudo então aqui a gente tem o r f003 que é avaliação dos serviços no caso dos clientes né é um requisito de avaliação o sistema deve permitir que os clientes avaliem e deixe comentários sobre os serviços recebidos Na barbearia após a conclusão de um agendamento o cliente será solicitado a fornecer uma nota de um a cinco estrelas e escrever um comentário opcional sobre a experiência as avaliações serão visíveis para para a barbearia e para os outros clientes Quais são as entradas e pré-condições o cliente deve ter completado um serviço Na barbearia então só vai acontecer isso quando ele completar um serviço e o cliente deve estar autenticado no sistema para deixar uma uma avaliação essa aqui é as as pré-condições quais são as pós condições o sistema registra a avaliação e o comentário do cliente a avaliação é exibida no perfil da barbearia e pode ser visualizado por outros clientes O sistema permite que a barbearia responda aos comentários se desejar prioridade necessário seria muito importante que tivesse isso tudo bem e aí você poderia ter também um requisito opcional nesse caso eu não coloquei aqui os requisitos funcionais você vai colocar todos pessoal então pode ter quantos precisar tá 10 15 5 6 entendeu depois você vai também documentar os requisitos não funcionais que aí é o que tá por debaixo dos panos mu das vezes aí no caso você vai colocar esse termo aqui ó rnf de requisito não funcional rnf 001 o nome do requisito não funcional arquitetura de software e aqui você só vai colocar uma descrição não precisa colocar prioridade porque é o que vai ficar por debaixo dos panos entendeu o cliente não vai ver isso daqui muito das vezes arquitet de software é um requisito não funcional o aplicativo vai utilizar uma arquitetura de software moderna pode ser mvvm mvc enfim você pode descrever melhor isso daqui possibilitando que o aplicativo seja escalável sustentável e totalmente testável por outros desenvolvedores futuros Opa legal então o aplicativo é escalável sustentável e testável outro requisito não funcional 002 suporte a múltiplos idiomas ó descrição o sistema deve oferecer suporte a pelo menos três idiomas principais com tradução completa das interfaces e mensagens e aqui tem outro requisito não funcional 003 transferência de responsabilidade isso aqui é muito importante que você coloque tá aí Aqui tem a descrição ó após o desenvolvimento completo do aplicativo barbearia do Lucão a responsabilidade pela operação do sistema será transferida para o contratante Ou seja a responsabilidade do sistema vai ser passada pro Lucão né Você vai transferir para ele pro contratante para quem tá contratando você esse processo de transferência deverá ser formal AD junto a contratante isso daqui também você vai passar no contrato tá estabelecendo as condições e os termos de responsabilidade operacional do sistema Então você vai passar os direitos do projeto pro seu cliente porque toda vez que você cria um projeto os direitos autorais são seus isso aqui tem que est no contrato também e um último requisito não funcional são as tecnologias utilizadas no projeto né o aplicativo será desenvolvido utilizando a linguagem cotlin com banco de dados online do firebase o Fire Store e aqui você pode colocar mais tecnologias que você utilizou e aqui no final não é obrigat mas eu coloco quando eu faço esse documento né de análise de requisitos eu deixo pronto pro cliente eu já coloco porque aí eu já consigo definir um orçamento quando eu consigo capturar todos os requisitos aí sim eu consigo definir de fato com precisão o preço do projeto quantas partes eu vou dividir aí você pode colocar aqui embaixo já o orçamento junto com a análise o usuário vai ter toda a descrição do projeto todos os requisitos e o preço do projeto então aqui tá o preço total do projeto R 7.

500 projeto será dividido em quatro partes e o pagamento pode ser feito em duas vezes quatro vezes oito vezes ou 12 vezes né formas de pagamento transferência bancária pix ou cartão e o prazo de entrega máximo 35 dias mas aí você coloca uma observação nesse caso foi colocado aqui né mas pode ser entregue antes aí tudo isso vai est no contrato com mais detalhes beleza aqui é para você fechar com o seu cliente antes de passar pelo contrato Então você vai fechar com ele opa ele gostou a gente vai fechar aí a agora você vai formalizar tudo isso no contrato depois que ele assinar ele vai ter que fazer um pagamento ali para dar uma entrada aí você começa o serviço e aqui no final do do documento é muito importante que tenha essas informações dos stakeholders o que que são stakeholders são partes interessadas que influenciam ou são afetadas pelo projeto inclui usuários finais clientes gerentes e equipes de desenvolvimento testes e suporte aí Aqui tem e um exemplo do que seria esses stakeholders né né usuários finais ou seja utilizadores Diários do software clientes solicitantes do desenvolvimento do software gerentes responsáveis pela supervisão do projeto equipe de desenvolvimento criadores e implementadores do software equipe de testes garantidores de da qualidade funcionamento de software e equipe de suporte suporte técnico e pós-implementação e aqui você vai colher a assinatura dos stakeholders envolvidos é aqui que você vai colher a assinatura do seu cliente depende do projeto pode ter só um stakeholder dois eu já cheguei a pegar projeto com muitas pessoas envolvidas tem pessoas do seu lado e pessoas do lado daquela empresa Às vezes a pessoa que entrou em contato com você ela é como eu posso dizer um intermediário a pessoa que vai pagar você é por exemplo o gerente ou seja o que é responsável Ali pela supervisão do projeto Então você precisa ter esse documento Claro e colher a assinatura também do supervisor da pessoa que tá ligando para você então todas as pessoas precisam estar cientes disso porque se você não colher por exemplo uma assinatura tem outra pessoa envolvida pode dar algum problema então é importante que você deixe claro isso daqui aí aqui você troca tá stakeholder você pode colocar stakeholder um desenvolvedor né cliente assinatura gerente né o supervisor ou o nome da pessoa mesmo você pode colocar aqui assinatura da equipe assinatura do cliente João assinatura do supervisor Mário entendeu então aqui você pode alterar isso daqui tá aqui tá uma maneira de teste ainda não foi colhido nenhuma assinatura não foi modificado e aqui no final são os históricos de alterações vamos supor que durante o processo que você tá levantando os requisitos e formulando o documento o cliente decidiu que vai colocar mais requisitos ou vai tirar alguma coisa então você vai precisar colocar mais requisitos ou tirar requisitos Aí você coloca a primeira alteração aqui na data de 31/07 de2022 foi feita a primeira alteração eu passo a versão do meu documento que é a versão 1. 0 pra versão 2.