TADS - Engenharia de Software - Modulo II - Aula 02

Olá a todos sejam bem-vindo a nossa segunda aula do módulo dois eh nossa primeira aula a gente viu um pouco sobre engenharia de requisitos entendemos o processo o que que é engenheiro de requisitos o que que é você e tem pensar nos requisitos como um um dos uma das partes mais importantes né durante todo o processo de desenvolvimento de software eh nós vimos também documento de requisitos a importância de você ter Um documento de requisitos desse documento de requisitos ser eh o documento que você vai se comunicar tanto com os engenheiros de software como também

com o cliente agora nessa aula de de que a gente tá vendo agora a gente vai se preocupar com a elicitação de requisitos em inglês é elicitation eh em português traduzido para ele citação mas nada mais é do que a busca pelos requisitos eh Quais são os mecanismos que eu posso eh ter Quais são as Ferramentas que eu tenho para que eu consiga buscar os requisitos e colocar el colocá-los de maneira correta no no documento Tá bom então o objetivo dessa aula seria descrever o processo da elicitação e análise dos requisitos introduzir o número de

técnicas de licitação a gente vai ver bastante exemplos de várias técnicas todas retirar dos livros né A gente vai ver que tem algumas mais utilizadas que são mais conhecidas e outras que não tão não São tão conhecidas assim e vamos discutir como que os protótipos podem ser utilizados no processo de engenharia de requisitos a nossa última aula vai ser sobre prototipação dentro do processo de engenharia de requisitos tá bom eh lembrando eh que o nosso último módulo a gente vai ter engenharia de requisitos eh voltada para um protótipo para desenvolvimento web bom será a primeira

etapa aí que a gente vai pensar no Desenvolvimento de um sistema web aqui mais uma charge que é só pra gente identificar um problema que ocorre bastante né que em outras engenharias isso seria impossível de ocorrer né talvez se você fizesse um planejamento aconteceria aqui tá lá o gerente de projeto falando assim olha eu vou sair e procurar o que que a gente tem que fazer enquanto isso vocês aí desenvolvedores comecem a a a codificar ou seja né e é o que acontece muitas vezes muitas vezes O software construído sem saber direito Quais são os

requisitos o pessoal vai desenvolvendo eh por tentativa e erro a gente já viu lá aquele método lá no módulo um sobre tentativa e erro e e depois vai entregando pro cliente O cliente acha que não é aquilo volta e fica um vai e volta e acaba atrasando ficando mais caro e por aí vai né a gente já sabe todo eh o desenrolar desse problema mais uma charge aqui eh dessa vez uma situação onde tem lá o Desenvolvedor e um cliente eh o cliente tá acabou de de de de passar várias informações sobre o levantamento de

requisitos do software que ele que que seja construído e quase que finalizando o cliente fala bom acho que agora ficou claro né oente lá digitando pegando os requisitos crique com essas informações vocês vocês poderão desenvolver e o que nós necessitamos né o cliente falando na verdade eu não sei o que eu estou pedindo mas vocês sabem o que eu quero Aí o engenheiro dis software ali dá um desmaio né Essa é a confiança que o cliente tem né se você não não tiver um contrato muito bem feito um contrato de confiança né entre o cliente

e o desenvolvedor você não vai conseguir saber eh se você tá construindo algo correto e o próprio eh confiança do cliente também acha que o engenheiro de software vai saber o que que o que ele quer né então é é uma situação bem complicada por isso é importante essa Aula de agora para que a gente pense qual é melhor técnica para que recupere para que eu faça o levantamento dos requisitos corretamente uma última azinha prometo que é a última Ah só para que vocês de uma olhada aí façam a interpretação de vocês pause o vídeo

e tentam entender o que que tá acontecendo aqui né De novo é o Dilbert do Scott Adams falando sobre um pouquinho do processo de engenharia de requisitos começando agora a falar um Pouco sobre elicitação de requisitos né Daqui a pouco eu defino para vocês melhor o que que é licitação mas só para que a gente entende né todos os componentes o primeiro componente que deve ser entendido é o domínio da aplicação Tá bom então e a gente é desenvolvedor de software engenheiro de software e a gente não é especialista em mais quase que mais nada

né E por exemplo vamos supor que nosso cliente é uma farmácia e a gente conhece muito Pouco do domínio da farmácia então primeira coisa que a gente deve conhecer quando vai começar aí listar os requisitos antes de saber as necessidades dos stakeholders e as restrições do sistema é saber o domínio dessa aplicação ou seja como é que funciona uma farmácia né Quais são as leis que regem as farmácias e como é que funciona um estoque de de uma farmácia e por aí vai depois eh saber qual o problema ser resolvido Dentro desse domínio né então

fica mais fácil fechar o escopo depois que eu conheci o domínio da minha aplicação depois o contexto de negócio a minha aplicação vai trabalhar com qual contexto de negócio Ah vai ser para trabalhar com controle de estoque de vendas como é que isso funciona dentro do do domínio da aplicação e por fim Quais são os detalhes que são especificados pelo pelos stakeholders né O que que os os stakeholders querem de Diferente querem que se resolva para contexto deles Tá bom então esse é o domínio da aplicação Esse é o domínio que a gente vai trabalhar

e são os componentes que pertencem a licitação dos requisitos definindo aqui o que que é uma elicitação de requisitos é descobrir torná explícito obter o máximo de informações para o conhecimento do Objetivo em questão Então essa palavra que a gente vai aprender o engenheiro de Software sa utiliza bastante né que é a parte de elicitação de requisitos nada mais é do que descobrir os requisitos tornar explícito para que se torne explícito você pode utilizar alguma técnica que a gente vai ver daqui a pouco tá bom Então qual que é a função da elicitação cabe a

elicitação a tarefa de identificar os fatos que compõem os requisitos do sistema de forma a promover o mais correto mais completo entendimento do que é demandado daquele Software então a gente percebe que é você descobrir exatamente o aquele software faz e só pela pela definição a gente vê que não é algo simples né como é que a gente descobre eh tudo que o software faz né só na primeira etapa Só através da conversa então não é só através da conversa a gente vai ter outras técnicas que vai ajudar isso Começando aqui com algumas dificuldades que

