Aula 02 - Engenharia de Requisitos

Prévia do material em texto

<p>Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.</p><p>Explicar como a engenharia de requisitos se encaixa no processo mais abrangente da engenharia de sistemas</p><p>Explicar a importância do documento de requisitos</p><p>No início da computação não havia nenhuma processo para a descoberta dos requisitos</p><p>Os programadores sentavam-se e começavam a codificar.</p><p>Quando começa um processo de desenvolvimento de software, um lápis custa pouco mais de R$ 1,00 .</p><p>Só que a borracha para efetuar os ajustes custa milhões...</p><p>Não é fácil...</p><p>... entender a funcionalidade.</p><p>...obter a forma correta.</p><p>...entender problemas que você não está familiarizado</p><p>...entender os detalhes da solução.</p><p>Definem o que é solicitado ao sistema fazer e com quais limitações ele é requisitado a operar.</p><p>Por exemplo:</p><p>O sistema deve manter registro de todos os materiais da biblioteca incluindo livros, séries, jornais e revistas e CDROMs. (requisito funcional)</p><p>O sistema deve permitir que os usuários pesquisem um item através do título, autor ou ISBN. (requisito funcional)</p><p>A interface de usuário do sistema deve ser implementada para ser acessível via browser de WWW (World-Wide-Web). (requisito não-funcional)</p><p>O sistema deve suportar pelo menos 20 transações por segundo.	(requisito não-funcional)</p><p>Funcionais</p><p>definem as funcionalidades do sistema.</p><p>Serviços que o sistema deve fornecer</p><p>Como o sistema deve reagir a entradas específicas</p><p>Como o sistema deve se comportar em determinadas situações</p><p>Ex.: O sistema deve permitir a realização de compras de livros</p><p>Não-Funcionais</p><p>dizem respeito à restrições de desenvolvimento, aspectos de desempenho, interfaces com o usuário, confiabilidade, segurança, manutenibilidade, portabilidade, padrões a serem seguidos</p><p>Ex.: O sistema deve possuir uma GUI que siga o padrão de interface do Windows</p><p>Exemplos de requisitos funcionais</p><p>O usuário deve ser capaz de pesquisar em todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele</p><p>Para todo pedido deve ser alocado um identificador único (ORDER_ID) que o usuário possa copiar para a área de armazenamento permanente da sua conta</p><p>O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos</p><p>Definem propriedades e restrições de sistema</p><p>– Ex: confiabilidade, tempo de resposta e requisitos de armazenamento</p><p>Restrições são capacidade de dispositivos de E/S, representações de sistema, etc.</p><p>Requisitos de processo podem também ser especificados, impondo uma linguagem de programação, IDE ou método de desenvolvimento particular</p><p>Requisitos não-funcionais podem ser mais críticos do que os requisitos funcionais</p><p>Organizacionais</p><p>dizem respeito às metas da empresa.</p><p>políticas estratégicas adotadas,</p><p>os empregados da empresa com seus respectivos</p><p>objetivos;</p><p>enfim toda a estrutura da organização.</p><p>Ex.: O sistema visa aumentar os lucros da empresa</p><p>Problemas dos Requisitos</p><p>Os requisitos não refletirem as reais necessidades dos clientes do sistema.</p><p>Os requisitos serem inconsistentes e/ou incompletos.</p><p>O custo alto para se fazer mudanças de requisitos depois de terem sido concordados.</p><p>Existirem mal entendidos entre clientes, aqueles que desenvolvem os requisitos do sistema e os engenheiros de software que desenvolvem ou mantêm o sistema.</p><p>Imprecisão de requisitos</p><p>Problemas surgem quando os requisitos não são</p><p>precisamente definidos</p><p>Requisitos ambíguos podem ser interpretados de maneiras diferentes pelos desenvolvedores e usuários</p><p>Considere o termo ‘telas apropriadas’</p><p>Intenção do usuário – tela de propósito especial para cada tipo diferente de documento</p><p>Interpretação do desenvolvedor – fornece uma tela de texto que mostra o conteúdo do documento</p><p>Requisitos completos e consistentes</p><p>Em princípio, requisitos devem ser completos e consistentes</p><p>Completude</p><p>Eles devem incluir descrições de todos os recursos</p><p>requeridos</p><p>Consistência</p><p>Não deve haver conflitos ou contradições nas descrições dos recursos de sistema</p><p>Na prática, é impossível produzir um documento de requisitos completo e consistente</p><p>Questões mais frequentemente sobre requisitos</p><p>O que são requisitos?</p><p>Uma descrição de um serviço ou de uma limitação</p><p>O que é a engenharia de requisitos?</p><p>O processo envolvido no desenvolvimento de requisitos de um sistema</p><p>Quanto custa a engenharia de requisitos?</p><p>Cerca de 15% dos custos do desenvolvimento do sistema.</p><p>continuação</p><p>O que é o processo de engenharia de requisitos?</p><p>Um conjunto estruturado de atividades envolvidas no desenvolvimento dos requisitos do sistema</p><p>O que acontece quando os requisitos estão errados?</p><p>Os sistema atrasam, ficam não confiáveis e não satisfazem as necessidades dos clientes.</p><p>Existe um processo de engenharia de requisitos ideal?</p><p>Não - os processos precisam ser adaptados as necessidades organizacionais.</p><p>O que é um documento de requisitos?</p><p>Uma descrição formal dos requisitos do sistema.</p><p>continuação</p><p>O que são stakeholders do sistema?</p><p>Qualquer pessoa afetada de alguma forma pelo sistema.</p><p>Qual é o relacionamento entre requisitos e projeto?</p><p>Requisitos e projeto são interligados. Idealmente eles deveriam ser separados, mas na prática isto é impossível.</p><p>O que é gerenciamento dos requisitos?</p><p>O processo envolvido no gerenciamento das mudanças dos requisitos</p><p>O Processo da Engenharia de Sistemas</p><p>Atividades da Engenharia de Sistemas</p><p>Engenharia de Requisitos do Sistema</p><p>Os requisitos do sistema como um todo são estabelecidos e escritos para serem entendidos por todas as partes interessadas (stakeholders)</p><p>Projeto de arquitetura</p><p>O sistema é decomposto em subsistemas</p><p>Partição de requisitos</p><p>Os requisitos são alocados a estes subsistemas</p><p>Engenharia de Requisitos de Software</p><p>Requisitos de software mais detalhados são derivados para o software do sistema</p><p>Atividades da Engenharia de Sistemas</p><p>Desenvolvimento de subsistemas</p><p>Os subsistemas de hardware e software são projetados e implementados em paralelo.</p><p>Integração de sistemas</p><p>Os subsistemas de hardware e software são colocados juntos para compor o sistema.</p><p>Validação do sistema</p><p>O sistema é validado em relação aos requisitos.</p><p>Propriedades Emergentes</p><p>Propriedades do sistema como um todo que somente emergem quando todos os subsistemas estiverem integrados.</p><p>Exemplos de propriedades emergentes</p><p>Confiabilidade</p><p>Manutenabilidade</p><p>Desempenho (Performance)</p><p>Usabilidade</p><p>Segurança</p><p>Documento de Requisitos</p><p>Documento formal usado para comunicar os requisitos aos clientes, engenheiros e gerentes.</p><p>Descreve:</p><p>Os serviços e funções que o sistema deve prover;</p><p>As limitações sobre as quais o sistema deve operar;</p><p>Propriedades gerais do sistema, isto é limitações nas propriedades emergentes;</p><p>Definições de outros sistemas com o qual o sistema deve se integrar.</p><p>Documento de Requisitos</p><p>Descreve (continuação):</p><p>Informações sobre o domínio da aplicação do sistema;</p><p>Ex.: como calcular um certo tipo de computação</p><p>Limitações nos processos usados para desenvolver o sistema;</p><p>Descrições sobre o hardware no qual o sistema irá executar.</p><p>Deverá sempre conter uma capítulo introdutório que provê um resumo do sistema, necessidades de negócio suportadas pelo sistema e um glossário que explica a terminologia usada.</p><p>Usuários do documento de requisitos</p><p>Clientes do Sistema</p><p>Especificam os requisitos e os leem para checar se eles satisfazem suas necessidades.</p><p>Gerentes de Projeto</p><p>Usam os documentos de requisitos para planejarem uma proposta para o sistema e o processo de desenvolvimento do sistema.</p><p>Engenheiros de Sistema</p><p>Usam os requisitos para entenderem o sistema em construção.</p><p>Usuários do documento de requisitos (cont.)</p><p>Engenheiros de teste do sistema</p><p>Usam os requisitos para desenvolverem testes de validação do sistema.</p><p>Engenheiros de manutenção do sistema</p><p>Usam os requisitos para entenderem o sistema.</p><p>Estrutura do documento de requisitos</p><p>Padrão IEEE/ANSI 830-1998 uma estrutura para o documento de requisitos</p><p>Introdução</p><p>Propósito do documento de Requisitos</p><p>Escopo do produto</p><p>Definições, acrônimos e abreviações</p><p>Referencias</p><p>Resumo do resto do documento</p><p>Estrutura do documento de requisitos</p><p>Descrição Geral</p><p>Perspectiva do produto</p><p>Funções do produto</p><p>Características do usuário</p><p>Limitações gerais</p><p>Suposições e dependências</p><p>Requisitos específicos</p><p>Cobrem requisitos funcionais, não-funcionais e interface.</p><p>Apêndices Índice</p><p>Escrevendo requisitos</p><p>Requisitos são geralmente escritos como textos em linguagem natural complementados por diagramas e equações.</p><p>Problemas com os requisitos</p><p>Uso de cláusulas condicionais complexas que podem confundir;</p><p>Terminologia inconsistente;</p><p>Os escritores assumem que os leitores possuem conhecimento do domínio.</p><p>O essencial da escrita</p><p>Requisitos são lidos mais frequentemente do que são escritos. Você deverá investir tempo lendo e entendendo os requisitos.</p><p>Não assuma que todos os leitores dos requisitos tenham o mesmo background e usem a mesma terminologia sua.</p><p>Permita tempo para revisão e refeita do documento de requisitos.</p><p>Escrevendo diretrizes</p><p>Defina templates (modelos) padrões para descrição de requisitos;</p><p>Use a linguagem de forma simples, consistente e concisa;</p><p>Use diagramas de forma apropriada;</p><p>Complemente a linguagem natural com outras descrições de requisitos;</p><p>Especifique requisitos de forma quantitativa.</p><p>Pontos Principais</p><p>Requisitos definem o que o sistema deve provê e define os limites do sistema;</p><p>Problemas nos requisitos causam a entrega tardia dos sistemas e solicitações de mudanças depois que o sistema estiver em uso;</p><p>Engenharia de requisitos diz respeito a elicitação, análise e documentação dos requisitos do sistema.</p><p>Pontos Principais</p><p>Engenharia de sistemas diz respeito ao sistema como um todo, incluindo hardware, software e processos operacionais;</p><p>O documento de requisitos é a especificação definitiva para os clientes, engenheiros e gerentes;</p><p>O documento de requisitos deve incluir um resumo, glossário, definição de requisitos funcionais e limitações operacionais.</p><p>Processos</p><p>Processo é um conjunto organizado de atividades que transforma entradas em saídas;</p><p>Descrições de processos encapsulam conhecimento e permitem que sejam reusados;</p><p>Exemplos de descrições de processo:</p><p>– Manual de instrução de uma máquina de lavar, receitas de bolo, ER, etc</p><p>Processo de ER entradas e saídas</p><p>Processo de Engenharia de Requisitos</p><p>Informações de Sistemas Existentes</p><p>Necessidades das partes envolvidas</p><p>Padrões</p><p>Organizacionais</p><p>Regulamentações</p><p>Informações do Domínio</p><p>Requisitos Acordados</p><p>Especificação do</p><p>Sistema</p><p>Modelos de</p><p>Sistema</p><p>Entrada ou Saída	Tipo	Descrição</p><p>Informação sobre Sistemas Existentes	Entrada	Informação sobre a funcionalidade dos sistemas a serem substituídos ou de outros sistemas que interagem com o sistema que está sendo especificado.</p><p>Necessidades dos Participantes	Entrada	Descrições do que os participantes necessitam do sistema para suportar seus trabalhos</p><p>Padrões da</p><p>Organização	Entrada	Padrões usados na organização relativos às práticas de desenvolvimento de sistemas, gerenciamento da qualidade, etc.</p><p>Regulamentações	Entrada	Regulamentações externas tais como regulamentações de saúde e segurança que se aplicam ao sistema</p><p>Informação do Domínio	Entrada	Informações gerais sobre o domínio de aplicação do sistema</p><p>Variação do Processo de Requisitos</p><p>Os processos de requisitos variam radicalmente de uma organização para outra;</p><p>Fatores que contribuem para esta variação:</p><p>Maturidade Técnica;</p><p>Envolvimento disciplinas;</p><p>Cultura Organizacional;</p><p>Domínio de aplicação.</p><p>Portanto não existe um processo ‘ideal’ de engenharia de requisitos.</p><p>Atividades do processo de ER</p><p>Elicitação de Requisitos</p><p>Os requisitos são descobertos através da consulta com as partes interessadas</p><p>Análise e negociação de requisitos</p><p>Requisitos são analisados e os conflitos resolvidos através de negociação</p><p>Documentação de requisitos</p><p>Um documento de requisitos é produzido</p><p>Validação de requisitos</p><p>É checada a consistência e completude do documento de requisitos</p><p>Fatores Humanos e Sociais</p><p>Os processos de engenharia de requisitos são dominados por fatores humanos, sociais e organizacionais</p><p>– porque eles sempre envolvem um conjunto de partes interessadas com backgrounds diferentes e com objetivos organizacionais e individuais diferentes</p><p>As partes interessadas (stakeholders) pelo sistema podem ter uma variedade de background técnico e não técnico e de diferentes disciplinas</p><p>Fatores influenciando requisitos</p><p>Personalidade e status dos stakeholders;</p><p>Os objetivos pessoais dos indivíduos dentro da empresa;</p><p>O grau de influência política dentro de uma organização.</p><p>Melhoria de Processo</p><p>A melhoria de processo está relacionado com a modificação do processo de forma a alcançar algum objetivo de melhora;</p><p>Objetivos de melhora:</p><p>Melhoria de qualidade;</p><p>Redução de prazo;</p><p>Redução de recursos.</p><p>Planejando a melhoria do processo</p><p>Quais são os problemas com os processos atuais?</p><p>Quais são os objetivos de melhora?</p><p>Como o processo de melhora poderá ser introduzido para alcançar estes objetivos?</p><p>Como o processo de melhora poderá ser controlado e gerenciado?</p><p>Problemas do processo de ER</p><p>Falta de envolvimento dos stakeholders;</p><p>As necessidades do negócio não são consideradas;</p><p>Falta de gerenciamento dos requisitos;</p><p>Falta de definição de responsabilidades;</p><p>Problemas do processo de ER</p><p>Problemas de comunicação dos</p><p>stakeholders;</p><p>Planejamento longo demais e baixa qualidade dos documentos de requisitos.</p><p>Um modelo de maturidade de processo para ER</p><p>Níveis de maturidade da ER</p><p>Nível inicial</p><p>– Não há processo definido de ER. Sofre de problemas tais como volatilidade dos requisitos, stakeholders não satisfeitos e alto custo de refeita dos sistemas. Depende de habilidades e experiências individuais.</p><p>Níveis de maturidade da ER</p><p>Nível repetível</p><p>Padrões definidos para os documentos de requisitos e políticas e procedimentos para o gerenciamento de requisitos.</p><p>Nível definido</p><p>Um processo definido de ER, baseado em boas práticas e técnicas. Em funcionamento um processo ativo de melhoria.</p><p>Boas práticas para a melhoria do processo de ER</p><p>Os processo de ER podem ser melhorados pela sistemática introdução de boas práticas de engenharia de requisitos;</p><p>Cada ciclo de melhoria identificará diretrizes práticas e trabalhará em direção para a sua introdução na organização.</p><p>Objetivos</p><p>Descrever o processo da elicitação e análise requisitos.</p><p>Introduzir um número de técnicas elicitação de requisitos e análise de requisitos.</p><p>Discutir como protótipos podem ser usados no processo de ER.</p><p>Elicitação de requisitos</p><p>ELICITAR: descobrir, tornar explícito, obter o máximo de informações para o conhecimento do objeto em questão</p><p>Cabe à elicitação a tarefa de identificar os fatos relacionados aos requisitos do Sistema, de forma a prover o mais correto e mais completo entendimento do que é demandado daquele software</p><p>Componentes da elicitação de requisitos</p><p>Problema a ser resolvido</p><p>Contexto do negócio</p><p>Domínio da aplicação</p><p>Necessidades dos stakeholders</p><p>Atividades da Elicitação</p><p>Entendimento do domínio da aplicação</p><p>O conhecimento do domínio da aplicação é o conhecimento geral onde o sistema será aplicado.</p><p>Entendimento do problema</p><p>Os detalhes dos problemas específicos do problema do cliente onde o sistema será aplicado deve ser entendido.</p><p>Atividades da Elicitação</p><p>Entendimento do negócio</p><p>Você de entender como os sistemas interagem e contribuem de forma geral com os objetivos de negócio.</p><p>Entendimento das necessidades e limitações dos stakeholders do sistema</p><p>Você deve entender, em detalhe, as necessidades específicas das pessoas que requerem suporte do sistema no seu trabalho.</p><p>Elicitação de Requisitos: Dificuldades</p><p>Usuários podem não ter uma idéia precisa do sistema por eles requerido;</p><p>Usuários têm dificuldades para descrever seu conhecimento sobre o domínio</p><p>do problema;</p><p>Usuários e analistas têm diferentes pontos de vista do problema (por terem formações diferentes)</p><p>Usuários podem antipatizar com o novo sistema e se negar a participar da elicitação (ou mesmo fornecer informações errôneas).</p><p>Bacalá</p><p>73</p><p>Elicitação, análise e negociação</p><p>Estágios da Elicitação</p><p>Definir objetivos</p><p>Aquisição de conhecimento do background</p><p>Bacalá</p><p>76</p><p>Estágios da Elicitação</p><p>Definir objetivos</p><p>Os objetivos organizacionais devem ser estabelecidos incluindo objetivos gerais do negócio, um descrição geral do problema a ser resolvidos porque o sistema é necessário e as limitações do sistema.</p><p>Aquisição de conhecimento do background</p><p>Informação de background do sistema inclui informação acerca da organização onde o sistema será instalado, o domínio de aplicação do sistema e informação acerca de outros sistemas existente</p><p>Estágios da Elicitação</p><p>Organização do conhecimento</p><p>A grande quantidade de conhecimento que foi coletada nos estágios anteriores devem ser organizadas e colocadas em ordem.</p><p>Coletar os requisitos dos stakeholders</p><p>Os stakeholders do sistema são consultados para</p><p>descoberta de seus requisitos.</p><p>Algumas técnicas de elicitação</p><p>Entrevistas</p><p>Questionários</p><p>Brainstorm</p><p>Leitura de documentos</p><p>Cenários</p><p>Observações e análise sociais (etnografia)</p><p>Reuso de requisitos</p><p>Prototipação</p><p>Objetivos da Validação</p><p>Certificar que o documento de requisitos é uma descrição aceitável do sistema a ser implementado</p><p>Verificar as seguintes propriedades do documento:</p><p>Completude e consistência</p><p>Se está de acordo com os padrões</p><p>Conflitos de requisitos</p><p>Erros técnicos</p><p>Requisitos ambíguos</p><p>Análise e validação</p><p>Análise trabalha com os dados ‘crus` que foram elicitados dos stakeholders do sistema</p><p>Neste estágio a pergunta chave a ser respondida é “Temos os requisitos certos?”</p><p>Validação usa uma versão final do documento de requisitos, como os requisitos que foram negociados e concordados</p><p>Neste estágio a pergunta chave a ser respondida é “Temos certo os requisitos?”</p><p>Entradas da validação</p><p>Documento de requisitos</p><p>Deve ser um versão completa do documento, não uma versão preliminar. Formatada e organizada de acordo com os padrões organizacionais.</p><p>Conhecimento organizacional</p><p>Conhecimento, frequentemente implícito, da organização que poderá ser usado para julgar o realismo dos requisitos</p><p>Padrões organizacionais</p><p>Padrões locais, ex. para a organização do documento de requisitos</p><p>Saídas da validação</p><p>Lista de problemas</p><p>Lista dos problemas descobertos no documento de requisitos</p><p>Ações concordadas</p><p>Lista de ações que foram acertadas em resposta aos problemas dos requisitos. Alguns problemas podem ter várias ações corretivas; alguns problemas podem não ter ações associadas.</p><p>image3.png</p><p>image4.png</p><p>image5.png</p><p>image6.png</p><p>image7.png</p><p>image8.png</p><p>image9.jpeg</p><p>image10.jpeg</p><p>image11.png</p><p>image12.jpeg</p><p>image13.jpeg</p><p>image14.jpeg</p><p>image15.png</p><p>image16.png</p><p>image17.png</p><p>image18.png</p><p>image19.png</p><p>image20.png</p><p>image21.jpeg</p><p>image22.png</p><p>image23.png</p><p>image24.png</p><p>image25.png</p><p>image26.png</p><p>image27.png</p><p>image28.png</p><p>image29.png</p><p>image30.png</p><p>image31.jpeg</p><p>image32.png</p><p>image33.jpeg</p><p>image34.jpeg</p><p>image35.png</p><p>image36.png</p><p>image37.jpeg</p><p>image38.png</p><p>image39.png</p><p>image40.jpeg</p><p>image41.png</p><p>image42.png</p><p>image43.png</p><p>image44.png</p><p>image45.png</p><p>image46.png</p><p>image47.png</p><p>image48.png</p><p>image49.png</p><p>image50.png</p><p>image51.jpeg</p><p>image1.png</p>