AULA 7 | INTRODUÇÃO À ELICITAÇÃO DE REQUISITOS | REQUISITOS

E aí e fala galera sejam todos bem-vindos ao curso de engenharia de requisitos Eu sou Professor Otávio nessa aula eu vou introduzir o conceito de elicitação de requisitos E aí e licitação levantamento de requisitos é uma atividade Central na engenharia de requisitos ela é sumamente importante né tanto para as próximas etapas quanto para embasar o sistema em si então uma vez que a gente já conhece o contexto do sistema já fez aquele estudo é definir o que elementos estão dentro aí do contexto que elemento estão no sistema que elementos são irrelevantes em dia tem esse

conhecimento é que a gente viu nas últimas aulas o próximo passo é então levantar as necessidades e funcionalidades a serem implementadas pelo sistema é a ser desenvolvido ou seja levantar os requisitos E aí então assim primeiro passo a gente identificar as fontes de requisito porque é de lá que a gente vai pegar o requisito nossas principais fontes de requisitos nenhum ambiente são stakeholders documentos e sistemas que já estão em Operação lá então a gente vai olhar para essas três coisas para que nós possamos né extrair a maior parte de requisitos de um sistema e vamos

começando falar aí dos stakeholders é como a gente já viu os stakeholders são pessoas ou organizações que influenciam direta ou indiretamente nos requisitos identificar esses stakeholders é uma tarefa sumamente importante é muito importante no processo de engenharia de software fazer essa engenharia de requisitos fazer essa identificação se a gente deixa de considerar ou identificar um stakeholders é esse fato pode acarretar em consequências catastróficas é muita coisa ruim pode acontecer aí vai lá na frente ocasionaria alterações e manutenção no sistema quando estiver em operação então quanto mais tarde a gente deu início ao processo de engenharia

de requisitos quanto mais tarde os stakeholders forem identificados o maior o custo para o desenvolvimento Então se o seu projeto Já andou na está numa fase de análise de projeto e a gente identifica mais um steak holder lá na frente já vamos ter um custo muito maior do que se tivéssemos identificado esse steak holder lá atrás então assim é muito importante a gente de ciência é desse custo é bom a segunda coisa que a gente vai tratar vão se os documentos é o documentos também os documentos também são fontes de requisitos aí então a gente

pode ser documento de caráter particular daquele ambiente na registros e relatórios memorandos circulares planilhas de controle enfim qualquer tipo de documento que Tragam informações para gente que permitam saber é como eu funcionamento do processo naquele momento é isso é com certeza essas informações né tudo isso que é trazido por esses documentos que a gente consegue identificar vão se tornar requisitos para o sistema que vai ser desenvolvido tão documentos né de com o particular Eles são muito importantes na hora da gente considerar e as fontes de requisitos porque deles vem muitos requisitos aí para o nosso

sistema a gente pega uma planilha é assim que mais ou menos a empresa faz hoje para organizar ou para emitir um orçamento enfim E você já sabe então mais ou menos que aquele modelo ali que o sistema vai ter que trabalhar e tal e é isso já é vira um requisito A então documentos eles têm né Essa essa isso conteúdo que permite nessa identificação de requisitos não só documento de caráter particular umas documentos de caráter público também são fontes de requisitos e normas leis portarias regulamentações padrões e especificações Enfim tudo que vai influenciar direta ou

indiretamente o sistema e vai virar requisito aí precisa ser considerado Então se tem uma lei que o nosso sistema tá enquadrado nem precisa cumprir é um requisito a gente não pode deixar de cumprir aquela lei então isso tem que ser implementado no sistema e a terceira fonte como mencionei foram os sistemas que estão já em operação naquele ambiente então sistemas anteriores ao que a gente está desenvolvido sistemas legados nexon sistema sair mais antigos ou sistemas que vão tá ali atuando junto em paralelo com o sistema que vai ser implantado o que a gente tá aí

é trabalhando no processo de desenvolvimento eles podem conter informações importantes sobre as necessidades e também dos sobre os processos que vão ser automatizados pelo sistema que está sendo desenvolvido Então os stakeholders também podem fornecer aí as suas impressões sobre sistemas Então os sistemas por si só eles têm essas informações então a gente pode ir a um sistema desse que já tá funcionando lá e aí a gente vai ter uma noção muito grande de como o processo é feito hoje de repente um sistema legado ou então um sistema em paralelo a gente tem noção né dos

