Fundamentos da Engenharia de Software: Engenharia de Requisitos

Fundamentos da Engenharia de Software Engenharia de Requisitos O que é um Requisito Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as suas diversas propriedades Condição ou capacidade necessária que o software deve possuir para que o usuário possa resolver um problema ou atingir um objetivo para atender as necessidades ou restrições da organização ou de outros componentes do sistema Visão dos Requisitos Vai desde uma declaração abstrata até uma descrição formal Requisitos de usuário Linguagem natural com diagramas dos serviços esperados e restrições sob as quais ele deve operar Requisitos de sistema Definem detalhadamente funções serviços e restrições do sistemas Também chamado de especificação funcional define exatamente o que será implementado Descrição dos Requisitos Sistema LIBSYS Um sistema de biblioteca que fornece uma interface única para uma série de banco de dados de artigos em bibliotecas diferentes Os usuários podem pesquisar baixar e imprimir estes artigos para estudo pessoal Descrição dos Requisitos Classificação dos Requisitos Podem ser divididos em Funcionais Nãofuncionais De domínio Requisitos Funcionais Requisitos Funcionais RF Especificação dos serviços que o sistema deve prover como o sistema deve reagir a certas entradas como deveria ser o comportamento do sistema em certas situações Deve determinar o que se espera que o software faça sem a preocupação de como ele faz Requisitos funcionais do usuário podem ser de alto nível porém os requisitos funcionais do sistema devem ser especificados em detalhes Requisitos Funcionais Exemplo Sistema LIBSYS O usuário deve ser capaz de fazer uma busca em todo o conjunto inicial do banco de dados ou selecionar um conjunto com base nele O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos Para cada pedido deve ser alocado um único identificador ORDERID o qual o usuário deve ser capaz de copiar para a área de armazenamento permanente da conta Requisitos Funcionais Os requisitos devem ter Completeza Eles devem incluir descrições de todos os recursos requeridos Consistência Não deve haver conflitos ou contradições nas descrições dos recursos de sistema É impossível produzir um documento de requisitos completo e consistente A própria natureza grande e complexa do sistema irá induzir a erros Diferentes Stakeholders tem diferentes necessidades Requisitos NãoFuncionais Restrições aos serviços ou funções oferecidas pelo sistema Incluem restrição de tempo processo de desenvolvimento e padrões Em geral se aplicam ao sistema como um todo Requisitos NãoFuncionais Requisitos do Produto Produto entregue deve comportarse de forma particular velocidade de execução confiabilidade etc Requisitos Organizacionais Consequência de políticas e procedimentos organizacionais padrões de processo usados requisitos de implementação etc Requisitos Externos Consequência de fatores externos ao sistema e ao processo de desenvolvimento legislação etc Tipos de Requisitos NãoFuncionais Exemplos de Requisitos NãoFuncionais Requisitos de Domínio Derivados do domínio de aplicação e descrevem características de sistema que refletem o domínio Podem restringir os requisitos funcionais existentes ou estabelecer como cálculos específicos devem ser realizados Se os requisitos de domínio não forem satisfeitos o sistema pode não funcionar Exemplo de Requisitos de Domínio Deve existir uma interface de usuário padrão para todos os bancos de dados que será baseada no padrão Z3950 Devido às restrições de direitos autorais alguns documentos devem ser excluídos imediatamente na chegada Dependendo dos requisitos de usuário esses documentos serão impressos localmente no servidor de sistema para serem encaminhados manualmente para o usuário ou direcionados para uma impressora de rede Documento de Requisitos de Software Documento de Especificação de Requisitos O documento de requisitos do software deve ser composto por sentenças em linguagem natural seguindo determinados padrões 1 Use deve para requisitos obrigatórios e deveria para requisitos desejáveis Exemplo O sistema deve rodar em microcomputadores da linha IBM PC que possuam microprocessador 486 DX ou superior 2 Os requisitos devem estar organizados logicamente como por exemplo inicialmente todos os requisitos de entrada depois os de processamento e por último os requisitos de saída Documento de Especificação de Requisitos O documento de requisitos do software deve ser composto por sentenças em linguagem natural seguindo determinados padrões 1 Cada requisito deve ter um identificador único por exemplo um identificador numérico para posterior referência 2 Os requisitos do software devem estar divididos em requisitos funcionais e não funcionais de qualidade 3 Evitar o uso de jargões de computação Formato da Especificação de Requisitos Existem vários padrões de especificações de requisitos Um exemplo I Visão Geral do Sistema II Requisitos Funcionais III Requisitos NãoFuncionais IV Apêndice Padrão IEEEANSI 8301998 A Especificação pode ser acompanhada de um PROTÓTIPO executável ou em papel Formato sugerido pelo padrão IEEE 1 Introdução 1 Propósito do documento de requisitos 2 Escopo do produto 3 Definições acrônimos e abreviaturas 4 Referências 5 Visão geral do restante do documento 2 Descrição Geral 1 Perspectiva do produto 2 Funções do produto 3 Características dos usuários 4 Restrições gerais 5 Suposições de dependências 3 Requisitos específicos requisitos funcionais e nãofuncionais 4 Apêndices 5 Índice Problemas com especificação em linguagem natural Ambiguidade Os leitores e os escritores dos requisitos devem interpretar as mesmas palavras da mesma maneira Linguagem natural é naturalmente ambígua por isso muito difícil Flexibilidade excessiva A mesma coisa pode ser dita de várias maneiras diferentes na especificação Falta de modularização Estruturas de linguagem natural são inadequadas para estruturar requisitos de sistema Especificação baseada em formulário Processo de Engenharia de Requisitos Engenharia de Requisitos ATORES cliente e desenvolvedor PROBLEMA grande propensão a mal entendidos atividade aparentemente simples tornase complexa O Processo de Engenharia de Requisitos Engenharia de Requisitos Quatro fases Estudo de viabilidade entendimento do negócio e como o sistema pretende apoiar os processos de negócio Elicitação e análise de requisitos Validação dos requisitos Gerenciamento dos Requisitos Resultado DOCUMENTO DE REQUISITOS Estudo de viabilidade Um estudo de viabilidade decide se vale a pena ou não gastar tempo e esforço com sistema proposto É um estudo breve e focalizado que verifica Se o sistema contribui para os objetivos da organização Se o sistema pode ser implementado usando tecnologia atual e dentro do orçamento Se o sistema pode ser integrado a outros Engenharia de Requisitos Quatro fases Estudo de viabilidade Elicitação e análise de requisitos reunir informações sobre o sistema proposto e os existentes Fonte documentos organização especificações existentes observações entrevistas Validação dos requisitos Gerenciamento dos Requisitos Elicitação e Análise de requisitos Engenheiros de software clientes e usuários finais do sistema e outros envolvidos stakeholders trabalham para aprender Sobre o domínio da aplicação Quais serviçosfuncionalidades o sistema deve fornecer O desempenho esperado As restrições de hardware do ambiente do negócio Elicitação e Análise de requisitos Dificuldades Stakeholders não sabem o que querem do sistema e não expressam o que querem Stakeholders expressam requisitos naturalmente usando seus próprios termos domínio Diferentes stakeholders têm diferentes requisitos Fatores políticos podem influenciar mais poder para um gerente Ambiente dinâmico muda constantemente Novos requisitos podem surgir de novos stakeholders Elicitação e Análise de requisitos Processo interativo com realimentação contínua cíclico Atividades Obtenção de requisitos coleta de dados Classificação e organização de requisitos Priorização e negociação de requisitos Documentação de requisitos Obtenção dos requisitos Processo que reúne informações sobre o sistema proposto e os existentes para obter os requisitos de usuário e de sistema Fontes documentação stakeholders especificações de sistemas similares Resultados cenários protótipos modelos estruturados Obtenção dos requisitos Stakeholders para um sistema bancário Clientes atuais do banco Representantes de outros bancos acordos para integração entre sistemas Gerentes de agências gerenciamento do sistema Pessoal de atendimento nas agências envolvidas Administradores de banco de dados Gerentes de proteção bancária segurança Departamento de marketing Engenheiros de manutenção de hardware e software Reguladores de bancos conformidade com as leis Obtenção dos requisitos Técnicas Entrevistas Observações etnografia Questionários Reuniões de grupo Análise de sistemas similares Cenários exemplos reais de como um sistema pode ser usado Casos de Uso técnica baseada em cenários que identificam os agentes em uma interação e que descrevem a interação em si Cenário do LIBSYS Casos de uso do LIBSYS Engenharia de Requisitos Quatro fases Estudo de viabilidade Elicitação e análise de requisitos Validação dos requisitos mostrar que os requisitos realmente representam o sistema que o usuário deseja descobrir problemas revisão dos requisitos envolve clientes e desenvolvedores Gerenciamento dos Requisitos Validação de requisitos Dedicase a mostrar que os requisitos definem o sistema que o cliente realmente deseja Custos de erros de requisitos são altos e desse modo a validação é muito importante O custo da reparação de um erro de requisitos depois da entrega pode equivaler a 100 vezes o custo de reparação de um erro de implementação Verificação de requisitos Verificação de validade O sistema fornece as funções que melhor apoiam as necessidades do cliente Verificação de consistência Existe algum tipo de conflito de requisitos Verificação de completeza Todas as funções requisitadas pelo cliente foram incluídas Verificação de realismo Os requisitos podem ser implementados com o orçamento e a tecnologia disponíveis Facilidade de verificação Os requisitos podem ser verificados Técnicas de validação de requisitos Revisões de requisitos Análise manual sistemática dos requisitos Prototipação Uso de um modelo executável do sistema para verificar requisitos Geração de casos de teste Desenvolvimento de testes para requisitos a fim de verificar a testabilidade Revisões de requisitos Revisões regulares devem ser feitas enquanto a definição de requisitos está sendo formulada Ambos cliente e fornecedor devem ser envolvidos nas revisões Revisões podem ser formais com documentos completos ou informais Uma boa comunicação entre desenvolvedores clientes e usuários pode resolver problemas nos estágios iniciais Engenharia de Requisitos Quatro fases Estudo de viabilidade Elicitação e análise de requisitos Validação dos requisitos Gerenciamento dos Requisitos compreender e controlar as mudanças dos requisitos avaliar os impactos das mudanças Usuários muitas vezes mudam os requisitos ou não sabem o que querem Gerenciamento de requisitos Gerenciamento de requisitos é o processo de gerenciamento de mudanças de requisitos durante o processo de engenharia de requisitos e o desenvolvimento de sistema Requisitos são inevitavelmente incompletos e inconsistentes Novos requisitos surgem durante o processo à medida que as necessidades de negócio mudam e uma melhor compreensão do sistema é desenvolvida Os diferentes pontos de vista têm requisitos diferentes e estes são frequentemente contraditórios Mudança de requisitos A priorização dos requisitos em consequência das mudanças de pontos de vista durante o processo de desenvolvimento Os clientes do sistema podem especificar os requisitos a partir de uma perspectiva de negócio que conflitam com os requisitos do usuário final Os ambientes técnico e de negócio do sistema mudam durante seu desenvolvimento Planejamento de gerenciamento de requisitos Durante o processo de engenharia de requisitos você tem de planejar A Identificação de requisitos Como os requisitos são identificados individualmente O processo de gerenciamento de mudanças É o processo seguido quando da análise de uma mudança de requisitos Políticas de rastreabilidade É a quantidade de informações que é mantida sobre os relacionamentos de requisitos Apoio de ferramenta CASE O apoio de ferramenta requisitada para auxiliar no gerenciamento das mudanças requisitos Rastreabilidade A rastreabilidade está relacionada aos relacionamentos entre os requisitos suas fontes e o projeto de sistema Rastreabilidade da fonte Ligam os requisitos aos stakeholders que propuseram os requisitos Rastreabilidade de requisitos É a ligação dos requisitos dependentes Rastreabilidade de projeto Ligam os requisitos aos módulos de projeto Uma matriz de rastreabilidade D requisito da linha depende do requisito da coluna R existe algum relacionamento entre os requisitos Fundamentos da Engenharia de Software Engenharia de Requisitos