Engenharia de Software

Transcrição

1 Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed.

2 REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São declarações, em linguagem natural, sobre os serviços esperados pelo sistema e restrições. REQUISITOS DE SISTEMA: Definem detalhadamente as funções, serviços e restriçõeoperacionais.

3 Exemplo Didático: REQUISITOS DE USUÁRIO: O sistema deve manter a temperatura em 20 graus. REQUISITOS DO SISTEMA: O sistema deve verificar a temperatura ambiente a cada 1 minuto; Se a temperatura estiver acima de 20 graus, ligar o ar-condicionado; Se a temperatura estiver abaixo de 20 graus, ligar o aquecedor;

4 A quem interessa os requisitos: Requisitos de Usuários: Clientes, Arquitetos do sistema.» Ideal para especificar uma necessidade. Requisitos de Sistemas: Usuários finais, Arquitetos de sistemas, Desenvolvedores de software.» Ideal para especificar uma proposta de sistema.

5 Requisitos de Sistema: Normalmente podem ser classificados como: Requisitos Funcionais: Declarações de serviços que o sistema pode oferecer, como ele pode reagir e como se comportar. Requisitos Não-Funcionais: São restrições ao serviço ou funções oferecidas ao sistema. Requisitos de domínio: São requisitos provenientes do domínio da aplicação.

6 Requisitos Funcionais: Descrevem o que o software deve fazer. Ex.: - O usuário pode alterar o valor da temperatura média do sistema. Problemas: 1. Imprecisão; 2. Ambigüidade; 3. Má especificação (não ficou claro).

7 Requisitos Não-Funcionais: São restrições a funcionalidades do software. Ex.: - O sistema deve registrar a nova temperatura e adequar-se a ela no tempo máximo de 5 minutos. Problemas: 1. Não estão ligadas a características individuais do sistema; 2. Podem ser mais importantes que os requisitos de sistema; 3. Podem anular um sistema; 4. Podem restringir o processo de desenvolvimento de um software; 5. Originam-se de diversas fontes, como: Orçamento, politicas organizacionais, necessidade de interoperabilidade...

8 Requisitos Não-Funcionais: Podem ser classificados como: Requisitos de produtos: Desempenho, confiabilidade, portabilidade, usabilidade. Requisitos Organizacionais: Padrões de processos, implementação, prazos. Requisitos Externos: Interoperabilidade, legais, éticos. As vezes é de difícil verificação e vagos(ex. tempo de resposta) Sempre devem ser escritos de forma quantitativa. Ex.: Velocidade (tempo de resposta), Tamanho (KB), confiabilidade (média de falhas)...

9 Requisitos de Domínio: São derivados do domínio da aplicação em vez de necessidades específicas dos usuários do sistema. Fazem referências a conceitos do domínio. Podem restringir os requisitos funcionais ou estabelecer cálculos específicos a serem realizados. Ex.: Normas específicas do domínio, cálculos específicos...

10 Requisitos de Usuário: Descrevem os requisitos funcionais e não funcionais do sistema. São redigidos em linguagem natural em forma de texto ou gráficos. Falta de clareza Confusão de requisitos Fusão de requisitos Muitas informações (Restrição da liberdade de desenvolvimento) Ideal que: Estejam em um formato padrão; Com uma escrita consistente; Partes importantes do texto destacadas;

11 Requisitos de Sistema: São Versões expandidas dos requisitos de usuário. Devem descrever simplesmente o comportamento do sistema e suas restrições operacionais. Pode ser escritos em linguagem natural : Pode causar ambigüidade na interpretação; Muito flexível; Difícil padronização. Ideal que sejam escritas em: Linguagem estruturada; Linguagem de descrição de projetos; Notações gráficas; Especificações matemáticas.

12 Requisitos de Sistema Linguagens Estruturadas: É uma forma de escrever requisitos em linguagem natural. Faz uso de formulário padrão (templates). Deve descrever: Descrição da função ou entidade padrão; Descrição das entradas e saídas; Indicações de uso de outras partes do sistema; Descrição das ações a serem tomadas; Pré-condição e pós-condição; Descrição de efeitos colaterais, caso existam.

13 Exemplo de especificação de requisitos com formulário padrão Função: Descrição: Monitoramento da temperatura Monitorar a temperatura ambiente a cada 1 minuto A temperatura deve estar no valor padrão do sistema Entradas: Valor padrão temperatura( ), Valor da temperatura (). Origem: Saídas: Destino: Ação: Sistema (Valor padrão temperatura), Sensor temperatura (Valor da temperatura) Ajuste ar-condicionado(), Ajuste aquecedor(). Ar-condicionado, Aquecedor. Caso a temperatura esteja abaixo do valor padrão da temperatura, o aquecedor deve ser ligado com para a adequação da temperatura e receberá um valor X para sua potência. Caso a temperatura esteja acima do valor padrão de temperatura o ar-condicionado deve ser ligado, recebendo um valor Y para sua potência. Os valores devem ser re-calculados a cada 1 minuto, para re-calculo dos valores fornecidos, com o prazo máximo de adequação da temperatura em 5 minutos.