processos e like de repente vão ter que ser feitos aí no nosso sistema É mas não apenas né a gente extrair informações diretamente do sistema a gente pode estar informações através dos stakeholders dos stakeholders eles podem dar a impressão deles sobre os sistemas que ele já trabalham eles podem falar isso aqui eu gosto muito pois sistema só que é muito legal funciona muito bem então isso aqui para mim tão muito legal e parte que não estão legais né falar isso que eu não gosto muito falta isso falta aquilo né isso deixa desejar nesse ponto E

aí você já vai pescando esses pontos a identificando Pô então isso aqui isso aqui é bom que esteja o nosso sistema já isso aqui isso aqui os stakeholders não gostam muito então vamos fazer de forma diferente é vamos implementar de maneira mais intuitiva que esteja mais satisfatório para os stakeholders in bom então assim entendeu o que pode ser melhorado né O que poderia existir não existe de repente tem que eu vou de reclamar isso aqui podia ser podia tar melhor podia tá assim ou Puxa que legal que seria se tivesse essa funcionalidade aí não tem

felizmente então assim olhar para essas coisas para esses aspectos e levar isso em consideração na hora de estabelecer os requisitos né para o sistema a ser desenvolvido então sistemas em operação eles fornecem para gente esse feedback bom uma outra coisa muito importante né no engenheiro de requisitos é gerenciar e interagir com os stakeholders gente é viu a grande importância dos stakeholders mas quando a gente começa a lidar com projetos nesses temas de grande porte projetos de grande alta complexidade e a gente começa a lidar com uma grande quantidade de stakeholders do a gente começa a

lidar com muitos e muitos steak roads e a um ponto que a gente não vai conseguir considerar todos eles a existem situações que a gente não vai poder considerar uma um cada um dos stakeholders que ele está envolvido naquele ambiente então assim quando isso acontecer na quando não for viável é considerar todos os stakeholders a gente deve ser deixando a cuidadosamente quais steak roads vão fornecer aí os dados os requisitos para gente aí é de uma certa forma eles vão fornecer representando todos os outros por isso que a gente deve escolher com cautela é qual

o steak holder ou fazer um grupo misturando de repente um funcionário mais novato um que já a experiência para que a gente consiga abrange aí mais ou menos Toda a realidade dos stakeholders ali presente então um exemplo né se a gente tem aí 100 mil operadores de telemarketing em uma empresa e a gente está fazendo um sistema ali é que vai ter uma parte do telemarketing para se registrarem lá os protocolos as operações que eles vão fazer nós não vamos conseguir como Engenheiros entrevistar 100 mil profissionais com o Heleno requisitos de cada um a gente

não vai conseguir isso não é viável financeiramente e também no tempo demorariam muito tempo e de repente não seria assim um retorno tão grande ele estar um por um desses 100 mil é Então nesse caso fica enviável E aí a gente precisa né selecionar aí alguns membros desses E esse grupo de stakeholders pra que eles nos passem os requisitos então selecionar em membros né diversificados né Por aqui consigamos abranger o máximo possível daquela realidade é e existe também um outro problema né que pode acontecer inclusive nessa situação né os stakeholders que não recebem a devida

atenção é do engenheiro de requisitos nenhum dinheiro e requisito de repente ele vai falar com colega dele que tá do lado dele mais acaba não falando com ele é comer ação né podem começar a criticar o projeto é porque eles podem acreditar que as necessidades deles as ideias que eles têm não vão ser atendidas né o mesmo porque eles não estão vendo relevância poxa por aqui botar um sistema Aqui tá o cliente no continua fazendo dessa forma o Don sim é a gente começa a se deparar com essa situação então sempre a gente deve considerar

o máximo de stakeholders possível né para que essa situação não aconteça para que todo mundo seja ouvido mas se isso não for possível como é o caso é que eu acabei de comentar a gente deve deixar né todo mundo à parte né seja através de um comunicado geral alguma coisa assim deixar todo mundo ciente é das informações do projeto do que que tem é até agora levantado deixar todos cientes né do seu papel ali do que que você está fazendo explicar muitas vezes o motivo do porque você não poder falar com todo mundo né e

perguntar né deixar aberto falar mas se alguém tiver alguma ideia e alguém tiver alguma sugestão alguém olhar e ver o que a gente tem aqui tá incompleto Tá faltando sim tá Boa tarde para vir até mim falar é para me comunicar alguma coisa que tá faltando que com certeza a gente vai levar em consideração então fazendo dessa forma né deixando mais aberta as coisas né ficou ambiente muito mais amigável e a gente evita esse tipo de crítica é esse achismo né dê a entender que não vai atender as minhas ideias aquilo que eu tô esperando

