Engenharia de Software I - Unidade III

Prévia do material em texto

<p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>3</p><p>1</p><p>2</p><p>CONTEÚDO</p><p> Unidade III:</p><p> Engenharia de Requisitos.</p><p> Requisitos funcionais e não funcionais.</p><p> Especificação de requisitos.</p><p> Processos de engenharia de requisitos.</p><p> Elicitação e analise de requisitos.</p><p> Técnicas utilizadas para elicitação e análise dos requisitos.</p><p> Levantamento de dados.</p><p> Documento de Requisitos.</p><p>3</p><p>ENGENHARIA DE REQUISITOS</p><p>Entendemos que Engenharia de software, de acordo com o IEEE, é a aplicação de uma abordagem</p><p>sistemática, disciplinada e quantificável no desenvolvimento, operação e manutenção de software.</p><p>Sistemática por que parte do princípio de que existe um processo de desenvolvimento definindo as</p><p>atividades que deverão ser executadas.</p><p>Disciplinada por que parte do princípio de que os processos definidos serão seguidos.</p><p>Quantificável por que se deve definir um conjunto de medidas a serem extraídas do processo durante o</p><p>desenvolvimento de forma que as tomadas de decisão relacionadas ao desenvolvimento do software</p><p>(por exemplo, melhoria de processo) sejam embasadas em dados reais, e não em “achismos”.</p><p>“Desenvolver software é uma atividade complexa por natureza. Uma das razões para esta afirmação é</p><p>que não existe uma única solução para cada cenário de desenvolvimento. Além disso, lidamos o tempo</p><p>todo com pessoas, o que torna o sucesso do projeto bastante relacionado à competência da equipe e à</p><p>forma como trabalham, e, para dificultar ainda mais, muitas vezes não fazemos uso de um processo bem</p><p>definido para apoiar as atividades do projeto...”.</p><p>4</p><p>REQUISITOS...</p><p>Uma característica do sistema ou a descrição de algo que o sistema é</p><p>capaz de realizar para atingir os seus objetivos</p><p>5</p><p>REQUISITOS...</p><p>Exigência que deve ser</p><p>cumprida para atingir um</p><p>objetivo</p><p>6</p><p>REQUISITOS...</p><p>1. As descrições das funções e restrições são os requisitos do sistema.</p><p>2. Um requisito é uma propriedade que o software deve exibir para resolver</p><p>algum problema no mundo real.</p><p>3. Uma condição ou uma capacidade que deve ser alcançada ou estar</p><p>presente em um sistema para satisfazer um contrato, padrão,</p><p>especificação ou outro documento formalmente imposto.</p><p>4. Declaração abstrata em alto nível de um serviço que o sistema deve</p><p>oferecer ou uma restrição a um sistema (requisito em baixo nível de</p><p>descrição).</p><p>5. Definição detalhada e formal de uma função do sistema (requisito em alto</p><p>nível de descrição).</p><p>7</p><p>REQUISITOS...</p><p>8</p><p>REQUISITOS...</p><p>Podemos entender requisitos como sendo o conjunto de necessidades</p><p>explicitadas pelo cliente que deverão ser atendidas para solucionar um</p><p>determinado problema do negócio no qual o cliente faz parte.</p><p>Porém, é importante estar atento para esta definição: embora o requisito seja</p><p>definido pelo cliente, nem sempre o que o cliente quer é o que o negócio</p><p>precisa. Cabe à equipe de consultores identificar a real necessidade do</p><p>negócio.</p><p>9</p><p>ENGENHARIA DE REQUISITOS</p><p> Sommerville diz que “os requisitos de um sistema são as descrições do que o sistema deve fazer,</p><p>os serviços que oferece e as restrições a seu funcionamento. Esses requisitos refletem as</p><p>necessidades dos clientes para um sistema que serve a uma finalidade determinada...”O</p><p>processo de descobrir, analisar, documentar e verificar esses serviços e restrições é chamado</p><p>Engenharia de Requisitos.</p><p> Para Vazquez “a Engenharia de Requisitos está ligada à aquisição e aplicação de conhecimento</p><p>para a criação, o aperfeiçoamento e a implementação de sistemas de informação”.</p><p> Pressman afirma que “A engenharia de requisitos estabelece uma base sólida para o projeto e</p><p>para a construção. Sem ela, o software resultante tem grande possibilidade de não atender às</p><p>necessidades do cliente”.</p><p>10</p><p>ENGENHARIA DE REQUISITOS</p><p>Importância da ER</p><p>11</p><p>ENGENHARIA DE REQUISITOS</p><p>Pressão do cliente para uma construção rápida do</p><p>sistema.</p><p>“Temos que nos acostumar com a</p><p>pressão.</p><p>Mais além, toda vez que</p><p>sentirmos pressão, mentalizar</p><p>que isso nos ajuda a alcançar</p><p>nossos objetivos.</p><p>Dá-nos mais gás para agir em</p><p>direção à nossa meta.”</p><p>Lauro Valente</p><p>Requisitos Incorretos</p><p>12</p><p>ENGENHARIA DE REQUISITOS</p><p>Suposição incorreta, por parte dos stakeholders, de</p><p>que muito do assunto é evidente.</p><p>“Geralmente as pessoas falham</p><p>em serem bons ouvintes.</p><p>Elas simplesmente presumem</p><p>que sabem o que a outra pessoa</p><p>esta dizendo ou simplesmente</p><p>porque elas já ouviram isso</p><p>antes adotam a ideia de que</p><p>aquela pessoa é igual a outra “.</p><p>Requisitos Ambíguos</p><p>13</p><p>BIBLIOGRAFIA</p><p> UA - Fundamentos da engenharia de requisitos.</p><p> UA - Conhecer requisitos.</p><p> http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034</p><p> https://www.ieee.org/</p><p> https://developerslife.tech/pt/</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª Edição.</p><p>São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9. ed. –</p><p>Porto Alegre: AMGH, 2021. E-pub.</p><p> VAZQUEZ, Carlos Eduardo, SIMÕES, Guilherme Siqueira. Engenharia de Requisitos - Software orientado ao</p><p>negócio. Editora Brasport,2016.</p><p> Recomendação de leitura:</p><p> Fonte: https://www.youtube.com/watch?v=UZfpUdYLsao</p><p>http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034</p><p>https://www.ieee.org/</p><p>https://developerslife.tech/pt/</p><p>https://www.youtube.com/watch?v=UZfpUdYLsao</p><p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>3</p><p>2</p><p>2</p><p>CONTEÚDO</p><p> Unidade III:</p><p> Engenharia de Requisitos.</p><p> Requisitos funcionais e não funcionais.</p><p> Especificação de requisitos.</p><p>3</p><p>ENGENHARIA DE REQUISITOS</p><p>Os requisitos podem assumir diferentes funções e níveis de detalhamento:</p><p> Em alguns casos, detalham uma função do sistema, por exemplo: “um usuário</p><p>solicitando que o relatório financeiro deve ser separado por mês, separando em</p><p>colunas as informações, indicando os pagamentos parcelados e os pagamento à</p><p>vista, quando solicitado pelo gerente financeiro, o relatório deve incluir também</p><p>quais clientes têm parcelas em atraso e quais estão no último mês de contrato”.</p><p> Em outros casos apenas descrevem em alto nível o serviço que o cliente espera que</p><p>o sistema faça, como: “o usuário deve ser capaz de cadastrar um novo cliente.”</p><p>4</p><p>ENGENHARIA DE REQUISITOS</p><p> Requisitos de Usuário:</p><p> Elaborado pelos clientes e/ou usuários finais, com linguagem natural e diagramas,</p><p>contendo as funções que o sistema deve fornecer e as restrições.</p><p> Requisitos de Sistema:</p><p> Podem ser elaborados por usuário final/arquiteto de sistema ou desenvolvedores; é</p><p>um documento estruturado com as descrições detalhadas, também chamado de</p><p>Especificação Funcional, das funções e restrições do sistema. Pode, inclusive, ser</p><p>parte do contrato do cliente com a equipe de desenvolvimento.</p><p>5</p><p>REQUISITOS FUNCIONAIS</p><p>Sommerville afirma que os requisitos funcionais são</p><p>“declarações de serviços que o sistema deve fornecer, de como o</p><p>sistema deve reagir a entradas específicas e de como o sistema</p><p>deve se comportar em determinadas situações. Em alguns casos,</p><p>os requisitos funcionais também podem explicitar o que o sistema</p><p>não deve fazer.”</p><p>Para Vazquez os requisitos funcionais “descrevem o que o</p><p>software faz, considerando uma perspectiva de tarefas e serviços</p><p>de seus usuários em específico”.</p><p>Em engenharia de software, um</p><p>requisito funcional define uma</p><p>função de um sistema de software</p><p>ou seu componente. O requisito</p><p>funcional representa o que o</p><p>software faz, em termos de tarefas</p><p>e serviços. Uma função é descrita</p><p>como um conjunto de entradas, seu</p><p>comportamento e as saídas.</p><p>A especificação dos requisitos funcionais deve procurar</p><p>sempre ser completa, de forma a atender todos os serviços</p><p>e funcionalidades que foram pedidas pelo cliente e</p><p>também consistente de forma a não ter definições que</p><p>sejam contraditórias entre si.</p><p>6</p><p>REQUISITOS FUNCIONAIS</p><p> Estabeleça um</p><p>formato padrão e use-o para a descrição de todos os requisitos.</p><p> Utilize a linguagem de modo consistente. Faça distinção entre os requisitos obrigatórios</p><p>e os que são desejáveis (O sistema deve... O sistema deveria...).</p><p> Utilize destaque no texto para ressaltar partes importantes dos requisitos.</p><p> Evite o uso de jargões de informática.</p><p>Um clássico e simples exemplo de requisito funcional é a funcionalidade</p><p>“MANTER USUÁRIO” (o verbo “manter” é utilizado na documentação de</p><p>software para referir-se à uma funcionalidade de cadastro, que contempla a</p><p>inclusão de um novo item, a alteração de um item, a exclusão de um item além</p><p>da leitura de suas informações).</p><p>7</p><p>REQUISITOS NÃO FUNCIONAIS</p><p>Sommerville define como sendo as “restrições aos serviços ou funções oferecidos pelo</p><p>sistema. Incluem restrições de timing, restrições no processo de desenvolvimento e</p><p>restrições impostas pelas normas. Ao contrário das características individuais ou serviços</p><p>do sistema, os requisitos não funcionais, muitas vezes, aplicam-se ao sistema como um</p><p>todo.”</p><p> Usabilidade (funcionamento da interface, sistema de ajuda..).</p><p> Confiabilidade (funcionamento de backups, quem poderá utilizá-lo...).</p><p> Performance (qual o recurso mínimo para um bom funcionamento do sistema, que para ser</p><p>realizado uma determinada consulta o sistema não poderá demorar mais que cinco segundos...).</p><p> Suportabilidade (para o funcionamento do sistema qual o sistema operacional, qual o banco de</p><p>dados deve ser instalado...)</p><p>8</p><p>REQUISITOS NÃO FUNCIONAIS</p><p>Pressman considera como sendo “pode ser descrito como um atributo de qualidade, de</p><p>desempenho, de segurança ou como uma restrição geral em um sistema”.</p><p>Requisito funcional é, ‘tudo aquilo que o sistema “deve fazer”, enquanto que o requisito não</p><p>funcional, por sua vez pode ser definido como “de qual maneira o sistema deve fazer“.</p><p>Requisitos não funcionais devem sempre ser mensuráveis, ou seja, deve ser possível verificar se ele</p><p>está ou não sendo atendido pelo software:</p><p> O sistema deve ser multiplataforma – Windows, Linux e macOS.</p><p> O desenvolvimento deve ser em linguagem C++.</p><p> O programa deve funcionar offline.</p><p> O sistema deve respeitar o tempo máximo de 160 segundos durante processamentos.</p><p>Exemplos de requisitos não</p><p>funcionais</p><p>9</p><p>REQUISITOS NÃO FUNCIONAIS</p><p>Requisito não funcional deve ser sempre verificável, caso contrário ele não pode ser</p><p>interpretado como tal.</p><p> O sistema deve ser rápido.</p><p> Não deve corromper dados.</p><p> O programa deve ser seguro.</p><p>Nenhum desses requisitos podem ser medidos, aferidos ou mensurados para verificar sua</p><p>conformidade.</p><p>10</p><p>REQUISITOS....</p><p>11</p><p>ENGENHARIA DE REQUISITOS</p><p>Um exemplo prático. Imagine que você está sendo contratado como analista de requisitos para o</p><p>desenvolvimento de um software de prontuário eletrônico para um hospital.</p><p>Requisitos funcionais (RF):</p><p> o sistema deverá criar um prontuário eletrônico para</p><p>cada paciente que for atendido;</p><p> o prontuário deverá armazenar os dados cadastrais do</p><p>paciente;</p><p> o prontuário deverá ter todo o histórico detalhado de</p><p>atendimentos ao paciente;</p><p> o sistema deverá ter a funcionalidade de imprimir</p><p>guia de atendimento;</p><p> o sistema deverá ter a funcionalidade de imprimir</p><p>receita médica;</p><p> o sistema deverá ter a funcionalidade de imprimir</p><p>pedidos de exame e seus respectivos resultados.</p><p>Requisitos não funcionais (RNF):</p><p> o software não pode ficar off-line por mais de</p><p>5 segundos em nenhum momento das 24h do</p><p>dia;</p><p> Os profissionais de saúde, usuários do</p><p>sistema, devem poder se autenticar no</p><p>sistema utilizando o crachá do hospital sem</p><p>ter que digitar login e senha;</p><p> A Secretaria de Saúde do estado exige que</p><p>sejam reportados relatórios mensais com as</p><p>estatísticas de atendimento.</p><p>12</p><p>ESPECIFICAÇÃO DE REQUISITOS</p><p>Consiste em transcrever os requisitos de usuário e de sistema em um</p><p>documento de requisitos.</p><p>Para Sommerville “Os requisitos de usuário para um sistema devem descrever</p><p>os requisitos funcionais e não funcionais de modo que sejam compreensíveis</p><p>para os usuários do sistema que não tenham conhecimentos técnicos</p><p>detalhados”.</p><p>13</p><p>ESPECIFICAÇÃO DE REQUISITOS</p><p>Notação Descrição</p><p>Linguagem Natural Os requisitos são escritos em frases numeradas em linguagem natural.</p><p>Cada frase deve expressar um requisito.</p><p>Linguagem Natural Estruturada Os requisitos são escritos em linguagem natural em um formulário</p><p>padrão ou template. Cada campo fornece informações sobre um</p><p>aspecto do requisito.</p><p>Linguagem de descrição de</p><p>projeto</p><p>Essa abordagem usa uma linguagem como de programação, mas com</p><p>características mais abstratas.</p><p>Notações gráficas São usados modelos gráficos: diagramas de caso de uso e de sequencia</p><p>da UML.</p><p>Especificações matemáticas Baseadas em conceitos matemáticos como maquinas de estado finito</p><p>ou conjuntos.</p><p>14</p><p>BIBLIOGRAFIA</p><p> UA - Fundamentos da engenharia de requisitos.</p><p> UA - Conhecer requisitos.</p><p> UA - Especificação dos requisitos não funcionais de software.</p><p> http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034</p><p> https://analisederequisitos.com.br/wp-content/uploads/2018/02/analiserequisitos-dilbert-requisitos-do-software-o-c</p><p>liente-pediu.png</p><p> https://dilbert.com/</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª Edição.</p><p>São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9. ed. –</p><p>Porto Alegre: AMGH, 2021. E-pub.</p><p> VAZQUEZ, Carlos Eduardo, SIMÕES, Guilherme Siqueira. Engenharia de Requisitos - Software orientado ao</p><p>negócio. Editora Brasport,2016.</p><p>http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034</p><p>https://analisederequisitos.com.br/wp-content/uploads/2018/02/analiserequisitos-dilbert-requisitos-do-software-o-cliente-pediu.png</p><p>https://analisederequisitos.com.br/wp-content/uploads/2018/02/analiserequisitos-dilbert-requisitos-do-software-o-cliente-pediu.png</p><p>https://dilbert.com/</p><p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>3</p><p>3</p><p>2</p><p>CONTEÚDO</p><p> Unidade III:</p><p> Processos de engenharia de requisitos.</p><p> Elicitação e análise de requisitos.</p><p> Técnicas utilizadas para elicitação e análise dos requisitos.</p><p>3</p><p>PROCESSOS DE ENGENHARIA DE REQUISITOS</p><p>Para Sommerville “a engenharia de requisitos é um processo iterativo em que</p><p>as atividades são intercaladas”.</p><p>Exemplo:</p><p> Mesmo depois de os requisitos serem validados (atividade 3)</p><p>pode ser necessário revisitar a atividade 1 e 2 para elicitar e</p><p>analisar novos requisitos que surgiram;</p><p> O processo também é contínuo. Após concluídas todas as</p><p>atividades de requisitos e o software ser entregue aos</p><p>usuários finais, a atividade 4 (gerenciamento) permanece</p><p>sendo executada e quase sempre surgirão novos requisitos a</p><p>serem elicitados, analisados e validados;</p><p> Todas as 4 atividades do processo de engenharia de requisitos</p><p>visam a criação de um documento de especificação de</p><p>requisitos, que é a materialização de todo o processo em um</p><p>artefato escrito.</p><p>4</p><p>ELICITAÇÃO E ANÁLISE DE REQUISITOS</p><p>��� Elicitação de requisitos é uma fase do projeto onde são extraídas informações do cliente sobre o que ele</p><p>deseja que seja construído. É a fase em que o profissional de TI entende a necessidade do cliente e o</p><p>orienta. É o momento de conversa com o usuário, de sentimento sobre o que este espera que seja</p><p>entregue a ele.</p><p> A fase de levantamento de requisitos, em um projeto, representa a parte de negócio, ou seja, O QUE</p><p>exatamente o cliente está precisando. Nessa fase, o profissional de TI busca informações como:</p><p>funcionalidades que o sistema deve ter, as regras de negócio dessas funcionalidades, restrições,</p><p>usabilidade do software, e assim por diante.</p><p> Elicitação é um processo de aquisição de conhecimento, onde se aplicam técnicas para compreender</p><p>melhor o negócio a ser impactado pelo projeto, identificar as</p><p>partes interessadas e refinar os tipos de</p><p>requisitos que o sistema irá possuir.</p><p>5</p><p>TÉCNICAS UTILIZADAS PARA A ELICITAÇÃO E ANÁLISE DOS REQUISITOS</p><p> Para Pressman a elicitação de requisitos ou coleta de requisitos “combina elementos de</p><p>resolução de problemas, elaboração, negociação e especificação”.</p><p> Ávila ainda completa que um pré-requisito para um software de qualidade, embora não seja</p><p>garantia, é uma especificação de requisitos bem elaborada.</p><p> Elicitação (ou levantamento ou descoberta) de requisitos é a etapa inicial do processo.</p><p>Consiste em reunir informações a respeito do sistema requerido e filtrar os requisitos a partir</p><p>dessas informações. Envolve contato direto com os stakeholders (partes interessadas) para o</p><p>correto entendimento das necessidades e dos objetivos do projeto.</p><p> As técnicas de elicitação e análise: análise de documentos, glossário, etnografia, entrevista e</p><p>pesquisa.</p><p>6</p><p>ANÁLISE DE DOCUMENTOS</p><p> Muitas vezes, algumas informações são difíceis de serem obtidas através de entrevistas ou observação.</p><p>Tais informações revelam, tipicamente, um histórico da organização e sua direção.</p><p> Através de investigação, podemos obter mais facilmente informações, tais como tipos de documentos e</p><p>problemas associados, informação financeira e contextos da organização.</p><p>Exemplo:</p><p> A equipe de desenvolvimento avaliará os documentos utilizados pela academia antes do software, por</p><p>exemplo, as fichas cadastrais dos alunos e as fichas de exercícios, todas preenchidas de forma manual.</p><p>De posse das fichas, o avaliador poderá verificar a quantidade de campos existente atualmente, se</p><p>realmente todos são utilizados e, dessa maneira, prever como será a interface de cadastro de alunos no</p><p>sistema.</p><p> Na atividade de montagem de um treino para o aluno, vamos questionar as funcionalidades das fichas</p><p>que indicam as atividades que cada aluno deve fazer durante o treino, a quantidade de campos</p><p>existentes atualmente nessa ficha, quais são mais importantes, quais campos são, de fato, usados, as</p><p>fichas de histórico de atividades do aluno e assim por diante.</p><p>7</p><p>GLOSSÁRIO</p><p> Vazquez indica que o glossário “identifica e define termos-chave para o domínio do</p><p>problema, capturando o vocabulário comum das partes interessadas”.</p><p> Sommerville lembra de que o glossário “Deve definir os termos técnicos usados no</p><p>documento. Você não deve fazer suposições sobre a experiência ou o conhecimento do</p><p>leitor”.</p><p> Para identificar termos candidatos ao glossário, devemos nos atentar para:</p><p> termos únicos ao escopo do projeto;</p><p> termos com mais de uma definição;</p><p> termos cuja definição local seja diferente da definição do senso comum;</p><p> termos que podem causar dificuldade de entendimento;</p><p> termos técnicos da linguagem de negócio;</p><p> abreviações e siglas;</p><p> termos sinônimos e antônimos;</p><p> termos que causam dúvidas na equipe durante reuniões;</p><p> siglas que definem departamentos e gerências.</p><p>8</p><p>OBSERVAÇÃO (ETNOGRAFIA)</p><p>A etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais</p><p>e organizacionais, ou seja, entender a política organizacional bem como a cultura de trabalho com</p><p>objetivo de familiarizar-se com o sistema e sua história:</p><p> O analista se insere no ambiente de trabalho em que o sistema será utilizado.</p><p> O trabalho diário é observado e são anotadas as tarefas reais em que o sistema será utilizado.</p><p>O principal objetivo da etnografia é que ela ajuda a</p><p>descobrir requisitos de sistema implícitos, que refletem</p><p>os processos reais, em vez de os processos formais,</p><p>onde as pessoas estão envolvidas.</p><p>9</p><p>OBSERVAÇÃO (ETNOGRAFIA)</p><p> Vazquez “Ao perceber como as atividades são executadas, a intensidade em que ocorrem, quais passos são</p><p>mais demorados ou rápidos, fica mais fácil propor uma solução com uma interface mais amigável à</p><p>realidade de trabalho das partes interessadas”.</p><p> Vazquez diz que ao realizar uma observação “deve-se sempre estabelecer quais são os objetivos da</p><p>observação. A partir disso, selecionar o grupo de pessoas e a janela de tempo adequada. A seleção é feita</p><p>com base na compatibilidade entre o tipo de necessidade de informação e as responsabilidades dos</p><p>grupos em avaliação ou das janelas de tempo disponíveis.”</p><p> Definidos esses pontos, o observador deve optar por ter postura:</p><p> Ativa - conversando com quem está sendo observado, tomando nota dos fatos e podendo interromper</p><p>para fazer perguntas a qualquer momento.</p><p> Passiva - observa o processo todo, para somente depois fazer perguntas, antes, apenas toma nota dos</p><p>fatos que acontecem.</p><p>10</p><p>BIBLIOGRAFIA</p><p> UA - Aplicação de técnicas de elicitação de requisitos de software.</p><p> UA - Conhecer requisitos.</p><p> www.devmedia.com.br.</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª Edição.</p><p>São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9. ed. –</p><p>Porto Alegre: AMGH, 2021. E-pub.</p><p> VAZQUEZ, Carlos Eduardo, SIMÕES, Guilherme Siqueira. Engenharia de Requisitos - Software orientado ao</p><p>negócio. Editora Brasport,2016.</p><p>http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034</p><p>http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034</p><p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>3</p><p>4</p><p>2</p><p>CONTEÚDO</p><p> Unidade III:</p><p> Técnicas utilizadas para elicitação e análise dos requisitos.</p><p>3</p><p>ENTREVISTA</p><p> Entrevista é a modalidade de levantamento de dados destinada a levantar realidades</p><p>estruturadas com uma clientela.</p><p> Os dados e informações são obtidos com perguntas, feitas diretamente aos usuários</p><p>alocados nos postos de trabalho envolvidos na execução do processo em análise.</p><p> Uma entrevista é uma conversa direcionada com um propósito específico, que utiliza</p><p>um formato “pergunta-resposta”.</p><p>4</p><p>ENTREVISTA</p><p>Principais características desta modalidade:</p><p>1. Destinada à uma clientela não volumosa e pouco dispersa geograficamente;</p><p>2. É sequencial: recomenda-se realizar uma entrevista com apenas uma pessoa por vez;</p><p>3. É a modalidade mais flexível pois permite questionamentos abertos sobre o que se deseja saber e tem</p><p>um baixo custo;</p><p>4. Adequar o discurso a linguagem do entrevistado, ou seja, utilizar um vocabulário compreensível ao</p><p>cliente;</p><p>5. Adequar a roupa, no momento da entrevista, ao ambiente de trabalho do cliente, afinal, além da</p><p>linguagem verbal, a corporal conta muito para criar um vínculo de confiança entre o entrevistado e</p><p>entrevistador;</p><p>6. Pontualidade acima de tudo, afinal de contas, se o cliente disponibilizou um certo tempo de seu dia para</p><p>te atender é nossa obrigação cumprir o horário estipulado. Confiança é algo que se conquista em</p><p>pequenas atitudes;</p><p>7. Em nenhum momento deve-se contradizer ou discutir com o cliente, a não ser que aquela rotina</p><p>analisada seja impossível de ser automatizada.</p><p>5</p><p>ENTREVISTA</p><p> Leia as documentações do projeto e do ambiente,</p><p>marcando ou anotando as dúvidas para que sejam</p><p>sanadas durante a entrevista.</p><p> Estudar material existente sobre os entrevistados e</p><p>suas organizações.</p><p> Estabelecer objetivos.</p><p> Decidir quem entrevistar.</p><p> Preparar a entrevista.</p><p> Decidir sobre os tipos de questões e a estrutura da</p><p>entrevista.</p><p> Decidir como registrar a entrevista.</p><p>1º passo: Preparação para a entrevista</p><p> Clientes e usuários não são seus amigos</p><p> O entrevistado não gosta de ser</p><p>entrevistado</p><p> Não induzir perguntas</p><p> Anote tudo!</p><p>2º passo: Execução da entrevista</p><p>A entrevista termina quando todas as</p><p>dúvidas do analista forem sanadas.</p><p>Após o término de todas as sessões, o</p><p>analista vai elaborar um relatório final com</p><p>data, hora, tópicos abordados, perguntas e</p><p>respostas.</p><p>3º passo: Finalização da entrevista</p><p>6</p><p>QUESTIONÁRIO</p><p> O questionário é a técnica de levantamento onde os dados e informações são obtidos</p><p>com a utilização de perguntas escritas, publicadas</p><p>em mídia eletrônica ou em papel.</p><p> É aplicável quando a quantidade de perguntas e respostas possíveis é conhecida, a</p><p>clientela é volumosa ou muito dispersa geograficamente.</p><p> É possível aplicar essa técnica em uma quantidade de pessoas muito grande ao mesmo</p><p>tempo.</p><p>7</p><p>QUESTIONÁRIO</p><p> Para se elaborar um questionário, faz-se</p><p>uma entrevista com o solicitante.</p><p> Nessa entrevista, o analista irá verificar</p><p>quais são os dados a serem coletados,</p><p>não quais serão as perguntas a serem</p><p>feitas.</p><p> Essas perguntas serão elaboradas pelo</p><p>analista, depois de saber quais são as</p><p>informações desejadas.</p><p>1º passo: Elaboração</p><p> Eletrônico:</p><p> Inteligente: Aqui é inadmissível ver erros de</p><p>preenchimento pelo usuário. Para isso, criam-se todas as</p><p>validações necessárias, inclusive as de regra de negócio.</p><p> Layout: Recomenda-se um visual limpo e intuitivo para</p><p>que o usuário não se perca no meio do preenchimento.</p><p> Em papel:</p><p> Tamanho: Para evitar problemas com os tipos de papéis,</p><p>é recomendável se utilizar o papel padrão que, hoje, é o</p><p>A4.</p><p> Gramatura: Deve-se observar que, quanto maior a</p><p>gramatura do papel, mais pesado ele fica, maior é a sua</p><p>duração e maior o seu custo.</p><p>2º passo: Execução</p><p>8</p><p>QUESTIONÁRIO</p><p>Nesta fase será compilado os relatórios a serem entregues ao solicitante do relatório.</p><p>3º passo: Analise das respostas</p><p>Armazenar o questionário em mídia ou em papel para futuras pesquisas.</p><p>4º passo: Arquivamento</p><p>9</p><p>BIBLIOGRAFIA</p><p> UA - Aplicação de técnicas de elicitação de requisitos de software.</p><p> UA - Conhecer requisitos.</p><p> UA - Verificação de requisitos de software</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª Edição.</p><p>São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9. ed. –</p><p>Porto Alegre: AMGH, 2021. E-pub.</p><p> VAZQUEZ, Carlos Eduardo, SIMÕES, Guilherme Siqueira. Engenharia de Requisitos - Software orientado ao</p><p>negócio. Editora Brasport,2016.</p><p>Unidade:</p><p>Aula:</p><p>ENGENHARIA DE SOFTWARE I</p><p>Prof. Ma. Izabel Cristina Mioranza</p><p>3</p><p>5</p><p>2</p><p>CONTEÚDO</p><p> Unidade III:</p><p> Levantamento de dados.</p><p> Documento de requisitos.</p><p>3</p><p>LEVANTAMENTO DE DADOS</p><p>É comum lidarmos com clientes que, têm uma necessidade, mas não sabem expressá-la,</p><p>por isso devemos aplicar as diversas técnicas estudadas anteriormente para conseguirmos</p><p>levantar o maior número de informações possível.</p><p>Esse levantamento visa, principalmente, chegar a um acordo acerca do escopo do projeto,</p><p>do problema que ele deve resolver, convergir as ideias para soluções únicas e garantir o</p><p>mesmo entendimento a todas as partes interessadas.</p><p>Como afirma Vazquez, “não existe uma técnica de levantamento de dados melhor que a</p><p>outra, existe o momento e a situação para aplicar cada uma, por isso é importante o</p><p>analista conhecer e se adaptar a todas para poder usá-las conforme as necessidades.”</p><p>4</p><p>LEVANTAMENTO DE DADOS</p><p>“O dono da rede de academias apresenta ao analista uma lista de documentos, dentre eles, relatórios</p><p>financeiros, fichas de cadastro, ficha de treino e ficha de avaliação física”.</p><p>Analise de documentos</p><p>Surgimento de dúvidas por parte dos analistas com relação as funcionalidades da academia e também a</p><p>confirmação do entendimento que foi obtido pela técnica acima.</p><p>Entrevista</p><p>Após a entrevista com os responsáveis por cada setor a equipe verifica que alguns documentos não são</p><p>necessários na sua totalidade ou ainda que alguns fichas são preenchidas de acordo com o perfil de cada</p><p>aluno ou ainda os relatórios que serão gerados devem possuir valores baseados em períodos. Caso</p><p>surjam duvidas com relação a termos e nomenclaturas utilizadas ou ainda a equipe tenha duvidas sobre</p><p>outros pontos, nesse momento deverá ser utilizadas outras técnicas de levantamento de dados.</p><p>Glossário e Questionário.</p><p>5</p><p>LEVANTAMENTO DE DADOS</p><p>Exemplos de perguntas que podem ser feitas:</p><p>1. Quais são suas vantagens em relação aos seus concorrentes?</p><p>2. O que a empresa considera que não faz, e deveria ser feito, ou faz com pouca</p><p>qualidade?</p><p>3. O que seus competidores fazem melhor que vocês?</p><p>4. Que tipo de obstáculos pode acontecer na vida da organização?</p><p>5. Como a empresa pode manter ou melhorar isto?</p><p>6. Como a empresa pode se preparar para evitar uma ameaça?</p><p>6</p><p>LEVANTAMENTO DE DADOS</p><p>O documento de levantamento de dados deve conter no mínimo a seguinte estrutura:</p><p>1. Introdução</p><p> Breve descrição do que se trata o documento;</p><p>2. Objetivos</p><p> Breve descrição do objetivo do software a ser desenvolvido;</p><p>3. Visão Geral do Sistema</p><p> Breve descrição do que será o software;</p><p>4. Descrição Comercial da Empresa com nome; razão social; endereço completo;</p><p>telefone; e o nome do gerente ou responsável pela empresa.</p><p>7</p><p>LEVANTAMENTO DE DADOS</p><p>5. Estrutura da organização</p><p> Um breve histórico da empresa;</p><p>6. Sistemas de informática</p><p> Se possui softwares instalados; quais são; pra que serve; quais departamentos o utilizam; se esta</p><p>sendo usado ou não pela empresa; quais equipamentos possui e a descrição dos mesmos;</p><p>7. Situação atual:</p><p> Descrição em detalhes do funcionamento da empresa para conseguir responder as questões:</p><p>• Como esta atualmente a empresa?</p><p>• Quais os problemas que isso acarreta?</p><p>• As sugestões de melhoria que a equipe tem</p><p> As solicitações do cliente referente ao item que esta em analise.</p><p>8</p><p>LEVANTAMENTO DE DADOS</p><p> Uma das grandes tarefas do analista é conseguir identificar o máximo de requisitos “nas</p><p>entrelinhas”.</p><p> Sommerville afirma que “Mudanças organizacionais, mudanças nos negócios e</p><p>mudanças técnicas inevitavelmente geram mudanças nos requisitos para um sistema de</p><p>software”.</p><p> Vazquez complementa que “A análise de requisitos tem por objetivo aumentar o</p><p>entendimento atual da informação, completá-la e melhorá-la ao identificar omissão,</p><p>ambiguidade, conflito, redundância ou erro nos requisitos”</p><p>9</p><p>DOCUMENTO DE REQUISITOS</p><p>Sommerville afirma que o documento de requisitos de software “é uma declaração</p><p>acordada dos requisitos do sistema. Deve ser organizado para que ambos - os clientes do</p><p>sistema e os desenvolvedores de software - possam usá-lo”.</p><p>O PMI - Instituto de Gerenciamento de Projetos – apresenta uma lista dos motivos de</p><p>porque desenvolver um bom documento de requisitos:</p><p>1. É a base para validar as necessidades dos stakeholders e definir as soluções do software;</p><p>2. É a base para as documentações a serem criadas, por exemplo, manuais e base para garantir o</p><p>desenvolvimento e testes com qualidade;</p><p>3. É suporte para fechamento de contratos e auditorias.</p><p>10</p><p>DOCUMENTO DE REQUISITOS</p><p> O Documento de Especificação de Requisitos tem como principal função documentar os</p><p>requisitos funcionais e não funcionais de um projeto de software.</p><p> A análise de requisitos pode gerar vários artefatos durante sua execução: diagramas em</p><p>linguagem UML (diagrama de classe, diagrama de caso de uso, diagrama de sequência,</p><p>e outros), requisitos funcionais e requisitos não funcionais, protótipos de interfaces,</p><p>modelos de negócio, fluxo de ação e muitos outros.</p><p>11</p><p>DOCUMENTO DE REQUISITOS</p><p>Requisito de usuário que diz:</p><p>“Necessidade de visualizar relatório financeiro mensal de cada academia da rede, de forma</p><p>individualizada.”</p><p>Para esse requisito do usuário, teremos os requisitos do sistema, que indicam como o software deve</p><p>funcionar, suas restrições e quais itens são obrigatórios ou opcionais.</p><p>Nos requisitos do sistema, cada frase deve representar um requisito do software, por exemplo:</p><p>O sistema deve gerar o relatório financeiro de cada filial, no primeiro dia de cada mês, contendo as</p><p>mensalidades e a data de quitação.</p><p>O sistema deverá gerar um relatório contendo apenas as mensalidades estornadas.</p><p>O sistema deve gerar um relatório para os alunos com atraso superior a três meses.</p><p>Exemplo:</p><p>12</p><p>DOCUMENTO DE REQUISITOS</p><p> Gerenciamento das informações do cadastro de cidade</p><p>1. O sistema deverá permitir o cadastro de uma cidade</p><p>através dos seguintes dados:</p><p>Código(*), Nome da Cidade(@) e Estado(@).</p><p>2. O sistema deverá permitir a alteração dos dados da cidade com exceção do seu código.</p><p>3. O sistema deverá permitir a exclusão de uma cidade apenas se a mesma não possuir</p><p>registros relacionados com nenhuma entidade no sistema.</p><p>4. O sistema deverá realizar a pesquisa através da descrição ou do estado da cidade.</p><p>5. O sistema devera permitir o cadastro de uma cidade apenas se ela já não estiver</p><p>cadastrada no sistema, realizando a verificação através do nome da cidade e do</p><p>estado.</p><p>Documento elaborado em um editor de texto.</p><p>13</p><p>BIBLIOGRAFIA</p><p> UA - Aplicação de técnicas de elicitação de requisitos de software.</p><p> UA - Conhecer requisitos.</p><p> UA - Verificação de requisitos de software</p><p> UA - Especificação de requisitos funcionais utilizando casos de uso</p><p> UA - Especificação dos requisitos não funcionais de software</p><p> https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/2340</p><p>8</p><p> SOMMERVILLE, Ian. Engenharia de software. trad. Luiz Cláudio Queiroz [recurso eletrônico]. 10ª Edição.</p><p>São Paulo: Pearson Education do Brasil, 2018.</p><p> PRESSMAN, R. S. Engenharia de software: uma abordagem profissional [recurso eletrônico]. 9. ed. –</p><p>Porto Alegre: AMGH, 2021. E-pub.</p><p> VAZQUEZ, Carlos Eduardo, SIMÕES, Guilherme Siqueira. Engenharia de Requisitos - Software orientado ao</p><p>negócio. Editora Brasport,2016.</p><p>https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408</p><p>https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408</p><p>14</p><p>REFERÊNCIAS</p><p>Imagens utilizadas nos slides:</p><p> https://www.inf.ufpr.br/andrey/ci167/projua02c.pdf</p><p>Exemplos utilizados nos slides elaborados pela professora.</p><p>https://www.inf.ufpr.br/andrey/ci167/projua02c.pdf</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Engenharia de requisitos</p><p>Requisitos...</p><p>Requisitos... (2)</p><p>Requisitos... (3)</p><p>Requisitos... (4)</p><p>Requisitos... (5)</p><p>Engenharia de requisitos (2)</p><p>Engenharia de requisitos (3)</p><p>Engenharia de requisitos (4)</p><p>Engenharia de requisitos (5)</p><p>BIBLIOGRAFIA</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Engenharia de requisitos</p><p>Engenharia de requisitos (2)</p><p>Requisitos Funcionais</p><p>Requisitos Funcionais (2)</p><p>Requisitos não Funcionais</p><p>Requisitos não Funcionais (2)</p><p>Requisitos não Funcionais (3)</p><p>Requisitos....</p><p>Engenharia de requisitos (3)</p><p>Especificação de requisitos</p><p>Especificação de requisitos (2)</p><p>BIBLIOGRAFIA</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Processos de engenharia de requisitos</p><p>Elicitação e análise de requisitos</p><p>Técnicas utilizadas para a elicitação e análise dos requisitos</p><p>Análise de documentos</p><p>Glossário</p><p>Observação (Etnografia)</p><p>Observação (Etnografia) (2)</p><p>BIBLIOGRAFIA</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Entrevista</p><p>Entrevista (2)</p><p>Entrevista (3)</p><p>questionário</p><p>questionário (2)</p><p>questionário (3)</p><p>BIBLIOGRAFIA</p><p>Engenharia de software i</p><p>Conteúdo</p><p>Levantamento de dados</p><p>Levantamento de dados (2)</p><p>Levantamento de dados (3)</p><p>Levantamento de dados (4)</p><p>Levantamento de dados (5)</p><p>Levantamento de dados (6)</p><p>Documento de requisitos</p><p>Documento de requisitos (2)</p><p>Documento de requisitos (3)</p><p>Documento de requisitos (4)</p><p>BIBLIOGRAFIA</p><p>Referências</p>