Engenharia de Requisitos PDF

O que você entende por “Requisito de REQUISITOS Software”? DE SOFTWARE Introdução Muitos problemas de Engenharia de Software originam-se da imprecisão na especificação de requisitos ( Levantamento de Necessidades) ▫ Atraso na entrega do sistema; ▫ Aumento dos...

O que você entende por “Requisito de REQUISITOS Software”? DE SOFTWARE Introdução Muitos problemas de Engenharia de Software originam-se da imprecisão na especificação de requisitos ( Levantamento de Necessidades) ▫ Atraso na entrega do sistema; ▫ Aumento dos custos. “O começo é a parte mais importante do trabalho.” (Platão) 2 E-Mail do Cliente Para: Lucas Bender Enviado: Qui 23/11/2006 14:45 De: Ancelmo Marques Assunto: Solicitação para desenvolvimento de sistema Prezados Senhores! Conforme conversa telefônica, nós da Universidade Estudo Certo solicitamos uma proposta para o desenvolvimento de um sistema de matrículas, visto que nosso processo ainda é totalmente presencial e em grande parte manual e demorado. Este novo sistema deverá permitir aos professores e alunos acessar o sistema através da Internet. Futuramente deverá permitir que os professores mantenham as notas dos alunos de suas disciplinas. O objetivo deste novo sistema é, além de agilizar o processo de matrícula, melhorar a imagem da Instituição. Desejamos ter o novo sistema disponível para o próximo período de matriculas, o que deverá ocorrer em Julho próximo. Gostaríamos de agendar uma reunião para o discutirmos sobre a viabilidade do projeto. Aguardo retorno. Obrigado. Ancelmo Marques Diretor Acadêmico E AGORA ???? Eu irei lá descobrir o que eles estão precisando e enquanto isso vocês todos comecem a programar ! Afinal, o que é um Requisito de Software? Requisitos de software Engenharia de Requisitos Objetivo ▫ Sistematizar o processo de definição dos requisitos, obtendo uma especificação correta e completa dos requisitos (IEEE, 1991). ▫ Desenvolver uma especificação completa, consistente e não ambígua, descrevendo o quê o produto de software irá fazer, mas não como ele será feito (Boehm, 1989). 8 Engenharia de Requisitos Processo para descobrir, analisar e documentar funções e as restrições de um sistema O produto desse processo é um Documento de Requisitos Documento de Requisitos de Software completo e consistente – preciso: ▫ Enteder o contexto em que o problema se situa:  Objetivos do produto a ser desenvolvido.  Funcionalidades do produto. 9 Importância da Engenharia de Requisitos Erros são causados por diversas razões, mas a principal causa pode ser originada na especificação (fonte: "Software Testing", Ron Patton) Existem tipos diferentes de Requisito de Software? Tipos de Requisitos Requisitos Funcionais - RF ▫ RF são requisitos diretamente ligados a funcionalidade do software Requisitos Não Funcionais – RNF ▫ Expressam restrições que o software deve atender ou qualidades específicas que o software deve ter Requisitos de Domínio ou Regras de Negócio - RN ▫ Requisitos provenientes do domínio da aplicação do sistema Requisitos Funcionais - Funções do Sistema O que o sistema deve fazer? Declarações de funções que o sistema deve fornecer; Como o sistema deve reagir a entradas específicas; 13 Exemplos de Requisitos Funcionais ▫ “O sistema deve permitir que o usuário cadastre os clientes...” ▫ “O sistema deve permitir que o gerente emitia relatório de vendas do dia...” ▫ “O Sistema deve permitir que a atendente cadastre as locações...” Não Funcionais ▫ “O sistema deve ser utilizado em plataforma Windows...” ▫ “O sistema deve ter restrições de segurança solicitando login e senha...” ▫ “O sistema deve acessar o banco de dados Oracle...” Requisitos de Domínio ou Regras de Negócio ▫ “A média para passar na disciplina é 6,0” ▫ “Não se pode fazer uma matricula caso o pré-requisito não esteja cursado...” Requisitos Não Funcionais Não dizem respeito diretamente às funções específicas fornecidas pelo sistema; Colocam restrições no sistema; Restrições sobre os serviços ou as funções oferecidos pelo sistema; Por exemplo: ▫ Restrições de tempo de resposta, desempenho, espaço em disco, portabilidade, entre outros. 15 Exemplos de requisitos não funcionais Velocidade ▫ Transações processadas / segundo ▫ Tempo de resposta ao usuário / evento Facilidade de uso ▫ Tempo de treinamento ▫ Nível de detalhe de ajuda on-line Confiabilidade ▫ Tempo médio para falhar ▫ Probabilidade de indisponibilidade ▫ Disponibilidade Robustez ▫ Tempo de reinício depois de uma falha ▫ Porcentagem de eventos que causam falhas Portabilidade ▫ Número de sistemas-alvo (especificar cada sistema-alvo) Requisitos não funcionais - Classificação Produto: Referem-se a características do comportamento do produto que esta sendo desenvolvido Organizacional: São procedentes de políticas e procedimentos definido nas organizações do cliente e do desenvolvedor. Externo: Impostos tanto ao produto quanto ao processo de desenvolvimento em função do ambiente no qual o sistema é desenvolvido Requisitos Não Funcionais Exemplos Requisito Não Funcional de Produto RNF de usabilidade: usuarios devem ser capazes de usar as funções do sistema após duas horas de treinamento RNF de confiabilidade: o sistema deve estar disponível 99% das vezes RNF de segurança: o acesso aos dados deve ser protegido, conforme RN01 RNF de desempenho: o sistema deve processar 1000 transações por segundo Exemplos Requisito Não Funcional de Produto RNF de capacidade: o sistema deve suportar 270 usuários concorrentemente RNF de portabilidade: o sistema deve rodar nas plataformas X e Y Exemplos Requisito Não Funcional Organizacional RNF de entrega: um relatório de progresso deve ser entregue toda semana RNF de implementação: o sistema deve ser implementado em.Net Exemplos Requisito Não Funcional Externo RNF de interoperabilidade: o sistema deve interagir com os sistemas Compras e Vendas RNF de restricoes éticas: o sistema não deverá revelar aos operadores nenhuma informação pessoal dos clientes RNF de restricoes legais: o sistema deverá armazenar as informações de acordo com a Lei número XXYY do ano de XXXX. Atividade 1 - Identificar Requisitos Funcionais, Requisitos não funcionais e Requisitos de domínio Uma biblioteca deve automatizar seus registros de livros, leitores e empréstimos. Esse sistema deve ser utilizado através do navegador Firefox. Suponha que seus procedimentos sejam básicos, onde não há reserva de livros, o prazo de devolução é de uma semana, não há multa e o leitor não tem limite máximo para retirada de livros. O sistema deve permitir a consulta da bibliotecária ou leitor ao acervo, indicando se o livro está retirado ou disponível, imprimir relatórios de leitores, leitores em atraso e livros disponíveis e retirados. O sistema de rodar 24 horas x 7 dias, com tempo máximo de resposta de 10 segundos. Atividade 2 – Clínica odontológica Quando um paciente deseja marcar uma consulta, a atendente deve verificar a agenda do dentista e oferecer o primeiro horário disponível (data e hora), de acordo com o que o paciente deseja. Caso o paciente concordar com o horário, é registrado na agenda o nome do paciente e horário combinado. Os pacientes já cadastrados têm a ficha de consulta preenchida automaticamente. Os pacientes novos devem fornecer seus dados de cadastro: RG, endereço, telefone, data nascimento, profissão. A consulta consiste de 2 tipos de serviços: de limpeza e restauração, ou exames para diagnóstico. Na realização da consulta, o dentista faz o registro do serviço efetuado em detalhes e, se necessário, o paciente marca uma nova consulta. O dentista pode pesquisar as fichas de seus pacientes por nome ou data de consultas. O Sistema deve ficar pronto até outubro de 2014. Atividade 3 – Locadora de filmes Ao realizar uma locação, o sócio deve primeiro informar seu código para que o atendente possa verificar se este esta cadastrado no sistema. Caso o sócio não esteja cadastrado, a locação deverá ser recusada e o sócio poderá ser cadastrado. Caso esteja cadastrado, o atendente deve verificar se o sócio em questão já devolveu todas as locações feitas anteriormente, se não o tiver feito a locação deverá ser recusada. Caso o sócio esteja em conformidade com os requisitos acima, deverá informar as cópias dos filmes que deseja locar.Em seguida o atendente registrará a locação e fornecerá as cópias em questão para o sócio. É responsabilidade do atendente realizar a manutenção dos filmes e de suas respectivas cópias. Registrando novos filmes adquiridos pela locadora, por exemplo. E isto é só o começo de uma longa viagem... Processos de Engenharia de Requisitos Objetivo ▫ Criar e manter um documento de requisitos Engenharia de Requisitos Visão tradicional Estudos de Viabilidade Conjunto preliminar de requisitos de negócios, um esboço da descrição do sistema e como o sistema pretende apoiar os processos de negócios Estudo breve e focalizado que procura responder a uma séria de questões: ▫ O Sistema contribui para os objetivos gerais da organização? ▫ O sistema pode ser implementado com tecnologia atual de dentro das restrições definidas de custo e prazo? ▫ O sistema pode ser integrado a outros sistemas já implantados? Estudos de Viabilidade Envolve a avaliação de informações, sua coleta e a elaboração de um relatório. Após a identificação das informações podem surgir outras questões: ▫ Como a organização se comportaria se o sistema não fosse implementado? ▫ Quais são os problemas com os processos atuais e como o novo sistema ajudaria a reduzir esses problemas? ▫ Qual será a contribuição direta do sistema para os objetivos e requisitos da empresa? ▫ As informações podem ser transferidas e recebidas de outros sistemas da organização? ▫ O sistema requer tecnologia que ainda não foi usada na organização? ▫ O que deve ser apoiado pelo sistema e o que não precisa ser apoiado? Elicitação e Análise de Requisitos Nessa atividade os engenheiros de software trabalham com os clientes e os usuários finais para aprender sobre o domínio da aplicação ▫ Quais serviços o sistema deve fornecer, o desempenho esperado, restrições de hardware, etc. Pode envolver várias pessoas na organização, os stakeholders (envolvidos, afetados, interessados) Elicitação e Análise de Requisitos Dificuldades Elicitação e Análise de Requisitos Atividades do Processo Elicitação e Análise de Requisitos Atividades do Processo Obtenção de requisitos ▫ Interação com stakeholders para coletar requisitos  Entrevistas, Reuniões, Questionários, Prototipagem, Role Playing, Observação Direta, etc. Classificação e organização de requisitos ▫ Agrupa requisitos relacionados Priorização e negociação de requisitos ▫ Vários stakeholders => requisitos conflitantes Documentação de requisitos ▫ Documentação de requisitos levantados. Elicitação e Análise de Requisitos Obtenção de Requisitos Especificação de Requisitos Detalhamento e descrição dos requisitos obtidos de acordo com um template padrão Validação de Requisitos Requisitos realmente definem o sistema? O que deve ser feito? ▫ Verificações de validade ▫ Verificações de consistência  Sem conflitos ▫ Verificações de completude  Requisitos definem o sistema como um todo? ▫ Verificações de realismo  É possível fazer em termos de prazo e custo? ▫ Facilidade de verificação  Linguagem padronizada de escrita de requisitos Validação de Requisitos Realizada através de: ▫ Revisões  Problema: Quem vigia o vigia? ▫ Prototipação ▫ Casos de teste  Antes de implementar: Implementar o caso de teste  Se o teste é difícil de se implementar... ▫ Então o código também é! ▫ Re-analisar os requisitos... Gerenciamento de Requisitos Fato: Requisitos mudam... ▫ Utilizar ferramentas que permitam a rastreabilidade de requisitos.  Armazenamento de requisitos  Gerenciamento de mudanças  Ligação entre requisitos e artefatos gerados por ele.  Diagramas de análise  Casos de uso  Código Documento de Requisitos O Documento de Requisitos do sistema deve ser composto por sentenças em linguagem natural, seguindo determinados padrões: 1. Iniciar com “O sistema deve…” 2. Usar frases curtas. “ O sistema deve rodar em microcomputadores da linha IBM PC que possuam microprocessador 486 DX ou superior.” 40 Documento de Requisitos 3. Os requisitos devem estar organizados logicamente 4. Cada requisito deve ter um identificador único. ▫ Um identificador numérico, para posterior referência. 5. Os requisitos do software devem estar divididos em requisitos funcionais e não funcionais. 6. Os requisitos não devem conter detalhes de implementação ▫ É importante não utilizar termos relacionados à implementação, tais como “arquivo” e “menu”. 41 Padrão IEEE para o Documento de Requisitos 1. Introdução 1.1 Propósito do documento de requisitos  Motivações, público alvo, … 1.2 Escopo do produto  Explicitar o que o produto faz (e o que não faz).  Descrever a aplicação. 1.3. Definições, abreviações 1.4. Referências  Listar todos os documentos referenciados.  Especificar a origem dos documentos. 1.5. Visão Geral do restante do documento  Estrutura / Organização. 42 Padrão IEEE para o Documento de Requisitos 2. Descrição Geral 2.1 Perspectiva do Produto  Relacionamento: sistema, usuário, hardware, software, comunicação. 2.2 Funcionalidades do produto 2.3. Características do Usuário 2.4. Restriçoes Gerais  Limitações de hardware, consideraçoes sobre segurança. 2.5. Suposições e Dependências  Máquina específica, SO,... 3. Apêndices 4. Índice 43 Questões para discussão Qual a importância da Engenharia de Requisitos para a qualidade do software? O que podemos fazer para minimizar os problemas dos fatores críticos referentes à Engenharia de Requisitos? Quais os principais cuidados a serem tomados na Engenharia de Requisitos? Referências Sommerville, I. Engenharia de Software www.ieee.org