a gente pode encontrar na elicitação usuários po de não ter uma ideia precisa Do sistema que eles requerem né então Eh isso é bastante comum onde usuários não sabem o que eles querem né E às vezes o engenheiro não consegue obter isso de forma concisa né engenheiro de software usuários têm dificuldade para descrever em seu conhecimento sobre o domínio do problema isso também é bastante comum usuários e analistas de software T diferentes pontos de vista do problema por terem diferentes formações Então pode ter algum problema que um usuário Eh sei lá vamos supor de novo

da farmácia tem um um ponto de vista de como vai resolver aquele problema já o desenvolvedor de software tem um outro ponto de vista de como resolver aquele problema né Isso precisa ser negociado usuário pode podem eh antipatizar se com o novo sistema e se negarem a participar da licitação eh ou mesmo fornecer informações errôneas isso acontece né se você tem uma empresa muito grande eh e você vai informatizar várias áreas dessa Empresa ou vai trocar o sistema atual e você precisa entrevistar aqueles funcionários aqueles usuários do sistema para obter informações para gerar um novo

sistema esses usuários podde ficar com medo de de perderem o emprego para esses novos sistemas né agora com a i então vai ficar mais complicado isso né então isso pode acontecer na etapa de licitação retomando os componentes da elicitação eh o entendimento do domínio da aplicação então é o conhecimento do Domínio é o conhecimento geral onde o sistema ser aplicado como aquele exemplo da farmácia que eu falei para vocês se você vai fazer um sistema de farmácia precisa conhecer como é que funciona asas farmácias por isso eh muitas desenvolvedores de software se especializam em um

determinado domínio a gente vai conhecer muitos desenvolvedores de softwares que fazem software por exemplo pra área da saúde porque ele já vai ter aquele Conhecimento de domínio da aplicação tá bom É mais fácil você começar desenvolvendo um software para um determinado domínio do que você ficar e pensando em vários domínios você vai ficando cada vez mais conhecedor e vai ficando cada vez mais fácil entendimento do problema os detalhes dos problemas específicos do problema do cliente onde Será aplicado deve ser entendido bom eh a gente vai ver por exemplo Qual que é o problema Qual que

é o o software quer Fazer o quê controle de estoque quer fazer controle de vendas ou ou os dois né então a gente tem que ter um melhor entendimento sobre isso também do mesmo jeito muitos desenvolvedores de software se especializam num determinado tipo de problema dentro daquele domni então por exemplo a gente vai ver muitos desenvolvedores que fazem software de controle de stoque softwares de venda especializam por exemplo o software de venda não é tão simples n você tem que Se especializar por exemplo eh como é que funcionam as leis eh para emissão de nota

fiscal como é que funciona tudo isso eh ou então software de RH de Recursos Humanos você tem que também estar por dentro das leis então ISO demanda um tempo então por isso muitos edores se especializam num problema dentro de um determinado domínio ou às vezes só de um determinado problema entendimento do negócio então você deve entender como os sistemas interagem e Contribuem de forma geral com os objetivos do negócio então mais uma vez né se você vai fazer um sistema eh provavelmente ele vai funcionar junto com outros sistemas e como é que funcionam esses outros

sistemas né qual que é eh a o papel desse novo sistema que eu tô construindo Quais são as dependências que eu vou ter com outro sistemas e o entendimento das necessidades e limitações dos stakeholders do sistema Então deve entender em detalhe as necessidades específicas eh das pessoas que requerem suporte ao sistema de seu trabalho então aí vai um trabalho mais minucioso para saber quem são os stakeholders primeiramente e depois pensar como cada um desses aí eh V vão interagir com o sistema de que maneira vão interagir com ele o processo de elicitação de requisitos anda

junto com a análise e com a negociação a gente vai ver um pouco de cada um daqui a pouco tá Bom Por isso que chama analista de software a gente ou negociador de software a gente vai entender o porquê disso daqui a pouco nos próximos slides Tá bom então o primeiro slide imagine aqui de novo essa figura aqui dá um pause se você precisar mas não é o mesmo modelo espiral tá bom aqui mostra uma espiral só pra gente ver que a esse processo de licitação também ele vai eh ficando mais complexo conforme o passar

do tempo tá bom então Eh tomando como Início lá o a espiral lá no meio né na licitação de requisitos começa ali na licitação que é você obter os requisitos descobrir os requisitos eh depois você vai fazer uma análise dos requisitos analisar e verificar por exemplo o que desses requisitos que vai virar software tá bom Depois dessa análise você vai fazer o que a gente chama de negociação a negociação tanto é o tempo eh paraa construção daquele tipo de requisito onde que esse requisito vai Entrar se você tiver fazendo um sistema interativo incremental então em

qual iteração ou seja em qual e versão do software vai entrar esse no requisito E por aí vai volto de novo a licitação volto de novo a análise volto de novo a negociação com isso com o tempo você vai tendo eh um documento de requisito mais robusto conforme o tempo tá bom então você vai evoluindo eh conforme o tempo e sempre passando por essas três etapas pelo menos né licitação análise e Negociação vamos ver agora os estgios da licitação né um passo a passo explicando aquela figura que a gente acabou de ver eh a primeira

parte parte da elicitação seria você definir os objetivos objetivos organizacionais que devem ser estabelecidos eh objetivos Gerais de negócio eh uma descrição Geral do problema ser resolvido ah por exemplo dentro de uma empresa grande dentro de uma de uma farmácia eu quero tratar somente o estoque tá bom est uma Descrição geral sobre isso eh Por que que o sistema é necessário e muitas vezes a gente tá fazendo um sistema e talvez já exa outro sistema melhor ou então Eh talvez não seja necessário para aquele momento que tá passando pela empresa né a gente tá fazendo

vários sistemas e aqueles sistemas em específico seja necessário então justificar isso né as limitações do sistema também quais são as limitações do sistema o que que ele vai onde que Ele vai operar né Qual que é o objetivo inicial e depois a aquisição de conhecimento de background Ou seja a base de conhecimento por exemplo de novo Eh vou fazer eh por uma farmácia Quais são as leis que regem o que que eu preciso saber eh de todo o domínio sobre farmácia se eu vou trabalhar com estoque Qual será o estoque quais são e eh as

