ENGENHARIA DE REQUISITOS

Transcrição

1 Universidade Federal de Santa Maria Mestrado em Computação ELC 923 Processos de Negócio e Engenharia de Requisitos Especialização em Modelagem e Desenvolvimento de Aplicações Web com JAVA ENGENHARIA DE REQUISITOS Profa. Rosana Wagner Adaptado do material de Lisandra M. Fontoura

2 Roteiro Introdução Requisitos de Software Funcionais Não funcionais De usuário De sistema Especificação de interface Documentação de requisitos Processos de Engenharia de Requisitos Estudos de viabilidade Elicitação e análise de requisitos Validação de requisitos Gerenciamento de requisitos Bibliografia

3 Introdução Roberto quer modernizar sua empresa. Ele tem uma agência de turismo. Ele não tem uma equipe de desenvolvedores, então ele decide contratar uma empresa para fazer o sistema para ele. Ele diz: Eu preciso de um website onde os clientes possam ver nossas ofertas e onde eles possam reservar e pagar online.também quero oferecer um serviço de luxo que inclua viagem de e para o hotel/aeroporto e acomodação.

4 Introdução Sua tarefa é analisar o que Roberto disse e construir os requisitos iniciais. A grosso modo... Requisito é algo que o software deve fazer.

5 Introdução Requisito #1 Título: mostrar ofertas Descrição: O site deve mostrar ofertas aos clientes da agência. Requisito #2 Título: reservar oferta Descrição: O site deve permitir que os clientes possam reservar ofertas. Requisito #3 Título: reservar pacotes especiais Descrição: O site deve permitir que os clientes consigam reservar pacotes e adicionar serviços extras. Requisito #4 Título: reservar transporte Descrição: O site deve permitir ao cliente reservar transporte do hotel ao aeroporto e vice-versa. Requisito #5 Título: reservar hotel Descrição:...

6 Introdução Agora é só programar! Parece fácil, não é?

7 Introdução

8 Mas o que são requisitos afinal? Requisitos de um sistema são descrições dos serviços fornecidos e as suas restrições operacionais (SOMMERVILLE). Eles refletem a necessidade dos clientes.

9 Engenharia de Requisitos Ajuda os engenheiros de SW melhor entender o problema que eles vão trabalhar para resolver. Quem faz? Engenheiros de SW e demais stakholders (clientes, gerentes, usuários finais) Por que é importante? Não adianta fazer um SW que não atenda as necessidades!! Qual é o produto do trabalho? Fornecer a todas as partes um entendimento escrito do problema.

10 Importância da Engenharia de Requisitos (fonte: "Software Testing", Ron Patton)

11 Classificação de Requisitos Quanto ao nível de detalhamento Requisitos de sistema Funcionais Não Funcionais De Domínio Requisitos de usuário Especificação do projeto de software

12 Requisitos Funcionais São as declarações de serviços que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como o sistema deve se comportar em determinadas situações. Também podem estabelecer o que o sistema não deve fazer. Resumindo: descrevem o que o sistema deve fazer!

13 Requisitos Funcionais - Exemplos "O software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal"; "O software deve emitir relatórios de compras a cada quinze dias"; "Os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo.

14 Requisitos não funcionais São aqueles não diretamente relacionados às funções específicas fornecidas pelo sistema. Geralmente vinculados às propriedades emergentes do sistema (confiabilidade, tempo de resposta e espaço de armazenamento). Esses requisitos especificam ou restringem as propriedades emergentes do sistema.

15 Requisitos não funcionais - Exemplos "A base de dados deve ser protegida para acesso apenas de usuários autorizados". "O tempo de resposta do sistema não deve ultrapassar 30 segundo". "O software deve ser operacionalizado no sistema Linux". "O tempo de desenvolvimento não deve ultrapassar seis meses".

16 Tipos de requisitos não funcionais Requisitos de produto Especificam o comportamento do produto. Ex: requisitos de desempenho quanto à rapidez com que o sistema deve operar e quanto de memória ele requer, tolerância à falhas, portabilidade e usabilidade. Requisitos organizacionais Derivados de políticas e procedimentos da organização do cliente e do desenvolvedor. Ex: padrões de processo a serem usados, linguagem de programação, método de projeto, documentação. Requisitos externos Derivados de fatores externos ao sistema e ao seu processo de desenvolvimento. Ex: requisitos de interoperabilidade (como o sistema interage com outros sistemas de outras organizações), requisitos legais e éticos.

17 Requisitos não funcionais Detalhes importantes Podem ser mais importantes que os funcionais; São difíceis de verificar (clientes raramente os vêem como metas gerais); Requisitos ambíguos serão interpretados pelos programadores de modo a simplificar a implementação; Alguns requisitos são difíceis de traduzir em metas (Ex: manutenibilidade); Requisitos não funcionais podem entrar em conflito com requisitos funcionais (sistema em tempo real e tamanho);

