FACULDADE DE ENGENHARIAS

ANÁLISE E DESENHO DE SISTEMAS

AULA 5 e 6
 Metodologias de Desenvolvimento de SI
 Descrição de SI
 Definição de Requisitos Funcionais
 Definição não Funcionais
 Definição de Requisitos de Usabilidade
SILVA NO Â NGELO C A STA NHEIR A

2020
METODOLOGIAS DE DE SI

 É uma série recomendada de passos e procedimentos

para obteção de um SI;
 Conjunto recomendado de filosofias, fases,
procedimentos, técnicas, regras, ferramentas,
documentação, gestão, e treino para o desenvolvimento
de um SI;
 Conjunto formado por procedimentos, técnicas,
ferramentas e documentação que auxiliarão todo
processo de desenvolvimento e exploração de um SI.

1
METODOLOGIAS DE DE SI
Orientação para Processos:
Envolve a criação de representações gráficas
como os diagramas de fluxo de dados, gráficos e
mapas;
O foco é o fluxo, uso e transformação de dados em
SI;
Os dados são seguidos da fonte até o destino final;
e
Não se especifica a estrutura natural dos dados. 2
METODOLOGIAS DE DE SI

Orientação para Dados:

Descreve a organização ideal dos dados,
independente de onde e de como os dados são
usados;
O modelo dos dados descreve tipos dos dados e
dos relacionamentos do negócio entre os dados; e
As regras do negócio descrevem como a
organização capta e processa os dados.
3
METODOLOGIAS DE DE SI

Constrangimentos Adjacentes:
Pouco tempo para recolha de dados sobre o
desenvolvimento do SI;
Fraca comunicação durante o
desenvolvimento do SI; e
Falta de testes do SI que resulta na sua
complexidade funcional e na manutenção.
4
TRABALHO EM GRUPO

RAD;
JAD;
XP;
 STRADIS;
MERISE;
ISAC;
OSSAD;
ETHICS; e (Docente Castanheira)
ICONIX.
METODOLOGIAS DE DE SI

Abordagem nas Metodologias de DSI:

Análise Estruturada;
Análise Essencial; e
Análise Orientada a Objectos.

5
METODOLOGIAS DE DE SI

Análise Estruturada:
Enfatiza a perspectiva das funções, com
ênfase nos processos;
A análise estruturada clássica não modela
o comportamento temporal, nem
complexos relacionamentos de dados.

6
METODOLOGIAS DE DE SI

Análise Estruturada:
 Utiliza as seguintes ferramentas:
 Diagrama de Contexto (DC);
 Diagrama de Fluxo de Dados (DFD);
 Diagrama de Entidade e Associação (DEA);
 Dicionário de Dados (DD);
 Esquema de Tabelas (ET);
 Árvore de Decisão (AD); e
 Tabela de Decisão (TD). 7
METODOLOGIAS DE DE SI

Análise Essencial:
É uma evolução da Análise
Estruturada por adicionar a
preocupação com o controlo;
Usa uma lista de eventos externos
como base para o particionamento do
Sistema;
8
METODOLOGIAS DE DE SI

Análise Essencial:
 O modelo essencial é construído por:
 Modelo Ambiental – define a fronteira entre o SI e o
ambiente (DC e Lista de Eventos);
 Modelo Comportamental – descreve o comportamento
interno do sistema (DFD e DD);
 Modelo de Informação – modela os dados necessários
às actividades essenciais do sistema (DEA); e
 Modelo de Implementação – extensão do modelo
essencial com restrições de implementação (Tempo,
capacidade e comunicação).
9
METODOLOGIAS DE DE SI

Análise Orientada a Objectos:

Mudança do enfoque das funções para os
dados;
Preocupação em modelar de forma mais
detalhada o SI;
Análise mais próxima da realidade; e
Facilidade na comunicação com o utilizador.
“O mundo real é composto por objectos“.
10
DESCRIÇÃO DE DE SI

É obtida usando uma ou a combinação das

