Levantamento de Requisitos

Transcrição

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 Agenda Documento de requisitos preliminar Requisitos funcionais Casos de uso Requisitos não funcionais 1

2 Situando-se: Disciplina (subprocesso) Análise de negócios Análise de requisitos Análise & Projeto 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. Modelo de negócios Declaração de trabalho Documento de requisitos (preliminar) (objetivo: delimitar escopo) Modelo conceitual Elaboração Examinar os objetivos e escopo detalhados do sistema, a escolha da arquitetura e a resolução dos maiores riscos. Documento de requisitos (detalhado) (objetivo: guiar os outros subprocessos) Projetoda camada de domínio (DCP) Projeto das realizações de casos de uso 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 gerenciale operacional. Pode também conter outras preocupações relevantes para o cliente, tais como informações sobre tecnologias a serem empregadas. 2

3 Como construir um documento de Declaração de Trabalho? Favor acessar o documento de Declaração de Trabalho do nosso exemplo de livraria: Outro exemplo: sistema simplificado de transações bancárias: Declaração de trabalho Agenda Documento de requisitos preliminar Requisitos funcionais Casos de uso Requisitos não funcionais 3

4 Documento de requisitos preliminar Objetivo: Levantar os requisitos funcionais e não-funcionais do sistema a ser desenvolvido, de modoquesepossadelimitaroescopodomesmoeestabelecerasestimativasdecustoe 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 Alinhado com os objetivos do negócio 4

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 Com interação com usuário (Casos de uso) CRUD Relatório Funcionais Outros (processo de negócio) Sem interação com usuário Batch Integração Processamento interno Não funcionais Classificação FURPS+ ou Classificação da ISO/IEC

6 Agenda Declaração de trabalho Documento de requisitos preliminar Requisitos funcionais Casos de uso Requisitos não funcionais Requisitos funcionais São requisitos relacionados diretamente ao negócio. Consistem de uma operaçãoe/ou consultade negócio no sistema. Podem ser vistos como requisitos que consistem em processamento de dados. Representa uma funcionalidadeque 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 Fazer backup automático dos dados 6

7 Agenda Declaração de trabalho Documento de requisitos preliminar Requisitos funcionais Casos de uso Requisitos não funcionais Representando requisitos funcionais Requisitos funcionais que envolvem interação com usuário são tipicamente representados por CASOS DE USO (de sistema). Mas o que é um caso de uso de sistema? 7

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. Obs.: um caso de uso pode ter um ou mais cenários. 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. Observação: Umrequisitofuncionalpodecorresponderaumoumaiscasosdeuso.Vejaoexemplo: Requisito: 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. Casos de uso correspondentes: "Manter time" "Manter partida" "Manter campeonato" O requisito foi desmembrado em várias funcionalidades coesas. Cada uma será um caso de uso. 8

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 Não necessariamente! 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? 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. 9

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 10

11 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 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). Eles podem, entretanto, estabelecer pré-condições e pós-condições (veremos depois). 11

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 Não é coeso Dependem de um uso maior. 12

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 Processamentos internos são casos de uso? Não! Casos de uso são, como o nome diz, devem representar usosdo 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) Nota: lembre-se que processamentos internos são requisitos funcionais. 13

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 sistemarepresenta um usuário do sistema que é responsávelpor efetuar uma interaçãocom o sistema. É "quem" exerce um papelno 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. É "quem" interage com o sistema. 14

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 basepara 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. 15

16 Diagramas de caso de uso Diagramas de caso de uso Serve para representar: os casos de uso os atores que interagem com os casos de uso as relações entre eles Serve para mostrar, de forma gráfica, uma visão geraldos casos de uso do sistema ou de parte dele. 16

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" Clientee Agenteinteragem com o caso de uso "Reservar Vôo" Secretário interage com o caso de uso "Cadastrar Vôo" 17

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

19 Itens de paleta utilizados: Relação de inclusão de funcionalidade 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. Declaração de trabalho Agenda Documento de requisitos preliminar Requisitos funcionais Casos de uso Requisitos não funcionais 19

20 Requisitos não-funcionais São aqueles que impõem restriçõese definem atributos de qualidadeao 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. 20

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. Como construir um Documento de Requisitos preliminar? Favor acessar o Documento de Requisitos preliminar do nosso exemplo de livraria: 21