18 Requisitos de usuário Descrevem requisitos funcionais e não funcionais, de modo que os usuários que não possuem conhecimento técnico possam entender; Devem especificar o comportamento do sistema e evitar, sempre que possível, características de projeto do sitema; Cuidar jargões de software, notações formais... Utilizar linguagem simples, tabelas, formulários e diagramas intuitivos; Problemas comuns: falta de clareza, confusão de requisitos, fusão de requisitos;

19 Requisitos de usuário Exemplo O sistema deve fornecer um módulo de contabilidade financeira que mantenha registros de todos os pagamentos realizados pelos usuários do sistema. Os gerentes podem configurar esse módulo de forma que os usuários frequentes possam receber descontos.

20 Requisitos de Sistema São versões expandidas dos requisitos de usuário usados pelos engenheiros de software como ponto de partida para o projeto de sistema. Eles adicionam detalhes e explicam como os requisitos de usuário devem ser fornecidos pelo sistema. Não deveriam estar relacionados como o sistema pode ser implementado (mas na prática é muito difícil excluir essas informações, dado o nível de detalhamento necessário em um sistema complexo).

21 Especificação de requisitos do sistema Formulário Padrão Descrição da função/entidade Descrição das entradas e de onde elas são provenientes Descrição das saídas e para onde elas irão Indicações de quais outras entidades são usadas Descrição da ação a ser tomada Pré-condição e pós-condição (para abordagens funcionais) Descrição dos efeitos colaterais da operação

22 Ex: Software de controle bomba de insulina Função: Calcular a dose de insulina, nível seguro de açúcar Descrição: Calcula a dose de insulina a ser liberada quando o nível medido de açúcar atual está na zona segura entre 3 e 7 unidades. Entradas: Leitura atual do açúcar (r2), as duas leituras anteriores (r0, r1) Saídas: CompDose a dose de insulina a ser liberada Destino: Loop de controle principal Ação: CompDose será zero se o nível de açúcar estiver estável ou em queda, ou se o nível de açúcar estiver aumentando mas a taxa de aumento estiver diminuindo. Se o nível de açúcar...

23 Ex: Software de controle bomba de insulina Requer: Duas leituras anteriores de modo que a taxa de mudança do nível de açúcar possa ser calculada Pré-condição: O reservatório de insulina deve conter, pelo menos, o máximo de dose única permitida de insulina (o que acontece se não for satisfeita?) Pós-condição: r0 é substituído por r1 e r1 é substituído por r2 Efeitos colaterais: nenhum

24 Especificação de interface Quase todos os sistemas de software devem operar com sistemas existentes já implementados e instalados em um ambiente; Essas interfaces devem ser especificadas com precisão; Devem ser definidas no início do processo; Devem ser incluídas no documento de requisitos; Tipos de interface De procedimentos: APIs Estruturas de dados que são passadas de um subsistema para outro; Representações de dados estabelecidas previamente.

25 Documento de requisitos de software Também conhecido como SRS (Software Requirements Specification); Declaração oficial do que os desenvolvedores devem implementar; Possui os requisitos de usuário e de sistemas; Possui um conjunto diversificado de usuários

26 Usuários de um documento de requisitos

27 Padrão IEEE Documentos de requisitos Introdução Propósito do documento Escopo do produto Definições, acrônimos e abreviaturas Referências Visão geral do restante do documento Descrição Geral Perspectiva do produto Funções do produto Características dos usuários Restrições gerais Suposições e dependências Requisitos Específicos Abrangem requisitos funcionais, não funcionais e de interface. Não há uma estrutura padrão para essa parte. Apêndices Índice

28 Características dos Requisitos Para assegurar que os requisitos estão entendidos de maneira apropriada, é importante verificar se eles têm as seguintes características: Os requisitos estão corretos? (foram definidos sem erros) Os requisitos são consistentes? (não-ambíguos e não-conflitantes) Os requisitos estão completos? (conjunto completo de requisitos) Os requisitos são realistas? (é possível fazer o que o cliente pede) Cada requisito descreve algo que é necessário para o cliente? Os requisitos podem ser verificados? Os requisitos podem ser rastreados?

29 Processos de engenharia de requisitos Etapas [PRESSMAN] Concepção, Levantamento, Elaboração Negociação Especificação Validação, Gestão. Etapas [SOMMERVILLE] Estudo de viabilidade; Obtenção de requisitos (elicitação e análise); Especificação de requisitos; Validação de requisitos; Gerenciamento de Requisitos.

30 Etapas do processo

31 Etapas do processo