do sistema então é importante né Essa abertura por parte do engenheiro de requisitos é os stakeholders também né Isso é um outro problema eles podem demonstrar aí desmotivação com projeto que está sendo desenvolvido é porque às vezes eles já estão satisfeitos com os sistemas que ele tem pô e o cara a gente já tá ali há dez anos trabalhando naquele sistema ele tá muito satisfeita já sabe decora de fazer tudo e ele não quer migrar de e é ainda que haja necessidade ainda que o sistema possa trazer melhorias à Então por medo dessas mudanças né

que de repente ele vai ter que reaprender as coisas né e mudanças na rotina dele aqui ele já tá acostumado com aquela rotina com aquele sistema ele de repente tem medo de mudar aquela rotina né então assim às vezes pode acontecer Também com esse medo vem de uma experiência negativa poder repente a empresa já tentou implantar um projeto antes e o projeto ficou muito ruim é E aí eles quebraram a cabeça para tentar usar o novo sistema e no final não conseguiram tiveram que voltar para o sistema legado e enfim isso pode trazer medo de

um novo projeto agora poxa vai ser tudo a mesma coisa vai chegar isso novo não vai dar certo a gente vai ter que voltar então trabalheira danada à toa enfim então gente é importante a gente entender que isso é próprio do ser humano um medo da mudança é a cisma daquilo que vai mudar as pessoas elas tendem a criar suas rotinas e querem manter aquelas rotinas elas não gostam de ficar mudando a rotina ela se sentem ameaçadas quando alguma coisa começa a mudar ao redor delas e quando influencia elas diretamente aí mais ainda então se

é próprio do ser humano isso está presente no mundo profissional também então quando a gente chega é para profissionais assim que já estão aí é muito tempo de repente usando uma solução a oferecer resistência né de repente eles não vão querer colaborar é enfim vão sempre falar para vocês para você que aquilo não adianta nada que não vai dar certo enfim e várias coisas negativas então é importante o engenheiro de requisitos ele atuar É nesse âmbito para convencer né a todo mundo dos benefícios que o projeto vai trazer é e da importância da implantação dele

na organização na empresa Poxa arranco É eu sei que isso é esse programa funciona bem mas poxa é esse aqui vai ter isso esse isso é isso aqui vai ter isso aqui que vai funcionar mais rápido tem essa vantagem né você não vai mais perder dado enfim fazia propaganda do projeto convencer né que vale a pena mudar que você tá mudando para melhor bom então esse é o papel do engenheiro de requisitos nesse caso né para que todo mundo colabore com você que você precisa da colaboração dos stakeholders especialmente os mais experientes é que vão

poder de fornecer muitos informações sobre processos Sobretudo com uma exposição feitas ali então assim é você não quer que essas pessoas se tranca em se fechem e só fiquem falando que não vai dar certo e não te passo as informações que você precisa então para isso sempre se deve atuar para convencer né para fazer essa propaganda de que as coisas vão melhorar com projeto e daí então criar esse ambiente em mais favorável EA interação do engenheiro com os stakeholders bom então sim é a gente sempre deve procurar evitar qualquer problema não é com os stakeholders

integral todo mundo daquilo que tá acontecendo é fazer um acordo verbal ou escrito se for o caso né fala não ah mas eu não quero esse sistema novo porque eu gosto muito a coisa já funciona assim você faz um acordo com cara ali e meio de boca né falar tudo bem então a gente né vai deixar mais ou menos assim não vai mudar tanto a sua rotina qualquer coisinha que foi mudar eu falo com você eu te explico é como que vai ser e tal e aí você traz essa segurança é para os stakeholders E

aí você sempre deve deixar claro tudo isso não é deixar claro a sua conduta é qual será a sua conduta de dentro seu papel ali dentro e qual deve ser a conduta deles para com você de sempre ajudar de colaborar a fornecer as informações que você precisar e deixa Claro é sempre responsabilidades tanto do engenheiro suas responsabilidade quanto à responsabilidade deles no projeto porque não adianta Só Engenheiro trabalhar num projeto de engenharia de requisitos é ele é uma parte a outra parte são os stakeholders tinha uma dessas partes não funciona a coisa não anda então

deixar isso sempre muito Claro aí quando a gente fala de responsabilidades é vale a pena então citar aí as principais responsabilidades de cada uma das partes estão falando aí das responsabilidades do engenheiro de requisitos então assim gente encara como responsabilidades principais né falar em linguagem compreensiva pelos stakeholders nada de falar coisa rebuscada termo técnico que ninguém vai entender nada esse distância você nos teus stakeholders o Don sim é justamente o que você não quer você quer proximidade aí você quer é essa essa forma de obter essas informações né de forma mais suave é fluida conseguir

