Breve revisão dos requisitos
O que são requisitos?
Uma sentença identificando uma capacidade, uma
característica física ou um fator de qualidade que limita
um produto ou um processo (IEEE 1220-1994).
Requisitos do usuário
É algum comportamento ou característica que o usuário deseja do
software ou o sistema como um todo.
O que o usuário quer.
São escritos pelo próprio usuário ou levantados por um analista de sistemas
que consulta o usuário.
Requisitos do sistema
É algum comportamento ou característica exigido do sistema como um
todo, incluindo hardware e software.
O comportamento desejado do sistema.
São normalmente levantados por engenheiros ou analistas de sistemas,
refinando os requisitos dos usuários e os transformando em termos de
engenharia.
Características de um bom requisito
Necessário: Se retirado, ele não atenderá plenamente as expectativas do
usuário.
Não devem existir requisitos do tipo “seria interessante ter”.
Deve ser levado em conta que cada requisito aumenta a complexidade e o
custo do projeto.
Não-ambíguo: Possui uma e apenas uma interpretação.
Verificável: Não ser vago ou geral e sendo quantificado de uma maneira
que permita a verificação de uma das seguintes formas: inspeção, análise,
demonstração ou teste.
Características de um bom requisito
Conciso: Cada requisito define apenas um requisito que deve ser feito e apenas o que deve ser feito, de maneira clara e simples.
Não inclui explicações, motivações, definições ou descrições do seu uso.
Alcançável: Realizável a um custo definido por uma ou mais partes do sistema.
Consistente: Não contradiz ou duplica outro requisito.
Ordenável: Por estabilidade e/ou importância.
Aceito: Pelos usuários e desenvolvedores.
Características de um bom requisito
Requisito for funcional, deverá ser também Independente da
Implementação.
O requisito define o que deve ser feito, mas não como!
Como fazer os requisitos?
Devemos chegar ao problema:
É necessário que todos concordem com a definição do problema.
Entender as causas do problema:
O problema por trás do problema pode ser mais importante, sendo que o problema visto inicialmente é apenas um sintoma.
Identificar todos os stakeholders e usuários.
Definir a fronteira do sistema de solução.
Identificar as restrições impostas à solução.
Requisitos funcionais e de informação
Requisito funcional:
Representa algo que o sistema deve fazer, ou seja, uma função esperada do
sistema que agregue algum valor a seus usuários.
Requisito informação:
Representa a informação que o cliente deseja obter do sistema.
São as respostas fundamentais do sistema.
Requisitos não funcionais
São a forma como os requisitos funcionais devem ser alcançados.
Eles definem propriedades e restrições do sistema.
Muitos requisitos não funcionais são também requisitos de qualidade,
como exigências de desempenho e robustez.
Outros são restrições ou exigências de uso de tecnologia.
Requisitos não funcionais
Exemplo de Requisitos
Em um sistema médico:
O sistema deverá permitir que um paciente marque uma consulta.
O sistema deverá confirmar que a consulta foi aceita pelo paciente.
Em um sistema para condomínios:
O sistema deverá permitir que um condômino solicite a segunda via de sua
conta condominial.
O sistema deverá permitir um aviso ao condômino que não pagar sua no prazo
correto.
Em um sistema para controle de produtos:
O sistema deverá permitir que um fornecedor cadastre um produto no
catálogo.
O sistema deverá informar ao sistema de estoques que um produto foi vendido
Dicas para formular os requisitos
Use sentenças e parágrafos curtos.
Use a voz ativa.
Use verbos no futuro.
Use os termos de forma consistente e mantenha um glossário.
Dicas para formular os requisitos
Para cada requisito, avalie se a partir de sua definição é possível
determinar se ele está pronto ou não.
Garanta que todos os requisitos são verificáveis imaginando (e
possivelmente documentando) uma forma de fazê-lo.
Verifique requisitos agregados e divida-os.
Mantenha um nível de detalhe único em todos os requisitos.
Requisitos suplementares
O que são requisitos suplementares?
São requisitos não funcionais.
Os requisitos suplementares são todo tipo de restrição tecnológica ou
lógica que se aplica ao sistema como um todo e não apenas a funções individuais.
Exemplo:
Errado
O sistema deve ser fácil de usar.
Certo
O sistema terá ajuda on-line em todas as telas e para todas as funções.
Requisitos Suplementares
18/10/2013 Profª.: Rosanete Grassiani dos Santos
18
Nome Restrição Categoria Desejável Permanente
S1 Tipo de Interface As interfaces do sistema devem ser
implementadas como formulários acessíveis em um browser html.
Interface ( ) ( )
S2 Armazenamento de
dados
A camada de persistência deve ser implementada
de forma que diferentes tecnologias de bancos de dados possam vir a ser utilizadas no futuro
Persistência ( ) ( 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 ( ) ( )
... ... ... ... ...
Documento de Requisitos
18/10/2013 Profª.: Rosanete Grassiani dos Santos
19
Sistema Livir
Documento de Requisitos
Requisitos funcionais
1. Registrar novos títulos a partir do catálogo das editoras.
2. Registrar vendas de livros.
3. Realizar encomendas de livros.
4. Registrar e autorizar pagamentos com cartão de crédito.
5. Registrar e aplicar promoções.
6. Calcular custos de entrega.
7. Emitir relatório de livros mais vendidos.
8. Emitir relatório de compradores mais assíduos.
9. Emitir sugestões de compra para compradores baseadas em
compras anteriores.
Requisitos suplementares
1. O sistema deve operar via interface Web
2. Todos os controles de interface devem ter um campo de ajuda
associado.
Documento de Requisitos
Alternativa 2
18/10/2013 Profª.: Rosanete Grassiani dos Santos
20
Desafios da Análise de Requisitos
Como descobrir os requisitos.
Como comunicar os requisitos para as outras fases ou equipes do projeto.
Como lembrar dos requisitos durante o desenvolvimento e verificar se
foram todos atendidos.
Como gerenciar a mudança.
18/10/2013 Profª.: Rosanete Grassiani dos Santos
21
Organização dos Requisitos
Casos de Uso
Os principais processos
“Manutenção” de Conceitos
Implementação das operações de cadastro
Consultas/Relatórios
Acesso à informação que não altera a informação em si
18/10/2013 Profª.: Rosanete Grassiani dos Santos
22
Organizando Requisitos em Casos de
Uso
O objetivo de listar os casos de uso é levantar informações sobre como o sistema interage com possíveis usuários e quais consultas e transformações são necessárias além daquelas já identificadas na fase de levantamento de requisitos.
18/10/2013 Profª.: Rosanete Grassiani dos Santos
23
Nome Atores Descrição Referências Cruzadas
Realizar venda de livros
Cliente O cliente se identifica e identifica os livros que deseja levar efetuando ao final o pagamento com cartão de crédito.
F1, F3, F5, F9, F10
Realizar encomenda de livros
Gerente O gerente autoriza a encomenda de livros faltantes e lançamentos as editoras.
F2, F4, F6, F7, F8
Registrar e aplicar promoções
Gerente O Gerente configura as promoções válidas em determinado período.
F11, F12
Organizando Requisitos em Casos de
Uso
Para descobrir os casos de uso, devem-se identificar os atores envolvidos com o sistema. Para tanto, o analista deve responder algumas perguntas:
Quem usa o sistema?
Quem mantém e configura o sistema?
Quais os outros sistemas de informação utilizam ou são utilizados pelo sistema?
Quem busca informações no sistema?
Quem provê informações para o sistema?
18/10/2013 Profª.: Rosanete Grassiani dos Santos
24
Diagrama de Casos de Uso UML
18/10/2013 Profª.: Rosanete Grassiani dos Santos
25
Diagrama de Casos de Uso UML
18/10/2013 Profª.: Rosanete Grassiani dos Santos
26
Diagrama de Casos de Uso UML
18/10/2013 Profª.: Rosanete Grassiani dos Santos
27
Granularidade de um Caso de Uso
Um caso de uso deve ser monossessão, ou seja, executado em uma única
interação e não se estendendo ao longo de vários dias .
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.
18/10/2013 Profª.: Rosanete Grassiani dos Santos
28
Organização de Requisitos em
Função de Conceitos
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ó, pois não há
necessidade de se estudar seu processo interativo, que
é de um único passo.
18/10/2013 Profª.: Rosanete Grassiani dos Santos
29
Organização de Requisitos em
Função de Conceitos
Sugere-se a criação de um modelo conceitual preliminar para facilitar esta
tarefa.
Indicar apenas os conceitos e associações que constituem informação a
ser armazenada pelo sistema.
18/10/2013 Profª.: Rosanete Grassiani dos Santos
30
Como Encontrar Conceitos e Atributos
Verificar o texto dos casos de uso expandidos.
Selecionar termos que representam informação transmitida do e para o
sistema.
Agrupar sinônimos
18/10/2013 Profª.: Rosanete Grassiani dos Santos
31
Cada conceito normalmente tem
associadas operações de:
inserção (I)
alteração (A)
exclusão (E)
consulta (C)
Também podem ser identificadas restrições ou regras de validação para execução das operações
18/10/2013 Profª.: Rosanete Grassiani dos Santos
32
Tabela para Representar Operações
de “Manutenção”
18/10/2013 Profª.: Rosanete Grassiani dos Santos
33
Conceito I A E C Observação Ref. Cruzadas
Cliente x x x x Só é possível excluir se não houver vendas associadas F13
Reserva x x x x F15, F16
Livro x x x x Só é possível excluir se não houver vendas associadas F18
Vendas x x A inclusão das vendas só pode acontecer através do caso de uso “Registrar venda de livros”. Não é possível alterar uma vendas, apenas excluir.
F17, F19
Modelo Conceitual Preliminar
18/10/2013 Profª.: Rosanete Grassiani dos Santos
34
Modelo Conceitual Preliminar
18/10/2013 Profª.: Rosanete Grassiani dos Santos
35
Organização de Requisitos em
Consultas
A identificação das consultas/ relatórios desejados na fase de concepção
pode ajudar muito no levantamento dos requisitos e na elaboração do
sistema.
Não precisam ser tratados como casos de uso.
São listados para auxiliar a construção das etapas posteriores.
18/10/2013 Profª.: Rosanete Grassiani dos Santos
36
Organização de Requisitos em
Consultas
18/10/2013 Profª.: Rosanete Grassiani dos Santos
37
Nome Referências Cruzadas
Vendas Mensais F20, F21, F22
Clientes Suspensos F13, F23, F1
... ...
Planejamento do Desenvolvimento
Alocar o desenvolvimento em ciclos iterativos de mesma duração.
Estimativa de Esforço:
Pontos de Função
Pontos de Caso de Uso
18/10/2013 Profª.: Rosanete Grassiani dos Santos
38
Estabelecendo Prioridades
Casos de Uso Críticos
Casos de Uso de Apoio
Conceitos
Consultas
18/10/2013 Profª.: Rosanete Grassiani dos Santos
39
Planejamento dos Ciclos Iterativos
18/10/2013 Profª.: Rosanete Grassiani dos Santos
40
Ciclo Casos de
Uso Manutenção de Informações
Consultas Observações Esforço estimado
1 Vender Livros (550)
- - Neste ciclo ainda não será implantado o mecanismo de persistência
550 horas
2 Encomenda Livros (300)
- - Implementar mecanismo de persistência (300 horas)
600 horas
3 Reservar Livros (270)
Livro (100), Cliente (100) e Reserva (100)
- - 570 horas
4 - Venda (100) todas (400) - 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 da equipe.
18/10/2013 Profª.: Rosanete Grassiani dos Santos
41
Planejamento com 4 equipes
18/10/2013 Profª.: Rosanete Grassiani dos Santos
42
Dias: 1-10 11-20 21-30 31-40 41-50 51-60 61-70 70-90
Ciclo 1 análise projeto implementação testes
Ciclo 2 análise projeto implementação testes
Ciclo 3 análise projeto implementação testes
Ciclo 4 análise projeto implementação testes
Implantação implantação
Planejamento com 2 equipes
18/10/2013 Profª.: Rosanete Grassiani dos Santos
43
Dias: 1-20 21-40 41-60 61-80 81-100 101-120 121-140 141-160 161-180 181-200 201-220
Ciclo 1 análise projeto impl. testes
Ciclo 2 análise projeto impl. testes
Ciclo 3 análise projeto impl. testes
Ciclo 4 análise projeto impl. testes
Implantação implant.
Dúvidas?
Atividade
Fazer uma pesquisa sobre diagrama de classes.
O que é?
Como funciona?
Fazer um exemplo.
Entregar em documento word ou escrito a mão.
Para o diagrama de classe deste trabalho não deverá ser utilizada ferramenta de diagramação.
Entrega no e-mail: [email protected] até 25/10/2013. Não serão aceitos trabalhos após esta data!