regras que eu preciso para estoque por exemplo eu sei que para alguns tipos de medicamento eh esse controle de estoque Tem que ser feito junto com uma receita médica né como é que eu vou fazer isso né como é que o sistema vai controlar isso então é importante que eu saiba desse domínio é diferente por exemplo de um controle de estoque de um supermercado organização do conhecimento então com a grande quantidade de conhecimento coletado Você vai precisar organizar isso eh de alguma maneira que tem alguma ordem a gente viu lá o modelo scrum e e

no scrum a gente viu que por Exemplo e ele quebra em backlogs Você pode organizar por exemplo em cenários a gente vai ver daqui a pouco algumas técnicas de elicitação de requisitos e vai ajudar a esclarecer melhor isso e por fim coletar os requisitos dos stakeholders dos envolvidos lá no sistema E para isso a gente vai ter que saber algumas técnicas que é o que a gente vai ver daqu daqu a pouco aqui a gente tá vendo agora uma figura que mostra duas partes importantes da Elicitação de requisitos que seria a análise e a negociação

dos requisitos no retângulo aqui acima onde tá escrito A análise de requisitos a gente vai fazer a checagem da Necessidade desses requisitos eh da consistência e da completude para ver se se ele tá totalmente completo quando ele foi elicitado isso aí depois da primeira vez que você faz a licitação depois que você faz a coleta dos requisitos e a checagem da viabilidade é o quanto viável é a que Aquele requisito seja implementado Será que há tempo será que eh a tecnologia para que isso seja eh eh possível de se implementado junto com a análise vocês

vão ver lá embaixo a negociação dos requisitos que seria você discutir junto com a sua equipe de engenharia de software dependendo do tamanho do software que você tá construindo mas junto com a equipe de desenvolvimento e também junto com os clientes com os stakeholders envolvidos A discussão de requisitos que são necessários ou tão que são necessários é para aquele momento que você pode priorizar e chegar em acordo de requisitos Quando que vai ser implementado em qual versão do software daquele tal requisito vai ser implementado então a negociação também faz parte dessa etapa de de licitação

de requisitos de gerência de requisitos aqui mais analisando Eh o que deve ser feito na análise a gente fala que tem feit um checklist né primeiro checar a necessidade eh Lembra quando eu falei que é necessário primeiro que você defina os objetivos quando você Define um objetivo é para que isso quando você vai ter os requisitos você vê qual que é a necessidade daquele requisito para que atinja aquele objetivo né checar consistência completude para ver se aquele requisito eh está completo por Exemplo eh se necessita outra rodada talvez de licitação de requisitos de coleta de

requisitos e checar a viabilidade n a viabilidade tanto no ponto de vista que com o tempo que foi determinado para o projeto para terminar o projeto eh esse requisito não vai ser possível de ser implementado ou então com as tecnologias envolvidas talvez com as tecnologias que eu tenho hoje eu não consigo implementar tal requisito mais uma chargez inha aqui só eh falar sobre A importância de você saber negociar na negociação de requisitos é importante que a aqueles requisitos que foram identificados como problemáticos volta o vídeo naquela figura que eu tô mostrando para vocês que lá

na análise você identifica com os requisitos problemáticos que talvez não seja o momento de Eles talvez não contribuam para o objetivo que você definiu Mas é você discutir com os stakeholders e outros envolvidos eh e apresentar seus Pontos de vista sobre eh aquele requisito e tomar uma decisão se ele eh torna a ser necessário ou não eh Outro ponto interessante na negociação é que você vai fazer a priorização dos requisitos na verdade você vai fazer é parecido com que o scram faz que é você colocar o backlog para você lançar lá o Sprint lembra disso

não lembra retome a aula sobre scrum então aqui você vai definir quais requisitos que vão entrar na próxima versão do software que você Tá fazendo Tá bom e a concordância dos requisitos é uma solução para os problemas requisitos são identificadas e o conjunto de requisitos são acordados Tá bom então e esse é o é o ponto e crucial da negociação de requisitos se você concordar Quais são os requisitos que vão ser implementados e quais talvez vão ser para uma próxima versão ou que não serão implementados é muitas empresas fazem o seguinte ainda você pode eh

ter requisitos que você vai Adquirir isso por um outro software Tá bom talvez um exemplo Claro por exemplo se você tá fazendo um sistema de vendas e talvez o sistema que vai controlar o cartão de crédito ou outras coisas você não vai desenvolver Tá bom você vai utilizar Talvez o software que já vem junto ou as bibliotecas que já vem junto com a maquininha de cartão por exemplo existe isso Eh quem tá trabalhando com microsserviços por exemplo talvez você defina que você não vai implementar algo Você vai utilizar um microsserviço que é um serviço que

é um software n já já implementado e que fica na nuvem tá bom Então essas são as decisões que você vai tomar aqui falamos e falamos de elicitação de requisito né então agora a gente vai ver a as principais técnicas tá bom sobre licitação de requisitos e vamos acompanhar aqui a gente vai falar um pouco de técnicas de licitação e Lembrando que às vezes a maioria das vezes a gente só pensa em Entrevista que é o engenheiro de de requisitos e lá entrevistando o cliente tá bom então a gente vai ver outros tipos de técnicas

que são úteis para o desenvolvimento de software O que é importante da técnica é que o conhecimento que você vai adquirir através dessa licitação é que ele tem que ser particionado Eh Ou seja agregado com conhecimentos relacionados eh você vai fazar comparti colocar em compartimentos né O Que a gente chama né abstração reconhecendo as generalidades Então você vai ver o que que é pode ser talvez reutilizado que talvez seja parte do sistema que já foi eh falado Em outro momento e e uma projeção ou seja uma organização de acordo com a perspectiva isso vai ter

a ver com a prototipação também que a gente vai ver na próxima e na próxima aula desse módul ainda e de você já começar a pensar como é que vai ser a estrutura de todo Como é que vão e Eh seguir um fluxo de informações através desses requisitos Um dos problemas da elicitação É que geralmente o pessoal não dedica muito tempo para isso né às vezes eh como a gente já já viu isso um pouco antes pessoal se dedica muito mais à implementação do que realmente saber o que que vai ser construído né eh ou

