Fase de Concepção (Início,
Planejamento)
Objetivos
Conhecer a empresa
Levantar requisitos
Organizar requisitos
Casos de Uso
Manutenção de Entidades
Consultas / Relatórios
Esboçar o modelo conceitual do sistema
Planejar o desenvolvimento
Iterações
Cronograma
Recursos
Conhecimento da Empresa
O que a empresa quer com o projeto?
Por que ele está sendo proposto?
Por que a empresa vai gastar dinheiro com o
projeto?
O projeto é realizável?
A equipe de desenvolvimento tem condições
de realizar este projeto?
Em caso de uma empresa produtora de
software para clientes externos:O cliente
tem dinheiro para pagar o desenvolvimento?
Há tempo disponível?
Comprar ou desenvolver?
Conhecimento da Empresa (2)
Se as respostas são positivas, o passo
seguinte é elaborar o sumário
executivo do projeto
Primeiro artefato
Artefatos
Sumário Executivo
Documento de Requisitos
Casos de Uso
Modelo Conceitual
Sumário Executivo
Sumário Executivo
É um documento de 3 páginas, no máximo,
que responde às seguintes perguntas
Por quê?
O quê?
[Onde?]
Também chamado de Visão Geral do
Sistema
Estudo de Caso: sistema de locação de vídeo
Sumário Executivo
documento de texto em formato livre
Sistema Videolocadora
Visão Geral do Sistema
É proposto o desenvolvimento de um sistema de controle de
videolocadora, que vai informatizar as funções de empréstimo, devolução e
reserva de fitas. O objetivo do sistema é agilizar o processo de empréstimo
e garantir maior segurança, ao mesmo tempo que possibilita um melhor
controle das informações por parte da gerência. Deverão ser gerados
relatórios de empréstimos por cliente, empréstimos por fita e empréstimos
no mês. O sistema deverá calcular automaticamente o valor dos
pagamentos a serem efetuados em cada empréstimo inclusive multas e
descontos devidos. A cada devolução de fitas corresponderá um
pagamento, não sendo possível trabalhar com sistema de créditos. A
impossibilidade de efetuar um pagamento deve deixar o cliente suspenso,
ou seja, impossibilitado de emprestar novas fitas até saldar a dívida.
Sumário Executivo (2)
Exercício: avalie o documento do slide
anterior
Ele permitiria responder bem a estas
perguntas
Por quê?
O quê?
[Onde?]
Documento de Requisitos
Levantamento de Requisitos
Entrevistas
Análise de Documentos Existentes na
Empresa
Estudo Bibliográfico Comparativo
Requisitos
Requisitos funcionais correspondem à
listagem de todas as coisas  primitivas ou
atômicas  que o sistema deve fazer para
bem gerir o negócio do usuário
Requisitos não funcionais são restrições
que se colocam sobre como o sistema deve
realizar seus requisitos funcionais
Requisitos Funcionais
Requisitos funcionais evidentes são
efetuados com conhecimento do
usuário
Requisitos funcionais ocultos são
efetuados pelo sistema sem o
conhecimento explícito do usuário
A negação de requisito funcional
evidente
Requisitos Não Funcionais
Permanentes (o contrário:
Transitório)
Desejáveis (o contrário: Obrigatório)
Requisitos Não Funcionais
Categoria
de interface
de implementação
de eficiência
de tolerância a falhas
de segurança
de compatibilidade
etc
Requisitos Não Funcionais
Associados a requisitos funcionais
Suplementares
Associados a qualquer requisito
funcional, indistintamente
Requisitos Funcionais
Código do requisito funcional (Ex.: F1,
F2, F3, ...)
Nome do requisito funcional
(especificação curta)
Descrição (especificação longa, ou
detalhamento do requisito)
Evidente ou oculto?
Requisitos Não Funcionais
Código de requisito não funcional associado
(Ex.: NF1.1, NF1.2, ... NF2.1, NF2.2, ...)
Nome do requisito não funcional
(especificação curta)
Restrição: especificação (longa) do requisito
não funcional, por categoria de restrição
Obrigatório ou Desejável?
Permanente ou Transitório?
Requisitos Não Funcionais (2)
Suplementares
S<índice i >
Requisitos Funcionais e Não
Funcionais Associados
Oculto ( )
F1 Registrar empréstimos
Descrição: O sistema deve registrar empréstimos de fitas, indicando o cliente e as fitas que foram emprestadas, bem
como a data do empréstimo e valor previsto para pagamento na devolução.
Requisitos Não Funcionais
Nome
Restrição
Categoria
Desejável Permanente
( )
(x)
NF1.1 Controle de
A função só pode ser acessada por usuário com perfil Segurança
Acesso
de operador ou superior.
( )
(x)
NF1.2 Identificação de As fitas devem ser identificadas por um código de
Interface
Fitas
barras
( )
( )
NF1.3 Identificação do O cliente deverá ser identificado a partir de seu nome
Interface
cliente
(x)
( )
NF1.4 Tempo de
O tempo para registro de cada fita deve ser inferior a
Performance
registro
um segundo.
(x)
(x)
NF1.5 Janela única
Todas as funções relacionadas a empréstimos devem Interface
ser efetuadas em uma única janela
...
...
...
...
...
Oculto ( x )
F2 Calcular descontos
Descrição: O sistema deve calcular descontos nos empréstimos em função da política da empresa.
Requisitos Não Funcionais
Nome
Restrição
Categoria
Desejável Permanente
( )
( )
NF2.1 Desconto de fim Nos fins de semana, usuários que levam 4 fitas
Especificação
de semana
pagam apenas 3.
...
...
...
...
...
Requisitos Funcionais e Não
Funcionais Associados (2)
Com relação a F1 e F2, e para sermos
mais precisos (atomicidade)
Registrar (1) empréstimo
Calcular (1) desconto
Requisitos Suplementares
Nome
Restrição
S1 Tipo de Interface
As interfaces do sistema devem ser
Interface
implementadas como formulários acessíveis em
um browser html.
A camada de persistência deve ser implementada Persistência
de forma que diferentes tecnologias de bancos de
dados possam vir a ser utilizadas no futuro
( )
( )
( )
(x)
S3 Perfis de usuário
Os perfis de usuário para acesso ao sistema são:
3. Administrador - pode efetuar todas as
operações.
2. Operador - pode efetuar as operações de
empréstimo, devolução, pagamento e
cadastramento.
1. Convidado - pode efetuar apenas consultas
nos próprios dados (cliente).
Segurança
( )
( )
...
...
...
...
...
S2 Armazenamento de
dados
Categoria
Desejável
Permanente
Desafios da Análise de
Requisitos
Como descobrir os requisitos
Como comunicar os requisitos para as
outras fases e as equipes do projeto
Como lembrar dos requisitos durante
o desenvolvimento e verificar se
foram todos atendidos
Como gerenciar a mudança
Organização dos Requisitos
Casos de Uso
Manutenção de Conceitos (Entidades)
Consultas/Relatórios
Casos de Uso
Caso de Uso
Um cenário de interação usuário-sistema
Ordenação de um subconjunto de requisitos
funcionais, e seus requisitos não-funcionais
associados, relacionados com a interação
Implica em mudança de estado do sistema (
consulta / relatório)
Pouco detalhado na fase de concepção
Bastante detalhado na fase de elaboração
(refinamento de casos de uso)
Caso de Uso (2)
Um caso de uso pode ser também
pensado como um grande  nível de
agregação mais alto  requisito
funcional
Caso de
Uso
F1
F2
Fi
Pelo menos um requisito funcional deve modificar
o estado do sistema
Fn
Caso de Uso (3)
O nome de um caso de uso é sempre
uma expressão verbal
Emprestar Fitas
Devolver Fitas
Reservar Fitas
Validação de Requisitos
Funcionais
Dado um requisito funcional, ele deve
aparecer em pelo menos
um caso de uso, ou
uma manutenção de entidade, ou
um relatório / consulta
Organizando Requisitos em Casos
de Uso
Nome
Atores
Descrição
Emprestar Cliente,
O cliente se identifica e identifica as fitas que deseja levar.
Fitas
Funcionário O funcionário faz o registro e libera as fitas para
empréstimo.
Devolver
Cliente,
O cliente entrega ao funcionário as fitas. O funcionário
Fitas
Funcionário faz o registro da devolução e o cliente efetua o pagamento
devido.
Reservar
Cliente,
O cliente solicita a reserva de um ou mais filmes. O
Fitas
Funcionário funcionário registra a reserva.
Referências Cruzadas
F1, F3, F5, F9, F10
F2, F4, F6, F7, F8
F11, F12
Exercício: Mostre que cada caso de uso modifica,
à sua maneira, o estado do sistema
Diagrama UML de Casos de Uso (Alto Nível,
ou sem Decomposição)
Diagrama de Caso de Uso
Em geral, na fase de concepção, um
caso de uso não é decomposto
Decomposição é detalhamento (fase de
elaboração)
Atores primários e secundários
Funcionário: primário
Interage diretamente com o sistema
Cliente: secundário
Interage com o sistema via um ator primário
‘Tamanho’ de um Caso de Uso
Um caso de uso deve ser uma unidade lógica de trabalho
Critérios de tamanho de um caso de uso
De 3 a 10 passos
Um passo é um elemento descritivo, não necessariamente um requisito
Duração de minutos a 1 hora
Um caso de uso deve ser interativo, com informações fluindo
para dentro e para fora do sistema
Um caso de uso deve produzir uma alteração consistente na
informação armazenada
Uma seqüência de consultas puras ao sistema não caracteriza
um caso de uso
‘Tamanho’ de um Caso de Uso (2)
Algumas operações relativamente
simples e elementares (de um único
passo), como o registro de uma fita,
ou de um pagamento, não devem ser
consideradas como casos de uso por si
só (um único passo)
Outra maneira de dizer: nestas casos, o
caso de uso reduz-se a um requisito
funcional
Modelo Conceitual Preliminar
Modelo Conceitual
A entrada para o modelo conceitual são os
casos de uso
Cada conceito ou entidade, assim como seus
relacionamentos, deve aparecer direta ou
indiretamente nas descrições dos casos de uso
Terminologia UML
Diagrama de Classes em Alto Nível, ou Diagrama
de Entidades e Relacionamentos
‘Mais tarde’, conceitos ou entidades se tornam classes
de software
Diagrama de Classes
Caso de Uso: Diagrama Preliminar
de Entidades e Relacionamentos
Entidades (não exaustivamente)
Cliente, Empréstimo, Reserva, Fita
Note que entidades são designadas por substantivos
Relacionamentos (não exaustivamente)
Cliente Fez Empréstimo
Cliente Solicitou Reserva
Empréstimo Locou Fita
Reserva Referenciou Fita
Note que relacionamentos são designados por verbos
Estes relacionamentos e entidades foram
extraídos dos casos de uso Emprestar Fitas e
Reservar Fitas
Diagrama Preliminar
Diagrama Preliminar (2)
Note que o diagrama está incompleto
Faltando contemplar o caso de uso
Devolver Fitas
Esta situação é normal, na fase de
concepção
Os refinamentos e detalhamentos são
feitos principalmente durante a fase de
elaboração
Diagrama Preliminar (3)
Note também que faltam as
multiplicidades dos relacionamentos
1:1
1:N
M:N
As multiplicidades devem aparecem já
no modelo conceitual preliminar
Diagrama Preliminar (4)
Exercícios
Qual a diferença entre Modelo e Diagrama?
Modifique o diagrama para só contemplar um
empréstimo ou uma reserva correntes
Inclua as multiplicidades dos relacionamentos
Modifique o diagrama para contemplar
históricos de empréstimos e reservas
Inclua as multiplicidades dos relacionamentos
Manutenção de Conceitos ou
Entidades
O Padrão Manutenção de Caso
de Uso
Cada conceito normalmente tem operações
associadas de
inserção (I)
alteração (A)
exclusão (E)
consulta a um conceito (C)
Isso configura um padrão de caso de uso
Manter Conceitos ou Entidades
Cada caso de uso do padrão é uma manutenção de
entidade
Recebe um tratamento específico e simplificado
Manutenção (Estudo de Caso)
Conceito I A E C
Obs
Ref.
Cruza
das
Cliente
X
X
X
X
Só é possível excluir se não
houver empréstimos
associados
F13, F14,
F20, F21
Fita
X
X
X
X
Só é possível excluir se não
houver empréstimos
associados
F18, F30,
F31, F32
Reserva
X
I, A e E: dentro dos casos de F15, F16
uso Reservar Fitas (I e A) e
Emprestar Fitas (E)
Empréstimo
X
A: não é possível
I e E: dentro dos casos de
uso Emprestar Fitas (I) e
Devolver Fitas (E)
F17, F19
Consultas / Relatórios
Organização de Requisitos em
Consultas / Relatórios
Muitos requisitos funcionais não mudam o
estado do sistema
Eles podem ser organizados em consultas /
relatórios
Não incluem consultas a entidades simples
Consultas / relatórios são importantes para
validar modelos conceituais
Importante: qualquer sistema de
informação tem um conjunto relativamente
diverso de consultas / relatórios
Organização de Requisitos em
Consultas / Relatórios (Estudo de
Caso)
Nome
Vendas Mensais
Clientes Suspensos
...
Referências Cruzadas
F20, F21, F22
F13, F23, F1
...
Planejamento das Iterações
Planejamento do
Desenvolvimento
Alocar o desenvolvimento em ciclos
iterativos de mesma duração
Observar as fases do processo UP
(“Major milestones”)
Estimativa de esforço para cada
iteração
Estabelecendo Prioridades
Prioridade #1: Casos de Uso Críticos
Definidos pelo cliente
Prioridade #2: Casos de Uso Nãocríticos
Prioridade #3: Manutenção de
Conceitos
Prioridade #4: Consultas / Relatórios
Estabelecendo Prioridades (2)
Fase de Elaboração
Requisitos funcionais
Alguns requisitos não-funcionais
associados a requisitos funcionais
Fase de Construção
Requisitos não-funcionais associados a
requisitos funcionais
Requisitos não-funcionais suplementares
Planejamento dos Ciclos
Iterativos (Fase de Elaboração)
Ciclo
1
2
3
4
Casos de
Uso
Emprestar
Fita (550)
Manutenção de
Informações
-
Consultas
Observações
-
Devolver Fita
(300)
Reservar
Filme (270)
-
-
-
Neste ciclo ainda não será
implantado o mecanismo de
persistência
Implementar mecanismo de
persistência (300 horas)
-
Fita (100), Cliente (100) e Reserva (100)
Emprestimo (100)
todas (400)
-
Esforço
estimado
550 horas
600 horas
570 horas
500 horas
Cronograma de Execução
Considerar
Tempo total estimado para o projeto (em
hora/pessoa)
Tempo disponível (em semanas ou meses)
Tamanho da equipe
Estruturação em equipes
Planejamento com 4 equipes
Dias:
1-10
11-20
Ciclo 1
análise projeto
Ciclo 2
análise
Ciclo 3
Ciclo 4
Implantação
21-30
implementação
projeto
análise
31-40
testes
implementação
projeto
análise
41-50
51-60
61-70 70-90
testes
implementação testes
projeto
implementação testes
implantação
Planejamento com 2 equipes
Dias:
Ciclo 1
Ciclo 2
Ciclo 3
Ciclo 4
Implantação
1-20
análise
21-40
projeto
41-60
impl.
análise
61-80
testes
projeto
81-100
101-120
impl.
análise
testes
projeto
121-140
141-160
161-180
181-200
impl.
análise
testes
projeto
impl.
testes
201-220
implant.
Observações
Note que, associando requisitos nãofuncionais a requisitos funcionais, uma
parte dos requisitos não-funcionais é
implementada na fase de elaboração
Fase de construção: os demais requisitos nãofuncionais e os requisitos suplementares
Note também que, trabalhando com várias
equipes, somente as atividades de
implementação-testes são seqüênciais
Atividades de análise-projeto podem ocorrer
em paralelo
Projeto do Curso
Projeto
Fase Início (Concepção, Planejamento)
Documento constando de:
Sumário Executivo
Requisitos Funcionais e Não-funcionais Associados
Requisitos suplementares
Casos de uso
Modelo Conceitual
Manutenção de Entidades
Consultas / Relatórios
Planejamento das Iterações
Prazo de entrega: 20/07