técnicas de recolha de informação;
Representa um sumário detalhado ou não das
actividades do sistema;
Através dela é possível listar os requisitos do
sistema; e
De alguma forma, é a descrição simplificada do
funcionamento de uma empresa.
11
DEFINIÇÃO DE REQUISITOS DE SI

 Envolve a determinação de objectivos e

restrições associadas;
 Requisitos representam as expectativas do
cliente em relação ao funcionamento do SI;
 É a identificação e a descrição dos requisitos
do novo SI; e
 Faz-se no início e continua indefinidamente.
12
REQUISITOS DO SISTEMA

 Objectivos, capacidades ou restrições do sistema;

 Expressam as características e restrições do
produto, do ponto de vista das necessidades do
utilizador;
 O documento de requisitos é constantemente
revisto e actualizado;
 Os requisitos de Software são separados em:
 Funcionais;
 Não funcionais; e
 Usabilidade. 13
REQUISITOS FUNCIONAIS (RF)

 Actividades que o sistema deve realizar;

 Baseados nos procedimentos e funções de
negócio;
 Deve determinar o que se espera que o
Software faça, sem se preocupar como ele
faz; e
 Actualizações, consultas, relatórios, dados e
interfaces com outros sistemas.
14
REQUISITOS FUNCIONAIS - EXEMPLOS

Possibilitar o cálculo de gastos diários;

Emitir relatórios de compras a cada 15
dias;
Efectuar o cadastro dos dados do
estudante;
Gerar o mapa de multas diárias; e
Gerar gráficos das vendas mensais. 15
 REQUISITOS FUNCIONAIS (RF)

Código Descrição Prioridade Dependência

RF01 Login Máxima ---

RF02 Logout Máxima RF01

RF03 Adicionar anúncio Máxima ---

RF04 Actualizar anúncio Máxima RF03

RF05 Remover anúncio Máxima RF03

RF06 Pesquisar desaparecido(a) Médio ---

RF07 Exibir resultados Máxima ---

RF08 Visualizar anúncio Máxima ---

RF09 Intervir no anúncio Baixa RF08

16
REQUISITOS NÃO FUNCIONAIS (RNF)

 São as qualidades globais de um Software:

 Disponibidade;
 Desempenho;
 Custos;
 Segurança;
 Tempos de resposta;
 Volume de informação;
 Restrições de acesso;
 Monitoria; e
 Auditoria e controlo de constrangimentos.

 Muitas vezes são difíceis de validar.

17
REQUISITOS NÃO FUNCIONAIS - EXEMPLOS

O SI deve:
 Ser desenvolvido em menos de 6 meses;
 Ter um tempo de resposta que não
ultrapasse os 30 segundos;
 Ser desenvolvido usando ferramentas livres;
 Estar protegida para acesso apenas de
usuários autorizados; e
 O sistema deve efectuar backups diário.
18
REQUISITOS NÃO FUNCIONAIS (RNF)
Segurança
RNF01 Definir privilégios para utilizadores.
RNF02 Encriptar as senhas de acesso dos utilizadores ao sistema.
Disponibilidade
RNF03 Tolerâncias as falhas.
Desempenho
RNF04 Enquanto escalável deverá funcionar normalmente.
Interoperabilidade
RNF05 Estabelecer comunicação com o sistema de base de dado.
Usabilidade
RNF06 Possuir uma interface amigável.
RNF07 Possuir telas responsivas.
RNF08 Possuir modo de guia para os utilizadores.
19
REQUISITOS DE USABILIDADE

 É a característica do Software que o torna agradável e familiar ao usuário

final;
 Representa o conjunto de restrições ou regras para o uso do Software;
 Perspectiva de uso de um Software, tradicionalmente relacionado aos
seguintes aspectos:
 Facilidade de aprendizado;
 Eficiência operacional;
 Facilidade de reter o conhecimento sobre a aplicação obtida em usos
anteriores (memorização); e
 Baixo índice de erros e satisfação dos usuários.

“Qual é o esforço para aprender, operar, preparar entradas e interpretar

saídas de um programa”.
20
REQUISITOS DE USABILIDADE

 Facilidade de Aprendizado: grau de facilidade de

