Requisitos de Software



Documentos relacionados
Requisitos de Software

Engenharia de Software

Requisitos de Software

Análise de sistemas. Engenharia de Requisitos

T écnicas de Obtenção de Requisitos

MODELAGEM DE SISTEMA Apresentação

Engenharia de Software Aula 2.1 Introdução à Engenharia de Requisitos. Prof. Bruno Moreno

Proporcionar a modelagem de sistemas utilizando todos os conceitos da orientação a objeto;

Processo de Desenvolvimento de Software

1.1. Definição do Problema

Engenharia de Software.

Qualidade de Produto. Maria Cláudia F. P. Emer

Introdução. Qualidade de Produto. Introdução. Introdução ISO/IEC Normas

Documento de Requisitos do Sistema SISFOTO Sistema de gerenciamento de eventos fotográficos Versão 1.0

Montadores e Compiladores

GESTÃO DA MANUTENÇÃO

Padrões de Projeto. Factory Method

Guia para Modelagem de Casos de Uso Metodologia CELEPAR

Aula 4 Engenharia de Requisitos

Interpretações de Qualidade de Software. Interpretações de Qualidade de Software. Aspectos Importantes das Definições de Qualidade

Universidade Paulista

Modelando sistemas em UML - Casos de uso.

Dispositivos Externos

Aula 01 Introdução Custo de um algoritmo, Funções de complexidad e Recursão

Glossário Versão 1.0 Desenvolvimento do Sistema de Gestão de Documentos Doc Manager Histórico de Revisão

Programação de Computadores I. Linguagem C Função

Dispositivos Externos Manual do Utilizador

INE 5323 Banco de Dados I

Verificação e validação

Como Fazer uma Monografia

Motivação Este trabalho apresenta o desenvolvimento do controle da interatividade num sistema para a área de computação gráfica, mais especificamente

Termo genérico que se aplica a vários tipos de diagramas que enfatizam interações de objetos.

Gerenciamento de Integração. Prof. Anderson Valadares

Soluções de gestão de clientes e de impressão móvel

Métodos Formais. Agenda. Relações Binárias Relações e Banco de Dados Operações nas Relações Resumo Relações Funções. Relações e Funções

LINHAS MESTRAS; FASES; DISCIPLINAS; PRINCÍPIOS E MELHORES PRÁTICAS.

2. Tipos Abstratos de Dados

Levantamento de Requisitos

BANCO DE DADOS. Professor: André Dutton

Engenharia de Software. Ciclos de Vida do Software. 1. Sistemas

Engenharia de Software

- Campus Salto. Disciplina: Sistemas de Arquivos Docente: Fernando Santorsula

Fundamentos do Planejamento

7. Defina encapsulamento. R.: Encapsular é ocultar. Criar uma cápsula ao redor da classe, para proteger o que está dentro dela.

LINGUAGEM SQL Linguagem usada em SGBD para: Definir estrutura de dados; Modificar dados em um banco de dados; Especificar restrições de segurança; Rea

ANÁLISE DE FALHAS DE COMPUTADORES

Modem e rede local Guia do usuário

Modelos de Ciclo de Vida de Software

DEVF IT Solutions. Gerenciador de Log. Documento Visão. Versão 2.0. Projeto Integrador 2015/2 Engenharia de Software

Arquitetura e Organização de Computadores

Algoritmos e Programação : Conceitos e estruturas básicas. Hudson Victoria Diniz

Plano de Ensino PROBABILIDADE E ESTATÍSTICA APLICADA À ENGENHARIA - CCE0292

Regulamento paraa Certificação do Sistema de Gestão da Saúde e Segurança Ocupacional

Prof. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.

Escrita de Relatórios

Apresentação da disciplina

PROJETO DE PESQUISA FINALIDADE TEMA ESCOLHA DO PROFESSOR ORIENTADOR GUIA SEGURANÇA NA COLETA DE MATERIAIS ESPAÇO PARA FICHAMENTOS

Gerenciamento de projetos (Project Management).

SIMULADO A - COBIT 5 PORTUGUES

