3 Requisitos de alto nível

Transcrição

1 3 Requisitos de alto nível Atores de sistema Casos de uso de sistema Como encontrar casos de uso de sistema no modelo de negócio Requisitos Modelo conceitual preliminar

2 3.1 Introdução aos requisitos de alto nível Casos de uso de sistema em alto nível ou resumido = requisitos funcionais de alto nível. Anotações nos casos de uso = requisitos não funcionais. Especificações suplementares = requisitos suplementares

3 Utilidade dos casos de uso de sistema Definição e validação da arquitetura do sistema Criação de casos de teste Planejamento de iterações Base para documentação do usuário

4 3.2 Atores de sistema Entidade do mundo real que interage com o sistema por meio de um caso de uso. Tipos: Humano Sistema

5 Sistemas atores São sistemas de informação completos. Não são módulos ou partes do sistema sendo desenvolvido.

6 3.3 Casos de uso de sistema Caso de uso de negócio Processos da organização Caso de uso de sistema Processos de uso de um sistema a ser informatizado Duram dias ou semanas Pode ser interrompido e reiniciado Duram segundos ou minutos Deve ser executado como uma transação ininterrupta Vários atores humanos primários Usualmente um ator humano primário e eventualmente alguns secundários

7 Exemplo

8 Características de casos de uso de sistema como requisitos de alto nível... Sessão indivisível Interativo Resultado consistente Essencial Alto nível Fronteira de sistema definida

9 3.3.1 Sessão indivisível Deve iniciar e terminar sem sofrer interrupção. EBP (Elementary Business Process Processo Elementar de Negócio.

10

11 Porém, isso está correto

12 3.3.2 Interativo Deve existir um ator para interagir com o sistema. Processos internos do sistema não são casos de uso, não importa quão complexos sejam.

13 3.3.3 Resultado consistente Produz uma alteração de estado consistente e completa na informação. Apresenta uma informação completa que tenha significado como objetivo de negócio para algum ator.

14 Por isso

15 3.3.4 Essencial Essencial: seu detalhamento independe da tecnologia usada. Real ou concreto: é pensado para uma tecnologia específica de interfaceamento.

16 Modelos essenciais São mais flexíveis, deixando mais opções em aberto. São mais capazes de acomodar mudanças na tecnologia. São mais robustos do que as representações concretas porque mais provavelmente permanecerão validos caso haja alguma mudança na tecnologia de implementação.

17 3.3.5 Alto nível Sua descrição se dá apenas pelo seu nome.

18 3.3.6 Fronteira do sistema Representa os limites do sistema computacional.

19 3.4 Como encontrar casos de uso de sistema no modelo de negócio Candidatos a atores de sistema no modelo de negócio:

20 Diagramas de atividades podem indicar casos de uso de sistema

21 Pontos a serem observados Atividades que necessariamente são executadas em sequencia pertencem ao mesmo caso de uso de sistema. Se uma atividade não precisa iniciar imediatamente após outra então elas pertencem a casos de uso de sistema diferentes. Se o papel do ator vai ser automatizado, então suas atividades passam a ser processos internos do sistema.

22 Transições de estado em diagramas de máquina de estado são casos de uso de sistema potenciais

23 Resultado

24 Atividade 4 Identifique atores e casos de uso de sistema a partir do modelo de casos de uso de negócio, diagrama de atividades e diagrama de máquina de estados.

25 3.5 Requisitos Identificar casos de uso de sistema é a principal atividade da disciplina de requisitos do UP.

26 3.5.1 Eliciação de requisitos Casos de uso = requisitos funcionais Anotações = requisitos não funcionais Regras de negócio Requisitos de qualidade

27 Anotações no diagrama

28 Anotações no caso de uso (só com ferramenta CASE)

29 3.5.2 Eliciar requisitos não é design! Princípio da psicanálise

30 3.5.3 Desafio dos requisitos Descobrir Comunicar Lembrar Gerenciar mudança

31 3.5.4 Requisitos funcionais evidentes e ocultos Evidente: usuário está ciente da ação. Oculto: interno ao sistema.

32 3.5.5 Requisitos não funcionais Restrições lógicas: Regras de negócio restrições sobre as funções. Restrições tecnológicas: Questões de qualidade eficiência, usabilidade, acessibilidade, segurança, etc. Um requisito não especifica como a restrição vai ser implementada, ele apenas a exige.

33 3.5.6 Requisitos não funcionais permanentes e transitórios É uma decisão sobre a qualidade da adaptabilidade. Permanente: Mais barato implementar, mais caro manter. Transitório: Mais caro implementar, mais barato manter.

34 3.5.7 Requisitos obrigatórios e desejáveis No caso dos funcionais, define prioridade No caso dos não funcionais, flexibiliza restrições. Escala MoSCoW: Must Should Could Would

35 3.5.8 Requisitos suplementares São qualidades gerais do sistema Modelos: FURPS+ Funcionalidade, usabilidade, confiabilidade, performance, suportabilidade. ISO características subdivididas em 42 subcaracterísticas.

36 Exemplo 25010

37 Aplicação do exemplo a Livir

38 3.6 Modelo conceitual preliminar Apoio ao levantamento de requisitos. Modelo de classes simplificado (apenas nomes das classes e associações simples). Extraído a partir dos nomes dos casos de uso de sistema.

39

40

41 Para ajudar a saber se CRUDs devem ser definidos: Para cada conceito do modelo preliminar verifique se existem operações que criam (alteram e deletam, se for o caso) e consultam os dados representados pelo conceito. Se faltar alguma é sinal de que pode ser necessário um novo caso de uso. Se o conceito for simples (independente) pode ser o caso de criar um caso de uso CRUD.

42 Resultado

43 Por fim, verificar se existem relatórios necessários mas não cobertos por nenhum caso de uso

44 3.7 O processo visto aqui

45 Atividade 5 (se o tempo permitir) Elabore um modelo conceitual preliminar baseado no diagrama de casos de uso de sistema. Identifique novos casos de uso (possivelmente CRUD) para conceitos que não são suficientemente tratados pelos casos de uso existentes no modelo atual.