então a preparação inadequada dos Engenheiros às vezes não sabe as técnicas corretas eh de elicitação de requisitos Então pode Perder tempo com isso e os próprios stakeholders não estarem convencidos da necessidade de um novo sistema Tá bom então tudo isso aí faz parte eh das técnicas de licitação de requisito Vocês estão vendo aqui algumas técnicas e essas técnicas vão ser utilizadas dependendo eh do domínio do seu problema do domínio da sua aplicação que você vai desenvolver bom geralmente quando você vai construir um Sistema mais complexo você vai utilizando cada vez mais técnicas a gente vai

ver desde as técnicas mais conhecidas como entrevistas abertas e fechadas até técnicas poucos conhecid como observações e análises sociais que são poucos conhecidas talvez da área de engenheria de software mais conhecidas talvez de outras áreas de Human bom os profissionais de Eng de requisitos eles devem saber selecionar quais técnicas que vão ser utilizadas eh geralmente Depois que ele conhece o domínio do problema geralmente que ele conhece o domínio da aplicação que vai ser feita eh ele começa a pensar nas técnicas e foi por isso que é importante que o engenheiro de software o engenheiro de

requisito eh conheça todas as técnicas e depois saiba selecionar como eh quais vão ser utilizado E como que eu vou integrar elas depois é importante eu utilizar uma uma linguagem de modelagem de apoio ou seja depois que eu eh Obtenho os requisitos onde eu vou guardar esses requisitos de que maneira que eu vou representar isso né se você tiver utilizando orientação objeto a gente vai utilizar uma técnica chamada casos de uso a gente vai ver um exemplo dela daqui a pouco eh o esquema de integração entre as técnicas utilizadas dependerá do problema é óbvio né

e da equipe participante e um ponto importante é que é ter o conhecimento da técnica para Saber qual utilizar né você ter esse conhecimento e saber quando que uma é melhor do que a outra tá bom a gente vai ver eh até na sua e eh atividade avaliativa dois na atividade avaliativa dois de vocês vai cair bastante coisa sobre isso tá bom PR bastante atenção nessas aulas aqui é mais uma lanzinha que vai fazer eh sentido daqui a pouco quando vocês vão ver algumas técnicas a primeira técnica que a gente tá vendo é entrevistas eh

tem muitas vantagens Porque eu Engenheiro um analista de requisitos que discuti o sistema eh Direta com diferentes stakeholders eh e eu tem o entendimento dos requisitos a principal vantagem é que o contato direto com o usuário e a validação imediata você se você tá obtendo requisitos direto da fonte Então você já consegue validar que aquele requisito é o que realmente se quer uma das desvantagens é o chamado conhecimento Tácito conhecimento Tácito é aquele Conhecimento que você acha que é tão banal que você acaba que você nem pergunta sobre ele então Eh um exemplo vamos supor

um sistema de biblioteca eh o bibliotecário sabe que todo Livro tem o is BN que é um número único para cada livro tá bom para cada eh edição de livro eh só que o engenheiro de software às vezes não sabe disso então o engenheiro de software eh talvez pense que vai ter que criar uma identificador Único para aquele livro para aquela edição de livro Só que um pergunta sobre isso e o outro já acha que tem uma solução que é ideal porque não perguntou Tá bom então por exemplo ficou conheo que não foi passado eu

não perguntei sobre o identificador único porque eu nem sabia que existia por exemplo eu como engenheiro de software e o o stakeholder que trabalha lá na biblioteca não falou sobre o isbn que é esse número único que é tão banal para Ele que ele achava que todo mundo sabia então ficou falta de informação e diferenças de Cultura também às vezes o domínio por exemplo eu quando a gente é da da área de desenvolvimento de software a gente é muito focado em alguns outros tipos de eh perguntas eh e quando a pessoa é de uma outra

área da biblioteca de novo também também o domínio dela de conhecimento é respectivo a um determinado tipo de cultura a gente falou mais ou menos Sobre isso lá na primeira aula sobre abstração Lembra que eu falei que era importante exatamente por isso a gente como engenheiro de software tem que saber se colocar no lugar eh do cliente do stakeholder que vai utilizar aquele software para conseguir colher os requisitos de maneira correta alguns tipos de entrevistas né que são as fechadas abertas e o tutorial por exemplo a fechada o engenheiro de requisitos já busca algumas respostas

Específicas para um conjunto de questões pré-definidas Então vamos supor que ele já fez um um levantamento inicial de de requisitos aí surgiram algumas dúvidas pontuais aí ele faz tipo um questionário para ser mais direcionado aí é mais direto entrevistas abertas é quando não há uma uma agenda pré-definida e ele vai perguntando eh de forma aberta sobre para os stakeholders sobre o que que ele acha que deve ter naquela parte do sistema entrevista aberta Mas ela já é Focada em um determinado tipo de problema uma determinada resolução o engenheiro de requisitos já espera obter resposta sobre

aquele determinado requisito que ele quer colher e o tutorial que é um é algo bastante interessante é quando você tem alguém da empresa por exemplo que você vai construir um software vamos voltar lá de novo à farmácia você tem lá um gerente da farmácia que ele é bastante conhecedor eh de de tudo da farmácia Então você pede para que ele dê uma aula para você sobre o que ele acha que deve ter o sistema nessa aula você vai discutindo com ele eh E fazendo mais perguntas eh entrevistando ele para saber como o que tá faltando

que o que você não entendeu Tá bom é o essencial das entrevistas né Talvez seja o o instrumento mais utilizado na elicitação de requisitos é que o listador tem que estar com a cabeça aberta o que a gente fala cabeça aberta é o seguinte a gente Como engenheiro de software a gente já tem uma ideia do como poderá ser implementado aquele requisito então a gente às vezes força eh que o o entrevistado meio que responde eh vai responder naquele caminho que a gente já meio pré concebeu Lembrando que os requisitos para que sejam feitos de

em qualidade eu preciso saber examente o que deverá ter no sistema não o como o como depois o o engenheiro de software vai dar uma solução tá bom eh informar Aos stakeholders o ponto inicial da discussão eh pode ser uma questão uma proposta de requisitos ou um sistema existente é aquele ponto de você definir já eh O que que você quer Eh colher daquele eh entrevistado e deve estar o entrevistador deve estar ciente da política organizacional muitos requisitos reais podem não serem discutidos devido a implicações Políticas n é muita às vezes alguns tipos de requisitos