realizar determinada tarefa;
 Eficiência Operacional: rapidez com que podem efetuar
determinada tarefa, em virtude da padronização do
processo;
 Memorização: grau de facilidade do usuário em utilizar o
sistema, tendo ficado algum tempo sem operá-lo; e
 Índice de Erros: baixa quantidade de erros cometidos
pelos usuários e grau o de facilidade de resolver uma
situação de erro.
21
REQUISITOS DE USABILIDADE

Componentes Requisitos

Processador Processador com frequência

x64: 1,4 GHz ou mais.
Memória 8 GB de RAM ou mais.

Disco rígido 500 GB de memória de

armazenamento ou mais.
Placa de rede 100/1000 Mbps ou mais.
22
FONTES DOS REQUISITOS
 As pessoas interessadas na implementação do SI
com sucesso;
 Grupo primário:
 Clientes (pagam pelo sistema);
 Utilizadores (usam o sistema);
 Pessoal técnico (garantem a operação do
sistema); e
 O Analista de Sistemas deve identificar todos
os tipos de fontes de requisitos do sistema. 23
ESPECIFICAÇÃO DE REQUISITOS

Uma boa especificação resulta em requisitos:

 Claros e não ambíguos;
 Completos;
 Correctos;
 Compreensíveis;
 Consistentes;
 Concisos; e
 Confiáveis.
24
 ANÁLISE E NEGOCIAÇÃO DOS REQUISITOS

 Classificação dos requisitos para facilitar a visão;

 Padronização do formato dos requisitos;
 Destinção clara dos comportamentos esperados e
desejáveis;
 Uso de terminologia familirizada com os stakeholders;
 Resolução de conflictos, pela multiplicidade dos
envolvidos;
 Prioritização dos requisitos (elevada/média/baixa); e
 Confirmação junto dos stakeholders.

25
ANÁLISE E NEGOCIAÇÃO DOS REQUISITOS

Constrangimentos:
 Factores externos (forçar pontos de vista,
requisitos que sirvam interesses pessoais
e não da organização); e
 Ambiente económico/organizacional
(novas partes interessadas no sistema
podem provocar alterações no sistema).
26
ANÁLISE E NEGOCIAÇÃO DOS REQUISITOS

No processo de Negociações:
 Saber lidar com ataque pessoais;
 Argumentar a justificação das posições
tomadas;
 Salientar os benefícios que uma solução
apresenta; e
 Suavizar as restrições quando se torna óbvio
que as actuais não conseguem levar a um
concenso. 27
DOCUMENTO DE ESPECIFICAÇÃO

Descreve uma combinação entre RF, RNF e de

Usabilidade do Sistema e é multiuso:
 Clientes:
 Confirmar os requisitos e propor alterações;
 Gestores:
 Orçamentar e planear o processo de desenvolvimento;
 Engenheiros:
 Compreender o sistema a desenvolver;
 Desenvolver testes para validar o cumprimento dos requisitos;
 Compreender o sistema e a ligação entre as suas partes; e
 Existem vários padrões para este documento, o mais usado é o
IEEE/ANSI 830-1993. 28
DOCUMENTO DE ESPECIFICAÇÃO

Validação:
 Com ela pretende-se demonstrar que o documento de
requisitos produzido, corresponde, de facto ao sistema
que o cliente pretende;
 Serve para encontrar problemas e conflitos;
 É importante em sistemas de grande dimensão (erros
encontrados mais tarde saem mais caro!); e
 Deve-se verificar se se cumpre com os atributos de uma
boa especificação.
29
DOCUMENTO DE ESPECIFICAÇÃO

Técnicas de validação de Requisitos:

 Revisão: Equipa de revisores juntamente com

clientes;
 Prototipificação: Implementação de um
protótipo;
 Geração de casos de teste: Plano de testes para
cada requisito; e
 Análise de consistência automática: Uso de
ferramentas CASE Tools. 30
FLUXO PARA GESTÃO DE REQUISITOS

31
OBRIGADO