32 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. Muitas vezes as empresas desenvolvem sistemas que não contribuem para os seus objetivos pois elas não têm um perfil claro desses objetivos. O que faria se o sistema não fosse implementado? Quais são os problemas com processo atuais? Como o sistema proposto ajudará?...

33 Elicitação e análise de requisitos Envolve pessoal técnico trabalhando com os clientes para descobrir sobre o domínio de aplicação, os serviços que o sistema deve fornecer e sobre as restrições operacionais. Por que esse processo é tão difícil? Stakeholders não sabem o que eles realmente querem. Stakeholders expressam requisitos em seus próprios termos. Diferentes stakeholders podem ter requisitos conflitantes. Fatores organizacionais e políticos podem influenciar os requisitos de sistema. A mudança de requisitos durante o processo de análise. Novos stakeholders podem surgir e o ambiente de negócio muda.

34 Processo de elicitação e análise Processo iterativo e contínuo!

35 Processo de elicitação e análise - Etapas Obtenção de requisitos Interação com os stakeholders para coletar seus requisitos. Classificação e organização de requisitos Agrupa requisitos relacionados e organiza-os em conjuntos coerentes. Priorização e negociação de requisitos Priorização de requisitos e resolução de conflitos de requisitos. Documentação de requisitos Os requisitos são documentados e colocados na próxima volta da espiral.

36 Especificação de Requisitos Pode ser um documento escrito, modelo, diagrama, cenários de uso, prototipação, entre outros; Ou uma combinação de um conjunto desses elementos. Especificação é o produto final produzido pelos engenheiros de requisitos.

37 Validação de Requisitos Dedica-se 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: A 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.

38 Verificação de Requisitos Verificação de validade: O sistema fornece as funções que melhor apóiam 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?

39 Validação de Requisitos - Revisões de Requisitos Processo manual que envolve os stakeholders (verificação do documento em busca de anomalias e omissões); Revisores podem verificar: Facilidade de verificação (requisito é testável de forma realista?) Facilidade de compreensão (stakeholders compreendem de forma adequada?) Rastreabilidade (origem do requisito está claramente estabelecida?) Adaptabilidade (requisito pode ser mudado sem grandes efeitos?) Conflitos, contradições e omissões devem ser registrados formalmente num relatório de revisão.

40 Gerenciamento de Requisitos O que é? Processo de gerenciamento de mudanças de requisitos durante o processo de engenharia de requisitos e o desenvolvimento de sistema. Evolução de requisitos

41 Gerenciamento de Requisitos Processo pra compreender e controlar a mudança dos requisitos de sistema; Necessário manter acompanhamento dos requisitos individuais e manter as ligações entre os requisitos dependentes, de modo que seja possível avaliar o impacto das mudanças de requisitos; Requisitos permanentes: relativamente estáveis, se relacionam diretamente com o domínio de aplicação do sistema; Requisitos voláteis: provavelmente irão mudar durante o processo do desenvolvimento ou depois de instalado;

42 Gerenciamento de Requisitos Classificação de requisitos voláteis

43 Gerenciamento de Requisitos Planejamento 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.

44 Gerenciamento de Requisitos Planejamento: Rastreabilidade A rastreabilidade está relacionada aos relacionamentos entre os requisitos, suas fontes e o projeto de sistema. Tipos de informações de rastreabilidade: 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.

45 Gerenciamento de Requisitos Gerenciamento de Mudanças Deve ser aplicado à todas as mudanças propostas aos requisitos. Estágios principais: Análise de problema: discutir problemas e mudanças de requisitos; Análise de mudança e estimativa de custo: avaliar os efeitos das mudanças sobre outros requisitos; Implementação de mudança: Modificar documentos de requisitos e outros documentos para refletir as mudanças.

46 Tópicos considerados Introdução: O que é requisitos, eng. de requisitos, para que serve, quem faz? Requisitos de Software Funcionais, Não funcionais, De usuário, De sistema; Especificação de interface Documentação de requisitos Processos de Engenharia de Requisitos Estudos de viabilidade (O que é, para que serve) Elicitação e análise de requisitos: Obtenção (stakeholders, pontos de vista, entrevista, cenários, casos de usos), Etnografia Validação de requisitos (verificação e revisões de requisitos) Gerenciamento de requisitos (o que é, planejamento, rastreabilidade e gerenciamento de mudanças)

47 Bibliografia SOMMERVILLE, I. Engenharia de Software, 8 edição. São Paulo: Pearson Addison-Wesley, PRESSMAN, R. Engenharia de Software, 6 edição. São Paulo: McGraw-Hill, MILES, R. e PILONE, D. Head First Sofware Development. O'Reilly. Requirements Definition: Bringing Software Requirements to Life: The Problem with Software Definition: related