aí atuar né fazer seu papel se familiarizar com o ambiente o domínio do projeto né ou seja estar ali dentro entender como funciona aquele ambiente a entender as especificidades dele ou seja se familiarizar aí de uma certa maneira aí tá um pouco Emerso né naquela realidade para entender melhor como tudo funciona é documentário os requisitos na Lógico não ficar naquela de ar Vou guardar tudo na mente tá o porque não adianta são muitos requisitos muitos os detalhes estão documentar tudo para que não não haja o transtorno de você falar com stakeholders repente você faz uma

reunião um pouco cansativo ou para pegar os requisitos ela é uma ou mais horas e aí você não documenta perde o esquece aqui os tem que fazer aquilo tudo de novo pode estressar não pode deixar o stakeholders já indisposto não querendo mais ajudar tanto Enfim então sempre documentar tudo para que você tem esses informações aí palpáveis apresentar as informações importantes e resultados os stakeholders então é deixar todo mundo inteirado do andamento do processo né as informações importantes que foram levantados se tiver algum comunicado importante a fazer é resultados a 20 definiu que vai ser assim

a gente definiu que vai ter uma tela que vai ser dessa maneira expor para todo mundo é para que todo mundo já começa a ter ideia aí vai ser mais ou menos assim e tal e se alguém tiver alguma coisa contra já se manifeste não é papel de stakeholders não só com olhei informações né E aí extrair isso doces tem que o outro mas também fazer o caminho ver as passar informações para ele sobre o andamento do projeto é só como estão as coisas que está sendo decidido é como que vai ficar uma coisa ou

outra enfim para que os stakeholders já vão se familiarizando aí com as ideias e estejam sempre a página para que depois não chegue lá no final um dele falo Poxa mas não era nada disso não queria nada disso então Poxa porque se não falaram comigo antes disso então assim assim todo mundo já fica ciente manter uma relação respeitosa com os stakeholders é não criar conflito não é mesmo que hajam steak rodriques que seja mais temperamental aí que de repente não seja assim tão gentil né Não não faça e não pague na mesma moeda porque você

vai gerar um conflito você vai gerar um problema é um problema principalmente para você porque aí você vai precisar da ajuda daqueles take holder então assim mantém uma relação respeitosa mas se alguma coisa acontecer se você fale com aquele steak roads seja muito sincero mas sempre com respeito com cordialidade para que você sempre mantenha um ambiente agradável um ambiente favorável ao seu trabalho é não crer brigas não criar intrigas nada disso é fofoca nada aí isso não faz parte do seu trabalho né não chegue nem perto dessas coisas porque isso vai prejudicar muito pode afundar

aí é sua carreira como engenheiro de requisitos e até prejudicar muito projeto que você tá trabalhando permite que os stakeholders solicitem propriedades no sistema que simplifica e facilita em sua utilização então assim deixar Sempre sei que Rodrigues né aberto e falasse implora vocês podem aí e sugestões vocês podem pedir aí o que o que vocês desejarem para o sistema não sei se a gente vai poder atender dentro do orçamento mais o que tiver ao nosso alcance a gente vai fazer a gente vai ajudar e assim os stakeholders né vão ter sua liberdade a mais para

chegar até você e passar essas informações que são De grande valia para o sistema né Por aqui no final tem uma aprovação muito maior aí Por parte dos stakeholders do que teria se ninguém falasse nada né do que das ideias do que desejasse garantir que o sistema atenda os requisitos funcionais e não funcionais dos stakeholders tão assim gente se vocês já foram lá fizeram todo esse trabalho junto com os stakeholders escolheram opiniões Poxa o pediram tudo não é justo que depois chega o sistema para eles totalmente diferente né com nada daquilo que eles pediram gerando

um monte a turma então assim é papel também do engenheiro de requisitos está lá do outro lado junto à equipe de desenvolvimento primando ali por aqui os desenvolvedores os projetistas arquitetos analistas enfim estejam trabalhando na estejam desenvolvendo da forma que diz take Hold solicitaram na forma que você documentou da forma que você especificou para que fosse desenvolvido então assim é papel do engenheiro nessa essa fiscalização ela junto ao a equipe de desenvolvimento para que o sistema seja entregue de acordo com os requisitos então assim essa parte também é inerente ao Engenheiro é sempre avisar-nos que

não é bem assim né É assim que foi pedido pelo cliente o cliente solicitou isso aqui não é desse jeito que está sendo feito então ter essa visão eu medi ambas as realidades para manter aí tudo Unificado tudo direitinho né Então essas aí são as principais [Música] responsabilidades do engenheiro de requisitos e assim também existem essa responsabilidade dos stakeholders para com o projeto para com o engenheiro também então introduzir um engenheiro de requisitos no ambiente da aplicação então é importante que os stakeholders eles sejam bem receptivos é eles não excluam não tratem o engenheiro de

