E aí e fala galera sejam todos bem-vindos ao nosso curso de engenharia de requisitos Eu sou Professor Otávio e nessa aula nós vamos entender os conceitos de engenharia de software engenharia de requisitos e a importância da engenharia de requisitos no processo de desenvolvimento de software bom então antes da gente tratar diretamente na engenharia de requisitos a gente tem que entender a grande área na qual está incluída que é a engenharia de software engenharia de software ela é uma área da computação é que tá voltada pro especificação desenvolvimento manutenção e criação de Soft o Tom a
ideia dela é gerir na gerenciar todo o processo de desenvolvimento de um software conto do início ao fim tudo aquilo que diz respeito ao desenvolvimento de software estará incluído na engenharia de software Então ela engloba todos os processos tudo que está diretamente ou indiretamente relacionado com o desenvolvimento de software com o intuito de entregar no final um produto com qualidade e da produtividade o processo de desenvolvimento organização Então tudo isso é objetivo da engenharia de software naturalmente como engenharia de software é uma grande área que engloba né vários processos ela se divide em 10 outras
áreas e não para gente saber é vamos aí tomar conhecimento delas a primeira gerência de configuração de software e depois a gente tem gerência de engenharia de software processo de engenharia de software ferramentas e métodos qualidade de software engenharia de requisitos design de software construção de software teste de software e manutenção de soft Então são essas as 10 áreas em na qual engenharia de software se divide o nosso curso aqui naturalmente a gente vai estudar à engenharia de requisitos estão que é a engenharia de requisitos engenharia de requisitos ela é uma metodologia sistemática para especificar
e gerenciar requisitos e é com o intuito da gente conhecer os requisitos relevantes formar um consenso entre os stakeholders Caso haja divergência entre eles documentar os requisitos de acordo com os padrões estabelecidos gerenciar sistematicamente todos esses requisitos entender e documentar as expectativas na o quê que o espera o steak holder cada um dos stakeholders do sistema que está sendo desenvolvido é o que que eles querem Qual a o objetivo deles para com sistema como eles desejam que esteja implementado e as vontades deles demandas deles é especificar nessas demandas por aqui seja isso implementado posteriormente no
softer e enfim fazer todo esse processo é de maneira a entregar no final um sistema que atenda às necessidades dos stakeholders é ou seja minimizar ao máximo o risco de entregarmos um sistema que não atenda às necessidades e expectativas dos stakeholders é de entregar no final sistema e os stakeholders e olharem já com um olhar torto a Não era isso que eu queria não era assim não tá legal e é isso gera um transtorno isso gera manutenção suja era custo é e custa tempo também bom então assim a ideia da engenharia de requisitos essencialmente é
essa é no final a gente entrega algo que atenda à expectativa do usuário é que todos Eles olham Poxa era realmente isso que eu queria tá funcionando do jeito que eu queria e minimizar ao máximo coisas com a pessoa que não tá bem legal hoje que isso vai acontecer mas a ideia justamente Minimizar não é para que fique uma coisinha outra Talvez no final que precisa ser corrigida coisas pequenas e que no final a gente consiga entregar um sistema que atenda e muito satisfatoriamente o nosso Road stakeholders E aí gente importante a gente entender que
a fase de levantamento de requisitos e todas as tarefas relacionadas a requisitos elas elas constituem a base de um bom desenvolvimento e só bom então uns um bom desenvolvimento só filha não tem base ele já começa errado ele já começa ruim eu vou mostrar agora alguns dados para vocês e vão de repente permitir que vocês entendam né o com importante e com grave né eu tratar dessa questão dos requisitos é um dado que a gente tem aqui mais de sessenta por cento dos erros nos projetos de software Eles começam se originam na fase da engenharia
de requisitos os erros nascem na fase de engenharia de requisitos então assim é só que embora esses erros nação na fase de engenharia de requisitos eles só vão ser detectados você já só vou perceber que aquilo tá errado nas etapas finais do projeto bom então assim e às vezes até depois do projeto Pronto já foi entregue para o cliente e aí que esses erros são detectados então isso provoca um transtorno absurdo né o erro começou lá atrás no início antes do sistema começasse a codificado e só foi detectado lá na frente e isso é muito
grave é o transtorno gerado por isso é muito grande um outro dado é que quanto mais à frente quanto mais tarde um defeito é descoberto no software mais alto vão ser os custos e esforços para corrigir aquele defeito então assim é estimado que por exemplo na etapa de programação na construção seja quando tá sendo o co dado né codificado soft e o custo de correção de um erro ele pode custar assim 20 vezes ele é 20 vezes maior que se fosse detectado e corrigido na fase de requisitos 20 vezes maior tô na fase de testes
o custo pode chegar cem vezes mais do que na fase de requisitos caso algum defeito seja descoberto então assim a gente tiver falando de softwares que custam aí milhares ou milhões de dólares de reais enfim 20 vezes sem vezes é muito dinheiro é muito dinheiro então assim é o que que custa tão caro assim porque quando a gente já tá nessas fases decodificação de testes se a gente descobre o erro desse a gente tem que refazer muita coisa a gente tem que refazer código errado então assim gente tem que desfazer o que tá errado e
fazer certo a gente tem que documentar né Rê documentar as coisas seja documentos que estão errados a gente precisa né descartá-los e gerar documentos corretos corrigir muita coisa Às vezes a gente tem que refazer casos de teste a e fazer um monte teste o programa o juiz já tava todo testado e a gente descobriu que não era que o usuário queria a gente vai ter que fazer o teste todo de novo para ver se a coisa tá funcionando Então olha a quantidade de coisas de transtornos e isso pode gerar então a gente começa enxergar é
quando a gente começa a entender esses fatos é com catastrófico pode ser para um projeto ter requisitos mal formulados incompletos ou até mesmo inexistentes porque existem desenvolvedores de software desenvolvedores que nem levantamento de requisitos direito faz pergunta mais ou menos lá e faz olha a gravidade disso você começa um projeto sem estrutura nenhuma e além da gente tem um outro problema que um grande problema que os stakeholders Eles não conseguem expressar com exatidão é o que que eles querem muitas vezes então assim eles não explicitam detalhes às vezes informações porque eles acham que aquilo é
óbvio eles acham que aquilo ali ai isso aqui é lógico que ele vai entender só que muitas vezes as coisas não são facilmente compreensíveis para o profissional que não é daquela área às vezes para ele que é da área e tal aqui né Bem Simples aquele ver todo dia trabalha todo dia agora não é o mesmo quando é um profissional da área de computação da área de software que é o caso do engenheiro de requisitos então assim e essas informações elas sendo omitidos ou não sendo passadas é direito o engenheiro de software e pegue muitas
vezes pegar aquilo ou quem seja que tiver lá ele Citando os requisitos E aí isso pode gerar vários equívocos né ao engenheiro de requisitos acabou pensando que era assim mas não era E por quê Porque lá para o steak holder aquilo lá é trivial para ele é fácil entender que o porém a realidade de quem tá lá levantando os requisitos é outra então assim isso pode provocar muitos erros um erro de interpretação desse pode gerar muitos problemas para o processo de desenvolvimento de software Bom agora eu vou mostrar para vocês aí essa essa charge né
que é uma forma cômica da gente entender é como que os equívocos Nelson os desentendimentos as falhas de interpretação elas vão piorando no ano conforme as informações elas vão tramitando entre a equipe de desenvolvimento então no primeiro quadrinho aí a gente tem aí o que que o cliente de fato queria bom então isso era o que ele desejava Né tava dentro aí da mente dele que ele queria realmente E aí no segundo quadrinho a gente tem como ele explicou né para o líder de projeto para quem tava ali ele Citando os requisitos E aí ele
já explicou algo diferente eu não era bem aquilo que ele queria E aí como que né o o líder estava ele citando entendeu entendeu algo diferente do que ele tinha falado E aí quando Líder passe o analista específica assim já algo totalmente diferente do que o líder tinha entendido aí na hora com analista Especifique passo especificação Olha como um programador entende especificação então assim olha como uma coisa vai distorcendo e ele entende assim olha como ele desenvolve o aplicativo aí nesse último quadrinho e E aí a gente tem né A parte de testes que a
gente tem o resultado do teste de carga aonde a gente testa ou soft é é trabalhando uma grande quantidade de dados e tal e não o programa não aguentou aí colocou até ironicamente não aguentou uma borboletinha né então não aguentou o mínimo de carga que tinha que ser aguentado E aí os testadores Beta né que testam de fato ir lá no ambiente do cliente né olha a parte do software que eles receberam para poder testar receber um software incompleto né meio ganbiarra Du na hora da instalação suporte ele instala menos ainda nutriente estava uma parte
muito mais em completa do software quando o cliente é cobrado ele é cobrado assim ó o Montanha Russa E aí quando os erros surgem é como que os pets de correção eles são aplicados né gambiarras e gambiarra sair para sustentar o projeto e como o projeto foi documentado nada não houve documentação nenhuma um erro grave que os projetos têm aí atualmente nada é documentado E aí como que o consultor de marketing né como que eu marketing descreveu que seria o sistema né uma coisa reluzente conforto né E aí vem o anúncio do software né uma
coisa totalmente discrepante que foi anunciado pelo marketing quando foi entrega do software né séculos depois da de começar o desenvolvimento A solução do suporte para alguns problemas nada na base é fina pouquíssima coisa resultado do efeito de iG É no site no software online que seja efeito de Ilhéus o o efeito quando existe muitos e muitas requisições de muitos usuários E aí o sistema não suporta e cai deixe de responder e finalmente a gente tem aí a versão ou pen sorte a versão gratuita equivalente ao software que foi desenvolvido é que atende ir muito melhor
e não custava nada bom então galera é essa e essa charge né uma mostra para gente é essa é uma realidade que existe no processo de desenvolvimento softer uma realidade infeliz mas é uma realidade né não tem como fugir dessa realidade é então assim focar só na codificação ao desenvolver um software É programar tudo é programar não é e felizmente não é assim existem vários outros processos e e que nós vamos estudar né a importância da questão dos requisitos minha como a gente viu Nessa charge e eu a coisa com o problema começa lá na
raiz o cliente que é uma coisa de explicar diferente quem tá ele citando entende diferente passa para o analista que já entendi diferente específica diferente programador entendi uma coisa e programa outro e a coisa vai passando assim até que a coisa desanda de uma tal maneira que quando a coisa entregue lá no final não era nada daquilo que foi pedido né então gera uma insatisfação muito grande bom esse gráfico que vocês estão vendo na tela aí ele simboliza né ele apresenta o custo de correção na Quanto custa a correção nas diferentes é a correção a
zonas diferentes etapas de um software então a gente pode observar aí que quanto antes ao Quanto quanto antes a gente Descobriu um erro né aqui na parte a prevenção de defeitos é que no início sim aqui o custa muito pequeno agora quando a coisa vai indo lá para frente né defeitos descobertos durante a purificação integração efeito descoberto durante o teste de fez do teste de aceitação é E aí no final já é o custo do da correção no quando o programa já foi lançado e tá rodando lá no cliente então assim É a coisa vai
subindo absurdamente custo de dinheiro custo de tempo então muitas vezes até em viabiliza o custo pelo orçamento Inicial que foi feito então assim é uma coisa muito séria né e lidar com requisitos é uma coisa muito séria né que nós precisamos de fato aprender e colocar em prática beleza galera então espero que tenha ficado claro aí é o com importante né é a realização de um processo eficaz de engenharia de requisitos para evitar toda essa dor de cabeça sem satisfação esses transtornos é lá na frente então espero que tenha ficado que eu tenho conseguido aí
passar para vocês a importância desse processo beleza galera Então a nossa aula fica por aqui Um grande abraço a todos e até a próxima [Música] E aí [Música] [Música]
