Curso de Gestão da TI

Análise de Projetos de Sistemas

Prof. Flávio Barbosa

26/08/2009
1
 Módulo 4.1

Aula 4

Ciclo de Vida do Software

2
 AGENDA
• Definição de Requisitos
• Tipos de Requisitos
• Documento de requisitos

3
 ENGENHARIA DE REQUISITOS:
O termo Engenharia de Requisitos ou
Análise de Requisitos refere-se a uma
coleção de processos:
Extração
Especificação
Verificação
Validação
Stokes (2003 apud FISCHER, 2001, p. 74)
4
 ENGENHARIA DE REQUISITOS:
EXTRAÇÃO
Exatamente...
EXTRAÇÃO: As
expectativas!

É o exercício de agrupar as informações

a fim de verificar exatamente
o que o cliente ou usuário está
requerendo.

5
 ENGENHARIA DE REQUISITOS:
ESPECIFICAÇÃO
ESPECIFICAÇÃO (1/2):
Criar Documentação
onde constem todas as
informações extraídas
sobre um determinado SI
que está ou esteve em
processo de Análise.
6
 ENGENHARIA DE REQUISITOS:
ESPECIFICAÇÃO
ESPECIFICAÇÃO (2/2):
O fluxo dos dados é avaliado;
As funções são definidas e detalhadas;
O comportamento do
software entendido no
contexto do ambiente;
As restrições do
projeto são incluídas. 7
 ENGENHARIA DE REQUISITOS:
VERIFICAÇÃO
VERIFICAÇÃO:
Assegura que o(s) documento(s) de
especificação não contenham
inconsistências, uma vez que os
requisitos não devem ser
conflitantes
entre si.

8
 ENGENHARIA DE REQUISITOS:
VALIDAÇÃO
VALIDAÇÃO:
Assegura que o(s)
documento(s) de especificação
descreve precisamente o SI
que o usuário precisa (espera),
incluindo todas as
funcionalidades e restrições
impostas por ele.
9
 ENGENHARIA DE REQUISITOS
RESPONSABILIDADES DA
ANÁLISE DE REQUISITOS

Definir os serviços que um sistema deve

realizar;
Interface com outros sistemas;
Restrições para o sistema operar.

10
 RESPONSABILIDADE DA
ANÁLISE DE REQUISITO
LEVANTAR REQUISITOS

R R
3 4 R
R
5 R
2
R n
1

ANÁLISE DE REQUISITOS
11
 RESPONSABILIDADE DA
ANÁLISE DE REQUISITO
A reutilização, evolução e rastreabilidade de
requisitos estão intimamente relacionadas à
habilidade de gerenciar interações entre
requisitos, que, por sua vez, está
relacionada à habilidade de separar e
compor características, as representando em
modelos.

12
 RESPONSABILIDADE DA ANÁLISE
DE REQUISITO
Um único tipo de modelo não é
suficiente para explicitar todas as
características do sistema.
R R
3 4 R
R
5 R
2
R n
1

MODELAR OS REQUISITOS
ANÁLISE DE REQUISITOS
13
 RESPONSABILIDADE DA ANÁLISE
DE REQUISITO
NÃO BASTA LEVANTAR
O QUE OCORRE SE O
É PRECISO RASTREAR
REQUISITO “R1.a” FOR
OS REQUISITOS
R R MODIFICADO?
R1.a R
R 3 4
5 R
2
R n
1

ANÁLISE DE REQUISITOS
14
RESPONSABILIDADE DA ANÁLISE
DE REQUISITO
Tende a
desaparecer

MANUTENÇÃO

TESTES

IMPLEMENTAÇÃO

ANÁLISE DE REQUISITOS 15
 RESPONSABILIDADE DA ANÁLISE
DE REQUISITO

Manutenção MANUTENÇÃO
Estendida
Sem Análise de
Requisitos, as etapas
ficam confusas, e o
resultado é uma etapa de
manutenção alargada.
TESTES
IMPLEMENTAÇÃO 16
 CONCEITUANDO REQUISITOS
REQUISITOS:
É uma condição ou capacidade que o SI
deverá contemplar. Exemplos:

 Deverá haver “n” tipos de contatos associados

ao cliente (celular, telefone, e-mail, etc.);
 O tempo de resposta não deve ser superior a
30 segundos;
 Deverá ser anexado imagens dos produtos.
17
 ESPECIFICAÇÃO DOS
REQUISITOS
São características de uma
especificação de requisitos eficiente:

R0.: O SI de vendas
deverá funcionar 7x24
com Oracle em rede
gigabit ethernet ambas 18
 PROCESSO DE DEFINIÇÃO DE
