REQUISITOS DE SISTEMAS PROF. Horacio Ribeiro

Aula 2- Requisitos de Dominio e de usuário

REQUISITOS DE SISTEMASREQUISITOS DE SISTEMAS

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Conteúdo Programático desta aula

•Tipos de requisitos não funcionais•Propriedades dos requisitos• Características de requisitos de domínio•O que são requisitos de usuários• técnicas de especificação e documentação de requisitos de sistemas

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Objetivo de nível

•Objetivos (processos de negócio) •Provem a base para os sub-objetivos•Mostram :

•O ciclo de vida da seqüência de objetivos relacionados•O contexto no qual os objetivos do usuário operam

•Abrangem vários sub-objetivos de usuário•Tem a ver com a organização ( as intenções, o problema ) do usuário•Pode ser um sub-objetivo de outro objetivo estratégico

NOME DA AULA – AULA1

NOME DA DISCIPLINA

O sistema também tem Objetivos correspondentes

O uso do sistema faz com que os Objetivos possam ser alcançados ou falhem

Objetivos podem ser divididos em sub-objetivos

Normalmente existem hierarquias de objetivos, onde se vê Níveis dos Objetivos

Hierarquias e Navies de Objetivos

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Tipos de RequisitosFuncionais

o que o sistema faz para satisfazer as necessidades de seu usuário

Não Funcionais

Atributos técnicos que um sistema deve possuir para atender os requisitos funcionais

Restrições

Restrições que o sistema deve satisfazer, e que afetam igualmente os dois primeiros tipos.

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Requisitos não Funcionais (alguns)

•Usabilidade (facilidade de uso pelos usuários)•Confiança ( freqüência e resistência a falhas, capacidade de recuperação, predibilidade, precisão )•Desempenho (capacidade, taxas em relação ao tempo, de precisão: velocidade, disponibilidade, tempo de resposta, uso de memória )•Suporte ( capacidade manter o sistema atualizado, em termos de testes, manutenção, versões )•Aparência ( estética, visual, design gráfico )•Operacional ( o ambiente no qual será usado; ambiente operacional, condições do usuário, sistemas relacionados)•Segurança ( confidencialidade, integridade, disponibilidade )

NOME DA AULA – AULA1

NOME DA DISCIPLINAPropriedades dos requisitos (1)

