MINISTÉRIO DA EDUCAÇÃO
SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA TRIÂNGULO MINEIRO Campus Uberlândia Centro
Licenciatura em Computação
Graduação
Disciplina: Análise e Projeto de Sistemas
Levantamento de Requisitos
Prof. Dr. Nelio Alves –nelioalves.com
•
Declaração de trabalho
•
Documento de requisitos preliminar
•
Requisitos funcionais
•
Casos de uso
•
Requisitos não funcionais
Disciplina (subprocesso)
Iniciação
Identificação de escopo, estimativas de custo e prazo, estudo dos principais riscos e análise de viabilidade. Decidir
se continuar ou cancelar o projeto.
Elaboração
Examinar os objetivos e escopo detalhados do sistema, a escolha da arquitetura e a resolução dos maiores riscos.
Análise de negócios • Modelo de negócios Análise de requisitos • Declaração de trabalho
• Documento de requisitos (preliminar)
(objetivo: delimitar escopo)
• Documento de requisitos (detalhado)
(objetivo: guiar os outros subprocessos)
Análise & Projeto • Modelo conceitual • Projeto da camada de domínio (DCP)• Projeto das realizações de casos de uso
Situando-se:
Declaração de trabalho
Documento de formato livre no qual o analista descreve o que conseguiu
descobrir de relevante sobre o sistema após as conversas iniciais com
clientes e usuário.
• Outros nomes: Sumário executivo ou Visão geral do sistema (WAZLAWICK, 2011) • Não deve ser longo ou detalhado demais.
• Possui informações de nível gerencial e operacional.
• Pode também conter outras preocupações relevantes para o cliente, tais como informações sobre tecnologias a serem empregadas.
Favor acessar o documento de Declaração de Trabalho do nosso exemplo de livraria:
https://sites.google.com/a/iftm.edu.br/nelio/analise-e-projeto-orientado-a-objetos/exemplo-livraria
Como construir um documento de Declaração de Trabalho?
Outro exemplo: sistema simplificado de transações bancárias:
https://sites.google.com/a/iftm.edu.br/nelio/arquivos/apoo-banco-dt.rar
•
Declaração de trabalho
•
Documento de requisitos preliminar
•
Requisitos funcionais
•
Casos de uso
•
Requisitos não funcionais
Documento de requisitos preliminar
Objetivo:
Levantar os requisitos funcionais e não-funcionais do sistema a ser desenvolvido, de modo que se possa delimitar o escopo do mesmo e estabelecer as estimativas de custo e prazo para celebração contratual.
Construído na fase de iniciação do projeto.
Requisito
"Uma condição ou capacidade de um software que deve ser implementada por um sistema ou componente de sistema para satisfazer um contrato, padrão, especificação ou outra documentação formal" (LEFFINGWELL, 2006)
Características de um bom requisito:
• Completo • Consistente • Validável • Rastreável
• Deve ter aprovação dos envolvidos • Deve agregar valor ao negócio
Atributos dos requisitos
• Benefício: indica o grau de benefício esperado pelo requisito.
• Crítico: sua ausência compromete o negócio
• Importante: sua ausência prejudica, mas não chega a comprometer • Desejável: pouco utilizados e que podem até não ser contemplados
• Estabilidade: reflete a probabilidade do requisito sofrer alterações futuras. Reflete
o grau de entendimento do requisito pela equipe do projeto e pelo solicitante. • Alta: entendimento claro
• Média: que ainda possui pendências a serem esclarecidas pelo solicitante • Baixa: cuja mudança é certa, possui muitas pendências de esclarecimentos
• Situação: proposto, aprovado, cancelado (outras)
• Risco: alto, médio, baixo
O risco de um requisito aumenta conforme possuir baixa estabilidade, alta complexidade, novidades tecnológicas, dependências externas ou gerenciais, etc.
Classificação de requisitos
Funcionais Não funcionais Com interação com usuário (Casos de uso) Sem interação com usuário CRUD RelatórioOutros (processo de negócio)
Batch Classificação da ISO/IEC 9126 Processamento interno Classificação FURPS+ Integração ou
•
Declaração de trabalho
•
Documento de requisitos preliminar
•
Requisitos funcionais
•
Casos de uso
•
Requisitos não funcionais
Agenda
Requisitos funcionais
São requisitos relacionados diretamente ao negócio. Consistem de uma operação e/ou
consulta de negócio no sistema.
Podem ser vistos como requisitos que consistem em processamento de dados.
Representa uma funcionalidade que o sistema deve realizar, independentemente da
tecnologia, performance, usabilidade, etc.
Exemplos:
• Consultar produtos • Cadastrar cliente • Realizar vendas
• Identificar produtos favoritos ao usuário • Processar fila de mensagens
•
Declaração de trabalho
•
Documento de requisitos preliminar
•
Requisitos funcionais
•
Casos de uso
•
Requisitos não funcionais
Agenda
Representando requisitos funcionais
Requisitos funcionais que envolvem interação com usuário são
tipicamente representados por
CASOS DE USO
(de sistema).
O que é um caso de uso (de sistema)?
Um caso de uso é a descrição
da interação de um ou mais
usuários
(atores)
com
o
sistema a fim de efetuar um
fluxo de trabalho com um
significado coeso.
Caso de Uso: Comprar livros (cenário principal)
1. [IN] O comprador informa sua identificação. 2. [OUT] O sistema informa os livros disponíveis
para venda (título, capa e preço).
3. [IN] O cliente seleciona os livros que deseja comprar.
4. [OUT] O sistema informa o valor total dos livros e apresenta as opções de endereço cadastradas.
5. [IN] O cliente seleciona um endereço para entrega.
6. [OUT] O sistema informa o valor do frete e total geral.
7. [IN] O cliente seleciona um cartão de crédito. 8. [OUT] O sistema envia os dados do cartão e
valor da venda para a operadora. 9. [IN] A operadora informa o código de
autorização.
10.[OUT] O sistema informa o prazo de entrega.
Obs.: um caso de uso pode
ter um ou mais cenários.
Observação:
Um requisito funcional pode corresponder a um ou mais casos de uso. Veja o exemplo:
O sistema deve:
"Manter todos dados dos campeonatos"
Este requisito expressa bem uma necessidade, porém não é coeso. * não-coeso = refere-se a várias coisas diferentes.
Requisito:
"Manter time"
Casos de uso correspondentes:
"Manter partida"
"Manter campeonato"
O requisito foi desmembrado em várias funcionalidades coesas. Cada uma será um caso de uso.
Propriedades de um caso de uso
• Deve ser monossessão
• Deve poder rodar de forma independente (isoladamente) • Deve gerar resultados consistentes
• Deve ser interativo
1) Casos de uso devem ser monossessão
1) Uma organização possui processos de negócio para atingir seus objetivos. 2) Um software serve para automatizar os
processos de negócio.
Então, vou ter que criar um caso de uso para cada processo de negócio?
Não necessariamente!
Casos de uso de sistema devem representar usos "rápidos" do sistema. Casos de uso devem ter início e fim em tempo contíguo (sem interrupções - monossessão).
Já um processo de negócio pode ser interrompido, continuado em outro dia. Além disso, podem durar dias, meses etc.
Exemplo:
Suponha que seu cliente (uma empresa de comércio) tem o seguinte processo de negócio: Comprar produtos
Seu cliente quer um sistema para automatizar esse processo.
Quais casos de uso o sistema deverá ter?
Exemplo:
Suponha que seu cliente (uma empresa de comércio) tem o seguinte processo de negócio: Comprar produtos
Qual das opções é apropriada? (1)
Gerir compras de produtos (2) Solicitar produtos Retirar produtos Conferir produtos Solicitar reposição Atualizar estoque (3)
Enviar pedido de produtos Enviar pedido de reposição Registrar entrada de produtos
Qual das opções é apropriada? (1)
Gerir compras de produtos (2) Solicitar produtos Retirar produtos Conferir produtos Solicitar reposição Atualizar estoque (3)
Enviar pedido de produtos Enviar pedido de reposição Registrar entrada de produtos
Exemplo:
Suponha que seu cliente (uma empresa de comércio) tem o seguinte processo de negócio: Comprar produtos
2) Casos de uso devem poder rodar de forma independente
1) Eu posso ter mais de um caso de uso para automatizar um processo
Quer dizer então que eu tenho que pensar os casos de uso em sequência, como se tivesse
montando um algoritmo?
Não!
Casos de uso são partes de processos que podem ocorrer "sozinhos". Podem iniciar e terminar "sozinhos", sem necessidade de outros processamentos (para isso devem ter um significado lógico coeso para o processo).
Exemplo:
Quais das opções seriam casos de uso do sistema?Fazer login
Calcular total de itens do pedido Enviar pedido de produtos Digitar senha
Gerir compras de produtos
Exemplo:
Quais das opções seriam casos de usodo sistema? Fazer login
Calcular total de itens do pedido Enviar pedido de produtos Digitar senha
Gerir compras de produtos
Dependem de um uso maior. Dependem de um uso maior. Não é coeso Não é coeso
3) Casos de uso devem gerar RESULTADOS CONSISTENTES
Posso iniciar uma transação de banco de dados com um caso de uso e depois encerrar a
transação em outro caso de uso?
NÃO!
Mais uma vez: o caso de uso deve ser um uso que pode ocorrer de forma independente ("sozinho", independente de outros processamentos).
Um caso de uso consiste em uma sequência de transações. Assim, um caso de uso deve pegar o sistema em um estado consistente e entregar o sistema em outro estado também consistente.
4) Casos de uso devem ser interativos
Não!
Casos de uso são, como o nome diz, devem representar usos do sistema por parte dos usuários (atores). Devem ser interativos.
Exemplos: NÃO são casos de uso:
• Fazer backup automático dos dados • Processar fila de mensagens
• Efetuar coleta de lixo de memória (muito menos este! rs)
Processamentos internos são casos de uso?
Nota: lembre-se que processamentos internos são
Mas o que são atores?
1) Atores são usuários Então atores são pessoas?
Não! Atores são papéis (role)
Um ator de sistema representa um usuário do sistema que é responsável por efetuar uma
interação com o sistema. É "quem" exerce um papel no uso do sistema.
Nota: na área de processos de negócio, também existe o conceito de ator do processo é o
responsável por uma atividade do processo. É quem exerce um papel no processo.
Exemplo (sistema):
Ator de um sistema é um papel que pode ser desempenhado por:
• Uma pessoa (Gerente, Cliente, Fornecedor, Secretária)
• Um sistema ou máquina (Sistema de Captação de Pedidos, Sistema de Logística) • Uma entidade administrativa/jurídica (Processadora de Cartão)
• Etc.
Um ator de sistema representa um usuário do sistema que é responsável por efetuar uma interação com o sistema.
Exemplo (processo):
atores do processo
Ator de um processo é um papel que pode ser desempenhado por:
• Uma pessoa
• Um departamento ou serviço (ex: entrega, ouvidoria, compras, etc.) • Uma empresa
• Um órgão governamental • Um sistema ou máquina • Etc.
Um ator de um processo é o responsável por uma atividade do processo
Atores de sistema serão os perfis de acesso ao sistema?
1) Atores são papéis
Então os atores do sistema serão os perfis de usuário para permissões de acesso ao sistema?
Em geral sim.
A definição dos atores do sistema serve como base para a definição dos perfis de acesso ao sistema (não quer dizer necessariamente que esta correspondência será 1-1).
Porém, na fase de iniciação a identificação dos atores não precisa já ser definitiva, pois o objetivo é entender o sistema e não já definir todos os perfis de acesso.
Diagramas de caso de uso
Diagramas de caso de uso
Serve para mostrar, de forma gráfica, uma visão geral dos casos de uso do
sistema ou de parte dele.
Serve para representar:
• os casos de uso• os atores que interagem com os casos de uso • as relações entre eles
Atenção
Diagrama de caso de uso não é o mais importante.
O diagrama somente não agrega muito valor à especificação. Ele apenas
mostra os casos de uso, atores e os relacionamentos entre eles.
Essa informação pode ser inclusive mostrada de forma tabular ou textual.
Praticamente todo o valor do caso de uso vai estar em seu detalhamento.
Itens de paleta utilizados:
• Caso de uso (elipse) • Ator (boneco) • Interação (linha) • Sistema (retângulo)
No diagrama:
• Usuário, Cliente e Agente interagem com o caso de uso "Pesquisar Vôos"
• Cliente interage com o caso de uso "Cancelar Reserva"
• Cliente e Agente interagem com o caso de uso "Reservar Vôo"
Itens de paleta utilizados:
• Generalização ("é um")
No diagrama:
• Cliente é um Usuário • Agente é um Usuário
Itens de paleta utilizados:
• Relação de extensão de funcionalidade.
No diagrama:
"Realizar Upgrade no Vôo" estende a funcionalidade de "Reservar Vôo".
A extensão é OPCIONAL: deve existir pelo menos um cenário do caso de uso no qual o caso de uso de extensão não é também realizado.
No diagrama:
"Cadastrar Vôo" inclui a funcionalidade de "Pesquisar Aviões".
Presume-se obrigatoriedade no <<include>>: independentemente do cenário realizado, o caso de uso incluído é realizado também.
Itens de paleta utilizados:
• Relação de inclusão de funcionalidade
•
Declaração de trabalho
•
Documento de requisitos preliminar
•
Requisitos funcionais
•
Casos de uso
•
Requisitos não funcionais
Requisitos não-funcionais
São aqueles que impõem restrições e definem atributos de qualidade ao sistema. Alguns são percebidos pelo usuário e outros não.
Classificação de requisitos
Classificação FURPS+ • Funcionalidade
• Usabilidade • Confiabilidade • Performance
• Suportabilidade (plataformas, SO, distribuição, protocolos de comunicação)
O + significa que outros tipos de requisitos são também importantes, tais como:
• Restrições de projeto (procedimentos, etc.)
• Requisitos de implementação (padrões de codificação, etc.) • Tecnologias empregadas
• Requisitos de integração (interface com outros sistemas) • Requisitos físicos • Responsividade • Escalabilidade • Manutenibilidade • De documentação • De treinamento • Não-requisitos • etc.
Obs: as classificações não são mutuamente excludentes. Porém, por questões práticas, cada requisito é descrito no documento em um único tópico.
Classificação de requisitos
Classificação da ISO/IEC 9126:
Obs: as classificações não são mutuamente excludentes. Porém, por questões práticas, cada requisito é descrito no documento em um único tópico.
Favor acessar o Documento de Requisitos preliminar do nosso exemplo de livraria:
https://sites.google.com/a/iftm.edu.br/nelio/analise-e-projeto-orientado-a-objetos/exemplo-livraria