• Nenhum resultado encontrado

Levantamento de Requisitos

N/A
N/A
Protected

Academic year: 2021

Share "Levantamento de Requisitos"

Copied!
21
0
0

Texto

(1)

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

(2)

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.

(3)

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

(4)

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

(5)

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ório

Outros (processo de negócio)

Batch Classificação da ISO/IEC 9126 Processamento interno Classificação FURPS+ Integração ou

(6)

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

(7)

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).

(8)

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.

(9)

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.

(10)

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

(11)

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).

(12)

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 uso

do 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

(13)

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

(14)

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.

(15)

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.

(16)

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

(17)

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"

(18)

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.

(19)

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

(20)

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.

(21)

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

Como construir um Documento de Requisitos preliminar?

Referências

Documentos relacionados

Segue abaixo uma recomendação de quais informações devem ser descritas para o levantamento inicial dos requisitos de um sistema:..

c) Mas o fecho não era perfeito [...] Ou dir-se-ia tão comumente que os Reinos de Espanha são as “Índias dos outros Reinos Estrangeiros”.. Explique o sentido histórico

Cty Cp Đầu Tư Kiến Trúc Xây Dựng Toàn Thịnh Phát kietbsc@gmail.com thienduc_branch@yahoo.com .vn C.Ty Tnhh Công Nghệ Và Thương Mại Phương

´ Sob a dire ¸c ˜ao da Comiss ˜ao dos Coordenadores, esse departamento fornece `as ag ˆencias de not ıcias informa ¸c ´ ˜oes corretas sobre as Testemunhas de Jeov ´a,

Nesta segunda emanação ou manifestação de vida, o Logos prepara todo o suporte e estrutura para que os átomos permanentes das mónadas humanas

“Eu não preciso fazer cálculos previdenciários, eu tenho um software ou posso contratar alguém para fazer isso...”..

Tendo-se adoptado as disposições construtivas regulamentares que permitem a dispensa da verificação da segurança a este estado

Desligue o aparelho de ar condicionado e desconecte a unidade se não a for usar durante muito tempo.. Desligue e desconecte a unidade durante