requisitos como intruso é como alguém que está ali para fazer alguma coisa ruim porque isso prejudica muito a relação e consequentemente o trabalho de levantar os requisitos então assim é importante essa receptividade então é E caso isso não aconteça Deixa claro né Qual a além disso a regra é grande elevance dessa relação de confiança então assim Engenheiro e tem que estar imerso ali naquele ambiente ele tem que tar lhe dando a todo momento com os processos ele tem que tá compreendendo como as coisas funcionam tão tudo isso é papel do engenheiro aí os stakeholders eles

têm que favorecer nesse ponto fornecer todos os requisitos dos em os steak roads eles tem que passar para o engenheiro os requisitos é não é guardar Vou guardar o ouro vou guardar esse conhecimento que só eu sei isso com certeza vai fazer falta lá na frente o sistema vai vir em completo e de um jeito de outros vai ter que ser implementado depois vai acabar tendo que ser implementado então sem deixar todo mundo ciente disso Olha gente eu não tô aqui para criar um sistema para tirar emprego de ninguém para para que ninguém seja demitido

eu tô aqui apenas a criar um sistema que Vai facilitar a vida de todo mundo mas para isso eu preciso que vocês falem né as informações que eu pedi com a maior sinceridade clique em como as coisas são feitas quais os caminhos que tem que ser feito é de maneira direta sem querer enrolar a ou me confundi o que já é nem sempre é fácil o entendimento de certos ambientes aí se vocês tentarem confundir mais aí que prejudica então deixar todo mundo ciente disso para que os stakeholders entendam que é papel deles fornecer né da

forma mais simples né compreensiva todos os requisitos todos eles sem faltar nenhum a tomar as decisões em tempo hábil então se você pergunta aos stakeholders a como que vocês gostariam que isso aqui tivesse como vocês gostariam que fosse essa parte do sistema como que vocês gostariam que esse processo tivesse aí disponível para vocês no sistema se vocês fizer fizeram perguntas aos sei que Rose a cada pergunta de morar em uma semana um mês para responder dois meses isso vai atrasar o projeto assim astronomicamente então assim deixar os stakeholders cientes que é um projeto que está

sendo pago que cada dia que tá correndo projeto em desenvolvimento bom então assim eles não podem demorar para poder fornecer as respostas para tomar as decisões a eu quero dessa forma a gente chegou à conclusão que a gente quer dessa forma aí não ficar na dúvida toda vida porque vai se tornar inviável então assim deixá-los cientes que as decisões Elas têm que ser tomadas em tempo água né você não tem todo o tempo do mundo projeto a empresa que tá desenvolvimento soft desenvolvendo solta não tem todo tempo do mundo para tá ali ouvindo esperando as

decisões serem tomadas ver isso até decisões simples aí então assim e deixar isso também claro né que é uma responsabilidade dos stakeholders respeitar as estimativas de custo e viabilidades feitas pelo engenheiro então assim Engenheiro the vast Marcos tu vai vir se aquela de repente um stakeholders passa um requisito para o engenheiro com o engenheiro ele vai ter noção nesse aqui vai sair muito mais caro assim se vai dar para incluir no orçamento do projeto então o se aquilo é viável nós se tem como implementar aquilo se não tem como então assim às vezes o cara

pede uma coisa mirabolante né algo que realmente não vai ter como implementar naquele projeto Às vezes a coisa pode até ser interessante vezes é uma coisa viajado em filmes tem que roubar a gente tem de todos os tipos Mas eles têm que entender que às vezes o engenheiro vai ter que falar olha isso não dá para fazer ou então não dá para fazer agora bom então com custo que o orçamento do projeto infelizmente não vai ter como acrescentar essa funcionalidade então assim os stakeholders eles têm que entender né que tudo tem limitações limitação tecnológica e

é uma coisa mirabolante não dá para fazer imitação financeira né não vai não vai ter como dentro do orçamento colocar essa responsabilidade de alimentação de tempo o tempo que a gente tem do projeto não dá para colocar e isso então é é importante deixar esse Claro para o steak holder para que ele entenda é que existem essas limitações e que ele não pode né ficar enfezadinho porque não tá atendendo que ele quer e tal e eu não ele não pode ter esse comportamento ele tem que entender que existem limitações Tem coisas que vão dar para

fazer outras não né então é importante também que os stakeholders tenham ciência dessas limitações priorizar requisitos a também é uma responsabilidade de steak roads então eles precisam dizer quais são os requisitos mais importantes o que não pode faltar no sistema aquilo que é prioritário é que sem ele o processo não anda né não é que ela vai ter só um uma coisa lhe prejudicando é funcionando mal não vai andar mesmo então eles tem que priorizar né dizer quais são as prioridades Quais são as funcionalidades as restrições enfim que são as mais importantes que precisam ser