MANUAL DO USUÁRIO SIMPLEX. Prof. Erico Fagundes Anicet Lisboa, M. Sc.

BANCO DE DADOS I AULA 2. Willamys Araújo willamysaraujo7@gmail.com

Avaliação Baseada em Modelos Conceituais I - Engenharia Cognitiva

Propostas ISO. Benefícios com a certificação. ISO/IEC 9126 Qualidade de produtos de software

PLANEJAMENTO SIMPLIFICADO DE PROJETOS

APOSTILHA AULA 4 O CICLO DE VIDA DO PROJETO

Google AdWords. Sobre o curso. Criatividade - Marketing Digital. Promoção: 10% Desconto

Agenda. O que é Testar? Por que testar? Quando testar? Processo de teste Níveis de teste Tipos de teste Classificação dos testes.

ESTADO DO RIO GRANDE DO SUL ASSEMBLEIA LEGISLATIVA Gabinete de Consultoria Legislativa

SIG. USANDO A TECNOLOGIA COMO SUPORTE Tecnologias de Apoio

Administração do Relacionamento com os

Instruções para elaboração de TCC ANÁLISE DE MERCADO

Avaliação da Satisfação do Cliente de Informática

Introdução a Banco de Dados. INTRODUÇÃO

Árvores Parte 1. Aleardo Manacero Jr. DCCE/UNESP Grupo de Sistemas Paralelos e Distribuídos

Controladoria na gestão de serviços

AGRUPAMENTO DE ESCOLAS DR. VIEIRA DE CARVALHO

Administração Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

ATIVIDADES PRÁTICAS SUPERVISIONADAS

Falta Erro Falha. Motivação. Teste de Software. Falha, Falta e Erro. Falha, Falta e Erro. Falha, Falta e Erro. Falha, Falta e Erro 6/6/11

Universidade Federal da Paraíba Centro de Informática Departamento de Informática

Linguagens de Programação:

Transcrição:

Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1

Objetivos Descrever requisitos funcionais e não funcionais Explicar como os requisitos de software podem ser organizados em um documento de requisitos Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 2

Tópicos cobertos Requisitos funcionais e não funcionais Especificação de interface O documento de requisitos de software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 3

O que é um requisito? Pode variar de uma declaração abstrata de alto nível de um serviço ou de uma restrição de sistema para uma especificação matemática funcional. Isto é inevitável quando os requisitos podem servir uma função dual Pode ser a base para uma proposta de um contrato portanto deve ser aberta para interpretação; Pode ser a base para o contrato em si portanto deve ser definido em detalhe; Ambas as declarações podem ser chamadas requisitos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 4

Requisitos funcionais e não funcionais Requisitos funcionais 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. Requisitos não funcionais Restrições sobre serviços ou funções oferecidos pelo sistema tais como restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc. Requisitos de domínio Requisitos que vêm do domínio de aplicação do sistema e que refletem as características desse domínio. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 5

Requisitos funcionais Descrevem a funcionalidade ou serviços de sistema. Dependem do tipo de software, dos usuários esperados e o tipo de sistema onde o software é usado. Requisitos funcionais de usuário podem ser declarações de alto nível do que o sistema deve fazer mas os requisitos funcionais de sistema devem descrever os serviços de sistema em detalhe. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 6

Exemplos de requisitos funcionais O usuário deve ser capaz de pesquisar em todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele. O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos. Para todo pedido deve ser alocado um identificador único (ORDER_ID) no qual o usuário deve ser capaz de copiar para a área de armazenamento permanente da sua conta. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 7

Imprecisão de requisitos Problemas surgem quando os requisitos não são precisamente definidos. Requisitos ambíguos podem ser interpretados de maneiras diferentes pelos desenvolvedores e usuários. Considere o termo telas apropriadas Intenção do usuário tela de propósito especial para cada tipo diferente de documento; Interpretação do desenvolvedor fornece uma tela de texto que mostra o conteúdo de todos os documentos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 8

Requisitos completos e consistentes Em princípio, requisitos devem ser ambos, completos e consistentes. 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. Na prática, é impossível produzir um documento de requisitos completo e consistente. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 9

