Análise e Projeto Orientados a Objetos Aula IV Requisitos. Prof.: Bruno E. G. Gomes IFRN

Transcrição

1 Análise e Projeto Orientados a Objetos Aula IV Requisitos Prof.: Bruno E. G. Gomes IFRN 1

2 Introdução Etapa relacionada a descoberta e descrição das funcionalidades do sistema Parte significativa da fase de concepção do PU Objetivos desta aula: Levantar e analisar requisitos Definir requisitos funcionais e não funcionais Escrita do documento de requisitos 2

3 Identificação de requisitos O analista pode utilizar diversas fontes Departamentos, pessoas, clientes, interfaces, sistemas, etc. Para cada fonte, identificar as funções que o sistema irá disponibilizar A partir de diagramas de atividades e máq. de estados Identificar as funções necessárias para realizar as atividades ou as mudanças de estado Duas etapas principais Levantamento de requisitos Análise de requisitos 3

4 Levantamento de Requisitos Processo de descobrir e descrever: Quais funções o sistema deve realizar Quais são as restrições que existem sobre essas funções Exemplo de funções (livraria): controlar a compra e venda de livros, calcular automaticamente os pagamentos, gerar relatórios de vendas, etc. O conjunto de operações descobertas constituem a funcionalidade do sistema Por isso são chamadas de requisitos funcionais Restrições (requisitos não funcionais)dizem respeito a: De que forma, como, para quem, por quanto tempo... essas operações se realizam? 4

5 Levantamento de requisitos Na fase de concepção o levantamento de requisitos deve ser rápido Feito em extensão, não em profundidade O analista deve entender a extensão do que o sistema deve fazer, mas sem detalhar como ele vai fazer Um dos objetivos finais da fase de concepção é organizar a divisão do trabalho em casos de uso Serão associados aos ciclos iterativos nas fases de elaboração e construção Levantamento deve ser uma etapa de descoberta e não de invenção Os requisitos não descobertos nesta etapa podem ser acomodados ao longo do processo de desenvolvimento 5

6 Levantamento de requisitos Atenção: Requisitos são solicitações do cliente ou usuário e não um planejamento do analista São a memória das solicitações do cliente e não o início do projeto do sistema Desafios dos requisitos Como descobrir? Como comunicar os requisitos para outras fases ou equipes de projeto? Como lembrar dos requisitos e verificar se eles foram atendidos? Como gerenciar a mudança dos requisitos? 6

7 Requisitos Funcionais Devem conter os seguintes elementos: a) Descrição de uma função a ser executada pelo sistema (entrada/saída/transformação de informação) Ex.: cadastrar comprador, emitir relatório de vendas no mês b) A origem do requisito (quem solicitou) e/ou quem é o responsável pela execução da função (usuário) Importante para verificar o atendimento aos requisitos c) Quais informações são passadas do sistema para o usuário e vice-versa quando a função for executada Importante para a compreensão e análise do requisito d) Quais restrições lógicas (regras de negócio) ou tecnológicas se aplicam à função requisitos não-funcionais 7

8 Requisitos Não-funcionais Aparecem sempre ligados aos requisitos funcionais Podem ser lógicos ou tecnológicos Restrições lógicas Regras de negócio relacionadas à função em questão Ex.: no registro de uma venda: não efetuar a venda caso a operadora de cartão não autorize o pagamento Restrições tecnológicas Interface utilizada (Web, desktop, celular, etc.) Protocolo de comunicação, Tempo de resposta do sistema Segurança e tolerância a falhas, etc. Ex.: a autorização de débito no cartão não deve levar mais que cinco segundos. 8

9 Requisitos não-funcionais suplementares Todo tipo de restrição não-funcional que se aplica ao sistema como um todo não apenas a uma função individual Exemplos: O sistema deve usar um SGBD X O sistema deve ser implementado na linguagem X devido a tal motivo O sistema deve seguir determinado padrão de interface ou look and feel Cuidado com a redação Prefira O sistema terá ajuda on-line em todas as telas e para todas as funções a o sistema deve fornecer ajuda ao usuário 9