implementadas a todo custo e essa informação gente é muito importante porque é porque existem situações as vezes que você precisa né Você tá vendo que o tempo está avançando e você vê se precisa reduzir acabar reduzindo escopo ou seja o leque de funcionalidades que que ele só fica vai ter para entregar na data mesmo que você entregue uma parte depois enfim as vezes acontece esse tipo de atraso Nem sempre dá para estimar 100% ali o tempo certo que vai ser para desenvolver que ele soft bom então assim é quando chega no momento desse é a

Poxa não vai dar tempo de entregar tudo o que que a gente faz aí você vai lá ver o que que é prioridade isso aqui é prioridade faz isso agora se você não tem essa informação e aí você vai fazer um monte de coisa lá que é coisa secundária coisa que não é núcleo lá do funcionamento do negócio bom e quando chegar lá o sistema não vai servir para nada porque o principal não tava feito então assim é muito importante né que os stakeholders eles têm uma cidade priorizar falar com sinceridade o que que é

mais importante não é o que eles querem né então mas Falar o quê que é mais importante para a tarefa dele para o desempenho do seu serviço da sua função é do papel ali na empresa e também para o sistema como um todo bom então sim priorizar requisitos é uma responsabilidade e grande do stakeholders é uma falha em cumprir essa responsabilidade pode impactar no sistema que de repente nem vai ser utilizável no primeiro momento então sempre também deixar claro a importância né de priorizar os requisitos por aqui quando o sistema foi entregue eles vão ter

ao menos Essas funções e eles declararam como prioridade a em um outro erro também que não deve acontecer né achar que tudo é muito importante Às vezes tem que eu vou te falar isso aqui é realmente por isso mais isso aqui também tem isso aqui e no final você acabou priorizando tudo outro tudo com a mais alta prioridade Oi e aí a gente cai no mesmo problema se a gente precisar restringir o leque de funcionalidades a gente não consegue que tudo é prioridade então assim é trazer essa noção né próprios stakeholders que prioridade é só

aquilo que é essencial para que eles executem aí minimamente as tarefas de consigam executar essas tarefas dele é consigo cumprir os papéis e eles tem que desempenhar ali frente o sistema que vai ser entregue aí que outras coisas né Podem ficar aí para uma segunda entrega se for o caso né desenvolver depois e tal mas de repente a uma lei que tem que ser cumpridas não pode ser escondido pelos tag holder ver se tem que eu vou te falar isso aí cumpri depois E aí entrega o sistema sem essa restrição da Lei cumprida a empresa

pode ser multada olha olha a quantidade é de transtornos que pode acontecer a empresa pode ter que fechar até regularizar a situação então assim a gente não tá lidando com brincadeira né então a gente precisa a informar os stakeholders que isso é importante deixar o que é prioridade como prioridade e o que não é o que tiver menos prioridade e classificando com menor prioridade para que na hora né do vamos ver os engenheiros aqui o desenvolvimento Posso então priorizar os requisitos que vão ser entregues à a inspecionar os requisitos documentados então também a responsabilidade stakeholders

né fazer a validação depois em inspeção Engenheiro ele vai lá acolhe os dados tenta fazer da forma mais fidedigna possível mas depois que o engenheiro já documenta a tudo especificar como o sistema vai ser feito antes do sistema começar a ser feito o engenheiro tem que chegar prestei couro e fala Olha é isso aqui que que vai ser feito isso aqui que vocês me transmitiram agora preciso que vocês confiram se é isso mesmo eu não preciso que vocês analisem aí tudo que foi documentado me digam olha tá tudo certinho e isso aí mesmo ou não

tem um outra coisa aqui que tem que ser mexido Por que não tá legal então assim é responsabilidade dos stakeholders fazerem isso então e às vezes isso é complicado porque você vai chegar lá com os requisitos de repente documentados é e às vezes aquela pilha de requisitos o cara vai né torcionário e fala povo tem que ver isso tudo né Já não falei como é que é por que que eu vou ter que tá vendo isso tudo de novo bom então assim às vezes é difícil essa compreensão por parte dos stakeholders então é necessário levar

sua consciência fala olha vai dar um trabalhinho né eu sei que vai ter que parar dá uma olhadinha nisso tudo aí mas em compensação depois você vai ter a garantia de que tudo vai sair do jeito que você quer do jeito que você pediu e é muito pior mas você mentir para mim né falar que olhou tudo não olhou nada e falar que tá tudo certo sem olhar nada e depois chegar o sistema para você bom e você vai identificar depois na hora de usar que a coisa não tá do jeito que você pediu e