eu não posso simplesmente ir lá e perguntar né eu vou ter que eh saber eh como é que é a política eh da empresa eh às vezes alguns requisitos por exemplo de segurança eh ou então de estratégia da própria empresa Talvez eu tenha que saber com quem perguntar de que maneira eu deva eh fazer a licitação desse requisito outra técnica é a leitura de documentos onde Eh por exemplo vai fazer um sistema eh de RH de Recursos Humanos onde você precisa saber as leis que regem a maioria dos sistemas de RH você não vai fazer

só entrevistando o stakeholder principalmente você vai fazer através de leitura e das leis existentes que regem os os recursos humanos como como contratar eh como calcular o salário e quais são as porcentagens de imposto Então tudo isso vai tá em documentos Então você vai ter que fazer uma leitura eh dessas leis existentes tá bom eh então você vai saber eh abstrair A partir dessa leitura você abstrair é a partir de um papel de um de um documento você vai fazer algo para resolver o seu problema ou seja um sistema que controle os recursos humanos de

uma determinada empresa vai ter um vocabulário de aplicação né Eh você vai conhecer Quais são as siglas Quais são as leis Quais são os impostos que são cobrados Então Você vai saber tudo sobre isso então através da leitura a vantagem que é facilidade de acesso e o de informações Então você não vai precisar ficar procurando outras pessoas que estão envolvidas todo mundo você vai saber as leis Você pode procurar as pessoas depois até para fazer o o que a gente chama de front end né que é a interface eh qual a interface mais amigável Quais

são os dados que ela prefere numa tela e na outra mas o a a a massa de conteúdo De um Recursos Humanos de um de um software de recursos humanos que calcula eh folha de pagamento por exemplo vai est tudo nas leis as desvantagens e a dispersão das informações e volume de trabalho eh principalmente voltando de novo a esse exemplo de Recursos Humanos toda hora sai uma lei diferente Ou uma atualização de uma lei já existente Então você vai ter que sempre ficar atento a essa monte de informações que vai ter e essa quantidade de

informações Pode eh à se você tiver desatualizado pode dar um problema grande né a gente já falou um pouco sobre um questionário mas eh Na verdade lá na entrevista Mas seria algo mais como uma entrevista fechada que você é fechada entre aspas não é é um pouco de diferente quando você quer aplicar questionários mesmo e na elicitação de requisitos você tem que ter um ponto importante que é principalmente a análise estatística às vezes você quer saber por exemplo o Quantos qual a porcentagem da empresa que realiza um determinado procedimento Então você aplica um questionário que

é uma pergunta fechada e você consegue saber essa porcentagem melhor ou seja essa análise estatística ó cai isso na na nossa avaliação tá bom vantagem então de você aplicar um question depois de você saber você só pode aplicar um questionário se você tiver um um um conhecimento prévio sobre o que que você vai eh fazer e essa coleta de requisitos A vantagem é a padronização das perguntas e um tratamento estatístico das respostas acabei de falar a desvantagem e a limitação do universo de respostas e pouco interação é diferente lá da de você fazer a entrevista

fechada que mesmo você fazendo uma pergunta você pode a o entrevistado ele pode complementar a resposta dele mesmo que não esteja lá na entrevista aqui não aqui tem uma vantagem que pode ser estatística mas a desvantagem que vai me Limitar eh o universo de respostas porque eu fechei aquela pergunta outra técnica análise de protocolos eh nada mais do que você fazer uma observação eh de de interação de um funcionário com um determinada ou de dois funcionários por exemplo de uma empresa através da verbalização do que ele tá fazendo por exemplo vamos supor de novo lá

o sistema de da da farmácia e eu quero fazer o controle de estoque então o que que eu faço eu pego principalmente a a partir Da do gerente da da farmácia e como ele trata com estoquista talvez e eu peço para que eles verbalizem o que eles estão fazendo Ah vai ser reposto o estoque quando a partir de que limite então me fale o que você tá fazendo Me fale a conversa me fale em voz alta O que você tá fazendo tudo que você tiver fazendo me falea em voz alta tanto gerente na farmácia como

estoquista e eu vou anotando aqui para entender como que funciona noa comunicação e talvez eu Consiga aí entender melhor eh como é que vai ser o software que vai controlar isso eh o objetivo é estabelecer a racionalidade utilizada na execução de tarefas né Eh avantagem é a possibilidade de listar fatos não facilmente observáveis e permitir melhor entendimento dos fatos geralmente análise protocolos é utilizada com outras com outras técnicas talvez você não entendeu algum tipo de processo que tá dentro daquela empresa Então você faz O que a gente chama de análise de protocolos a desvantagem é

o desempenho do entrevistado eh que ele vai falar o que ele faz muito mais diferente de realmente o que ele faz então às vezes quando eu tô sendo observado Eu vou falar o que eu faço ali mas na realidade eu faço coisas bem diferentes tá bom participação ativa dos usuários é bastante interessante eh e algumas técnicas a gente vai ver principalmente lá o scrum utiliza essa participação Ativa dos usuários se você lembrar lá do scrum a gente tem o po que é o dono do produto product owner eh ele tem essa ideia de ser um

de ser um usuário que participa do desenvolvimento de software Tá bom então Eh Exatamente isso né a incorporação dos usuários ao grupo de engenheiro de requisitos os usuários precisam aprender as linguagens de modelagem utilizadas para ler as as inscrições e criticá-las a integração dos usuários com engen requisitos da Modelagem do sistema Tá bom então ele vai fazer parte realmente da da equipe de desenvolvimento é a vantagem Com certeza envolvimento do cliente usuários e também a a velocidade com que você consegue obter os requisitos e a desvantagem é o treinamento dos usuários e a falta impressão

de eficácia do sistema Além disso é a dificuldade de você ter realmente um usuário que possa ser deslocado da da função dele da empresa para trabalhar junto com o Desenvolvimento de software tá bom cenários é é bastante utilizado para licitação de requisitos e a ideia que são histórias que explica como o sistema poderá ser utilizado deve incluir preste atenção Nisso porque isso também cai lá na prova uma descrição do estado do sistema antes de começar o cenário o fluxo normal de eventos do cenário exceções ao fluxo normal de eventos informações sobre atividades concorrentes se houver