10 Documento de Requisitos Registra o que o sistema deve fazer e sob quais condições Eventuais lacunas serão preenchidas durante a fase de elaboração Pode ser organizado de forma textual ou na forma de um diagrama (específicos de ferramentas CASE) Pode ser dividido em subsistemas, caso o sistema seja de maior porte Formato: Índice principal contendo nome das funções ou requisitos suplementares Corpo contendo o detalhamento de cada requisito 10

11 Documento de requisitos exemplo Sistema Livraria Virtual Documento de requisitos Requisitos funcionais 1. Registrar novos títulos a partir do catálogo das editoras. 2. Registar venda de livros. 3. Realizar encomendas de livros. 4. Registrar e autorizar pagamentos com cartão de crédito. 5. Registar e aplicar promoções. 6. Calcular custos de entrega. 7. Emitir relatório de livros mais vendidos. 8. Emitir relatórios de compradores mais assíduos. 9. Emitir sugestões de compras para usuários com base em compras anteriores. 10. Requisitos Suplementares 1. O sistema deve operar via interface Web 2. Todos os controles de interface devem ter um campo de ajuda associado

12 Documento de requisitos O detalhamento de cada requisito (em especial os funcionais) deve aparecer no corpo do documento Detalhamento dos requisitos é uma etapa fundamental Sem ele o sistema pode parecer mais simples do que realmente é. Exemplo detalhamento do requisito Registrar novos títulos a partir do catálogo das editoras 12

13 Análise de Requisitos Nesta fase o analista irá caracterizar os requisitos de acordo com certas propriedades Classificação de requisitos funcionais Permanentes e transitórios Evidentes e ocultos Obrigatórios e desejados 13

14 Requisitos permanentes e transitórios Pode ou não mudar? Decisão do analista Decisão relativa a tempo e custo de desenvolvimento Permanente: mais fácil e rápido implementar, mais caro de manter se o sistema mudar Transitório: mais caro e complexo desenvolver, mais barato e rápido de manter Requisitos transitórios devem ser suscetíveis a acomodar mudanças Requisitos mais importantes devem ser transitórios Espera-se que possam mudar no futuro e essa mudança causa maior impacto no sistema 14

15 Requisitos evidentes e ocultos Evidentes: funções efetuadas com o conhecimento do usuário Consultas, entradas de dados, etc. Ocultos: cálculos ou atualizações feitas pelo sistema sem a solicitação explícita do usuário Como consequência de outras funções efetuadas por ele Apenas requisitos evidentes corresponderão aos passos do caso de uso expandido Requisitos ocultos são associados a eles para serem lembrados no momento de projetar as operações de caso de uso Exemplos: Evidente emitir relatório de livros Oculto aplicar uma política de desconto 15

16 Requisitos obrigatórios e desejados Indicam uma prioridade no desenvolvimento Quanto a importância e tempo de desenvolvimento Obrigatórios devem ser feitos de qualquer maneira Aplica-se também a requisitos não-funcionais Quais restrições se deseja acomodar e quais são apenas desejáveis, se sobrar tempo e recurso, por exemplo Exemplo da livraria: A interface Web deve ser obrigatória Acesso através de celular deve ser desejável Normalmente, o desenvolvedor deve dizer quais requisitos vai entregar, em quanto tempo e a qual custo 16

17 Classificação de requisitos não-funcionais Classificado por diversos atributos por questão de organização Exemplos: Usabilidade Confiabilidade Desempenho Configurabilidade Segurança Implementação Interface Empacotamento Legais 17

18 Considerações finais Requisitos é uma etapa importante do desenvolvimento Foco no cliente e em suas necessidades Deve ser feita de forma rápida, em extensão, tentando buscar o maior número de funcionalidade e restrições Funcionalidades restantes serão acomodadas nos ciclos de desenvolvimento Posteriormente, os requisitos relacionados serão organizados em processos, denominados de casos de uso 18