Introdução a Requisitos

Introdução a Requisitos Ceça Moraes cecafac@gmail.com

Conteúdo • Introdução • Engenharia de requisitos • Visão geral • Etapas • Documento de caso de uso Ceça Moraes

Introdução • Geralmente os projetos de software são entregues com atraso, custo acima do estimado e não atendem as necessidades do usuário. • A maioria por falha nos requisitos de sistema • Como abstrair e documentar a necessidade de um usuário para que todos tenham o mesmo entendimento do problema? Ceça Moraes

Introdução • A detecção precoce de erros faz valer a pena Ceça Moraes

Introdução • Triângulo crítico da engenharia de software: Ceça Moraes

Engenharia de Requisitos Visão Geral Ceça Moraes

Engenharia de Requisitos Atividades Ceça Moraes

Engenharia de Requisitos • A Engenharia de Requisitos busca resolver esses impasses através de um conjunto de técnicas de levantamento, análise e documentação de requisitos. Ceça Moraes

Engenharia de Requisitos • Um engenheiro de software deve convencer clientes e usuários de que: • Boas especificações de requisitos são indispensáveis; • Elas não representam custo supérfluos, mas investimentos necessários; • É fundamental a participação dos usuários; • Um boa especificação custa tempo e dinheiro; • A ausência de uma boa especificação custa muito mais tempo e dinheiro Ceça Moraes

Conceitos • Engenharia de Requisitos: Disciplina da engenharia de software responsável por levantar, detalhar, documentar e validar os requisitos de um produto. Ceça Moraes

Conceitos • Stakeholders • Qualquer pessoa afetada de alguma forma pelo sistema Ceça Moraes

Conceitos • Requisito: • Uma condição ou capacidade que um sistema ou componente de sistema deve ter para satisfazer um contrato, padrão, especificação, ou outro documento de formalidade • Descrição das necessidades ou desejos para um produto Ceça Moraes

Conceitos • Requisito: • Define as funções que o sistema deve realizar e as restrições sobre as quais vai operar • Objetivos ou restrições estabelecidas por clientes e usuários que definem as diversas propriedades do sistema Ceça Moraes

Tipos de Requisitos de Software • Requisitos funcionais • Definem as funcionalidades do software • Operações que clientes e usuários querem, ou precisam, que sejam realizadas pelo sistema • Exemplo: • Possibilitar consulta de Saldo e Extrato em Caixas Eletrônicos e pela Internet • Permitir impressão de cheques em Caixas Eletrônicos • Permitir solicitação de entrega de talão cheques pela Internet

Tipos de Requisitos de Software • Requisitos não funcionais • Atuam na limitação da solução • Conhecidos como limitações (no sistema e/ou processo de desenvolvimento) ou requisitos de qualidade • Dizem respeito a: • aspectos de desempenho, • interfaces com o usuário, confiabilidade, • segurança, • manutenibilidade, • portabilidade, • padrões,....

RequisitosExemplos • Sistema de Gestão de uma Biblioteca • O sistema deve manter registros de todos os materiais da biblioteca, incluindo livros, jornais, revistas, vídeo, audio, relatórios, CDs e DVDs. (RF) • O sistema deve permitir os usuário pesquisarem qualquer item por título, autor ou ISBN. (RF) • O sistema deve providenciar uma interface Web (RNF) • O sistema deve suportar pelo menos 20 transações por segundo (RNF) • As principais funcionalidades do sistema, disponíveis para o público, devem poder ser apresentadas em menos de 15 minutos (RNF) Ceça Moraes

Requisitos Não Funcionais – Exemplos

Processo da Engenharia de Requisitos • O processo de engenharia de requisitos pode ser descrito em 5 passos distintos: • Elicitação de Requisitos; • Análise de Requisitos; • Especificação de Requisitos; • Validação de Requisitos; • Gerenciamento de Requisitos. • Esses passos variam muito e dependem do domínio da aplicação, das pessoas envolvidas e da organização. Ceça Moraes

Elicitação de Requisitos • Consiste em: • Descobrir • Explicitar • Obter o máximo de informações para o entendimento do objeto em questão • Refere-se ao processo de extração de informação sobre a(s) funcionalidade(s) requisitada(s) e outras propriedades do sistema • É o primeiro estágio na construção da solução e entendimento do problema (correto e completo!!) que o software deve resolver

Técnicas de Elicitação de Requisitos • Utilizadasparaextrairinformações • Áreadelicada: nem sempre o usuárioconsegueexprimirsuasnecessidades, tarefas, etc. • As técnicassãocomplementares entre si • Entrevistas, reuniões, brainstorm, leitura de documentos, questionários, protótipos • O objetivomaior é extrairinformação, sejaumaououtratécnicasendoutilizada

Levantamento de Requisitos Ceça Moraes

Especificação dos Requisitos • Descrever em detalhes os requisitos do sistema • Exemplo: • O cliente que não está em débito pode alugar até 5 filmes na locadora • Uma especificação pode ser um documento escrito, um modelo gráfico, um modelo matemático formal, uma coleção de cenários, um protótipo, ou qualquer combinação entre eles.

Fatores de Falhas nos Projetos • Objetivosnãoestavamclaros • Ignorar um grupo de clientes • Requisitos e especificaçõesincompletos • Requisitos e especificaçõesinstáveis (mudanças) • Omitir um grupo de requisitos • Permitir inconsistências entre grupos de requisitos • Aceitar requisito inadequado, incorreto, indefinido, ou impreciso • Aceitar um requisito ambíguo e inconsistente

Importância da boa especificação... Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor

Validação de Requisitos • Garantir que todos os requisitos do sistema foram estruturados de maneira não ambígua, sem inconsistências e erros. • Garantir que os produtos de trabalho (ou artefatos) estão em conformidade com os padrões estabelecidos para o processo, para o projeto e para o produto • Podemos usar um check list para examinar as especificações dos requisitos Ceça Moraes

Documento Requisitos

Documento Requisitos • Documento formal usado para registrar/comunicar os requisitos dos/aos stakeholders • Descreve: • Serviços e funções que o sistema deve ter • As restrições nas quais o sistema deve funcionar • Requisitos funcionais e/ou Casos de Uso • Requisitos não funcionais • Definições de outros sistemas, com o qual o sistema deverá comunicar e/ou integrar-se Ceça Moraes

Documento Requisitos • Descreve (continuação): • Informação sobre o domínio de aplicação do sistema • Restrições sobre o(s) processo(s) usado para desenvolver o sistema • Descrição das plataformas computacionais (hardware, redes, ...) • Deve incluir uma introdução com uma visão geral do sistema, as necessidades de negócio que serão atendidas. Ceça Moraes

Use Cases • Um caso de uso é uma seqüência de ações realizada por um sistema que produz um resultadode valor observável para determinado ator/usuário • Realização do requisito Ceça Moraes

Exemplo: Banking • Ator: Cliente • Efetuar login • Alterar senha • Consultar saldo • Consultar extrato • Consultar fatura de cartão de crédito • Pagar fatura de cartão de credito • Realizar transferência • Realizar doc • Verificar talões de cheques • Desbloquear talões de cheques • Solicitar talões de cheques Ceça Moraes

Introdução a Requisitos