14 Especificação de Interfaces: São usadas para permitirem que novos sistemas se adéquem a outros sistemas. Devem ser especificadas em apêndices no documento de requisitos. Podem ser: Interfaces de Procedimento ( Sistema possui API s) Estruturas de dados (Ex. SGBD) Estrutura de dados com ordenação de bit s (Comum em sistemas de tempo real). Para essas especificações deve ser utilizado modelos formais e diagramas.

15 Documento de Requisitos: É a declaração oficial dos requisitos que serão implementados pelo sistema. Deve incluir os requisitos de usuário e os requisitos do sistema (detalhados). Modelo IEEE/ANSI sugere a seguinte estrutura para o documento:

16 1 Introdução 1.1 Propósito do documento de requisitos; 1.2 Escopo do produto; 1.3 Definições, Acrônimos e Abreviaturas; 1.4 Referências; 1.5 Visão geral do restante do documento. 2 Descrição geral 2.1 Perspectiva do produto; 2.2 Funções do produto; 2.3 Característica dos usuários; 2.4 Restrições gerais; 2.5 Suposições e dependências. 3 Requisitos específicos 4 Apêndice 5 Índice Ver documento exemplo (Volere)!

17 Possíveis usuários do documento de requisitos:

18 ENGENHARIA DE REQUISITOS O Objetivo geral da engenharia de requisitos e criar e manter o documento de requisitos do sistema. É composto por 4 sub-processos de alto nível: 1. Estudo de viabilidade; 2. Elicitação e análise; 3. Especificação; 4. Validação.

19 Estudo de Viabilidade Elicitação e análise de requisitos Especificação de requisitos Relatório de Viabilidade Modelos de Sistema Requisitos de usuários e sistema Validação de requisitos

20 Estudo de viabilidade: Estudo preliminar que apontará se vale apena os não o desenvolvimento do sistema. É necessário o levantamento inicial dos requisitos. Deve responder as seguintes questões: 1. O sistema contribuirá para os objetivos da organização? 2. O sistema poderá ser implementado com tecnologia atual no prazo e custo desejado? 3. O sistema poderá ser integrado a outros

21 Elicitação e análise dos requisitos: Os engenheiros de software trabalham com os stakeholders para aprender o domínio da aplicação e os serviços que o sistema deverá fornecer. O processo de elicitação é dificil por razões como: Os stakeholders normalmente não sabem o que querem do sistema; Os requisitos serão expressos naturalmente, com conhecimento necessário implícito;

22 Elicitação Obtenção dos requisitos: É o processo que reúne informações sobre o sistema a ser proposto. Podem ser provenientes de documentos, análise do domínio do problema, stakeholders ou especificações de sistemas similares. Podem ser provenientes de: Pontos de Vista (Interação, Indiretos e de domínio) Refere-se a como stakeholders vêem o sistema Entrevistas (Fechadas ou abertas) Cenários (Forma de interagir com o sistema) Casos de Uso (Atores e casos de uso) Etnográfia (Observações)

23 Validação de Requisitos: Processo que dedica-se a mostrar que os requisitos realmente definem o sistema que o usuário deseja. Pode-se validar os requisitos pelas seguintes técnicas: Revisões de requisitos; Facilidade de verificação (testável); Facilidade de compreensão; Rastreabilidade ; Adaptabilidade (Mudança). Prototipação; Geração de casos de testes.

24 Gerenciamento de Requisitos: Os requisitos de sistemas grandes estão em constantes mudanças. Sistemas grandes possuem vários usuários, com diferentes requisitos e prioridades; Requisitos impostos devido a restrições organizacionais; Mudanças no ambiente. Mesmo o sistema pronto, pode haver mudanças nos requisitos. A mudança deve ser controlada.

25 Gerenciamento de Requisitos: Requisitos Permanentes Requisitos estáveis, normalmente são referentes a atividade central da organização e se relacionam diretamente ao domínio da aplicação. Requisitos Voláteis Requisitos que poderão mudar durante o processo de desenvolvimento ou após a entrega do sistema.

26 Planejamento de Gerenciamento de Requisitos: Estabelece o nível de detalhamento necessário para o gerenciamento de requisitos. Durante o estágio de gerenciamento de requisitos é necessário decidir sobre: Identificação dos requisitos (únicos) Processo de gerenciamento de mudanças (viabilidade) Política de rastreabilidade (relacionamento entre requisitos)

27 Planejamento de Gerenciamento de Requisitos: A Rastreabilidade é a propriedade de uma especificação de requisitos que reflete a facilidade de encontrar requisitos relacionados. Podem informar sobre: Origem (Requisitos aos stakeholders); Requisitos (Ligam aos requisitos dependentes); Projeto (ligam a módulos de projetos implementados).

28 Planejamento de Gerenciamento de Requisitos: As ferramentas case podem: Armazenar requisitos; Gerenciar mudanças; Facilitarem a rastreabilidade. Exemplos: RequisitePro e DOOR.

29 Planejamento de Gerenciamento de Requisitos: O gerenciamento de mudanças de requisitos deve ser aplicado a todas as mudanças propostas aos requisitos. Pode seguir o seguinte fluxo: Análise do problema e especificação da mudança; Análise da mudança e estimativa de custos; Implementação da mudança.

30 FIM...» Dúvidas, comentários??? Bom dia a Todos!