aula 4 – análise de projetos de sistemas
TRANSCRIPT
1
Curso de Gestão da TI
Análise de Projetos de Sistemas
Prof. Flávio Barbosa
26/08/2009
2
Módulo 4.1
Aula 4
Ciclo de Vida do Software
3
AGENDA• Definição de Requisitos• Tipos de Requisitos• Documento de requisitos
4
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
ENGENHARIA DE REQUISITOS:
Stokes (2003 apud FISCHER, 2001, p. 74)
5
EXTRAÇÃO:
É o exercício de agrupar as informações
a fim de verificar exatamente
o que o cliente ou usuário está
requerendo.
ENGENHARIA DE REQUISITOS: EXTRAÇÃO
Exatamente...As expectativas!
6
ESPECIFICAÇÃO (1/2):
ENGENHARIA DE REQUISITOS: ESPECIFICAÇÃO
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
7
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.
ENGENHARIA DE REQUISITOS: ESPECIFICAÇÃO
8
VERIFICAÇÃO:
ENGENHARIA DE REQUISITOS: 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
9
VALIDAÇÃO:
ENGENHARIA DE REQUISITOS: 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
10
RESPONSABILIDADES DA
ANÁLISE DE REQUISITOS
ENGENHARIA DE REQUISITOS
Definir os serviços que um sistema deve
realizar;
Interface com outros sistemas;
Restrições para o sistema operar.
11
RESPONSABILIDADE DA ANÁLISE DE REQUISITO
ANÁLISE DE REQUISITOSANÁLISE DE REQUISITOS
R1
R2R3 R4
R5Rn
LEVANTAR REQUISITOS
12
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.
RESPONSABILIDADE DA ANÁLISE DE REQUISITO
13
RESPONSABILIDADE DA ANÁLISE DE REQUISITO
ANÁLISE DE REQUISITOSANÁLISE DE REQUISITOS
R1
R2R3 R4
R5Rn
MODELAR OS REQUISITOSMODELAR OS REQUISITOS
Um único tipo de modelo não é
suficiente para explicitar todas as
características do sistema.
14
ANÁLISE DE REQUISITOSANÁLISE DE REQUISITOS
R1
R2R3 R4
R5Rn
R1.a
NÃO BASTA LEVANTAR É PRECISO RASTREAR
OS REQUISITOS
O QUE OCORRE SE O
REQUISITO “R1.a” FOR
MODIFICADO?
RESPONSABILIDADE DA ANÁLISE DE REQUISITO
15
MANUTENÇÃO
TESTES
IMPLEMENTAÇÃO
ANÁLISE DE REQUISITOS
Tende a desaparecer
Tende a desaparecer
RESPONSABILIDADE DA ANÁLISE DE REQUISITO
16
MANUTENÇÃO
TESTES
IMPLEMENTAÇÃO
Sem Análise de
Requisitos, as etapas
ficam confusas, e o
resultado é uma etapa de
manutenção alargada.
Manutenção Estendida
Manutenção Estendida
RESPONSABILIDADE DA ANÁLISE DE REQUISITO
17
REQUISITOS:
É uma condição ou capacidade que o SI
deverá contemplar. Exemplos:
CONCEITUANDO REQUISITOS
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.
18
R0.: O SI de vendas deverá R0.: O SI de vendas deverá
funcionar 7x24 com Oracle em funcionar 7x24 com Oracle em
rede gigabit ethernet ambas rede gigabit ethernet ambas
(dados e rede) duplicadas. [CIO](dados e rede) duplicadas. [CIO]
R0.: O SI de vendas deverá R0.: O SI de vendas deverá
funcionar 7x24 com Oracle em funcionar 7x24 com Oracle em
rede gigabit ethernet ambas rede gigabit ethernet ambas
(dados e rede) duplicadas. [CIO](dados e rede) duplicadas. [CIO]
São características de uma
especificação de requisitos eficiente:
ESPECIFICAÇÃO DOS REQUISITOS
19
O processo de definição de requisitos pode ser definido, resumidamente, por três atividades: elicitação, modelagem e análise.
PROCESSO DE DEFINIÇÃO DE REQUISITOS
(Leite, 1988)UdI = Universo de Informações
20
Juntem-se em pares!
ATIVIDADE
R1.: O sistema deverá possuir
telas de fácil acesso.
R1.: O sistema deverá possuir
telas de fácil acesso.
Observem as características de um bom requisito
(em vermelho) e respondam: O requisito “R1”
está bem
especificado
(escrito)? Por quê?
21
Não está bem especificado porque ele gera
dúvidas “do que”, “onde”, “quem” exatamente
fará isso.
R1.: O sistema deverá possuir telas de fácil acesso.R1.: O sistema deverá possuir telas de fácil acesso.
RESPOSTA
22
REQUISITOS FUNCIONAIS:
São todas as funcionalidades (capacidades)
que o Software (sistema) deverá
contemplar:
Exemplo de requisitos funcionais:
TIPOS DE REQUISITOS
No sistema de frente de caixa as fotos dos
produtos deverão ser exibidas;
O usuário de frente de caixa se autenticará
no sistema usando biometria.
23
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.
TIPOS DE REQUISITOS
24
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
TIPOS DE REQUISITOS
24
25
TECNICAS DE LEVANTAMENTO DE REQUISITOS
CASOS DE USO:
Uma descrição de um conjunto de
sequências de ações, resultantes da
interação do sistema com um ator (um tipo
de requerente). Usuário
Configura Ambiente do SI.x
Faz leitura biometricapara autenticação
Configura Conexão
Conectar aoBanco de Dados
<<extend>>
<<include>>
<<include>>
26
RxRx^1
VIEWPOINTS:
São mecanismos que permitem considerar
aspectos do sistema percebidos por
diferentes requerentes (ângulos).
Rx^n
Rx^2Rx^3
TECNICAS DE LEVANTAMENTO DE REQUISITOS
27
RxRx^1
CORE – Expressão Controlada dos Requisitos:O SI é particionado em perspectivas ou
viewpoints.
Rx^n
Rx^2Rx^3
USUÁRIO FINALUSUÁRIO FINALDIRETORESDIRETORES
TECNICAS DE LEVANTAMENTO DE REQUISITOS
28
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.
TECNICAS DE LEVANTAMENTO DE REQUISITOS
29
DFD – Diagrama de Fluxo de Dados:
LEITURA DAS IMPRESSÕES
DIGITAIS
EXISTE?
ATIVO?
GERA ERRO
SIM
SIM
NÃO
NÃO
LIBERAR ACESSO
TECNICAS DE LEVANTAMENTO DE REQUISITOS
30
TECNICAS DE LEVANTAMENTO DE REQUISITOS
VOLERE:
É um método
completo de
obtenção de
requisitos,
baseado nos casos
de uso.
Requisitos e Restrições dos
Envolvidos
Eventos dos Sistemas
Interagentes
Determinação do Escopo do artefato(Caso de Uso - Investigação)
Possíveis Requisitos
Protótipo dos Requisitos
Portal da Qualidade (rastreabilidade)
Documento de Especificação dos Requisitos
31
DOCUMENTOS DE REQUISITOS : VOLERE 2006
Fonte: http://www.volere.co.uk/template.htm
32
Tema 5 – ANALISE ESTRUTURADA DE SISTEMAS
Modelo ambiental
Modelo Comportamental
Dicionário de dados
O que veremos na próxima aula:
Não se esqueçam de:
Ler o material didático
Participar das atividades do portal
33
Curso de Gestão da TI
Obrigado!
Nos vemos em nossa plataforma.
Prof. Flavio Barbosa
34
Visite o site e avalie a aula.
Utilize seu código e senha de aluno.
http://www.inepad.org.br/interativacoc/