né uma descrição Do estado do sistema ao final do cenário daqui a pouco a gente vai ver um exemplo de cenário só pra gente teressa noção do que que seria realmente um cenário mas cenários são exemplos de sessões de interação que descreve como o usuário interage com o sistema tá um usuário ou mais usuários e a descoberta de cenários dispõe interações possíveis do sistema e revela a facilidade que o o sistema pode precisar é só vendo aqui tem escrito história sem o h né e como é é porque na Verdade são histórias e eh diferente

da história com H seria uma história verídica alguma coisa que já teria acontecido nesse caso aqui são histórias para compor um cenário e cenário tem aquela ideia mesmo de cenário de filme né de você compor por exemplo quem são quem é o ator eh que tá interagindo E qual parte do sistema que que ele está interagindo e é um passo a passo eh da execução de uma determinada tarefa Tá bom então um cenário é bastante Utilizado em orientação objeto é o que a gente vai ver já já e lembra lá do modelo do processo Unificado

que é aquele processo mais robusto que é feito para orientação objeto que é baseado na uml Pois é ele usa cenários que é uma maneira de estruturar os requisitos dos sistemas orientados a objetos a gente vai ver no próximo slide como eu disse cenários fazem parte lá do do projeto orientado a objeto eh se a gente pegar e e e retornar lá no Processo Unificado a gente vai lembrar que o processo Unificado ele é guiado por casos de uso ou seja todo a A modelagem Lembrando que caso de uso é é o é o ponto

inicial dos requisitos e é como é modelado e eh lá nos requisitos né e depois a a partir desse caso de uso que eu vou fazer os outros diagramas Tá bom a gente vai ver isso em outra disciplina eh então cenários são partes inerentes de alguns métodos de desenvolvimento como eu acabei de falar Eh o termo caso de uso use case e é um caso específico do sistema Ou seja é na verdade uma funcionalidade do sistema a gente vai ver o exemplo daqui a pouco no próximo slide mas um caso de uso é um requisito

específico por exemplo cadastrar livros cadastrar livros seria um caso de uso seria um requisito aí o o cenário seria como que o funcionário cadastra o livro ele cadastra o livro passo a passo e e seria mostrando isso Em um cenário vamos ver o exemplo no próximo slide isso aqui seria eh o diagrama de um caso de uso o diagrama de caso de uso tem a intenção de ser bastante simples ó é o primeiro diagrama da uml que a gente tá vendo tá lembra que que é o ML linguagem de modelagem unificada ela é específica para

sistemas orientados a objetos a gente vai ver isso Quando vocês tiverem uma disciplina chamada eh programação orientado a objeto no nosso caso a gente tá vendo só A modelagem tá bom só a parte de requisitos que é o que a gente tá querendo ver para que que serve Então esse diagrama é para facilitar o entendimento quando eh o tanto o cliente como o a equipe de desenvolvimento já olha para esse diagrama já começa a entender o que que é olha não precisam ler muita coisa tá vendo eu tenho ali um vendedor e ten um cliente

e tem um cliente VIP eu tenho a funcionalidade de cadastrar Cliente realizar vendas e gerar relatórios então ó com esse simples olhar nessas simples figuras eu consigo entender é muito mais fácil explicar por exemplo eh para para pessoas que nunca viram eh código de programação eu explicar esse diagrama então a pessoa já começa a entender ah o vendedor faz o cadastro de cliente junto com as informações do cliente ah existe uma opção ali chamada realizar vendas Ou seja é o vendedor que Realiza vendas junto com o cliente o vendedor também gera relatórios ó o cliente

não gera relatórios eu consigo ver mais ou menos essas informações então com poucas informações com poucas informações que eu passo pro stakeholder ele consegue entender o que que o sistema faz para detalhar melhor então um diagrama de casa de uso ele tem além do diagrama que é esse desenho que a gente tá vendo aí cada bonequinho desse representa um ator ou seja alguém Que está envolvido em uma determinado funcionalidade e cada elipse dessa aí aqui cadastrar cliente realizar venda gerar relatório representa uma funcionalidade e por exemplo eu quero saber agora qual que é o cenário

né lembra que a gente tá falando sobre cenário do cadastrar cliente a gente vai ver isso agora então agora o o cenário cadastrar cliente é como se tivesse clicado naquela elipse do slide anterior volta lá se você não lembrar dele Cadastrar cliente quando eu for querer Qual é o cenário do cadastrar cliente eu faço isso ó lembra que tem que ter um fluxo básico né em outros a gente vai ver fluxo alternativo mas nesse caso só um fluxo básico ou seja o que que vai ser ser feito entre os atores para que o cliente seja

cadastrado isso seria o fluxo básico então lá são quatro Passos o vendedor acessa a opção cadastrar cliente já T imaginando uma tela ali né o Cliente informa os dados nome CPF Telefone e-mail o vendedor informa os dados do cliente do sistema o vendedor finaliza o adastra sando no botão salvar foi exatamente o que eu fiz tranquilo um cenário que mostra uma funcionalidade de cadastrar cliente agora o outro cenário do da outra elipse do outro caso de uso se você não lembrar como é que é volta um pouquinho o vídeo para você ver lá o realizar

vendas de novo é o vendedor interagindo com o cliente então lá fluxo básico esse agora tem fluxo alternativo São exceções ao fluxo básico fluxo básico o vendedor acessa a opção realizar vendas o Cliente informa o dado CPF o vereador informa o o dado do cliente no sistema o vereador registra a quantidade de sorvetes vendidos né é uma uma loja de sorvetes o sistema calcula o valor final de venda o sistema finaliza a venda sessão botão salvar o sistema contabiliza a venda para o cliente ó Isso é um cenário do fluxo básico ou seja deu tudo

certo então Eh sempre que Eu vou fazer um um cenário eu penso primeiro no passo a passo que vai dar tudo certo então realizou vem venda realizou a venda de tudo certo mas depois eu vou fazer os fluxos alternativos durante esse passo a passo alguma coisa dele pode eh eh ter uma alternativa ou pode exibir uma mensagem ou pode ir para outro fluxo até vamos ver um fluxo alternativo dois aqui 2.2 o sistema identifica que o cliente é VIP Opa então o sistema adiciona ó lá no o Cliente quando no fluxo básico o o passo

