Objetivos. Requisitos de Software. Tipos de Requisitos. O que é um requisito? Requisitos Funcionais e Não- Funcionais. Requisitos Funcionais

Transcrição

1 Objetivos de Software Gidevaldo Novais Introduzir os conceitos do usuário e do Descrever requisitos funcionais e nãofuncionais (domínio) Apresentar um esqueleto de documento e notas sobre preenchimento O que é um requisito? Tanto pode ser uma declaração abstrata de alto nível de um serviço ou restrição do quanto uma especificação funcional matemática detalhada Tipos de do Usuário Declarações em linguagem natural com diagramas de serviços que o deve oferecer e suas restrições operacionais. Escrito para os clientes do Sistema Documento estruturado com descrições detalhadas sobre os serviços do. Contrato entre cliente e fornecedor Especificação do Software Descrição detalhada do software que serve como base para projeto ou implementação. Escrito para desenvolvedores Funcionais e Não- Funcionais Funcionais Declarações sobre o que o deve oferecer, como o deve reagir a determinadas entradas e como o deve comportar-se em situações especiais Não-Funcionais Restrições sobre funções ou serviços oferecidas pelo (tempo, processo de desenvolvimento, padrões, etc) de Domínio vindos do domínio da aplicação do e que refletem características desse domínio (funcionais/não-funcionais) Funcionais Descreve funcionalidade e serviços do Depende do tipo do software, usuários esperados e o tipo do onde o software é usado funcionais do usuário devem ser declarações de alto nível sobre o que o deve fazer funcionais do devem descrever os serviços do em detalhes 1

2 Funcionais O usuário poderá pesquisar todo o conjunto inicial de banco de dados ou selecionar um sub-conjunto dele O deve oferecer visualizadores apropriados para o usuário ler documentos armazenados A todo pedido deve ser associado um identificador único, o qual o usuário pode copiar para a área de armazenamento permanente da conta Imprecisão dos Problemas podem surgir quando os requisitos não são estabelecidos precisamente ambíguos podem ser interpretados diferentemente por usuários e desenvolvedores Considere o termo visualizadores apropriados Visualizador de propósito especial para cada tipo de documento diferente (Usuário) Oferecer um visualizador de texto que mostra o conteúdo do documento (Desenvolvedor) Completude e consistência dos Em princípio, requisitos devem ser completos e consistentes Completo Descrições de todos os serviços Consistência Não deve haver conflitos e contradições nas descrições dos serviços Na prática, torna-se impossível produzir um documento completo e consistente Não-Funcionais Definem propriedades e restrições do (tempo, espaço, etc) de processo também podem especificar o uso de determinadas linguagens de programação, método de desenvolvimento não-funcionais podem ser mais críticos que requisitos funcionais. Não satisfaz, inútil. Classificação dos Não-Funcionais do Produto Produto entregue deve comportar-se de forma particular (velocidade de execução, confiabilidade, etc) Organizacionais Conseqüência de políticas e procedimentos organizacionais (padrões de processo usados, requisitos de implementação, etc) Externos Conseqüência de fatores externos ao e ao processo de desenvolvimento (legislação, etc) Não-Funcionais do Produto Toda consulta ao banco de dados baseada em código de barras não deve exceder 5 segundos Organizacionais Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00 Externos O não deve usar informações pessoais do usuário com os operadores do 2

3 de Domínio Derivados do domínio da aplicação e descrevem características do e qualidades que refletem o domínio Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas Se requisitos de domínio não forem satisfeitos, o pode tornar-se não prático de Domínio (Exemplo 1) A desaceleração do trem deve ser computada através da fórmula D trem =D controle +D gradiente onde... de Domínio (Exemplo 2) Deve existir uma interface padrão com o usuário para todos os bancos de dados baseada no padrão ABC-98 Devido a restrições de direitos autorais, alguns documentos devem ser apagados assim que chegam. Dependendo dos requisitos do usuário, tais documentos devem ser impressos em impressora local ou remota. de Domínio (Problemas) Entendimento são descritos na linguagem do domínio da aplicação Não é entendido pelos engenheiros de software que vão desenvolver a aplicação Implícito Especialistas no domínio entendem a área tão bem que não tornam todos os requisitos de domínio explícitos do Usuário Devem descrever requisitos funcionais e não-funcionais de tal forma que sejam entendíveis pelos usuários do que não têm conhecimento técnico detalhado do usuário são definidos usando linguagem natural, tabelas e diagramas Objetivos e não-funcionais podem ser muito difíceis de serem estabelecidos precisamente imprecisos são difíceis de verificar Objetivo Intenção geral do usuário (facilidade de uso) Requisito não-funcional verificável Declaração usando alguma medida que possa ser testada objetivamente Objetivos são úteis aos desenvolvedores, uma vez que eles apresentam as intenções dos usuários do 3

4 Objetivos e Um objetivo do Sistema deve ser fácil de usar por usuários experientes e organizado de forma a minimizar erros do usuário Um requisito não-funcional verificável Usuários experientes devem ser capazes de usar toda a funcionalidade do após 2h de treinamento. Após treinamento, erros não podem ultrapassar 2 por dia Propriedade Velocidade Tamanho Facilidade de uso Confiabilidade Robustez Portabilidade Medidas de Medida Transações processadas/seg Tempo de resposta do usuário/evento K bytes N o de chips de RAM Tempo de treinamento N o de quadros de ajuda Tempo médio de falhas Probabilidade de indisponibilidade Taxa de ocorrência de falhas Tempo de reinício após falha Percentual de eventos causando falhas Probabilidade de corrupção de dados após falha Percentual de declarações dependentes do destino N o de s destino O Processo da Engenharia de Processo da Análise de Estudo de viabilidade Relatório de viabilidade Elicitação de requisitos e análise Modelos do Especificação do usuário e do Validação Documento de requisitos Entrada do processo Definição e especificação Entendimento do domínio Coleta de requisitos Validação dos requisitos Classificação 6 3 Documento 5 4 Atrib. Prioridade Resolução de conflito O Documento de O documento é a declaração oficial do que é requerido dos desenvolvedores do Deve incluir uma definição e uma especificação dos requisitos Deve declarar o que o deve fazer e não como Guias para Escrever Adote um formato padrão e use-o para todos os requisitos Use linguagem consistentemente. Use deverá para requisitos obrigatórios e deveria para os desejáveis Use texto em negrito para identificar partes chave dos requisitos Evite jargão de computação 4

5 do Sistema Especificações mais detalhadas dos requisitos do usuário Serve de base para projetar o Pode ser usado como parte do contrato do Geralmente expressos usando modelos do UML Alternativas para Especificação Notação Linguagem natural estruturada Linguagem de descrição de projeto Notações gráficas Especificações Formais Descrição Depende de formulários padrão Linguagem semelhante a ling. prog. mas com recursos abstratos para especificar requisitos Ling. gráfica com anotações de texto (Use-cases de UML) Ling. com sintaxe e semântica bem-definidas (OBJ, Z, CSP, LOTOS, Redes de Petri) UML (Use-Case) Estrutura de um Documento de Usuário da biblioteca Serviços de empréstimo Administração do usuário Funcionário da biblioteca Introdução Glossário Definição dos do Usuário Especificação dos do Sistema Modelos do Sistema Evolução do Sistema Apêndices Índice Fornecedor Serviços de catálogo Bibliografia Sommerville, I. Software Engineering (Caps. 5 e 6) 5