aí você deu o aval você me fala olha o Vitor tá tudo certo então às vezes a culpa ainda vai recair em cima de você então deixar ter que horror de ciente disso vale a pena dá uma olhada que depois você tenha certeza que o sistema vai ser entregue de acordo como que você queria Então deixar o steak roads ciente de que isso vai ser produtivo né de que essa validação vai dar certeza que o engenheiro precisa para passar o projeto para mesa de produção bom então é importante né Essa essa inspeção essa validação dos

requisitos a comunicar imediatamente as mudanças nos requisitos em sabe que requisitos eles são coisas que não são estáticas eles são dinâmica eles são dinâmicos é então eles vão estar em movimento né Vamos por assim dizer vão haver mudança e não é que a gente a no início do projeto requisito era assim Pode ser que no meio do projeto né acabou surgindo alguma coisa aquele requisito mudou um processo dentro da empresa passou a ser feito diferente Surgiu uma lei nova que tem que ser cumprida Oi e aí um requisito vai ter que ser alterado ah ah

não é aquele desde que ela tudo já foi passado beleza reúne tudo Fecha a pasta leve e manda desenvolver na um tem que ter essa comunicação a mudou uma coisa que e é precisamos rever isso aqui para que o processo seja adequado no sistema e aqui essa Norma agora que é obrigatória seja cumprida pelo sistema antes não era quando a gente viu esse requisito agora é tão essa funcionalidade tem que cumprir essa Norma então assim quando o stakeholders souber de mudanças assim que impactam os requisitos ele deve comunicar imediatamente o engenheiro não é não deve

deixar para depois deixar para o final quando o sistema estiver pronto aí ele fala mas por agora não é mais assim e aí já é muito tarde então deixar de consciência ou qualquer coisinha que mudar ou Se vocês mudarem aí o processo ou se vocês acharem que ela não falaram em com clareza acharam que ficou meio confuso depois refletindo é podem falar comigo podem nem ligar para mim me mandar e-mail enfim e me falar como que é de fato Ou me falar o que mudou que precisa ser agora considerado é porque a gente faça os

ajustes aí o mais cedo possível para que a gente não tenha problema depois que o sistema foi entregue e é dever fazia muita coisa não quanto mais cedo vocês mudanças forem comunicadas é não Impacto de custo menor aí várias de várias coisas a respeitar E participar do processo de engenharia de requisitos então né é uma tarefa fundamental é esse respeito por parte do stakeholders nesse entendimento essa compreensão de que é aquele processo tá ali para ajudar aquele processo é o trabalho de outra pessoa no caso o seu do engenheiro de requisitos é o trabalho de

várias outras pessoas que vão estar na equipe de desenvolvimento não respeitar todos processo não é o processo de envolvimento processo de requisitos e colaborar com ele não entende que aquilo é uma coisa para todo mundo ganhar né Não só a empresa que está desenvolvendo soft não sou engenheiro e requisito mas para todo mundo sai ganhando todo mundo sai bem com soft é legal É bem desenvolvido vem testado validado bom então assim é muito importante que os stakeholders eles tenham essa consciência bom e o bom engenheiro de requisitos ele precisa dar uma atenção né importante na

documentação dos stakeholders ou seja os stakeholders também precisam ser documentados a gente meio que tem que ter um cadastro aí para cada stakeholders A então se a gente vê aqui é realmente e sempre vai ser né necessário manter informações de cada steak holder que está envolvido no processo a gente tem que manter ali uma ficha uma planilha para cada um dos stakeholders com dados sobre eles é justamente por aqui nós tenhamos aí eu sou tudo registrado cadastrado quem participou do projeto as informações de contato informações pessoais Enfim então assim é informações que tem que constar

nessa nessa planilha e só informações importantes e isso tudo tem que estar ali presente Então quando vocês forem não é desenvolver aí esse documento essa ficha de stakeholders tem que existir pelo menos a informação do nome né você precisa saber o nome do steak Roads e é senão não adianta nada então o senhor que identifica que eles têm que muda a função do is take Hold Qual o cargo que ele ocupa Qual o papel que ele que ele cumpra na empresa uma organização Enfim então a função dos stakeholders tem que estar na ficha os dados

pessoais que você achar necessário colocar a de repente acha interessante colocar a idade faixa etária né para uma forma de tratamento na hora que você se dirigir nas senhor céu ou então se dirige de maneira mais casual enfim é os dados pessoais que você julgar que tem que ter ali você coloca na de repente vai ser mais ou menos aí não tem como precisar para vocês quais vocês vão precisar vai depender aí do ambiente das pessoas que você tiver lidando Esse é o das fontes né a gente falou de pessoas mais existem também outras fontes