dois o Cliente informa o w CPF nesse momento vou conseguir saber se o cliente é VIP ou não né vou ter que ter um cadastro de cliente vip e um cadastro de cliente normal então no 2.2 o sistema identificou que o cliente é VIP então o sistema adiciona o desconto de 15% ao valor total da venda o outro ponto que pode ser ó o sistema Verifica que o cliente não está cadastrado então é uma outra alternativa vamos supor que ele Informou o CPF e o cliente não foi cadastrado ainda então Eh o sistema Verifica que

ele não foi cadastrado e entra lá de novo ele volta para aquele outro requisito e cadastrar cliente bom então eu consegui tratar os problemas que podem aparecer no fluxo básico e quando você vai fazer isso aqui é um exemplo é óbvio né tá bem simples mas quando você vai fazer um requisito é bem complexo então e você como engenheiro de software vai ter que pensar em todos os Fluxos alternativos que podem acontecer durante a execução e daquela atividade daquele requisito outro exemplo aqui também que a gente pode ver de gerar relatório se vocês lembrarem e

do diagrama somente agora o vendedor que vai aparecer aqui o único ator é o vendedor o fluxo básico ou seja aquele fluxo que vai dar tudo certo então vendedor acessa a opção gerar relatórios o vendedor seleciona e uma das opções relatório de vendas ou relatório diário Semanal ou mensal e o sistema apresenta relatório um fluxo alternativo Pode ser que ele selecionou por exemplo algum tipo de venda diário e o sistema não apresenta e não há venda naquele momento então o sistema vai apresentar uma mensagem que não há venda registrada tá vendo um fluxo alternativo para

tratar algum tipo de problema que pode ocorrer no fluxo básico observação e análise social é bastante utilizado em outras em outros tipos de de em outras ciências Por exemplo Ciências Sociais até na psicologia é bastante utilizado mas na computação é pouco utilizado para isso né Eh se vocês lembrarem de alguns filmes antigos ou já ler alguma coisa sobre isso por exemplo eh observação e análise social ou etnografia como é chamado era como por exemplo os pesquisadores observam eh tribo indígenas ao invés de ele ficar entrevistando o índio para saber como é que e como é

que ele faz a comida dele Como é que ele dorme não ele vai participar ativamente da cultura deles para conseguir entender melhor então seria a melhor maneira né acha difícil escrever o que elas fazem as pessoas geralmente acham difícil de escrever o que elas fazem por isso é uma maneira natural para ela às vezes a melhor forma é entender de entender isso né seria observá-los no trabalho eu já trabalhei com isso né já tive alguma um aluno de Mestrado meor que trabalhou com Etnografia e foi bastante interessante a gente trabalhou numa empresa que não tinha

não era uma empresa comum né e ele foi na participou da empresa como se fosse um estagiário e conseguiu entender os requisitos Tá bom então a etnografia é uma técnica das Ciências Sociais que se mostrou últim no entendimento dos processos reais reais no trabalho os processos reais de trabalho geralmente diferem daqueles processos de formag escritos né a gente já falou sobre isso Às vezes você faz uma entrevista a só fala geralmente não com o que ela faz de verdade mas como deveria fazer então às vezes não reflete a realidade do dos requisitos que você queria

colher o etnógrafo passa por algum tempo observando as pessoas no trabalho e constrói uma imagem de como o trabalho é realizado então o etnógrafo vai ter vai ter que est sempre com o caderninho dele para conseguir anotar eh e observar como é que funciona uma determinada eh eh Função que ele Talvez não consigi entender através de entrevista através de outras técnicas algumas diretrizes né se você quer realizar etnografia Assuma que as pessoas são boas no que fazem e procura formas não padronizadas de trabalho gaste algum tempo conhecendo as pessoas Estabeleça um relacionamento de confiança Essa

parte é importante né porque às vezes você vai ficar lá como se fosse uma pessoa estrangeira diferente né nas outras acaba que a Pessoa os funcionários que você tá interagindo não tenham confiança então A ideia é que você converse com as pessoas né seja associável né tome nota de forma detalhada lado de todas as práticas de trabalho como eu disse então tem tem que ter um caderninho ou então às vezes um gravador né Eh tomar cuidado para tirar fotos às vezes e as pessoas ficam intimidadas com tirar fotos então tem essa e eh essa noção

de quando for tirar foto de algum De alguma parte ou filmar muitas vezes pergunte né veja se pode né combine a observação com entrevistas abertas muitas vezes você vai est aprendendo ali alguma funcionalidade Organize regularmente sessões de relato onde o etnógrafo Fale para as pessoas externas ao processo e combine idn nografia contra as técnicas de licitação né então é importante eh talvez antes da etnografia você saber um pouco mais sobre como é que funciona aquela parte Da empresa eu dei um exemplo lá do meu aluno de Mestrado a empresa que a gente trabalhou chamava mosca

mé que é uma empresa um pouco diferente das tradicionais que a gente não sabe como é que funciona direito é uma empresa que produz uma vespa que acaba com a mosca da fruta né onde a gente já viu isso e a gente ia fazer um software para eles e não sabia como é que funcionava menos mesmo as pessoas descrevendo como é que funcionava a gente precisou utilizar de Etnografia para entender isso então ele ficou lá quase um mês aprendendo como é que funcionava todos os mecanismos e vendo eh colhendo os requisitos para que a gente

fizesse o nosso software bom aqui finalizando a etnografia então o etnógrafo procura teré a mesma perspectiva do cliente ele vira um grande conhecedor do negócio do software que ele vai construir Essa é parte bastante interessante né a vantagem visão mais completa e perfeitamente Ajustada ao contexto se ele passar um tempo lá então essa visão é bem completa a desvantagem é o tempo gasto Então você imagina você ter um engenheiro de requisitos passando um mês ou dois meses sei lá dentro da empresa para entender todo o processo então por isso é importante talvez usar etnografia como

parte para complementar um determinado processo de engia de requisitos Tá bom talvez alguma parte bem específica que você não conseguiu entender eh e você Mandar um engenheiro de requisitos para fazer essa parte e outra parte complicada é que existe uma pouca sistematização do processo né Então depende às vezes muito do engenheiro de requisitos se ele vai conseguir fazer esse papel de etnógrafo de colher essas informações reuso de requisitos é uma outra eh técnica na verade não bem uma técnica mas é um é uma melhoria de um processo de engen de requisitos onde você considera que