•Validade: requisitos identificados individualmente (isto é, junto a especificação resulta da análise dos requisitos identificados junto das diversas partes interessadas envolvidas.

•Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema

-Verificar em três dimensões:

- por tipo de ator

- por tipo de serviço

- por tipo de ambiente

NOME DA AULA – AULA1

NOME DA DISCIPLINAPropriedades dos requisitos (1)

•Consistência: não devem existir conflitos entre os requisitos identificados.Deve-se também validar os requisitos em duas dimensões: - legal - cultural

•Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas.

•.Realismo: dadas as restrições do projeto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável.

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Propriedades dos requisitos (2)

•Verificabilidade:

de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial.

Definir condições de testabilidade e verificação do requisito.

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Propriedades dos requisitos (3)

•Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos.

Requisito 1usuário

usuário

usuário

Funcionalidade 1.1

Modulo 1.1.1 Programa

1.1.1.1

Reuisitos de dominio e de usuário

 Requisítos de Usuários:

São declarações, em linguagem formal ( evitar linguagem natural) com diagramas, de quais serviços são esperados do sistema e as restrições sobre as quais ele deve operar

Define O QUE O SISTEMA FAZ.

Pode-se definir uma sintaxe da forma:

<temporaL> o sistema <ação do sistema>

Temporal: uma expressão que denota um instante no tempo. exemplo: sempre que solicitado o sistema..... as 14 horas do dia 30 o sistema.... ao identificar a chamada telefônica o sistema

 

Exemplo:Sempre que solicitado o sistema apresenta uma tela com o produto e a quantidade em estoque

Para cada requisito de usuário encontrado, deve-se estabelecer o conjunto de exceções.

Sintaxe:

O sistema não <ação> <condição>

O sistema não apresentará o produto e a quantidade se o produto for importado.

Para o sistema fazer o seu objetivo: O QUE

Precisa-se que algumas premissas sejam atendidas.Para identificar estas premissas temos a sintaxe:

<temporal><ator><ação no sistema>

<temporal>: uma expressão que denote um instante de tempo.<ator> um agente externo que atua sobre o sistema<ação no sistema> : normalmente cadastrar, deletar,...Exemplo:Sempre que um novo produto é comprado o gerente de compras atualiza a tabela de produtos informando o nome, características, quantidade.

exercício

Ache os requisitos necessários para implementar a necessidade abaixo, use a sintaxe apresentada.

Regra de negócio:RN1: “não se empresta livros quando existir apenas um volume”

“emprestar um livro para um estudante previamente cadastrado”

Requisitos de usuário

Devem descrever requisitos funcionais e não-funcionais de tal forma que sejam entendíveis pelos usuários do sistema que não têm conhecimento técnico detalhadoRequisitos do usuário são definidos usando linguagem natural (evitar), tabelas e diagramas

Problemas

- Interpretações da linguagem natural-- completude e entendimento da tarefa--participação do usuário

linguagem natural (problemas relacionados a falta de clareza, confusão de requisitos, fusão de requisitos,erros de interpretação por usuários e desenvolvedores, etc.).

Os requisitos do usuário devem ser classificados em:

requisitos obrigatórios: fundamentais para a aceitação do sistema

requisitos desejáveis: que devem ser implementados mas não comprometem a utilização do sistema

Os requisitos podem ser ainda:

Implantados: que serão ou estão implantados

Adiados: que serão implementados em outras versões

Os requisitos de sistemas precisam ser documentados de forma mais especifica e detalhada

-Diagramas a análise estruturada, essencial, orientada a objetos

-Usa-se notações para levantamento de requisitos (Notações Gráficas, Especificações Matemáticas, Linguagem Natural, etc.)

-Vamos trabalhar mais estes conceitos e produtos ao longo do curso

formalizar a documentação de requisitos

Nome do Caso de Uso

Descrição

Atores

Objetivo

Fluxo de Eventos

Fluxo Básico

Sub-objetivo 1

Sub-objetivo 2

.............

Fluxo Alternativo

Pré-condições

Pós-condições

Outras técnicas de levantamento

-Mapas mentais.--entrevistas--documentos-Encontros estruturados--linguagens e especificação--softwares de gerencia de requisitos--templates (RUP) (praxis)...

Estrutura de documentos do RUP - templates

Mais detalhes: www.espacodoprofessor.com---horacioribeiro--curso de requisitos

Derivados do domínio da aplicação e descrevem características do sistema 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 sistema pode tornar-se não prático

Requisitos de dominio

Problemas com dominio

Entendimento

Requisitos 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

Implicitude

Especialistas no domínio entendem a área tão bem que não tornam todos os requisitos de domínio explícitos

Propriedade MedidaVelocidade Transações processadas/seg

Tempo de resposta do usuário/eventoTamanho K bytes

No de chips de RAMFacilidade de uso Tempo de treinamento

No de quadros de ajudaConfiabilidade Tempo médio de falhas

Probabilidade de indisponibilidadeTaxa de ocorrência de falhas

Robustez Tempo de reinício após falhaPercentual de eventos causando falhasProbabilidade de corrupção de dados após

falhaPortabilidade Percentual de declarações dependentes do destino

No de sistemas destino

Métricas de requisitos

Próxima aula

-engenharia de requisitos

-Processo de gestão de requisitos

-Estudo de viabilidade

- Documentação de requisitos

NOME DA AULA – AULA1

NOME DA DISCIPLINA

Contactos e material complementar e exercícios

www.espacodoprofessor.com

Professor: Horacio ribeiro

Modulo Estácio 2012.1

Senha 222222