aí pode ser documentos né então a gente cria uma ficha a tal norma é um requisito A então assim às vezes é importante claro que aí a gente tem que usar o bom senso e verificar quais Campos cabem é por esse tipo de ter que o Holden então dados pessoais informações de contato bom então você tem que ter informações de contato daquele stakeholders é para por quê que tem que ter porque se você precisar contratar ele é porque tirar uma dúvida por você escreveu e colheu os requisitos e tal aí depois Bateu aquela dúvida pois

será que é isso mesmo vou ligar para ele vou mandar um e-mail para ele se não você vai ter que ir lá na empresa tentar chá então assim as informações de contato elas ajudam muito né no processo de engenharia de requisitos os locais e horários em que ele está disponível na isso é muito importante para que você não incomode por você já tá meio que incomodando né tendo que pedir informações consultar o cara ali às vezes muitas vezes então assim você não quer incomodar ele não sei lá numa reunião que ele tiver numa hora que

ele não esteja disponível para isso Então pergunta a ele e anota deixa registrado nessa ficha quais os horários que eles horários que ele está disponível e também locais nesse foi o caso aonde que eu posso te procurar Se eu precisar falar com você pessoalmente é para tratar de algum assunto enfim registrar os locais e os horários também que ele vai estar nesse local os horários que ele pode falar por telefone enfim tudo isso é importante deixar registrado o nível de conhecimento então assim até mesmo por você saber como que você vai falar com stakeholders não

adianta você de repente foi uma pessoa que tem um nível baixo de conhecimento não adianta você falar aí muita coisa mais rebuscada ou termos mais técnicos daquela área mesmo que a pessoa não vai te entender aí a comunicação não flui então assim pode ser interessante a gente está um nível de conhecimento de cada um né Com relação à área que eles estão trabalhando ou com relação à área técnica mesmo é o de soft enfim e às vezes cê vai falar alguma coisa sobre soft e a pessoa não mexe no computador Às vezes uma pessoa tem

mais idade Enfim então você precisa ter essa informação registrada nesse nível de conhecimento para que você consiga conversar com a pessoa sabendo ela não sabe disso tão vou tentar trocar informações com ela né usando analogias ou perguntando sobre o processo que ela faz em manualmente para que a gente possa automatizar Enfim então isso é importante é a relevância daquele stakeholders bom né então assim se ele é um stakeholders que fornece muitos requisitos o que fornece os principais requisitos do sistema aos requisitos do núcleo do sistema enfim se ele é um steakholders assim ele tem muita

relevância é alguns teclado fornece um requisito só e vezes é um requisito do seu com Dário então ele tem uma relevância menor bom então assim saber a relevância dos stakeholders é muito importante porque é desse cara que às vezes a gente vai precisar mais então ter essa informação isso registrado em importante e os interesses dos stakeholders também para com projeto então assim deixar registrado é o que que ele espera do projeto né é o que que ele a como que ele acha que vai ser feito como que ele acha que vai estar no final lá

para que se alguma coisa não sai do jeito que ele quer você possa ligar ou informar de alguma maneira trocar uma ideia com ele é isso aqui infelizmente não vai dar para você assim estaria legal se fosse assim aí ele vai dizer sim ou não justificar Enfim então têm esses interesses é muito importante para que você se Organize é na hora de contratar os stakeholders nas vezes o cara para te deu uma ideia você foi boa ideia eu queria saber mais aí você já sabe quem te deu a ideia porque o engenheiro de requisitos ele

lida com tantos steak roads vezes com tantas ideias e depois vem na mente Poxa realmente podia ser assim só uma coisa importante e quem me falou isso então ele vai lá as fichas e acha né quem falou ou então hoje só lembra por aquele cara me falou uma coisa interessante não lembro muito bem que que foi vai lá na ficha e ver o que que ele tinha te pedido e aí você tem esse controle o maior é isso tudo de permite uma organização maior e uma fluidez muito maior no seu trabalho de interage Ltda com

os stakeholders beleza galera Então essas aí são as considerações que tinha para fazer é com relação a interação aí do engenheiro com os stakeholders eu espero que tenha ficado Claro para vocês aí qualquer coisa vejam novamente o vídeo para que vocês E essas responsabilidades e tudo isso que a gente viu na aula de hoje porque é sumamente importante essas características esses conhecimentos para a atuação do engenheiro de requisitos a gente fica por aqui Um grande abraço e até a próxima a E aí E aí [Música] [Música]