requisitos que já Foram desenvolvidos para para outros sistemas possam ser reutilizados em novos sistemas tá bom eh Lembrando que requisit reuso de requisitos não é control c control V né É você já desenvolver os requisitos elicitar os requisitos pensando que eles já deverão ser eh reutilizados Tá bom então você precisa padronizar Então lembrando voltando um pouquinho os slides você vai ver lá e os cenários então se você conseguir fazer um cenário que ele seja Mais genérico possível talvez você consiga reutilizar aquele cenário e sei lá realizar vendas cadastrar cliente em qualquer sistema que que tenham

o cadastrar cliente por exemplo né possibilidades de reuso na verdade quando você vai fazer um requisito que vai ser reutilizado geralmente é quando você trabalha num determinado domínio vamos supor que a minha empresa virou especialista de desenvolver software para a farmácia bom quando eu sou Especialista em desenvolver softare para farmácia eu já tenho alguns requisitos que vão sempre se repetir então eu posso deixar que eles eh me ajudem eh a ser reutilizados né Eh de acordo com algumas pesquisas somente 15 % de sistemas do mesmo domínio são específicos são exclusivos dele mesmo né então o

restante né Eh 85% podem ser reutilizados Olha que interessante isso né o reuso levaria a consistência no estilo entre aplicações Outra coisa que é interessante quando você reutiliza como você tem uma padronização que você já fez para poder ser reutilizado então todo mundo já vai saber mais ou menos que deve ser feito porque já tá padronizado por exemplo o o requisito que refletir políticas da da da companhia né da da empresa tais como segurança Então sempre que tiver segurança você já vai saber como que é que tipo de eh padronização a seguir a principal vantagem

do reuso a Produtividade a qualidade porque você supostamente já teve algo que foi testado e validado e a principal desvantagem é a dificuldade realmente de promover a reutilização sem modificação né mas mesmo assim se você já planejar um pouco eh como é que você vai construir os requisitos Você já consegue tirar uma grande vantagem aí a gente viu algumas técnicas de elicitação né A gente vai ver uma outra técnica que é prototipação numa aula específica que Vai ser a última aula desse módulo tá bom É uma aula bem curtinha bem interessante e depois a gente

vai trabalhar no módulo TR só sobre isso né a gente vai fazer um protótipo depois eu vou falar mais informações sobre isso mas as técnicas de licitação Então quais utilizar né o que por e como né pergunte o óbvio né organiza as respostas durante durante e depois né Eh viva a situação durante um tempo né a gente tem eh quando a gente fala dessas técnicas Nessas dicas das técnicas a gente pensa sempre como se fosse lá o piou do scran né o piou do scran Na minha opinião é o engenheiro de requisitos que faz exatamente

essas dicas né ou seja ele vive durante um tempo como se fosse o dono do do produto né Observe né O que tá acontecendo estudar o porquê o que e onde de começar e seja humilde né quando a gente fala de nessa parte Eng de requisitos né Procure sempre aprender com o sistema que tá acontecendo né não Não não ten ideias preconcebidas que isso só vai atrapalhar nas elicitação só elicitação de requisitos alguns pontos Chaves né já falei sobre isso mas tô aqui reforçando eh primeira coisa que é a compreensão do domínio da aplicação então

de novo Antes de eu começar os requisitos se você colocar voltar lá na naquele naquele naquela aula que eu falo sobre o processo Unificado que talvez seja o processo mais robusto em todas as áreas veja lá o tempo que você gasta Principalmente no conhecimento do domínio da aplicação antes de você fazer os requisitos tá bom eh processo de licitação de requisitos análise e negociação são interativos intercalados então às vezes você vai e volta Lembra daquela espiral que fi falando né que tem que ser repetido várias vezes passando para que você consiga chegar aos requisitos né

geralmente não dá certo isso porque o pessoal não gasta muito tempo nessa parte da inéia de Requisitos Existem várias técnicas de licitação de requisitos que podem ser utilizadas incluindo entrevistas cenários prototipagem observação dos participantes Então agora que você conhece um pouco mais né o engenheiro de software eles tem que conhecer todas para saber qual utilizar e quando você for utilizar em conjunto né saber eh como você conseguir colocar esses requisitos de forma organizada né protótipos são efetivos para licitação De requisitos a gente vai ver protótipos na próxima aula desse módulo ainda mas as partes interessadas

tem algo com Que ela possa experimentar e possa encontrar n seus reais requisitos e pode modificar né então prototipação talvez seja o ponto chave para que você Cometa menos erros né o problema da prototipação é o tempo talvez as técnicas que você vai utilizar né Lembrando que a prototipação tem algum alguns pontos Chaves tá a gente vai ver na próxima aula para Discutir um pouco melhor sobre isso listas de checagem São forma mas particularmente út né o checklist né que a gente faz né para organizar o processo de validação de requisitos então você pode fazer

um checklist na sua empresa eh que vai verificar alguma coisa que tá faltando dos seus requisitos se tá tudo completo você pode criar essa lista né conforme você vai Tero mais experiência em processos que você vai eh passando por ele e lembram aos analista que deve Ser checado quando a leitura dos requisitos propostos negociação dos requisitos é sempre necessário para envolver para resolver conflitos né a gente viu bastante sobre negociação de requisitos né Quais são qual é a necessidade daquele requisito Então qual a prioridade que ele deve ser implementado em qual versão que ele vai

ser entregue e envolve a troca de informação discussão e resolução de conflitos bom e essa foi a nossa aula Acho que falamos bastante coisa sobre engenheria de requisitos eh ainda não é completo essa aula existe muita informação sobre engenheria de requisitos a gente vai tentar falar mais um pouco ainda sobre prototipação na próxima aula então procure na nossa apostila né sobre relicitação e análise de requisitos lá na página 33 e 39 participe também das aulas se você tiver alguma dúvida né anote Lembrando que você pause o vídeo Anote o que você Precisa anotar toda essa

parte desse conteúdo aqui que a gente vai ver vai cair na atividade avaliativa dois então nessa atividade avaliativa dois eh provavelmente vocês vão fazer localmente né fisicamente lá n no Polo de vocês tá bom então vocês não vão fazer em casa essa outra parte anotem que vocês tiverem dúvida para tirar as dúvidas quando tiver a aula síncrona aula ao vivo comigo