Requisitos não funcionais Estes definem propriedades e restrições de sistema, por exemplo, confiabilidade, tempo de resposta e requisitos de armazenamento. Restrições são capacidade de dispositivos de E/S, representações de sistema, etc. Requisitos não funionais podem ser mais críticos do que os requisitos funcionais. Se estes não forem atendidos, o sistema é inútil. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 10

Classificações de requisitos não funcionais Requisitos de produto Requisitos que especificam que o produto entregue deve se comportar de uma maneira particular, por exemplo, velocidade de execução, confiabilidade, etc. Requisitos organizacionais Requisitos que são uma conseqüência de políticas e procedimentos da organização, por exemplo, padrões de processo usados, requisitos de implementação, etc. Requisitos externos Requisitos que surgem a partir de fatores externos ao sistema e seu processo de desenvolvimento, por exemplo, requisitos de interoperabilidade, requisitos legais, etc. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 11

Medidas de requisitos Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 12

Interação de requisitos Conflitos entre os diferentes requisitos não funcionais são comuns em sistemas complexos. Sistema de aeronave Spacecraft system Para minimizar o peso, o número de chips separados no sistema deve ser minimizado. Para minimizar o consumo de energia, chips de baixa potência devem ser usados. Contudo, o uso de chips de baixa potência pode significar que mais chips devem ser usads. Qual é o requisito mais crítico? Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 13

Problemas com linguagem natural Falta de clareza É difícil atingir uma precisão sem tornar o documento difícil de ler. Confusão de requisitos Requisitos funcionais e não funcionais tendem a estar misturados. Fusão de requisitos Vários requisitos diferentes podem ser expressos juntos. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 14

Diretrizes para escrever requisitos Inventar um formato padrão e usá-lo para todos os requisitos. Usar a linguagem de uma forma consistente. Use deve para requisitos obrigatórios, e deveria para requisitos desejáveis. Realçe o texto para identificar as partes principais do requisito. Evitar o uso de jargões de computação. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 15

Problemas com especificação em linguagem natural Ambigüidade Os leitores e os escritores dos requisitos devem interpretar as mesmas palavras da mesma maneira. Linguagem natural é naturalmente ambigüa, 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. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 16

Diagramas de seqüência Mostram a seqüência de eventos que ocorrem durante alguma interação entre usuário e sistema. Você lê os eventos de cima para baixo para ver a ordem em que as ações ocorrem. Retirada de dinheiro de um caixa eletrônico Validar cartão; Tratar solicitação; Completar transação. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 17

Diagrama de seqüência de retirada de Caixa eletrônico Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 18

Especificação de interface A maioria dos sistemas devem operar com outros sistemas, e as interfaces que operam devem ser especificadas como parte dos requisitos. Três tipos de interface podem ser definidos: Interfaces de procedimentos; Estruturas de dados que são trocadas; Representações de dados. Notações formais são uma técnica efetiva para especificação da interface. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 19

O documento de requisitos O documento de requisitos é a declaração oficial do que é requisitado pelos desenvolvedores do sistema. Deve incluir ambos, uma definição dos requisitos de usuário e uma especificação dos requisitos de sistema. NÃO é um documento de projeto. Logo que possível, será preciso definir O QUÊ o sistema deve fazer ao invés de COMO deve ser feito. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 20

Padrão de requisitos do IEEE Define uma estrutura genérica para um documento de requisitos que deve ser instanciado para cada sistema específico. Introdução. Descrição geral. Requisitos específicos. Apêndices. Índice. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 21

Pontos-chave Os requisitos estabelecem o que sistema deve fazer e definem as restrições sobre suas operações e sua implementação. Requisitos funcionais definem os serviços que o sistema deve fornecer. Requisitos não funcionais restringem o sistema que está sendo desenvolvido ou o processo de desenvolvimento. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 22

Pontos-chave Um documento de requisitos de software é uma declaração acordada dos requisitos de sistema. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 23

Bibliografia Sommerville Engenharia de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 24