REQUISITOS
O processo de definição de requisitos pode
ser definido, resumidamente, por três
atividades: elicitação, modelagem e análise.

UdI = Universo de Informações (Leite, 1988) 19

 ATIVIDADE
Juntem-se em pares!
Observem as características de um bom requisito
(em vermelho) e respondam: O requisito “R1”
está bem
R1.: O sistema deverá especificado
possuir telas de fácil (escrito)? Por quê?
acesso.

20
 RESPOSTA

R1.: O sistema deverá possuir telas de fácil

acesso.
Não está bem especificado porque ele gera
dúvidas “do que”, “onde”, “quem” exatamente
fará isso.

21
 TIPOS DE REQUISITOS

REQUISITOS FUNCIONAIS:
São todas as funcionalidades (capacidades)
que o Software (sistema) deverá
contemplar:
 No sistema de frente de caixa as fotos dos
Exemplo de requisitos funcionais:
produtos deverão ser exibidas;
 O usuário de frente de caixa se autenticará
no sistema usando biometria. 22
 TIPOS DE REQUISITOS
REQUISITOS NÃO-FUNCIONAIS:
Estão associados à qualidade do produto
(software) como, por exemplo, robustez,
segurança, disponibilidade ou integridade.
 Para exibição de fotos será necessária rede
Gigabit Ethernet;
 A biometria será por impressão digital para
identificação dos usuários de frente de caixa.
23
 TIPOS DE REQUISITOS
REQUISITOS NÃO-FUNCIONAIS:
São difíceis de validar e por
vezes são controversos.

 O tempo máximo de resposta deve ser de 10s.

 Deve-se usar Java para permitir multiplataforma;
 A organização possui Windows licenciado em
100% dos equipamentos e não pretende usar
Linux 24
 TECNICAS DE LEVANTAMENTO
DE REQUISITOS
CASOS DE USO:
Uma descrição de um conjunto de
sequências de ações, resultantes da
Conf igur a A m bie nt e do SI. x

interação do sistema com um ator (um tipo

<<extend>>

de requerente).Fa z le it ur a biom e t rica

pa ra a ut e nt ica çã o
Conf igur a Cone x ã o

Us uá rio <<include>>

<<include>>

Cone ct a r a o
Ba nco de Da do s

25
 TECNICAS DE LEVANTAMENTO
DE REQUISITOS
VIEWPOINTS:

São mecanismos que permitem considerar

aspectos do sistema percebidos por
diferentes requerentes (ângulos).
R
x^n
R R
x^2 Rx R
x^1
x^3
26
 TECNICAS DE LEVANTAMENTO
DE REQUISITOS
CORE – Expressão Controlada dos Requisitos:
O SI é particionado em perspectivas ou
viewpoints.
DIRETORES
USUÁRIO FINAL
R
x^n
R
R
x^2 Rx R
x^1
x^3
27
 TECNICAS DE LEVANTAMENTO
DE REQUISITOS
DFD – Diagrama de Fluxo de Dados:
Define o fluxo de dados entre os vários
processos funcionais, em que um
processo é a transformação em algum
dado de entrada em dados de saída, de
acordo com alguma funcionalidade.

28
 TECNICAS DE LEVANTAMENTO
DE REQUISITOS
DFD – Diagrama de Fluxo de Dados:
LEITURA
DAS SIM
EXIST
IMPRESSÕ
E?
ES
DIGITAIS NÃO

GERA ATIV
ERRO NÃO O?

LIBERAR
SIM
ACESSO
29
 TECNICAS DE LEVANTAMENTO DE REQUISITOS

Requisitos e
VOLERE: Eventos dos Restrições
Sistemas dos
Interagentes
É um método Envolvidos
Determinação do Escopo do
completo de artefato
(Caso de Uso - Investigação)
obtenção de Possíveis
Requisitos
requisitos,
Protótipo dos Requisitos
baseado nos casos Portal da Qualidade
(rastreabilidade)
de uso. Documento de Especificação dos
Requisitos 30
DOCUMENTOS DE REQUISITOS : VOLERE 2006

Fonte: http://www.volere.co.uk/template.htm
31
 O que veremos na
próxima aula:
Tema 5 – ANALISE ESTRUTURADA DE SISTEMAS
 Modelo ambiental
 Modelo Comportamental
 Dicionário de dados

Não se esqueçam de:

 Ler o material didático
 Participar das atividades do portal

32
 Curso de Gestão da TI

Obrigado!

Nos vemos em nossa plataforma.

Prof. Flavio Barbosa

33
 Visite o site e avalie a aula.

http://www.inepad.org.br/interativacoc/

Utilize seu código e senha de aluno.

34